[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: authmeth: SASL authorization/authentication ID syntax
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