[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Issues with current authmeth draft.
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
> <Kurt@OpenLDAP.or cc: "Ramsay, Ron" <Ron.Ramsay@ca.com>, ietf-ldapbis@OpenLDAP.org, "Mark
> g> Ennis" <mark.ennis@adacel.com>
> 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
>>(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.
>
><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