Re: [TLS] [Fwd: WWW-Authenticate challenge for client-certificates]
Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> Fri, 22 January 2010 16:13 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 CBA893A69DB for <tls@core3.amsl.com>; Fri, 22 Jan 2010 08:13:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.679
X-Spam-Level:
X-Spam-Status: No, score=-6.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 4I70oJetagmH for <tls@core3.amsl.com>; Fri, 22 Jan 2010 08:13:45 -0800 (PST)
Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by core3.amsl.com (Postfix) with ESMTP id C854C3A6A45 for <tls@ietf.org>; Fri, 22 Jan 2010 08:13:37 -0800 (PST)
Received: from rankine.its.manchester.ac.uk ([130.88.25.196]) by probity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Bruno.Harbulot@manchester.ac.uk>) id 1NYM8W-000FDY-6V for tls@ietf.org; Fri, 22 Jan 2010 16:13:28 +0000
Received: from pulsar.rcs.manchester.ac.uk ([130.88.1.47]:60268 helo=mymachine) by rankine.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Bruno.Harbulot@manchester.ac.uk>) id 1NYM8W-00042B-06 for tls@ietf.org; Fri, 22 Jan 2010 16:13:28 +0000
Message-ID: <4B59CEA7.7060201@manchester.ac.uk>
Date: Fri, 22 Jan 2010 16:13:27 +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
References: <4B55C476.1070302@manchester.ac.uk> <20100121165844.GA2878@redhat.com> <hjc1uf$e8g$1@ger.gmane.org> <20100122114325.GA5528@redhat.com>
In-Reply-To: <20100122114325.GA5528@redhat.com>
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]:60268
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: Re: [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: Fri, 22 Jan 2010 16:13:47 -0000
Joe Orton wrote: > On Fri, Jan 22, 2010 at 11:25:04AM +0000, Bruno Harbulot wrote: >> Yes, but 403 is exactly the problem. That's not really a TLS >> problem, but more of how TLS authentication is handled by HTTP, >> differently from the other HTTP-specified authentication mechanisms > > I don't see what difference it makes to have a fake 401 challenge as > opposed to a 403. If the client doesn't have a cert to present when > challenged, the best you can do is present an error page describing to > them how they obtain a client cert. The client *already knows* that a > client cert was requested; telling them again in a fake 401 doesn't add > additional information. It has to do with the 'retry' ability 401 gives to the client. 403 explicitly tells the client not to retry, even with different credentials. Thus, 403 always gives an error message to the end-user in a browser. In contrast, 401 presents the challenge to the browser which is then able to repeat the request with an appropriate response to the challenge. Like 302 redirections, this can be done transparently; the behaviour of the user-interface then depends on the configuration and the implementation, but a 401 response gives the opportunity to do something at the HTTP level. >> In addition, the use of a 401 status code would allow for >> configurations where the server can present two challenges at the >> same time, for example: > > Again, that is effectively already possible. Send a client cert > request, and a 401 challenge if none is presented. Not really, this creates an imbalance that gives priority to the certificate. RFC 2617 (HTTP Basic and Digest auth spec) says "The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based upon that challenge." While between TLS certs and clear username/password with HTTP Basic, the certificate is probably always the strongest auth-scheme. It wouldn't necessarily be a clear cut in all cases, for example if the service offers both TLS certificate authentication and SPNEGO/Kerberos authentication. (There are probably crypto experts on this list who might have an opinion on this, but I don't think it's easy to say which one of Kerberos or TLS client certificates is the strongest, not sure it even makes sense to compare.) With a 'Transport' scheme (aimed at whatever HTTP can't deal with directly, in particular, TLS certificates) you could have something as follows, letting the client decide which one it prefers: HTTP/1.1 401 Authorization Required WWW-Authenticate: Negotiate ... WWW-Authenticate: Transport mode="tls-client-certificate" Otherwise, if it presents a certificate, it won't be aware that Kerberos authentication could also have been used. This might have been a better choice (especially if the certificate that this client has is accepted by the server, but not sufficient to grant authorisation to the resource). In addition, and that's a slightly separate issue, this could be a clean way to manage change of identity or credentials during renegotiation, which isn't really specified at the moment as far as I know. More information at the HTTP layer, regarding specific resources, could be useful for choosing a certificate in cases where the client has more than one certificate accepted by the server's TLS settings (whether or not by the same CA). This could be useful for the renegotiation bug. For example, in the following exchange where the renegotiation happens between "X-Ignore: " and "GET": * Client->MitM->Server: POST /create/something/bad HTTP/1.0 X-Ignore: GET / HTTP/1.1 * Server->Client: HTTP/1.0 201 Created ... Instead, if the server was able to convey to the HTTP layer that a renegotiation had happened, it would send a 401, telling the client simply to re-send its original request, to make sure it was indeed the client: * Client->MitM->Server: POST /create/something/bad HTTP/1.0 X-Ignore: GET / HTTP/1.1 * Server->Client (a new handshake was detected, so it sends 401 for safety): HTTP/1.0 401 Authorization Required WWW-Authenticate: Transport ... * Client->Server: GET / HTTP/1.1 * Server->Client: HTTP/1.0 200 OK ... (If the MitM tried to renegotiate again, there would be another 401, etc.) 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