authmeth: SASL data vs. LDAP semantics

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

I lost this from my authmeth review:

> 10. SASL DIGEST-MD5 Authentication Mechanism
>   (...)
>
>   Implementers must take care to ensure that they maintain the
>   semantics of the DIGEST-MD5 specification even when handling
>   data that has different semantics in the LDAP protocol.

That should be in a SASL section, not just a section for DIGEST-MD5.
Something like:

10. Data with SASL-specific semantics

   Implementers must take care to ensure that they maintain the
   semantics of a SASL mechanism's specification even when the mechanism
   is handling data that has different semantics in the LDAP protocol.

If it becomes Section 10, it will be a nice contrast to the partly
LDAP-specific authorization ID handling in the preceding section
(9.7. SASL Authorization Identities).  In that regard, maybe this should
be added for emphasis:

   The authentication identity is a likely candidate for such semantics.

It needs an example; I think the DIGEST-MD5 example from the same
section can be moved to the new section (and maybe a reference to it
would be left under DIGEST-MD5).  Though now that I'm looking at the
example, I'd use a more diverse example (regardless of whether it's for
DIGEST-MD5 only or for SASL in general):

>   For example, the SASL DIGEST-MD5 authentication mechanism utilizes
>   realm and username values ([DIGEST-MD5] section 2.1) which are
>   syntactically simple strings and semantically simple realm and
>   username values. These values are not LDAP DNs, and there is no
>   requirement that they be represented or treated as such. Username
>   and realm values that look like LDAP DNs in form, e.g. <cn=bob,
>   dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
>   treats them as simple strings for comparison purposes. To illustrate
>   further, 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
>   [SASLPrep] semantics are used by DIGEST-MD5.

Though DN-like authentication IDs are important, I think this example
focuses too much on DNs.  In particular since it does not mention that
the "username" is the authentication ID and thus it does not mention the
motivation for discussing DN-like usernames in such detail.

Also, I believe 'because [SASLPrep] semantics are used by DIGEST-MD5' at
the end should be 'because DIGEST-MD5 matching is case-sensitive'.  As
far as I can tell, [SASLPrep] does not specify comparison, so
case-insensitive comparison would be compatible with [SASLPrep].

Except, I'm not sure the example (either the original or mine) is quite
correct anyway: Maybe the server could regard <cn=Bob,...> and
<cn=bob,...> as different DIGEST-MD5 usernames with the same password.
That would only work if the server stores the password as plaintext so
it can hash it with the provided username, not if what the server stores
is a hash of (password, DN, realm).

Ignoring the latter point until someone comments on it, how about:

   For example, the SASL DIGEST-MD5 authentication mechanism utilizes
   an authentication identity ("username") and a "realm" which are
   syntactically simple strings and semantically simple realm and
   username 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: It may e.g. 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.

-- 
Hallvard