Re: LDAP Verify Credentials operation

[masarati@aero.polimi.it]

> Ando and I have been discussing off-list the need for this op's request
> and response to carry additional fields.  The discussion started with a
> separate error code to distinguish errors which might be communicated back
> to authenticating entity (as opposed to the LDAP client submitting the VC
> request).
>
> My current proposal is:
>
> /*
>  * LDAP Verify Credentials operation
>  *
>  * The request is an extended request with OID 1.3.6.1.4.1.4203.666.6.5
> with value of
>  * the BER encoding of:
>  *
>  * VCRequest ::= SEQUENCE {
>  *      cookie [0] OCTET STRING OPTIONAL,
>  *      name    LDAPDN,
>  *      authentication  AuthenticationChoice
>  *      controls [3] Controls OPTIONAL
>  * }
>  *
>  * where LDAPDN, AuthenticationChoice, and Controls are as defined in RFC
> 4511.
>  *
>  * The response is an extended response with no OID and a value of the BER
> encoding of
>  *
>  * VCResponse ::= SEQUENCE {
>  *      resultCode ResultCode,
>  *      diagnosticMessage LDAPString,
>  *      cookie [0] OCTET STRING OPTIONAL,
>  *      serverSaslCreds [1] OCTET STRING OPTIONAL
>  *      authzid [2] OCTET STRING OPTIONAL
>  *      controls [3] Controls OPTIONAL
>  * }
>  *
>  * where ResultCode is the result code enumeration from RFC 4511, and
> LDAPString and Controls are as
>  * defined in RFC 4511.
>  */
>
> The use of controls here is to allow both the request/return of password
> policy information to the authenticating entity (as opposed those used on
> the extended operation itself to request/return password policy
> information about the LDAP client submitting the VC request).
>
> Comments?

The code client and server side works now according to the above specs for
simple bind with request and response controls.

I note that you moved authzid retrieval to RFC 3829 authzid control.  Are
you going to implement its support server-side?  Otherwise I might have
time to look at it, maybe not immediately.

p.