Re: Please review proposals for LDAP controls

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

At 08:50 PM 2001-11-19, Rob Weltman wrote:
>"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.

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

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

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.

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

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.

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

A referral resultCode does not indicate failure.

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

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


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

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.

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

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.

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

It's useful for administrative clients testing access controls.

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

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

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

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