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

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

I agree that Kurt seems to be going too far in trying to exclude LDAP DNs.

I note that SASLprep is applied by the client, that LDAP DNs are UTF-8 encoded and that, therefore, there is no problem as long as the server does not attempt to change the DN (username).

I cannot see how the A1 hash can be stored unless the client is also required to somehow canonicalise the DN. SASLprep is not enough.

Using the realm to select a behaviour sounds interesting but may affect current implementations.

Ron

-----Original Message-----
From: Mark Ennis [mailto:mark.ennis@adacel.com]
Sent: Tuesday, 19 August 2003 09:05
To: Kurt D. Zeilenga
Cc: Ramsay, Ron; Alexey Melnikov; LDAPBis WG
Subject: Re: Comments about draft-ietf-ldapbis-authmeth-05.txt


Kurt,

It still seems to me as though you are the one re-engineering LDAP and 
its application of DIGEST-MD5. I have yet to come across anything in the 
LDAP or SASL specifications which preclude the use of distinguished name 
strings in the DIGEST-MD5 username value, except possibly the 
normalisation of the username field being proposed in the SASLprep work. 
After all, we should not forget that an LDAPDN *is* an UTF8 string in 
the protocol, and provided it is not mangled (normalised or SASLprep'd) 
prior to the server receiving it, it can then be interpreted (and 
matched) as a LDAPDN. Normalisation should occur prior to generating the 
digests at both server and client to produce consistent results and 
allow the possibility of storing the A1 hash rather than cleartext 
passwords.

I agree that the LDAP specifications do not preclude the use of 
non-LDAPDN strings in the username field, allowing interaction with 
(possibly shared) back-end authentication services. I see no particular 
problem with using the realm to distinguished how the username field 
should be interpreted.

- Mark.

Kurt D. Zeilenga wrote:
> Ron,
> 
> It still sounds like you are trying to re-engineer LDAP and its
> application of DIGEST-MD5.  DIGEST-MD5 is not designed to support
> DN-based credentials.  As we have two mechanisms which are designed
> to support such, it seems far more appropriate for those who want to
> use DN-based credentials to simple use one of existing mechanism
> than for us to try to hack the LDAP TS to support DN-based credentials
> in DIGEST-MD5.
> 
> At 11:18 PM 8/17/2003, Ramsay, Ron wrote:
> 
>>I agree that we cannot canonicalise DNs (though I disagree that cn=foo and CN=FOO are different usernames). The canonicalisation was proposed to obviate the necessity of storing passwords in the clear.
>>
>>I also think the authmeth has the power to profile Digest-MD5.
> 
> 
> There are many reasons why we cannot do such, most have been previously
> discussed on the list.   However, I note that one of the reasons is that
> it will likely interfer with proxying of DIGEST-MD5 authentication
> requests to a "shared back-end authentication service" and/or
> implementing an LDAP-accessible "shared back-end authentication
> service".
> 
> 
>>If we simply state
> 
> 
> It's not so simple.  
> 
> 
>>1. The DN provided by the client in the bind is to be used (byte-for-byte) to calculate the required hashes, and
>>2. The realm provided by the server is to be used (byte-for-byte) to calculate hashes
> 
> 
> First, I note, that servers are required to use all usernames and realms
> byte-for-byte.  What's new to LDAP is that servers are to treat the
> username/realm as DNs in interactions with the (possibly shared)
> back-end authentication service.  Many of today's servers don't do that and
> those that do don't do it any standard way (as there is no formal
> specification of how to do that).  It is likely that any change in this
> area would cause interoperability problems, some of which likely have
> significant security considerations.
> 
> To standardize such interaction would require engineering work on how to
> deal with the problem that dnMatch(dnString, SASLprep(dnString)) may be
> FALSE for some representations of a DN.  This implies that one either
> needs to restrict users to a subset of DN representations or apply a transform
> such that dnMatch(dnString, SASLprep(transform(dnString))) is TRUE for all
> possible dnStrings.  Both alternatives are problematic.
> 
> 
>>then I think Digest-MD5 can be used in LDAP, but the passwords have to be stored in-the-clear.
> 
> 
> I do not think it appropriate for authmeth to suggest DIGEST-MD5 passwords
> are to be stored in-the-clear when DIGEST-MD5 was specifically designed
> to avoid such.
> 
> 
>>The realm suggestions of Alexey can also be added to the profile. (Is there any reason for requiring that the realm not be ""?)
>>
>>Ron
>>
>>-----Original Message-----
>>From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>>Sent: Monday, 18 August 2003 02:17
>>To: Alexey Melnikov
>>Cc: Ramsay, Ron; LDAPBis WG
>>Subject: Re: Comments about draft-ietf-ldapbis-authmeth-05.txt
>>
>>
>>Below are few additional technical comments...
>>
>>Basically what you are asking is that we state additional requirements that
>>implementations canonicalize
>>       a) all usernames, or
>>       b) all usernames which look like string representations of DNs.
>>
>>Both require the specification of an algorithm to produce a canonical string
>>representation of a DN.  The latter, (b), requires a specification of which input
>>strings are/are not to be canonicalized.
>>
>>First, I note that it is not generally possible to produce a canonical string
>>representation of a DN solely based on input of a non-canonical string
>>representation. Minimally, applicable schema is needed.
>>
>>Second, both a) and b) will introduce additional interoperability problems with
>>significant security implications.  In particular, if an existing system were
>>to have to different users "cn=foo" and "CN=FOO", one of these users
>>would no longer be able to long in as both a) and b) would cause these strings
>>to be treated as representing the same user where today they are clearly two
>>different users.
>>
>>Hence, even if we had a canonicalization algorithm, it would be inappropriate
>>to specify it be used here.  We need to preserve current semantics.
>>
>>Kurt
>>
>>
>>
>>At 08:24 AM 8/16/2003, Alexey Melnikov wrote:
>>
>>>Kurt D. Zeilenga wrote:
>>>
>>>
>>>>At 08:15 AM 8/13/2003, Alexey Melnikov wrote:
>>>>
>>>>
>>>>
>>>>>Kurt D. Zeilenga wrote:
>>>>>  
>>>>>
>>>>>
>>>>>>At 06:14 AM 8/13/2003, Alexey Melnikov wrote:
>>>>>>    
>>>>>>
>>>>>>
>>>>>>>I suggest that some text about the issue should be included in draft-ietf-ldapbis-authmeth.
>>>>>>>
>>>>>>>      
>>>>>>
>>>>>>If authmeth says anything about DNs and DIGEST-MD5, it should say
>>>>>>that the DIGEST-MD5 username and realm fields are, per the DIGEST-MD5
>>>>>>TS,
>>>>>>    
>>>>>
>>>>>Can you point me to the section where DIGEST-MD5 says that.
>>>>>  
>>>>
>>>>The DIGEST-MD5 TS [RFC2831] defines a username to be the user's
>>>>name (account) in a realm where the realm is a collection of names
>>>>(accounts), both have the form of a simple string
>>>
>>>Kurt, can you please point me to a formal definition of "simple username".
>>
>>RFC 2831 does not use the term "simple username".  It uses the term "username".
>>I believe RFC 2831 is reasonable clear that a username is a simple string used
>>as a user (account) name.  "simple" here meaning that the syntax and semantics
>>of the string are simple.
>>
>>
>>
>>>>and are to be compared as simple strings.
>>>
>>>Fine, I don't disagree with that.
>>
>>>But DNs are used in simple bind. So it is quite logical to allow to use DNs in SASL as well.
>>>(And for implementation of other protocols with a login command that I know this is true.)
>>>
>>>So, if the server allows for DN form of usernames, the client should canonicalize a DN before passing it to the server to avoid interoperability problems. This is pretty much what my previous message suggested. I wasn't suggesting that the server should do that after receiving the username.
>>
>>How does the client determine whether the string entered by the user should or
>>shouldn't be canonized?  Is the client to canonicalize all strings which *look
>>like" DN string representations?  That obviously would break some usernames.
>>
>>
>>>The same is true for a realm. If the server is using DNs as realms, it should canonicalize it before sending to the client. The client must not do any canonicalization.
>>
>>And that would break some realms.
>>
>>Also, saying that the client should canonicalize DN strings would necessitate
>>defining a canonical string representation of a DN.  Note that it is not generally
>>possible to generate a canonical DN string based solely on the input of a DN string
>>
>>
>>>>DIGEST-MD5 defines the syntax of the username and realm using ABNF.
>>>
>>>Which is just a sequence of Unicode characters (no NUL allowed) represented in UTF8, nothing more.
>>
>>RFC 2831 says a username is a sequence of UTF-8 encoded Unicode characters
>>which represent a user name.
>>
>>RFC 2831 does not say a username is a sequence of UTF-8 encoded Unicode
>>characters which represent a DN.
>>
>>
>>>Although the format of authentication ids (usernames) is SASL mechanism specific, DIGEST-MD5 doesn't have any restrictions other than the one mentioned above.
>>
>>It would be, in my opinion, inappropriate for LDAP to place additional syntax
>>and semantics upon the DIGEST-MD5 username and realm.
>>
>>
>>>>There is a common definition, it's a "simple user name", e.g. an
>>>>account name.  A DN doesn't name a user, it names a entry.
>>>
>>>Of course I wasn't talking about an *arbitrary* DN, but only that represents a user or a group of users.
>>
>>My point is a "distinguished names" and a "user names" are different abstractions.
>>The username string represents a user name not a distinguished name.
>>
>>
>>>>>(On a related note, I've seen IMAP servers that have used DNs as usernames).
>>>>
>>>>Did these IMAP servers allow all equivalent string representations
>>>>of the DN which referred to a user to be used as equivalent usernames in
>>>>DIGEST-MD5?
>>>
>>>Frankly I don't know, I don't remember if the server was supporting DIGEST-MD5.
>>
>>Even if was PLAIN or CRAM-MD5, I seriously doubt the IMAP server treated all
>>equivalent DN strings representations (stuffed in a username field) as being
>>equivalent.
>>
>>
>>
>>>>If no, then obviously the IMAP server didn't support
>>>>DNs as usernames.  It supported usernames which **looked like** DN
>>>>strings.
>>>>
>>>
>>>Alexey
>>>
>>>
> 
> 
> 
>