Re: authmeth: Access controls vs. confidentialityRequired

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

At 11:23 AM 9/28/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 08:34 AM 9/27/2004, Hallvard B Furuseth wrote:
>>>[Authmeth] says:
>>>
>>>> 3.1.1. StartTLS Request 
>>>
>>>>    If the client did not establish a TLS connection before sending a
>>>>    request and the server requires the client to establish a TLS
>>>>    connection before performing that request, the server MUST reject
>>>>    that request by sending a resultCode of confidentialityRequired.
>>
>> The MUST here is unnecessary.  Instead the specification
>> should simply say that the server may return confidentialityRequired
>> if it requires (stronger) data confidentiality services be in place.

I should have noted, this a general statement (outside of
the StartTLS specification) as the behavior we're talking
about is not directly tied to the StartTLS operation.

The confidentialRequired code may be returned whenever the
server wants to indicate to the client that strong(er) confidential
protections are required in order to perform the requested
operation.

>OK, except:
>
>>>If the security strength is used as an access control factor, the result
>>>will be insufficientAccessRights.
>
>...or in the case of Bind, as far as I can tell the server might return
>invalidCredentials.  Then the user would likely conclude that he
>mistyped the password, and send his password unprotected _again_:-(

Yes. I only note that's a topic more appropriately addressed
in a section about the Bind operation.

>I think server implementors should be warned about that and encouraged
>to return confidentialityRequired in this case.
>
>> If server may return insufficientAccessRights to indicate that
>> it not willing to perform the operation due to insufficient
>> access rights (which could be based on numerous factors).
>
>Assuming your "If" should not be there:
>Yes, with the "MUST" at the top gone, that's clear.
>
>>>The server could (SHOULD?) continue
>>>to check if the operation would otherwise be allowed and if so return
>>>confidentialityRequired, but I wonder if that can get too hairy to
>>>implement in all cases and we should do s/MUST/SHOULD/ above.  In either
>>>case, I think this should be mentioned.
>> 
>> The choice of which code to return depends on what the
>> server is trying to indicate.   For instance, if the
>> server requires some form of data confidentiality to
>> update the directory, returning confidentialityRequired
>> is a good code to indicate that this requirement has
>> been violated.
>
>OK.  Also, as with the Bind I mentioned, a security strength access
>control factor for sensitive data may indicate a user/client-side breach
>of security in sending the data unprotected, as well as that the server
>requires confidentiality to trust those data.
>
>> However, if the server is willing to
>> perform the operation but decides in that performance
>> that some access control factor precludes completing
>> that operation, insufficientAccessRights is good code
>> to indicate this.
>
>I don't understand.  Sounds to me like either the first case is an
>example of the second, unless you mean the second case is about how the
>operation is implemented - that is, it starts performing the operation
>and then runs into the access control factor, as opposed to discovering
>the access control factor at once.  I don't see why that should affect
>what the server says about why the operation was refused.

I'm trying to point out that the choice of code that
is returned in such cases often depends on whether
the decision to return the code was made within the
access rights (authorization) subsystem or made within
some other administrative control subsystem.