RE: Issues with current authmeth draft.

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:16 AM 5/12/2003, John McMeeking 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.

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

>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
>(jsmith@mycompany.com).  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.

Kurt