Re: authmeth: SASL authorization/authentication ID syntax

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:30 AM 9/27/2004, Hallvard B Furuseth wrote:
>[Authmeth] says:
>
>> 10.4. SASL Authorization Identity Syntax
>
>>    The format of
>>    userid is defined as only a sequence of UTF-8 [RFC3629] encoded
>>    [Unicode] characters, and any further interpretation is a local
>>    matter.  To compare  uAuthzID values, each uAuthzID value MUST be
>>    prepared using [SASLPrep] and then the two values are compared
>>    octet-wise.
>
>This is inconsistent.

The text needs to be reworded.  Something like:

        The format of userid is defined as a sequence of UTF-8
        encoded characters.  Servers MUST prepare the
        transferred value using the [SASLprep] algorithm
        before use.  Interpretation of the prepared value
        is a local matter.

The key here is, if for some character strings x and
y and z where
        x != y and
        z == SASLprep(x) == SASLprep(y)

the server is to interpret both x and y as it does z.



>If userid can be 'interpreted', then that
>interpretation can e.g. convert it to lowercase before it is compared,
>so it isn't necessarily SASLPrepped and compared octet-wise.
>Or is something else meant by 'further interpretation'?
>Note that neither of the examples that follow are compared octet-wise if
>they are implemented with their usual LDAP attributes, 'uid' and 'mail':
>
>>    For example, the userid could identify a user of a specific
>>    directory service, be a login name, or be an email address.
>
>Also, 'compared octet-wise' with what?  I can think of two meanings:
>
>- during bind, compare with the list of authorization IDs which
>  the authentication ID may authorize,
>
>- during non-bind, compare with the authorization IDs listed in the
>  access controls which apply to that operation.
>
>I notice that the wording has changed since I wrote this previously, but
>I don't know if that is in response to my comment, and if so I don't see
>how it addresses it.
>
>========
>
>> 11. SASL DIGEST-MD5 Mechanism
>
>>    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.
>
>If the user name is a DN in the directory, is it OK to compare them with
>distinguishedNameMatch?

While the encoding of the user name may look like a DN,
it doesn't have the syntactical nor semantical
characteristics of a DN.  This text is aimed at warning
administrators that if they tell the user "providing your
DN as the username to the DIGEST-MD5 promots", that
things are likely not to work.  Now, if instead
administrator says enter "uid=joe,dc=example,dc=com"
and the user does exactly that, while things might work,
they work because the string is treated as a simple
user name, not as a DN string.

That said, the text likely could be better worded.

>The exact DN has already been _almost_ ensured
>by using it for the DIGEST-MD5 hashes, though I suppose one could
>construct a case where this was not so.




>-- 
>Hallvard