Re: Report on preliminary decision on TLS 1.3 and client auth

[Amos Jeffries <[e-mail]>]

On 24/09/2015 5:16 a.m., Martin Thomson wrote:
> The minutes of the TLS interim have been posted. Some decisions regard
> client authentication were made.
> 
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
> 
> Here is a summary of the applicable pieces, plus what I options it provides
> HTTP/2...
> 
> (Caveat here: aspects of this could change if new information is presented,
> but it seems unlikely that there will be changes that will affect the core
> decisions.)
> The big change is that a server can request client authentication at any
> time. A server may also make multiple such requests. Those multiple
> requests could even be concurrent.
> 
> The security claims associated with client authentication require more
> analysis before we can be certain, but the basic idea is that
> authentication merely provides the proof that a server needs to regard the
> entire session to be authentic. In other words, client authentication will
> apply retroactively. This could allow a request sent prior to
> authentication to be considered authenticated. This is a property that is
> implicitly relied on for the existing renegotiation cases and one that we
> might want to exploit.
> 
> Each certificate request includes an identifier that allows it to be
> correlated with the certificate that is produced in response. This also
> allows for correlating with application context. This is what I think that
> we can use to fix HTTP/2.
> 
> Clients cannot spontaneously authenticate, which invalidates the designs I
> have proposed, however, the basic structure is the basis for the first
> option that I will suggest.
> 
> 
> Option 1 uses a new authentication scheme. A request that causes a server
> to require a client certificate is responded to with a 4xx response
> containing a ClientCertificate challenge. That challenge includes an
> identifier.  The server also sends - at the TLS layer - a
> CertificateRequest containing the same identifier, allowing the client to
> correlate it's HTTP request with the server's CertificateRequest.
> 
> Client@HTTP/2:
> HEADERS
>   :method = GET ...
> 
> Server@HTTP/2:
> HEADERS
>   :status = 401
>   authorization = ClientCertificate req="option 1"
> 
> Server@TLS:
> CertificateRequest { id: "option 1" }
> 
> Client@TLS:
> Certificate+CertificateVerify { id: "option 1", certificates... }
> 
> Client@HTTP/2:
> HEADERS
>   :method = GET ...
> 
> Server@HTTP/2:
> HEADERS
>   :status = 200
> 
> 
> Option 2 aims to more closely replicate the experience we get from
> renegotiation in HTTP/1.1 + TLS <= 1.2.  Rather than rejecting the request,
> the server sends an HTTP/2 frame on the stream to indicate to the client to
> expect a CertificateRequest. That frame includes the identifier.
> 
> Client@HTTP/2:
> HEADERS
>   :method = GET ...
> 
> Server@HTTP/2:
> EXPECT_AUTH
>   id = option 2
> 
> Server@TLS:
> CertificateRequest { id: "option 2" }
> 
> Client@TLS:
> Certificate+CertificateVerify { id: "option 2", certificates... }
> 
> Server@HTTP/2:
> HEADERS
>   :status = 200
> 
> In this case, the server probably wants to know that the client is willing
> to respond to these requests, otherwise it will want to use
> HTTP_1_1_REQUIRED or 421.  So a companion setting to enable this is a good
> idea (the semantics of the setting that Microsoft use for renegotiation is
> pretty much exactly what we'd need).
> 
> I think that the first option has some architectural advantages, but that
> is all.  The latter more closely replicates what people do today and for
> that reason, I think that it is the best option.
> 
> As for how to implement this same basic mechanism in TLS 1.2, I have an
> idea that will work for either option, but it's a bit disgusting, so I'll
> save that for a follow-up email.
> 


Option 1 re-introduces all the same problems NTLM and Negotiate have
over HTTP in the presence of proxy and gateway intermediaries. By using
single-connectin authorization over a multiplexed connection environment.

It would either need to be restricted to Proxy-Authorization or some
complex logic used to determine whether Authorization or
Proxy-Authorization was the proper response header.

Lets not go there.


Option 2 risks the same mess if the AUTH frame is defined end-to-end.
But a per-hop frame would work nicely as long as it is clear to server
implementers that intermediaries may be the source of the certificate.
Not some "user".


An option 3 might be to use a SETTINGS instead of dedicated AUTH frame.
So that the per-hop nature is made extra clear. That would also be more
backward compatible with older h2 implementations and work in with
clearing dynamic compression contexts at the same time as authenticating.


Amos