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.
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) 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 username to have the form of a DN and look up the named entry, or it may search for "(cn=<username>)" below "cn=<realm>,cn=auth,dc=example,dc=com". However, when the entry is located, authentication will fail if the realm and username values do not match according to DIGEST‑MD5's semantics.
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.
Thanks,
Roger |