Subject: Re: Compromise Authentication Proposal

From: [email-masked] (Mark C Smith)
Date: Tue, 06 Oct 1998 18:46:30 -0700

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?

---

From: Chris Newman <[email-masked]>
Date: Tue, 06 Oct 1998 22:42:27 -0700 (PDT)

> something, but I see "www" is used for HTTP.  LDAP should use "ldap" of

SASL explicitly references the GSSAPI service type registry.  It's at:

<http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names>

I think the Digest spec should reference this as well.  This leverages the
service names used by Kerberos, and has an authentication focus.  It would
be bad if Kerberos and Digest used different service name registries, as
the higher level API would then have to pass down two parameters rather
than one.

There are actually two other service registries -- the one for WKS records
in DNS, and the one for domain name naming conventions.  The WKS record
registry is full of junk, so I wouldn't want to use that.  The domain name
naming convention has a different purpose (user friendly names), rather
than the purpose of dividing services into separately manageable groups.

		- Chris

---

From: [email-masked] (Mark C Smith)
Date: Tue, 06 Oct 1998 18:46:30 -0700

---

From: Chris Newman <[email-masked]>
Date: Tue, 06 Oct 1998 22:42:27 -0700 (PDT)

- Chris