[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