Re: Please review proposals for LDAP controls

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

At 03:24 PM 2001-11-15, Rob Weltman wrote:
>  I intend to submit the following two Internet Drafts soon to the Application Area directors for last call to RFC standard status:


>LDAP Authentication Response Control
>http://search.ietf.org/internet-drafts/draft-weltman-ldapv3-auth-response-05.txt

As I've noted previously, I find the use of a bind control to
pass security related information inappropriate as the bind
control is not protected by the security layers negotiated
and established by the bind operation they are transferred
as part of.  I believe use of an extended operation to get
the information would be more suitable.  I have submitted an
I-D <draft-zeilenga-ldap-authzid-00.txt> which details this
alternative approach.

In regards to your auth-response draft, I have a couple
of quick comments:
- The control should be renamed.  It returns the
  "authorization identity" established by the bind.
- How is the server to behave if the client is not authorized
  to know which authzid the server has associated with it?
- Multi-step bind needs refinement to be consistent with
  RFC 2251, Section 4.1.2 (second sentence).  The request
  control needs to be attached to each bind request.
  However, the response control needs only to be attached
  to the last bind response.
- You note control should not be returned on failure, it
  shouldn't be returned with resultCode is not success.
- The last paragraph of 4 notes that certificate identities
  may be mapped.  This should be generalized as all identities
  may be mapped [RFC2829] and that the identity returned
  may or may be a DN and, if a DN, may or may refer to an
  entry in the DIT.
- And as the server may associate multiple authzid
  strings with the identity and is free to return which
  ever it chooses.  Obviously, the client cannot assume
  the authzid is useful for anything other than display
  purposes without bilateral agreement with the server.
  Some discussion of this would be appropriate.

[I note that my I-D doesn't (yet) address all of these issues.]

>LDAP Proxied Authorization Control
>http://search.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-08.txt

I have submitted a "grouping of related operations" approach which
you might want to review <draft-zeilenga-ldap-proxy-grp-00.txt>.
As I wrote this to help to flush out groupings I-D, I haven't yet
done a comparative review between it and your approach.

Anyways, in regards to the your proxy I-D, I do have a couple
of quick comments:
- Can a client distinguish between "user not allowed to
  assume asserted authzid" and "authzid has no rights to
  perform operation"?
- Suggest you state that the control value can be an
  authzId or empty, empty implying "anonymous" authorization.
- Suggest you state "anonymous" users cannot assume the
  identity of others.
- Suggest you state the control cannot be attached to a
  Start TLS operation.
- Suggest you state that multiple proxy controls cannot be
  attached to the same operation.
- Editorial, some of the language in section 4 is unclear.
  In particular, I find the term "proxy identity" confusing.
  After reading it twice, I believe you intend this term
  to refer to the entity associated with the provided
  authorization identity.  It may be appropriate to define
  the term explicitly.
- I find the behavior described last paragraph of section 4
  to be a bit odd.  This is partially because I view the
  authorization identity policy (the right for identity X
  to assume Y's identity) to be separate from Y's access
  right to a resource.  But also because the "operation (to)
  be processed under a provided authorization identity [AUTH]
  instead of as the current authorization identity associated
  with the connection" isn't so.  It's process under both
  authorization identities.