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

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

Well, OK, Kurt. But is there acceptance of this position on this list? Or, is there opposition to this position on this list?

?

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, 19 August 2003 13:24
To: Ramsay, Ron
Cc: Mark Ennis; Alexey Melnikov; LDAPBis WG
Subject: RE: Comments about draft-ietf-ldapbis-authmeth-05.txt


At 07:18 PM 8/18/2003, Ramsay, Ron wrote:
>Let me propose a way forward.

I suggest you write an individual I-D detailing your
technical proposal.

Kurt,  LDAPBIS co-chair

>The common namimg attributes used in DNs (c, l, o, ou, cn, dc) all have caseExactMatch as their matching rule. Therefore, DNs using these attributes can all be expressed in lowercase with extra spaces removed. So let's say that a realm of "canon@ldap" means that all DNs have been mapped to this form. For this realm, the A1 hash may be precomputed by the server. A client using this realm must use the mapped form of the DN to compute hashes.
>
>If the realm is, say, "other@ldap", the A1 hash cannot be precomputed so the server must use the DN as presented by the client to form the hash. The hash cannot be precomputed.
>
>For any other realm, the username may not be a DN or may not be restricted as above. How it is processed is a local matter.
>
>Ron
>
>-----Original Message-----
>From: Mark Ennis [mailto:mark.ennis@adacel.com]
>Sent: Tuesday, 19 August 2003 11:59
>To: Ramsay, Ron
>Cc: Kurt D. Zeilenga; Alexey Melnikov; LDAPBis WG
>Subject: Re: Comments about draft-ietf-ldapbis-authmeth-05.txt
>
>
>Ron,
>
>You're right about storing the A1 hash being a problem without requiring 
>some canonical form for the LDAPDN, which is a non-trivial issue.
>
>My understanding of the realm is that it exists to identify different 
>authentication services available to the server. The LDAP directory, 
>using LDAPDN in the username, could be viewed as one of these 
>authentication services. Where the realm is used for other purposes by a 
>server, the use of it I proposed would potentially cause problems.
>
>- Mark.
>
>Ramsay, Ron wrote:
>> 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
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>> 
>> 
>> 
>>