RE: Authentication Methods for LDAP - last call

[RL Bob Morgan <Bob.Morgan@Stanford.EDU>]

> > There is no standards track specification for HTTP digest in 
> > SASL at this
> > time, therefore it is out of order to propose it as a 
> > replacement.
> 
> Why does it need to be a SASL mechanism? As far as I could tell, section 8.1
> did not say "here's how to use any SASL mechanism with LDAP". It said
> "here's how to use CRAM-MD5 with LDAP", and mentioned it by name.
> 
> My counterproposal said, equivalently, "here's how to use Digest with LDAP",
> and Digest is standards track. Isn't that enough to satisfy the legalists?
> It provides all the same function as CRAM-MD5 in this context, so whether it
> has been officially dubbed "SASL" seems arbitrary. 
> 
> (I actually don't see what qualifies the current proposal for CRAM-MD5 in
> LDAP as "SASL".)

Application-level security mechanisms get added to LDAP by being defined
as SASL mechanisms.  CRAM-MD5 is registered with the IANA as a SASL
mechanism, as specified in RFC 2222. 

RFC 2195 defines CRAM-MD5.  While it does not mention SASL (since SASL is
RFC 2222, it couldn't), it does define CRAM-MD5 for use in the IMAP
AUTHENTICATE and POP3 AUTH commands.  The IMAP AUTHENTICATE command is the
standards precursor to the SASL framework and is (by hindsight) the
application of SASL to IMAP.  While IMHO it would be much better to have
an RFC specifically defining CRAM-MD5 as a SASL mechanism, the definition
in RFC 2195 is entirely usable as is.

While the authmeth doc goes into detail about how to do CRAM-MD5/SASL with
LDAPv3, I think this text provides only clarification (and some
implementation warnings like not reusing challenge strings); that is,
reading RFCs 2251, 2222, and 2195 is enough to produce an interoperable
implementation of this mechanism. 

I don't think the same can be said of RFC 2069.  Your proposed text is as
far as I can see an interpretation of how to apply the same basic ideas to
a SASL security mechanism, but is it complete and definitive?  Should the
"stale" and "algorithm" fields be dropped, for example?  Are there other
things lost or added in the translation?  Do any of these affect the
security properties of the scheme?  Should any of the other contributors
to RFC 2069 and its successor docs be consulted on these issues?

Your proposed text refers to draft-ietf-http-authentication-01.txt (I see
-02 in the I-D archive).  I don't know the status on this doc but it's too
late IMHO to be basing the LDAP authmeth doc on another doc that's still a
draft.

It's the time that it would take to clean up all these loose ends, and
make Digest a fully-specified SASL mechanism, that has people concerned
(including me).  It might not be a year, but the authmeth is long overdue
already, and is holding up progress on all other LDAP docs.

 - RL "Bob" Morgan
   Stanford