Re: Please review proposals for LDAP controls

[Rob Weltman <rweltman@netscape.com>]

"Kurt D. Zeilenga" wrote:
> 
> 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.

  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.


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

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


> - How is the server to behave if the client is not authorized
>   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.


> - Multi-step bind needs refinement to be consistent with
>   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
>   control needs to be attached to each bind request.

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


>   However, the response control needs only to be attached
>   to the last bind response.

  That is stated in the draft.


> - You note control should not be returned on failure, it
>   shouldn't be returned with resultCode is not success.

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


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

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


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

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

  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.

 
> 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"?

  No


> - Suggest you state that the control value can be an
>   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
>   identity of others.

  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
>   Start TLS operation.

  OK


> - Suggest you state that multiple proxy controls cannot be
>   attached to the same operation.

  That is implied in the draft, but OK.


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

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


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

  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