Re: authmeth: Access controls vs. confidentialityRequired

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

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_:-(

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.

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

-- 
Hallvard