[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: authmeth: Access controls vs. confidentialityRequired
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