WWW-Authenticate challenge for client-certificates

Hello,

I'd like to suggest ideas towards the potential specification of a 
challenge for client-certificate authentication using HTTP over TLS.

The current model of TLS client-certificate challenge doesn't integrate 
well with HTTP, as there is no way for a server to tell the client it 
requests or accepts a client-certificate at the HTTP layer: this must be 
done at the TLS layer, without any proper integration with the HTTP 
response status codes. This can lead to confusing behaviour.

For example, most TLS frameworks either "request" or "require" a 
client-certificate (using the Apache Httpd terminology).
In 'request' mode, the server asks for a client-certificate, but will 
continue the connection if the client doesn't present one 
("setWantAuthentication" in Java).
In 'require' mode, the server asks for a client-certificate, but makes 
the TLS handshake fail if the client doesn't present one 
("setNeedAuthentication" in Java).

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.


To try to solve this, I would like to suggest the introduction of 
something along the lines of a 'transport' challenge, implying that the 
authentication mechanism is outside the scope of HTTP itself.
This could be something like:
- WWW-Authenticate: transport
- WWW-Authenticate: transport mode="tls-client-certificate"

To this, could be added parameters describing what kind of certificate 
is preferred.


As a side note, I also think that such a mechanism could partly help 
with the TLS renegotiation issue (still discussed on the IETF TLS 
mailing list). Indeed, if the HTTP framework was able to detect a 
renegotiation had occurred, it could make the client re-send the request 
post-negotiation (rather than assume that the certificate presented 
during the second handshake were also valid for the request sent before).


I realise that the details of what I'm suggesting are still a bit vague, 
but I'm wondering whether the general idea would be of interest.


Best wishes,

Bruno.

Received on Tuesday, 19 January 2010 13:35:52 UTC