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

Martin Rex <mrex@sap.com> Tue, 19 January 2010 21:34 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA623A683D for <tls@core3.amsl.com>; Tue, 19 Jan 2010 13:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.104
X-Spam-Level:
X-Spam-Status: No, score=-10.104 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEhySGJ1o8hi for <tls@core3.amsl.com>; Tue, 19 Jan 2010 13:34:23 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 7DDE73A67E2 for <tls@ietf.org>; Tue, 19 Jan 2010 13:34:23 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o0JLYInT021455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 22:34:18 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001192134.o0JLYHnm008538@fs4113.wdf.sap.corp>
To: Bruno.Harbulot@manchester.ac.uk (Bruno Harbulot)
Date: Tue, 19 Jan 2010 22:34:17 +0100 (MET)
In-Reply-To: <4B55C476.1070302@manchester.ac.uk> from "Bruno Harbulot" at Jan 19, 10 02:40:54 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] [Fwd: WWW-Authenticate challenge for client-certificates]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2010 21:34:24 -0000

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