Re: SASL Semantics Within LDAP

["Roger Harrison" <RHARRISON@novell.com>]

Thanks for the feedback. I've incorporated all of your suggested changes
into authmeth-18. This section now reads:

5.2.2. SASL Semantics Within LDAP

Implementers must take care to maintain the semantics of SASL
specifications when handling data that has different semantics in the
LDAP protocol.

For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
utilizes an authentication identity and a realm which are syntactically
simple strings and semantically simple username and realm values
([DIGEST-MD5] section 2.1). These values are not LDAP DNs, and there is
no requirement that they be represented or treated as such.

After preparing these values as specified in [DIGEST- MD5], the server
may choose to use LDAP semantics to locate an entry with the user's
authentication information.  For example, it may expect the
authentication identity to have the form of a DN and look up the named
entry, or it may search for "(cn=<authentication identity>)" below
"cn=<realm>,cn=auth,dc=example,dc=com".  However, when the entry is
located, authentication may fail if the realm and authentication
identity values do not match according to DIGEST- MD5's semantics.  For
example, the two DNs "cn=Bob,dc=example,dc=com" (upper case 'B') and
"cn=bob,dc=example,dc=com" (lower case 'b') are equivalent when being
compared semantically as LDAP DNs because the cn attribute is defined to
be case insensitive, however the two values are not necessarily
equivalent if they represent authentication identity values in DIGEST-
MD5 because DIGEST- MD5 matching usually is case- sensitive.

Roger

>>> On Mon, Oct 24, 2005 at  4:05 am, in message
<435CB207.2040402@isode.com>,
Alexey Melnikov <alexey.melnikov@isode.com> wrote: 
> Roger Harrison wrote:
> 
>> Hallvard,
>>
>> Shortly after sending a proposed new section 5.2.2 for authmeth-17,
I 
>> rediscovered your email on the same subject from last March. I've 
>> reworked section 5.2.2, as below. I'd appreciate comments and
feedback 
>> prior to my submitting authmeth-17 on Friday.
>>
> I think I've missed few issues before:
> 
>> 5.2.2. SASL Semantics Within LDAP
>>
>> Implementers must take care to ensure that they maintain the
semantics 
>> of SASL specifications when handling data that has different
semantics 
>> in the LDAP protocol.
>>
>> For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]

>> utilizes an authentication identity (username)
>>
> A bit of nit picking: according to SASL "username" is not
authentication 
> identity, it is authorization identity. So I suggested you remove 
> "(username)".
> 
>> and a realm which are syntactically simple strings and semantically

>> simple username and realm values ([DIGEST-MD5] section 2.1). These 
>> values are not LDAP DNs, and there is no requirement that they be 
>> represented or treated as such.
>>
> [...]
> 
>> To illustrate, the two DNs <cn=Bob,dc=example,dc=com> (upper case
"B") 
>> and <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when

>> being compared semantically as LDAP DNs because the cn attribute is

>> defined to be case insensitive, however the two values are not 
>> equivalent if they represent username values in DIGEST- MD5 because

>> DIGEST- MD5 matching is case- sensitive.
>>
> "username" ==> "authentication identity".
> 
> The client has to treat authentication identities and realms as 
> case-sensitive, because it doesn't know if the server treats them as

> case-sensitive or not.
> However a server implementation can treat authentication 
> identities/realms as case-insensitive and I know that some existing 
> implementations are. For such servers the last statement is not
correct. 
> So I suggest to weaken the last sentence: "however the two values are

> not necessarily equivalent .. because DIGEST-MD5 matching might be 
> case-sensitive". Or "because DIGEST- MD5 matching is usually case-
sensitive".