draft-weltman-ldapv3-auth-response-04.txt comments

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

Rob, Mark, Mark:

As a security consideration, you should detail the impact of
the fact that content of the bind request control nor the bind
response control is protected by security layers negotiated by
the bind operation.

Given the above security consideration, I would think that a
post-bind extended operation would be a more appropriate design
choice.  As the design choice impacts security, you should
discuss your choice as a security consideration.

You should detail what is expected in multi-step bind operations.
Is the request control only provided on the first step, all
steps, or some subset?  Likewise for response control.

You have the OIDs added to supportedExtension, not supportedControl.

You *might* what to emphasis that the client should check
supportedControl and supportedLDAPVersion before using the request
control to ensure the server actually speaks LDAPv3.  If the server
doesn't, not only may a protocolError result, but a disconnect.  But,
IIRC, some LDAPv2 servers disconnect after any bind protocolError,
hence the *might*.

You state the criticality should be False or absent.  Please note
that a False criticality is to be encoded, per RFC 2251, as absent.
I suggest you say "False (absent)".   It seems odd that the
control cannot be marked critical.  As statement as to why this
is the case might be appropriate.

Lastly, the response control value should be an authorization
identity (authzId) [RFC 2829].

Regards, Kurt