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

From: Bruno Harbulot <[email-masked]>
Date: Wed, 20 Jan 2010 15:55:36 +0000

Hello,

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

---

From: Marsh Ray <[email-masked]>
Date: Wed, 20 Jan 2010 10:05:57 -0600

> information from MS about CVE-2009-3555 anyway.

Configuring a multi-purpose web server to allow an optional client
certificate can have the side effect of popping up a 'choose cert'
dialog in the user's web browser, whether they are likely to need one or
not. Not something you want on your home page.

I think it's mainly for this reason that certs are not accepted on the
initial connection.

> the credentials would be obtainable from the the TLS layer anyway.

You might have to specify everything that would be specified in the TLS
Certificate Request message, and add to that your enhancements.

RFC 2246:
>        enum {
>            rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
>            (255)
>        } ClientCertificateType;
> 
>        opaque DistinguishedName<1..2^16-1>;
> 
>        struct {
>            ClientCertificateType certificate_types<1..2^8-1>;
>            DistinguishedName certificate_authorities<3..2^16-1>;
>        } CertificateRequest;
> 
>        certificate_types
>               This field is a list of the types of certificates requested,
>               sorted in order of the server's preference.
> 
>        certificate_authorities
>            A list of the distinguished names of acceptable certificate
>            authorities. These distinguished names may specify a desired
>            distinguished name for a root CA or for a subordinate CA;
>            thus, this message can be used both to describe known roots
>            and a desired authorization space.
> 
>  Note: DistinguishedName is derived from [X509].
> 
>  Note: It is a fatal handshake_failure alert for an anonymous server to
>        request client identification.

- Marsh