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

[Bruno Harbulot <[e-mail]>]

Hello,

Steve Dispensa wrote:
> On 1/19/10 7:35 AM, "Bruno Harbulot" <[e-mail]>
>> 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?

Why not. I don't know much about SRP, but this might work in a similar 
way. We could have this:
   WWW-Authenticate: transport mode="tls-client-certificate"
   WWW-Authenticate: transport mode="tls-srp"


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

What I meant by 'require' is a server that would not accept a client 
sending an empty TLS Certificate message in response to a TLS 
CertificateRequest message (and thus terminate the handshake with an 
error message). I'm not sure we mean 'require' in the same way here, 
since it couldn't possibly let the client continue the connection in 
this case (the TLS connection not being even established).

IIS (and the .Net HTTP framework) seems to be configured by default not 
to request a certificate, but to request one only at a later point, 
depending on what the HTTP request is trying to access. I'm not sure if 
this is the commercial vendor you had in mind, but this one does indeed 
use re-negotiation by default (unless configured with 
clientcertnegotiation=true with netsh), but I can't find much 
information from MS about CVE-2009-3555 anyway.


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

Yes, I think such a header 'WWW-Authenticate' could also include a 
parameter to have a hint of which certificate to send. I'm not sure 
whether the request resent should have an 'Authorization' header, since 
the credentials would be obtainable from the the TLS layer anyway.


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

What I had in mind was indeed a "cleaner 401" behaviour for TLS 
authentication, so as to model the resend request like other HTTP 
mechanisms do (form/cookies excepted of course, but that's another debate).


Best wishes,

Bruno.