AuthMeth and RFC2251

["Kurt D. Zeilenga" <kurt@boolean.net>]

I noted previous that the introduction of authzid would require
significant change to the protocol and information model.  In
particular, I noted that it would likely cause introduction of
new attribute types to replace attribute types of syntax DN
(owner, member, creatorsname, modifiersname).  Jeff noted that
ACL reqt/model subject DN also needed to be updated to support
authzids.

It has been noted that most of these information model issues
would be resolved by requiring servers to map uAuthzId to some
LDAP DN.   I have also shown how the uAuthzIds values could be
encapulated within an LDAP DN to avoid the introduction of a
second on-the-wire representation of authorization identities.
I believe both of these suggestions need further investigation.

I also believe we may want to consider clarifying RFC2251.
Here are some other fuzzy areas:

RFC2251, 4.2 states:
- name: The name of the directory object that the client wishes to
bind as.  This field may take on a null value (a zero length
string) for the purposes of anonymous binds, when authentication
has been performed at a lower layer, or when using SASL credentials
with a mechanism that includes the LDAPDN in the credentials.

This implies that if the SASL credentials do not include an LDAPDN
than the name field may not be a null value (excepting SASL EXTERNAL).
I suggest this be clarified to state that in absense of an LDAPDN in
the SASL credentials or name field, the server SHALL assign some
locally unique LDAPDN to represent the authorization identity to be
used to implement the information model.

and section 7.:
When used with SASL, it should be noted that the name field of the
BindRequest is not protected against modification.  Thus if  the
   distinguished name of the client (an LDAPDN) is agreed through the
   negotiation of the credentials, it takes precedence over any value in
the unprotected name field.

This implies (weakly) that the negotiated credentials or the name field
includes an LDAPDN.  Similiar clarification as above is suggested.

And section 3.2.1 only says:
- creatorsName: the Distinguished Name of the user who added this
entry to the directory.


- modifiersName: the Distinguished Name of the user who last modified
this entry.

Though servers are not required to publish these attributes
RFC2252 says they SHOULD.  The statement implies that users
do have Distinguished Names.  Again, would be resolved
if RFC2251 was clarified as noted above.








----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>