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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:23 PM 3/9/2004, Hallvard B Furuseth wrote:
>> DIGEST-MD5 is LDAP's strong authentication mechanism
>> (which provides adequate data security services).  There is no
>> interop or security reason to mandate or recommend more (except
>> in limited cases, such as when Simple is to be used).
>
>While I like that TLS is optional, I don't buy this as an argument for
>it.

The argument is a) DIGEST-MD5 is good enough to be the
mandatory-to-implement authentication mechanism and
b) there only needs to be one mandatory-to-implement
authentication mechanism.

The reason why Simple+TLS is optional is simply due to
fact that once you've met the IETF requirements for
reasonable strong authentication mechanism and there doesn't
appear to much of a reason to require/recommend everyone to
implement yet another authentication mechanism.

I note that the WG did consider making Simple+TLS the
mandatory-to-implement strong authentication method, but
choose to stick with DIGEST-MD5.

>>> 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.

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

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.

>>>>  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.

Maybe we should just s/MAY/may/ (or s/MAY/can/) here.  That is,
just point out that implementations can support other implementations
but avoid discussing there applicability.  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.

>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.

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