Re: authmeth: removal of DIGEST-MD5

"Roger Harrison" <[email protected]> Wed, 19 Oct 2005 17:27:52 -0600
Newsgroups gmane.ietf.ldapbis
Message-ID <[email protected]>
Hallvard, 

I've added this new section to authmeth-17 based on your suggestion. 
I'd appreciate comments and feedback prior to my submitting authmeth-17
on Friday. 

5.2.2. SASL Semantics Within LDAP 

Implementers must take care to ensure that they maintain the semantics
of SASL specifications when handling data that has different semantics
in the LDAP protocol. 

For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
utilizes realm and username values ([DIGEST-MD5] section 2.1) which are
syntactically simple strings and semantically simple realm and username
values. These values are not LDAP DNs, and there is no requirement that
they be represented or treated as such. Username and realm values that
look like LDAP DNs in form, e.g. <cn=bob, dc=example,dc=com>, are
syntactically allowed, however DIGEST-MD5 treats them as simple strings
for comparison purposes. To illustrate further, the two DNs
<cn=Bob,dc=example,dc=com> (upper case B) and <cn=bob,dc=example,dc=com>
(lower case b) are equivalent when being compared semantically as LDAP
DNs because the cn attribute is defined to be case insensitive, however
the two values are not equivalent if they represent username values in
DIGEST-MD5 because [SASLPrep] semantics are used by DIGEST-MD5. 

Thanks, 

Roger

>>> Hallvard B Furuseth <[email protected]> 10/13/05 1:27 pm >>>
Roger Harrison writes:
> Based on the comments to the WG over the past several days, I believe
> that authmeth should only reference DIGEST-MD5 in historical terms.

You should probably keep much of the DIGEST-MD5 text on authmeth-15
page 16 and generalize it to talk about SASL.

> The Simple Mechanism Security Considerations currently state:
>
> The name/password authentication mechanism of the simple Bind method
> discloses the password to the server, which is an inherent security
> risk. There are other mechanisms such as DIGEST-MD5 that do not
disclose
> the password to the server.
>
> I would like to replace this reference with DIGEST-MD5 with another
> mechanism (it does not need to be normative) that would not disclose
> the password to the server.  Suggestions?

CRAM-MD5 seems to be the only alternative mechanism which is widely
enough deployed to suggest now.  That mechanism apparently has its own
problems, though.  So I suggest to keep the DIGEST-MD5 reference.

--
Hallvard