[Date Prev][Date Next]
Re: Comments about draft-ietf-ldapbis-authmeth-05.txt
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:Can you point me to the section where DIGEST-MD5 says that.
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
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:]
Which is just a sequence of Unicode characters (no NUL allowed)
represented in UTF8, nothing more.
syntactically and semantically not DNs. They are syntacticallyI disagree. DIGEST-MD5 doesn't say anything about syntax of username or realm,
and semantically simple usernames and realms, respectively.
DIGEST-MD5 defines the syntax of the username and realm using ABNF.
Although the format of authentication ids (usernames) is SASL mechanism
specific, DIGEST-MD5 doesn't have any restrictions other than the one
Of course I wasn't talking about an *arbitrary* DN, but only that
represents a user or a group of users.
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.
Frankly I don't know, I don't remember if the server was supporting
(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
If no, then obviously the IMAP server didn't support
DNs as usernames. It supported usernames which **looked like** DN