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

[Rob Weltman <robw@worldspot.com>]

"Kurt D. Zeilenga" wrote:
> 
> 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.

  OK

 
> 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.

  That's beyond the scope of this control, which is defined to solve a particular problem (finding the authorization identity resulting from a bind).

 
> 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.

  I'm adding text to the effect that the response control contains an identity, which in itself may raise confidentiality concerns in some environments. But the RFC 2253 security considerations section is not about confidentiality - it's about the fact that the same DN may be encoded in more than one way, and how to encode a DN unambiguously.

 
> 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.

  Using a control in conjunction with the bind request provides desirable atomicity that you don't achieve with an extended operation. The bind request produces a bind response containing the authorization identity.

  If it is unacceptable to pass the authorization identity without confidentiality protection in a particular environment, then TLS or some other protection should be in place before issuing the bind request with the auth response control, as you write above. There are many environments, though, where the authorization identity does not require confidentiality.

Rob