Re: WWW-Authenticate challenge for client-certificates

On 1/19/10 7:35 AM, "Bruno Harbulot" <Bruno.Harbulot@manchester.ac.uk>
> I'd like to suggest ideas towards the potential specification of a
> challenge for client-certificate authentication using HTTP over TLS.

Any interest in incorporating other TLS authentication methods like SRP?

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

Yes. In fact, in the early days of describing the renegotiation flaw, we
were not all sure whether or not it represented a bug in TLS or in HTTP's
use of TLS.

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

At least one commercial vendor has a server-wide setting to "require" that
TLS request a client certificate, but it's legal for the client to decline.
That being the case, this commercial vendor's decision is simply to move on
and keep processing, not bothering to validate the presence of the
certificate until later. This then triggered a renegotiation, leading to the
renegotiation problem. The point is that, in this case, simply setting the
server to "require" a client cert wasn't good enough, since it allowed the
client to decline it. The semantics of this area of HTTP-TLS interaction is
complex and ill-defined.

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


This would indeed obviate the need to renegotiate to request a client
certificate. In any case, it has the potential to clarify exactly what
authenticated identity is associated with each request. (There has been a
significant amount of discussion lately about identity changes during TLS
connections across renegotiations, and whether apps are prepared to properly
handle these changes.)

I'm all for a more explicit identity model here.

I also heard it suggested that an HTTP status code for "resend request"
would have been useful - that way, the trick of buffering a request and
requesting a renegotiation wouldn't have been needed in the first place. I
think clarifying the authentication process is a better, more specific
solution to the problem, but perhaps a "resend request" status would be
helpful. I just wanted to throw that out for discussion.

 -Steve

Received on Wednesday, 20 January 2010 04:16:41 UTC