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