Re: Applicability (Was: authmeth review notes [long])

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>At 01:23 PM 3/9/2004, Hallvard B Furuseth wrote:

>>>> BTW, MUST they support unauthenticated binds?
>>>
>>> I believe consensus is that the unauthenticated mechanism of the simple
>>> method is elective, (...)
>>
>>Then this is wrong:
>>
>> LDAP server implementations MUST support the anonymous mechanism of
>> the simple Bind method.
> 
> No, that's talking about the anonymous mechanism, not the
> unauthenticated mechanism.
> 
> Simple bind support three mechanisms: anonymous, unauthenticated,
> and authenticated.  While the first two both result in an anonymous
> associations, they are different mechanisms.

Oh.  The problem is, the 'anonymous mechanism' of Simple Bind isn't
defined anywhere, so it can be read eather as your definition or as
anonymous binds.  I see no reason to define it either, just to be able
to use it here.  So I suggest again:

>> It should be 'support anonymous binds with...' (according to section 6),
>> or 'anonymous authentication via the simple Bind method with no name or
>> password'.

Also, this text from your suggestion must be fixed in the same way:

  LDAP implementations which support any authentication mechanism
  (other than anonymous mechanism of the simple Bind method) MUST
  support the DIGEST-MD5 (...)

> I think we just need to be more precise when it comes to
> distinguishing mechanisms from outcomes.  One could say
> that the use of SASL/ANONYMOUS mechanism is an "anonymous
> bind".  But it is a different mechanism from the simple
> method's anonymous mechanism.

My suggested texts do refer to anonymous simple bind, so they exclude
SASL/ANONYMOUS.

>>>>>  Implementations MAY support additional authentication mechanisms of
>>>>>  the simple and SASL bind methods, and/or mechanisms of other bind
>>>>>  methods.  Some of these mechanisms are discussed below.
>>>>
>>>> I think this paragraph can be dropped.
>>>
>>> I think it is important to say that other mechanisms are elective.
>>
>>If you mean _all_ other mechanisms, the paragraph doesn't say that.
>>It just says there are elective mechanisms.  But I agree such a statement
>>would be nice.  As well as a similar statement for basic TLS features.
> 
> I rather not say _all_ other mechanisms, as some mechanisms have
> very limited applicability (and some other mechanisms may actually
> be deprecated (for very good reasons)).  So, I guess, it may be best
> not to actually say other mechanisms are elective.

This should cover both needs: 'Of the mechanisms defined in this
document, only the above mechanisms are mandatory'.

> Maybe we should just s/MAY/may/ (or s/MAY/can/) here.

Also an improvement over your original text.

> It might be appropriate
> to note that implementors considering supporting additional mechanisms
> should carefully consider their applicability to LDAP and directory
> applications they intend to support.

I don't understand.  Are you talking about a security consideration, or
something else?  Why and how would they consider it?

>>These seem inconsistent to me:
>>
>>>>>  LDAP implementations which support any authentication mechanism
>>>>>  (other than anonymous mechanism of the simple Bind method) MUST
>>>>>  support the DIGEST-MD5 [RFC2831bis] mechanism of the SASL Bind
>>>>>  method (as detailed in Section X).
>>>>
>>>> I preferred the authmeth-10 text which only required this of servers,
>>>> not "implementations".  It should be OK to write thin clients.
>>>
>>> I believe similar concerns were previously discussed.  I believe
>>> consensus supports the requirement as applying to both clients and
>>> servers.
>>
>>Above, clients that do not use DIGEST-MD5 must support it anyway.
>>Below, clients that do not use simple/anon need not support it.
> 
> Because the requirements address different concerns.
> 
> The former requirement is to ensure that all implementations
> share a strong authentication mechanism.

If this is to satisfy some formal IETF requirement that they must share
such a mechanism, I'm with you.  Otherwise I still don't see the
difference between clients that don't need DIGEST-MD5 and clients that
don't need discovery (below).  Also, that all implementations 'share'
DIGEST-MD5 doesn't mean that one can bind with DIGEST-MD5 to all servers
supporting it, for the reasons I meantioned before about DIGEST-MD5.

> The latter requirement is to ensure that all servers provide
> adequate support for discovery.  Clients are not generally
> required to use discovery (or use simple/anon with discovery),
> but servers are generally required to support discovery (if
> so configured).
> 
>>>>>  LDAP server implementations MUST support the anonymous mechanism of
>>>>>  the simple Bind method.
>>>>
>>>> You changed this from "implementations" to "server implementations".
>>>> I guess I agree with that.
>>>
>>> This is because servers need to support various initial operation
>>> sequences discussed in [Protocol].  However, clients need not support
>>> all of these.  For instance, a client is free to initially request
>>> DIGEST-MD5 authentication.  Such a client need not support the
>>> anonymous mechanism.  (...)

-- 
Hallvard