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

auth-response comments



Rob/Mark,

Here are some comments, some new, some old... all provided to
ensure completeness.

First, please note my general aversion to unsolicited controls.
IMO, controls should only be sent to clients which are known to
be able to make use of the information.


2. Publishing support for the Authentication Response Control

s/supportedExtensions/supportedControl/

3. Authentication Response

>The criticality field is not used.
I would suggest "The criticality of this control SHALL be
FALSE.  Servers SHOULD not provide the criticality field."

Not also that the controlType is determined, its the value
of the field which is TBD.

You do not specify how AuthResponseValue is to be encoded.

I do not see the need for authMechanism?  The client knows
the method and, if applicable, the SASL mechanism used.  However,
what might be useful is source of credential used to in
to complete a SASL/EXTERNAL authentication.

I note you specify the return of a DN and not an authzID.
You assume that if an userzID is provided (or implied)
by the client that it must be mapped to a DN and if a
DN is provided (or implied) that it is not mapped to
a userzID.  JeffH has made arguments that authzId should
be the general form of LDAP authorization information.
In fact, LDAP ACM allows authzID as subjects.  You likely
should consider changing authDN to authzID.

4. Security Considerations

Please make specific mention that the control is not
protected by SASL integrity and privacy services
negotiated by the bind operation it is provided with.
Due to this, I suggest use of a separate (extended)
operation instead of a bind control to request/return
this information.

	Kurt