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.