Subject: authmeth: Access controls vs. confidentialityRequired

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Sep 2004 17:34:21 +0200

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

If the security strength is used as an access control factor, the result
will be insufficientAccessRights.  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.

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

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 27 Sep 2004 13:45:46 -0700

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

>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

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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 28 Sep 2004 20:23:02 +0200

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

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

> 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

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.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 28 Sep 2004 12:30:59 -0700

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

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

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 28 Sep 2004 22:30:54 +0200

Kurt D. Zeilenga writes:
>> (...)

Well, yes, that's why I started this thread.  The natural way for the
server to do this does not seem to be the right way, unless it
explicitly provides another way than access control factors which should
be used to require a secure connection for access to an entity.

I've been waffling a bit over this, but lacking examples to the
contrary, I think the draft has it right 'in theory': The server MUST
return confidentialityRequired.  In practice, I suspect that's too hard
a requirement and only should be a SHOULD, with a warning that ignoring
the SHOULD can give severely misleading error responses.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 28 Sep 2004 14:13:25 -0700

>the SHOULD can give severely misleading error responses.

As I previously noted, I don't think the specification should,
in general, prescribe when particular results codes are to be
returned.  Instead, the specification should detail what each
code indicates (in regards to the request) and, except for some
guidelines, leave it to servers to return the most appropriate
result code.

Kurt