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
Date: Tue, 19 Jan 2010 22:34:17 +0100
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
- [TLS] [Fwd: WWW-Authenticate challenge for client… Bruno Harbulot
- Re: [TLS] [Fwd: WWW-Authenticate challenge for cl… Nicolas Williams
- Re: [TLS] [Fwd: WWW-Authenticate challenge for cl… Martin Rex
- Re: [TLS] [Fwd: WWW-Authenticate challenge for cl… Bruno Harbulot
- Re: [TLS] WWW-Authenticate challenge for client-c… Bruno Harbulot
- Re: [TLS] WWW-Authenticate challenge for client-c… Marsh Ray
- Re: [TLS] [Fwd: WWW-Authenticate challenge for cl… Joe Orton
- Re: [TLS] [Fwd: WWW-Authenticate challenge for cl… Bruno Harbulot
- Re: [TLS] [Fwd: WWW-Authenticate challenge for cl… Joe Orton
- Re: [TLS] [Fwd: WWW-Authenticate challenge for cl… Bruno Harbulot