Re: FYI: proposal for client authentication in TLS

Hi Martin,

Julian asked me to also review your drafts. So I took the opportunity to dive a into the subject.
Here are the few things that caught my attention.

1) http://datatracker.ietf.org/doc/draft-thomson-tls-care/?include_text=1

The TLS spec [1] reads: "In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption."
Currently I find no text about this. It seems clear that the new extension only applies to initial session handshakes. However, I think this should be stated explicitly.


2) http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/?include_text=1

> Abstract
> 
>    This document defines an HTTP authentication scheme that can be added to a
>    response to indicate to a client that a response will only be
>    provided over a TLS connection, and only if the client has provided a
>    certificate on that connection.
Perhaps the two responses should be qualified as "error response" and "successful response"? 

> 1.  Introduction
> 
>    [...] 
>    This document defines a new type of authentication scheme,
>    "ClientCertificate" for use in HTTP authentication challenges
>    [I-D.ietf-httpbis-p7-auth].
> 2.  Client Certificate Challenge
> 
>    A new kind of authentication scheme (auth-scheme
>    [I-D.ietf-httpbis-p7-auth]) for the "WWW-Authenticate" and "Proxy-
>    Authenticate" header fields is defined with the name
>    "ClientCertificate".
Two places where I'd rather trim the text a bit. Replace "type/kind of authentication scheme" by "authentication scheme".
 
> 2.  Client Certificate Challenge
> 
>    [...]
> 
>    A challenge with this auth-scheme does not define the use of any
>    parameters other than "realm".
The HTTP spec [2] describes the realm parameter in terms of resources: A client may reuse an authorization that was previously cached as successful for this resource.
It remains unclear, what the semantics of the realm parameter should be in context of this new authentication scheme. Even more so, since the client is expected to turn to the lower TLS protocol level, where resources have no meaning.
How do clients interact with servers using more than one protection space?
A realm (i.e. a protection space) is coupled to the server's host name. So taken to TLS this means that the SNI extension becomes mandatory?


Best regards,
Michael

[1] http://tools.ietf.org/html/rfc5246#section-7.4.1.4
[2] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-26#section-2.2


Am 08.03.2014 um 12:39 schrieb Martin Thomson:

> Pursuant to our discussion on TLS renegotiation, I've submitted part 1
> of the solution I proposed as an internet draft.
> 
> http://datatracker.ietf.org/doc/draft-thomson-tls-care/
> 
> If we agree to a mechanism whereby we augment the 401 status code with
> a "go away and make a new TLS connection with client authentication",
> then this is necessary, so that the server knows to request a client
> certificate.
> 
> --Martin
>