Subject: AuthMeth and RFC2251

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 1999 20:29:20 -0800

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 <bold>may take on a null value</bold> (a zero
length

     string) for the purposes of anonymous binds, when authentication

     has been performed at a lower layer, or <bold>when using SASL
credentials

     with a mechanism that includes the LDAPDN in the
credentials</bold>.

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 <bold>if 
the

</bold>   <bold>distinguished name of the client</bold> (an LDAPDN)
<bold>is agreed through the

</bold>   <bold>negotiation of the credentials</bold>, 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: <bold>the Distinguished Name of the user</bold> who
added this

     entry to the directory.

   - modifiersName: <bold>the Distinguished Name of the user</bold> 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		<<[email-masked]>

Net Boolean Incorporated	<<http://www.boolean.net/>