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

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

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

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

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.

[Minor comments below:]

> > > syntactically and semantically not DNs.  They are syntactically
> > > and semantically simple usernames and realms, respectively.
> > >      
> > I disagree. DIGEST-MD5 doesn't say anything about syntax of username or realm,
> >    
>
> 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.
Although the format of authentication ids (usernames) is SASL mechanism 
specific, DIGEST-MD5 doesn't have any restrictions other than the one 
mentioned above.

> > so it definitely allows for DN syntax.
> >    
>
> It allows usernames that **look like** a string representation of a DN to
> appear in the protocol, but they are not DNs to the protocol.  They
> are usernames to the protocol.  One can have a realm that looks like
> a domain name, but to the protocol its a realm.  The username is matched
> per the username matching rules and not DN matching rules and the realm
> is matched per realm matching rules and not domain matching rules.
>  
>
> > And because there is no common definition of "simple username" I would argue that a DN can be considered one for LDAP ;-).
> >    
>
> 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.

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

>  If no, then obviously the IMAP server didn't support
> DNs as usernames.  It supported usernames which **looked like** DN
> strings.
>  
Alexey