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

[Martin Rex <[e-mail]>]

Bruno Harbulot wrote:
> 
> - 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.

Clarifying:  If the server's TLS is configure to require a client-cert,
the server's TLS will produce the error message (and terminate the
TLS handshake with a fatal alert message), which in turn will
cause the client TLS implementation to report an error.

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

Unfortunately, the issue is _much_ more complex.
Difficulties you have to address:

  1. whether or not the server requests a client certificate
     is a decision of the server alone.  The client must not
     send an unsolicited client certificate (that should cause
     compliant servers to abort the handshake).

  2. there currently is _no_ standardized fashion for TLS to
     negotiate certain aspects of client certificate authentication

      a) client->server signaling that client des not have
         a certificate (or is determined to not send one)

      b) client->server signaling that client has a certificate
         and is willing to use it for client certificate authentication
         (provided that server certificate validation succeeds).

      c) server->client signaling that client may send *any*
         certificate with the promise that the server will _NOT_
         abort the handshake when the server does _not_ have a
         trust anchor necessary to verify the certificate sent
         by the client (requiring the server to either withhold
         such a client cert from the server application, as if
         the client had _not_ sent any cert -- at least _not_
         provide such a client cert to server apps in the same
         fashion as authenticated client certs.

         SSL/TLS client cert authentication kind-of blindly assumes
         a PKI and SSLv3&TLSv1.0 _require_ a server to send a
         non-empty list of trusted CAs.  Semantics of empty ca_list
         in TLSv1.1&1.2 is underspecified.

   3. (Bodo Moeller recently explained this to me):
      cryptographic algorithm constraints on client certificates
      According to rfc-5246 Section 7.4.6. there are constraints
      if the client certificate is of one of these types:
      rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh

      http://tools.ietf.org/html/rfc5246#page-56

      restricting compatible client certs that can be used for
      client cert authentication in TLS to _both_, characteristics
      of the cipher suite plus characteristics of the server certificate

      This additional restriction does not apply to client certificates
      rsa_sign, dsa_sign (and marginally to ecdsa_sign).


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

Changing/switching client identities is also a somewhat underspecified area.

In theory, clients can offer some means to "flush" the client-side
TLS session cache (several browsers have that, I think), but it
may be a function hidden in some configuration options many casual
users have never used or maybe even looked at.

I'm not sure that current / commonly used browsers, which offer
multi-windows and tabbed browsing, have an adequate client-side
session cache management (in the browser) to reliably manage many
parallel sessions with the exact same server and individual
TLS client identities/credentials for each session.


-Martin