[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



At 08:59 AM 2001-10-17, Kurt D. Zeilenga wrote:
>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.

I meant:
  As bind controls are not protected by the security layers
  negotiated by the bind operation, a security consideration
  should be added detailing this fact and its impact.

>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