Subject: RE: Issues with current authmeth draft.

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 May 2003 09:17:07 -0700

At 08:31 AM 5/12/2003, John McMeeking wrote:
>First, I doubt that Digest-MD5 with a LDAP DN (either as a authentication
>id or as an authorization id) would often be using a DN provided directly
>by a user.

YES!  DIGEST-MD5 is intended to be used where the user's credential
is a short user name and a password.

>I would expect its use to be more likely in one of these
>scenarios:
>
>1) An application is configured with a bind DN to use.  For this purpose, I
>think it would be reasonable if some standard or directory vendor supplied
>tool generated the proper normalized DN required for Digest-MD5.  This
>might be a wrapper around a Generate Digest-MD5 UserName extended request.

Then the application should use a mechanism intended for use
with DNs, like simple bind over TLS.

>2) An application authenticates to LDAP by first doing a search for
>(&(mail=xxxx)(objectclass=person)) and then issuing an LDAP bind request
>with the returned DN and the user entered password.  For this purpose, a
>standard algorithm, the above extended operation, or an operational
>attribute, could be used.

Requires the directory to be searchable and, to some degree, readable
by anonymous users.  Very bad.

>See additional comments marked <JAM>.
>
>I'll have to refresh my memory on the stringprep part.  If that turns out
>to require defining a DN normalization algorithm, or defining supporting
>extending operations, it might be more appropriate to address this type of
>item in a separate RFC.

Or just to say that simple bind with TLS, not DIGEST-MD5, is
applicable to applications attempting to authenticate with
credentials consisting of an LDAP DN and password.

>John  McMeeking
>
>
>                                                                                                                                 
>                      "Kurt D.                                                                                                   
>                      Zeilenga"                To:       John McMeeking/Rochester/IBM@IBMUS                                      
>                      <[email-masked]        cc:       "Ramsay, Ron" <[email-masked]>, [email-masked], "Mark     
>                      g>                        Ennis" <[email-masked]>                                                   
>                                               Subject:  RE: Issues with current authmeth draft.                                 
>                      05/12/2003 09:52                                                                                           
>                      AM                                                                                                         
>                                                                                                                                 
>                                                                                                                                 
>
>
>
>
>At 09:52 AM 5/12/2003, Kurt D. Zeilenga wrote:
>>With respect to DIGEST-MD5:
>>
>>1) If only the authentication mechanism is used (not data integrity or
>>confidentiality), it provides a bind mechanism that protects the password
>>without the need to establish a secure connection.  Also, LDAP DNs are a
>>natural choice for a user name when authenticating to a LDAP directory.
>>>From that perspective, I would like DIGEST-MD5 to allow the user name to
>be
>>a bind DN.
>
>There are few problems here.
>
>First DIGEST-MD5 security considerations encourage server implementors
>to store the A1 hash, not the clear text password.  For DIGEST-MD5 to
>work as intended, the client MUST provide the authentication identity
>is the form which the server used in generating the A1 hash.  There
>is no canonical DN textual string representation.
>
>Secondly, when DIGEST-MD5 is revised, the client and the server will
>be required to "stringprep" the username according to an algorithm
>specified in the DIGEST-MD5.  There will be some LDAPDNs which will
>not pass this stringprep and others which would be mangled.  One would
>have to define an algorithm for encoding LDAPDNs into DIGEST-MD5
>usernames and then require servers decode these for subsequent
>processing.
>
>Third, this would make LDAP's use of DIGEST-MD5 inconsistent with
>the general use of DIGEST-MD5, yielding it impossible for a
>multi-protocol application to consistently use the mechanism.
>
><JAM>
>Technical problems aside (not to trivialize them), I don't see where a
>predefined "LDAP DN" realm introduces any such problems.  This realm would
>only be used by application that are designed to authenticate using a LDAP
>DN, but want the additional password protection.  The multi-protocol
>application can use the appropriate realms.
></JAM>
>
>>One way to do that might be to define a standard realm name
>>that LDAP servers support, for example "RFC2253 LDAP DN".
>
>This would defeat the purpose of realms in DIGEST-MD5.
>
><JAM>
>I see this exectly the opposite way.  The purpose realm is to allow the
>application to chose which relam it uses and provide a hint to the user
>what username would be appropriate.  I do not intend that an LDAP server
>would support only this "LDAP DN" realm.
></JAM>
>
>>This would provide a standard way for clients to take advantage of
>DIGEST-MD5 for
>>password protection not offered by simple bind.  The mapping from
>>authentication id to authorization id is trivial.
>>
>>2) In the general case of using password based authentication to LDAP,
>with
>>a "user registry" that may, or may not, be the directory, the user name
>can
>>be most anything and the authentication id can be thought of as
>"<username>
>>in <authentication realm>".  For servers that have an access control
>>mechanism, the server must have some means of mapping the authentication
>id
>>to an authorization id.  And that is left to the server.  I'm fine with
>>that.
>>
>>If we look at authentication id with other mechanisms:
>>
>>GSSAPI:  The authentication id is based on a Kerberos principal name
>>([email-masked]).  Using the general form I described above:
>>"<kerberos-principal> in <all Kerberos realms>".
>>
>>EXTERNAL: Some folks tend to think of the authentication id as the
>>certificate subject DN, which is something LDAP folks are comfortable
>with.
>>But as I understand it, the subject DN really should be used in
>association
>>with the issuer DN.  So the authentication id is more properly something
>>like "<subject-dn> in <certificates issued by issuer-DN>", which isn't a
>DN
>>at all.
>>
>>simple bind:  could be expressed as "<bind-dn> in <RFC2253 LDAP DN>"
>>
>>Looked at this way, I'd say RFC2829 over-emphasizes authorization id,
>
>That I would agree with.  The purpose of SASL authorization identity
>strings are to support identity assumption (proxy authorization).
>
>>and
>>neglects the use that of LDAP DN as a natural choice for user names when
>>authenticating to a LDAP directory.  I suspect it would be rare for a
>>client to know what authorization id to specify, and it is likely that a
>>server would require the user name to be the same id the server would
>>generate internally.
>
>I think we put too much in "LDAP DNs are natural" line.  They aren't.
>Users shouldn't have to know their DN.
>
><JAM>
>I agree that users shouldn't know what their DN is, and for the
>applications I deal with that use simple binds, the user doesn't know their
>DN.  However, it is natural for applications to use DNs.
></JAM>
>
>Kurt

---

From: Mark Ennis <[email-masked]>
Date: Tue, 13 May 2003 09:24:29 +1000

Kurt,

All the introductory text in RFC2829 and [authmeth] indicate that the 
reason for introducing and, in [authmeth] case, requiring DIGEST-MD5 is 
for security considerations relating to protecting passwords from 
eavesdropping. The only mention of non-LDAPDN authentication identities 
in the early parts of these documents are in reference to using these 
non-LDAPDN identities as authorization identities for backward 
compatibility with non-LDAP authentication mechanisms. You are 
suggesting DIGEST-MD5 and other SASL mechanisms were introduced for 
other than reasons related to security considerations and yet all the 
text in the documents introducing these mechanisms into LDAP indicate 
the reasons are security related and for backwards-compatibility only.

- Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 May 2003 17:00:52 -0700

At 04:24 PM 5/12/2003, Mark Ennis wrote:
>All the introductory text in RFC2829 and [authmeth] indicate that the reason for introducing and, in [authmeth] case, requiring DIGEST-MD5 is for security considerations relating to protecting passwords from eavesdropping. The only mention of non-LDAPDN authentication identities in the early parts of these documents are in reference to using these non-LDAPDN identities as authorization identities for backward compatibility with non-LDAP authentication mechanisms.

Since RFC 2829 is a largely a SASL profile, I wouldn't expect it
to discuss LDAPDNs except in contexts where SASL allows application
profiles to use application specific forms of identities.

However, RFC 2829 is fairly clear when it states (very early):
   An authentication identity is the name presented in a credential.

   There are many forms of authentication credentials -- the form used
   depends upon the particular authentication mechanism negotiated by
   the parties.  For example: X.509 certificates, Kerberos tickets,     
   simple identity and password pairs.  Note that an authentication     
   mechanism may constrain the form of authentication identities used   
   with it.

In DIGEST-MD5 clearly constrains the form of the authentication
identity to a simple identity string, a user name.

>You are suggesting DIGEST-MD5 and other SASL mechanisms were introduced for other than reasons related to security considerations and yet all the text in the documents introducing these mechanisms into LDAP indicate the reasons are security related and for backwards-compatibility only.

I am suggesting that RFC 2829 recommends implementation of
simple bind over TLS to support DN/password credentials.
But it requires implementation of DIGEST-MD5 to support
username/password credentials.

However, regardless of this, it should be clear that stuffing
LDAPDNs into usernames is not a path to interoperability nor
security.  Matching issues alone should be enough to kill that
idea.  We cannot morph DIGEST-MD5 into something its not, that
breaks mechanism commonality between application protocols.
We needed to use each mechanism in a manner consistent with
its specification.

Going forward, it would be much better to clarify that simple
+TLS is to be used for DN/password credentials and DIGEST-MD5
(or PLAIN+TLS) be used for username/password credentials.

I note that due to the specification and interoperability problems
with DIGEST-MD5 (not just with LDAP), I would not be opposed to
changing the mandatory-to-implement authentication mechanism
from DIGEST-MD5 to simple+TLS.

Kurt

PS: I was once suggested in an I-D how one could stuff DNs
into DIGEST-MD5 credentials, it got no where.  See LDAPEXT
archives.