Re: [TLS] [Fwd: WWW-Authenticate challenge for client-certificates]

[Bruno Harbulot <[e-mail]>]

Hello,

Joe Orton wrote:
> On Tue, Jan 19, 2010 at 02:40:54PM +0000, Bruno Harbulot wrote:
> ...
>> This leads to a couple of problems:
>> - The HTTP application is unable to inform the client it would rather
>> have another certificate than the one that is presented. Whether-or-not
>> to accept the certificate is done by the trust management mechanism of
>> the TLS layer, and it is difficult for the HTTP application to deal
>> with. Often, once the certificate has been negotiated, browsers usually
>> keep the TLS connection open and changing certificate can often only be
>> done by closing the browser or letting the connection time out.
>> - If a certificate is mandatory, the 'require' mode leads to a handshake
>> error code on the client side, resulting in an abrupt error message,
>> which is confusing for most users.
> 
> I don't see how either of these problems are a consequence of protocol 
> design, merely server implementation or configuration.
> 
> It is simple to configure mod_ssl to avoid the second problem - you make 
> client certificates requested but optional ("SSLVerifyClient optional"), 
> and then use an HTTP authorization-level check to present an HTTP 403 
> error if in fact the TLS layer did not receive a client cert (using 
> "SSLRequire").  The 403 error page can be customized as usual.

Yes, but 403 is exactly the problem. That's not really a TLS problem, 
but more of how TLS authentication is handled by HTTP, differently from 
the other HTTP-specified authentication mechanisms (except form/cookies, 
but someone is working on a spec for these already).

As RFC 2616 (HTTP) says:
"10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. 
Authorization will not help and the request SHOULD NOT be repeated. [...]"

This is why I think that, when no certificate or an insufficient 
certificate is presented, 401 would be more appropriate:

"10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a 
WWW-Authenticate header field (section 14.47) containing a challenge 
applicable to the requested resource. The client MAY repeat the request 
with a suitable Authorization header field (section 14.8). If the 
request already included Authorization credentials, then the 401 
response indicates that authorization has been refused for those 
credentials. If the 401 response contains the same challenge as the 
prior response, and the user agent has already attempted authentication 
at least once, then the user SHOULD be presented the entity that was 
given in the response, since that entity might include relevant 
diagnostic information."



In addition, the use of a 401 status code would allow for configurations 
where the server can present two challenges at the same time, for example:

HTTP/1.0 401 Authorization Required
WWW-Authenticate: Basic realm="..."
WWW-Authenticate: Transport mode="tls-client-certificate"


I don't see this as just being an implementation or configuration issue. 
The problem being that "[...the 401 response] MUST include a 
WWW-Authenticate header field", and that no such header is specified for 
client certificates (or perhaps SRP).


Best wishes,

Bruno.