Re: Compromise Authentication Proposal

[mcs@netscape.com (Mark C Smith)]

Paul Leach wrote:
> 
> At Chicago, there was conditional concensus about using Digest as the MTI.
> It was conditional upon a digest/SASL spec being delivered "in a couple of
> weeks". It took a little longer than that, but I believe the precondition
> has now been met, and still seems to be relevant.
> 
> After a private conversation with Tim Howes, he suggested I "call the
> question". So here goes:
> 
> Are there any objections to making Digest/SASL the Mandatory-to-Implement
> non-plaintext password mechanism? If so, what are they?

No, although I have a bunch of relatively minor comments on the current
draft (see below).

> Are there any objections to making Digest/SASL the only
> Mandatory-to-Implement mechanism? If so, what are they?

If by this you mean "we plan to replace all occurrences of CRAM-MD5 with
DIGEST-MD5" in the LDAP Authentication Methods draft
(draft-ietf-ldapext-authmeth-02.txt), then I have no objections.  I
would like to see LDAP simple bind over TLS remain as a SHOULD for LDAP
though.


*** Start of detailed comments on draft-leach-digest-sasl-00.txt:

1) Section 1 and section 3.1 seem to be in conflict with respect to
support for confidentiality.  I don't see anything in the document that
provides confidentiality of messages other than those for the password
exchange itself, so I think section 1 is in error.

2) Section 2.1.1 (Step One) indicates that the server begins the SASL
exchange, but in LDAP (and IMAP for that matter I think) the client
actually needs to begin the exchange.  Is this issue covered in the SASL
RFC?  Either way, I'd like to see a note added to this document or to
the LDAP auth. methods draft to make it clear how LDAP client/server
pairs will begin a DIGEST-MD5 exchange.

3) Are there any serious restrictions on what a username can look like? 
Could it be an LDAP DN?  Of course for compatibility with other
protocols such as IMAP a DN might be a bad choice.  It would be helpful
if this document were clearer about how usernames are to be used.

4) Section 2.1.2 (Step Two): somewhere we need to define the serv-type
for all the protocols we care about.  It would be nice to refer to
something like the IANA list of protocol names or URI prefixes or
something, but I see "www" is used for HTTP.  LDAP should use "ldap" of
course.

5) Section 3.6 (Man in the Middle): An algorithm called "md5-neg" is
mentioned but not defined in the document.

6) Section 3.9 (Storing Passwords): I don't really like the idea of
servers storing a hashed version of username:realm:passwd since
usernames and realms may change at times when passwords ideally don't. 
Storing such a hash means I can't use the same password store in
different realms or change user names without changing my  password as
well.  It also makes it impossible for a servers in different realms to
share the same password store directly.  However, I understand the
advantages (from a security standpoint) of storing the hash instead of
acleartext password, and believe that the choice of whether to store the
hash or a cleartext password is a policy decision that is best left up
to implementors and deployers.

7) Section 4 (Example): the last paragraph contains some non-ASCII
characters (probably "smart quotes" or something similar).

*** End of detailed comments on draft-leach-digest-sasl-00.txt.

-- 
Mark Smith
Directory Architect / Netscape Communications Corp.
My words are my own, not my employer's.  Got LDAP?