RE: Compromise Authentication Proposal

[Paul Leach <paulle@microsoft.com>]

> -----Original Message-----
> From: mcs@netscape.com [mailto:mcs@netscape.com]
> Sent: Tuesday, October 06, 1998 6:47 PM

Thanks for the comments. Responses interleaved below.

> Subject: Re: Compromise Authentication Proposal
> 
> *** 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.

I had a section on confidentiality. It was real simple. The way to make it
simple is to hard-wire the cipher. Chris and the TLS experience convinced me
one needs to be able to negotiate the cipher. That got to be less simple. I
didn't want working out the kinks to hold up what was already overdue, and
which was not supported by CRAM-MD5 anyway.

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

Yes. It says that the client sends an empty "initial response".

 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.

This is the correct approach, IMO -- it belongs in the SASL profile for
LDAP, which is essentially what the ldap-auth-methods draft is: the place
that interactions between the authentication protocol and the application
protocol are defined.

> 
> 3) Are there any serious restrictions on what a username can 
> look like?

No.
 
> Could it be an LDAP DN?

Yes.

>  Of course for compatibility with other
> protocols such as IMAP a DN might be a bad choice.

Indeed.

> It would be helpful if this document were clearer about how usernames are
to be used.

I'm not sure how.

This is a layering issue, and a system issue. One of the ideas behind Digest
(and CRAM-MD5 before it) was that Digest could be used as a common mechanism
for many application protocols. Obviously, each application protocol can not
dictate what the form of user names is independently of the authentication
protocol. First, because the application protocols could conflict. Second,
because all the app servers may want to use a common authentication service,
which won't be able to map lots of different user names for the same person
onto one account. Third because users won't like have to have lots of
different user names. Finally, because the authentication protocol may
impose requirements.

That all said, the Digest protocol imposes no restriction on what's in a
user name. It's just text. It'll take whatever you give it and throw it into
the MD5 hash. As long as all clients and server use exactly the same form
for the user name, it'll all work fine.

However, some implementation may have lots of problems with being told what
the form of a user name is. To take an old example that is no longer
commercially significant, Multics wanted user names to be of the form
"user.project". That's what the system access control mechanism demanded.

Bottom line: if Digest is being used to authenticate to a single application
server with a single application protocol, then the form of user names can
be completely up to the application protocol. However, if the server is
participating in a system of many servers running different application
protocols and they try and make the user's life simpler by sharing a common
authentication service, then the authentication service has to be able to
pick the form of user names. I think we should allow both approaches.

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

There is an RFC with all of these. 2052, I think. I'll find it and put in a
reference.

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

Bug. But that section needs to be fixed.

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

First, as you point out below, they don't have to store the hash. 

Also, there's a HUGE advantage to the way it works -- I can use the same
password in different realms without having to trust all those realms to not
act as a client authenticate as me to any of them. One of the biggest
problems with password systems with many untrusting realms is that you would
have to choose a different password for each of them, making it very hard to
remember all of them. For an internet protocol in today's world of a huge
number of password protected sites, I think this it is intolerable to have
to pick a different password for each site to be secure.

A couple of things can be done to ameliorate the problem of storing the
hash. First, realms: the realm can be associated with the password store,
rather than the server.

Secoind, one may choose a form of user name _used to authenticate with_ that
does not have to change when the name of the user's entry in the directory
changes. This form can be a searchable attribute on the user's entry. This
means that moving the user's entry in the directory doesn't change the hash.

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

That choice is always available.

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

I tired to catch all of them. Sorry.

Paul