Subject: Please review proposals for LDAP controls

From: [email-masked] (Rob Weltman)
Date: Thu, 15 Nov 2001 15:24:38 -0800

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

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

   Both have been discussed in the past on this mailing list, and both have been implemented in at least a couple of LDAP servers.

   Please reply to the list if you have any comments on the drafts at this point.

Thanks,
Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Nov 2001 22:54:36 -0800

>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.]

>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.

---

From: Rob Weltman <[email-masked]>
Date: Mon, 19 Nov 2001 20:50:20 -0800

> I-D <draft-zeilenga-ldap-authzid-00.txt> which details this

  The two models may be appropriate for different scenarios. The environment primarily targeted by our proposal is a high-performance, high-bandwidth server application. The server receives requests from many clients (users), binds on their behalf, and retrieves some profile data from the Directory. Examples of such applications are very many consumer-facing Web applications and also applications such as mail servers. If the authorization query was an extended operation instead of a control, the application would have to issue an extra request for every client served - a 50% increase in most cases. 

  In a high-performance, high-bandwidth application environment, the application (or the framework in which it operates)  typically creates a connection pool at startup. It may establish a security layer for all connections with TLS. Any credentials passed during subsequent binds on behalf of clients are protected by the security layer.

>   "authorization identity" established by the bind.

  It is a control which is only valid with a bind request, delivered as part of the bind response. It is not part of an "authorization response", which doesn't exist as far as I know as an LDAPv3 protocol element. "AuthzId" is not a good name, because it implies assertion of an authorization identity. Our proposed control returns the authorization identity established as a consequence of the bind operation. I suppose it could be "Authorization Identity Bind Control".

>   to know which authzid the server has associated with it?

A request which is denied because the client is not authorized for it results in insufficientAccessRights (50) if the control is marked critical. If the control is not critical the server can just omit the response control.

>   RFC 2251, Section 4.1.2 (second sentence).

  The second sentence of section 4.1.2 in RFC 2251 is 

     "Note that in the UTF-8 algorithm 
     characters which are the same as ASCII (0x0000 through 0x007F) are 
     represented as that same ASCII character in a single byte." 

    Perhaps you mean section 4.2.1? It says 

     "If at any stage the 
     client wishes to abort the bind process it MAY unbind and then drop 
     the underlying connection." 

>  The request

  Please clarify this issue and quote the relevant sentence from 2251.

>   to the last bind response.

  That is stated in the draft.

>   shouldn't be returned with resultCode is not success.

  A bind request that does not return a resultCode of success has failed.

>   may or may be a DN and, if a DN, may or may refer to an

  The paragraph gives an example of a typical usage of the control. It doesn't enumerate all the possible usages, and it doesn't enumerate what types of authorization identity may be returned. For that it refers to RFC 2829, section 9. But we could clarify by prepending a couple of sentences:

   "Identities presented by a client as part of the authentication
   process may be mapped by the server to an arbitrary authorization
   identity.  The bind response control can be used to retrieve that
   AuthzID.

   For example, during client authentication with certificates...."

>   Some discussion of this would be appropriate.

  I guess the server could return something that was not useful to a client. But the example given in the draft (returning the DN that a client certificate was mapped to) illustrates that a server may return something which is extremely valuable to a client. A customer who is evaluating LDAP servers from different vendors may want to question the vendors on this point. Certainly any authzId returned by the server should conform to one of the two schemes identified in section 9 of RFC 2829 (or a scheme added in a future update).

> done a comparative review between it and your approach.

  That is a more complex and higher overhead way to accomplish something that was intended to support high-performance, high-bandwidth server applications. With the proxied auth control, a server application can issue requests on behalf of many clients with no setup and no preallocation of server resources. A proxied authorization control applies only to the operation it is submitted with. No prior group creation or subsequent group termination is required.

>   assume asserted authzid" and "authzid has no rights to

  No

>   authzId or empty, empty implying "anonymous" authorization.

  OK, but I don't think that is an important or typical usage.

> - Suggest you state "anonymous" users cannot assume the

  The draft leaves the decision on which users are to be granted rights at which parts of the DIT up to the server, although it describes a typical server behavior. Giving anonymous users the right to assume any proxied authorization identity in any part of the DIT would completely eliminate security; that is not recommended. But there may be a reason to allow anonymous users to adopt certain authorization identities within a particular subtree (I'm not proposing this).

> - Suggest you state the control cannot be attached to a

  OK

>   attached to the same operation.

  That is implied in the draft, but OK.

>   authorization identity.  It may be appropriate to define

  OK, "proxy identity" = "proxied authorization identity".

>   authorization identities.

  The server bases a decision on whether or not to grant the requestor the desired authorization identity on the proxied authorization rights of the requestor. If it grants the requestor that right, the operation itself is processed under the granted authorization identity. This is described in the draft.

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Nov 2001 22:04:59 -0800

>  In a high-performance, high-bandwidth application environment, the application (or the framework in which it operates)  typically creates a connection pool at startup. It may establish a security…

Yes, it seems we have different use scenarios and hence different
approaches.

>  It is a control which is only valid with a bind request, delivered as part of the bind response. It is not part of an "authorization response", which doesn't exist as far as I know as an LDAPv3 protocol element.

Controls, IMO, should be named after the function they provide,
not the operation they attach to.  The function of this bind request
control is to request transfer of an authorization identity.
The function of the bind response control is return an authorization
identity.

>"AuthzId" is not a good name, because it implies assertion of an authorization identity. Our proposed control returns the authorization identity established as a consequence of the bind operation. I suppose it could be "Authorization Identity Bind Control".

This would address my concern in this area.

>  The second sentence of section 4.1.2 in RFC 2251 is 

whoops, I meant 5.1.2.
   Controls which are sent as part of a request apply only to
   that request and are not saved.

That is, the request control needs to be part of each bind request
but only needs the last bind response needs the response control.

>  A bind request that does not return a resultCode of success has failed.

A referral resultCode does not indicate failure.

>   For example, during client authentication with certificates...."

Identies presented .... mapped to ... arbitrary authorization identities.
                                                                     ^^^^
One of these is returned upon request.  [See below]

>  I guess the server could return something that was not useful to a client. 

What's useful to one client is not necessarily useful to another.
Unless the server has some bilateral agreement as to how the client
intends to use the authzid, it would have to guess as to which
authzid it associates with the user is the most useful to the client.

>But the example given in the draft (returning the DN that a client certificate was mapped to) illustrates that a server may return something which is extremely valuable to a client.

What's extremely valuable to one client may be different than
what's extremely valuable to another.

>>   assume asserted authzid" and "authzid has no rights to

I can see cases where it would be useful to distinguish
these cases, for example when used by an administrative
clients in testing access controls.

>  OK, but I don't think that is an important or typical usage.

It's useful for administrative clients testing access controls.

>  The draft leaves the decision on which users are to be granted rights at which parts of the DIT up to the server, although it describes a typical server behavior. Giving anonymous users the right…

I suggest stating
  "Anonymous" users SHOULD NOT be allowed to assume the identity of others.

>  The server bases a decision on whether or not to grant the requestor the desired authorization identity on the proxied authorization rights of the requestor. If it grants the requestor that right,…

I'll have to re-read that section when I get a chance...

---

From: [email-masked] (Rob Weltman)
Date: Tue, 20 Nov 2001 17:43:09 -0800

OK

   OK

> One of these is returned upon request.  [See below]

   How about returning potentially more than one identity in the response control? That could be done by placing the authzId or authzIds in a sequence in the value part of the response control.

   I have yet to see an example of that, while I have seen many cases where the response control with a single DN-valued authzId is extremely useful, but at least the control would allow for the possibility of multiple authzIds.

> clients in testing access controls.

   A server can support that by returning different human-readable result strings (but the same result code). You're talking about debugging, not about a production environment.

   OK

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Nov 2001 21:48:34 -0800

>  I have yet to see an example of that, while I have seen many cases where the response control with a single DN-valued authzId is extremely useful, but at least the control would allow for the poss…

I'm concerned that this might not be enough, but the alternatives
I can think of off the top of my head are other issues.  I'll
to think about this a bit, chat with a couple of other folks,
and get back to you on this.

Given the I-D cut-off, for now, I suggest you leave the controlValue
syntax as is and state that the server "chooses" which to return.

>  A server can support that by returning different human-readable result strings (but the same result code).

I'd prefer another resultCode be used indicate the "user
not allowed to assume asserted authzid".  One can add a
resultCode to LDAP easy enough.   You can borrow language
from the draft-zeilenga-ldap-cancel-xx.txt.  For name
and number, I suggest proxyAuthorizationNotAllowed (47).

>You're talking about debugging, not about a production environment.

I'm talking about an administrator debugging ACLs in a
production environments.  (I know of few deployments
where the administrator maintains a separate system
(or replica) solely for debugging purposes.)