[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] [Fwd: WWW-Authenticate challenge for client-certificates]
From:       Bruno Harbulot <Bruno.Harbulot () manchester ! ac ! uk>
Date:       2010-01-22 16:13:27
Message-ID: 4B59CEA7.7060201 () manchester ! ac ! uk
[Download RAW message or body]

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.


[prev in list] [next in list] [prev in thread] [next in thread]