[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: authmeth: Access controls vs. confidentialityRequired



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.

>If the security strength is used as an access control factor, the result
>will be insufficientAccessRights.

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

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

The specification should be less prescriptive and
more descriptive in the area of result codes.

>Maybe this should also be mentioned under B.2 (Access Control Factors);
>for the "encryption strength" factor.
>
>-- 
>Hallvard