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

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

Kurt D. Zeilenga writes:
>At 10:09 AM 3/9/2004, Hallvard B Furuseth wrote:

>> Other protection, like IPSec, ldap://localhost/, or a Unix filename
>> socket, is fine.
>
> I assume you meant ldaps://.

For the filename socket?  Yes, ldaps:// sounds familiar.

>> BTW, I can't find any requirement that TLS be supported.
>
> It's not.

Sorry, I meant 'no requirement in any circumstance', like required when
you implement Simple Bind.  But you have already addressed that.

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

- cannot be used if the server-side password store is maintained
  encrypted by the OS, so there are no cleartext passwords to
  make MD5 digests from.

- is compromised if the store of MD5-digested passwords is compromised.
  (Or if just one such digested password is compromised?  I don't
  remember.)  If that happens, one must rehash the entire password
  store.  That means one must either maintain a cleartext password
  store, which may be unacceptable, or all users must change their
  passwords, which can be from expensive to near impossible for large
  organizations.

Since I don't actually want a change, this is obviously not important to
me, but it might be important to those who feel DIGEST-MD5 as an
argument for optional TLS.

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

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

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


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.

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