Re: Comments about draft-ietf-ldapbis-authmeth-05.txt

[Alexey Melnikov <Alexey.Melnikov@isode.com>]

Ramsay, Ron wrote:

> Good point. I note that RFC 2831 also allows the empty string for the realm.
>
> But what about storing the password. The ideal would be to store the username/realm/password hash. But the username is a DN(?) and it doesn't have a canonical value.
Yep, this is a problem.

> Yet the value used to precalculate the hash must agree with the value that the client is going to use when connecting. Do you have any suggestions about this?
All implementation that I've seen store password in the clear (which 
arguably defeat one of the purposes of DIGEST-MD5). But let's disregard 
them for a second.

After talking to my co-workers about the issue, here are some 
recommendations:
One way to solve this would be to require usage of some canonical form 
when passing this data to DIGEST-MD5.
Clients SHOULD send canonical forms of DNs that are used as usernames. 
Servers SHOULD send canonical forms of DNs when they are used as realms.
When adding/modifying a secret in the server's password database, 
canonical form of DNs SHOULD be used.

When DNs are constructed/canonicalized, the following steps should be 
done to insure interoperability:

1). For a known attribute the canonical attribute name must be used (e.g. "cn" ==> "CN", "CommonName" ==> "CN").
2). draft-ietf-ldapbis-strprep should be used for values of attributes (if they are recognized). In particular, for case insensitive values case folding will be performed.
3). Insignificant Spaces in DN production must be removed. E.g. "CN= John,  OU  = PSO" will be converted to "CN=John,OU=PSO".


I suggest that some text about the issue should be included in 
draft-ietf-ldapbis-authmeth.

Alexey