Comments: draft-weltman-ldapv3-auth-response-02.txt

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

Rob,

It should be noted that the identity assumed by the client may
not be represented as an LDAP DN and nor be associated with any
entry in the directory (RFC2829).  This control only defines
a mechanism to return the identity assumed by the client when
that identity is in the form of a DN.  You may want to allow
return of other forms.  I suggest the response return the
identity in the form of an AuthzId form.

As you've noted the authorization identity assumed by the
client may later be mapped to an access control (subject)
identity and this is the identity to be returned.  However,
the I-D inconsistently refers to this identity as the
authentication identity.

As there are often multiple identities (authentication,
authorization, access control) associated with a session,
it may be appropriate to expand the response to include other
identities.

I also believe the Security Considerations needs work.

The I-D states "No additional confidential information is
passed in the control."  This is not necessarily true.
The fact is that this control passes additional information,
a DN, and a DN may contain confidential information.  The
reader should be minimally referred to RFC 2253 security
considerations section.

However, as previously noted, a critical consideration for
this control is that it is not protected by security layers
negotiated by the bind operation.  As the primary purpose
of providing such information is for verify security
relations and/or managing information used to establish
security relations, it would likely be quite appropriate
to require or recommend the use of other security services
(such as TLS).

In fact, this consideration may be significant enough to
warrant redesign of the mechanism itself.  Use of an extended
operation may be more appropriate.