[TLS] [Fwd: WWW-Authenticate challenge for client-certificates]
Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> Tue, 19 January 2010 14:41 UTC
Return-Path: <Bruno.Harbulot@manchester.ac.uk>
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 C75B53A6924 for <tls@core3.amsl.com>; Tue, 19 Jan 2010 06:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 11zbcdbvLvjM for <tls@core3.amsl.com>; Tue, 19 Jan 2010 06:40:59 -0800 (PST)
Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by core3.amsl.com (Postfix) with ESMTP id C42563A6A82 for <tls@ietf.org>; Tue, 19 Jan 2010 06:40:59 -0800 (PST)
Received: from kelvin.its.manchester.ac.uk ([130.88.25.195]) by serenity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Bruno.Harbulot@manchester.ac.uk>) id 1NXFGI-000GK4-HO for tls@ietf.org; Tue, 19 Jan 2010 14:40:54 +0000
Received: from pulsar.rcs.manchester.ac.uk ([130.88.1.47]:33135 helo=mymachine) by kelvin.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Bruno.Harbulot@manchester.ac.uk>) id 1NXFGI-0008Cy-DI for tls@ietf.org; Tue, 19 Jan 2010 14:40:54 +0000
Message-ID: <4B55C476.1070302@manchester.ac.uk>
Date: Tue, 19 Jan 2010 14:40:54 +0000
From: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: Bruno Harbulot from pulsar.rcs.manchester.ac.uk (mymachine) [130.88.1.47]:33135
X-Authenticated-From: Bruno.Harbulot@manchester.ac.uk
X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details.
Subject: [TLS] [Fwd: WWW-Authenticate challenge for client-certificates]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 14:41:00 -0000
Hello, Apologies if this is slightly off-topic, but I thought some IETF TLS subscribers might find this relevant: http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0047.html Best wishes, Bruno. -------- Original Message -------- Subject: WWW-Authenticate challenge for client-certificates Date: Tue, 19 Jan 2010 13:35:23 +0000 Hello, I'd like to suggest ideas towards the potential specification of a challenge for client-certificate authentication using HTTP over TLS. The current model of TLS client-certificate challenge doesn't integrate well with HTTP, as there is no way for a server to tell the client it requests or accepts a client-certificate at the HTTP layer: this must be done at the TLS layer, without any proper integration with the HTTP response status codes. This can lead to confusing behaviour. 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). This leads to a couple of problems: - The HTTP application is unable to inform the client it would rather have another certificate than the one that is presented. Whether-or-not to accept the certificate is done by the trust management mechanism of the TLS layer, and it is difficult for the HTTP application to deal with. Often, once the certificate has been negotiated, browsers usually keep the TLS connection open and changing certificate can often only be done by closing the browser or letting the connection time out. - 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. 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. 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). I realise that the details of what I'm suggesting are still a bit vague, but I'm wondering whether the general idea would be of interest. Best wishes, Bruno.
- [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