Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 1 Nov 2015 11:01:11 +0200

On Sun, Nov 01, 2015 at 04:36:43AM +0900, Eric Rescorla wrote:
> 
> I've been planning to do a big rewrite of the security "analysis" sections
> and while I don't think it's worth having a real analysis in the protocol
> (the literature is going to do a much better job here than we can), this
> seems like exactly the kind of thing that we do want to capture to
> explain the design and for future extensions.

What I think is also very important with regards to security is
explaining the properties of interfaces to applications.

E.g. I want to be able to find answer to "Can I authenticate a client
by reading value off TLS-EXTRACTOR and signing it?"[1][2] in the final
RFC.

Or "Can I key something non-TLS off TLS-Extractor" (yes).

And with regards to protocol analysis, the thing that nails
you with highest probability (after known bad ideas) is some
oddball feature that nobody really analyzes (or analyzes in
non-realistic ways, for this documenting assumptions at
external interface is VERY useful). These often allow taking
cracks in one part of the protocol and then amplifying those
to actual attacks.

[1] The answer being: Yes, but:
- You also need ciphersuite if you need cross-collision resistance
  (TLS certificate auth would be vulernable to CC if another PRF-
  hash with 256 or 384 bit output was added).
- In versions previous to TLS 1.3, you need extended_master_secret
  negotiated (because otherwise TLS-Extractor outputs aren't nonces).

[2] While TLS does have built-in client certificate authentication,
application-layer certificate authentication can be much more
flexible, doing things that are just plain infeasible to do in
TLS layer (like fine-grained authentication).

-Ilari

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sun, 1 Nov 2015 10:19:58 +0100

Nice analysis! I think that the composition of different mechanisms in the protocol is likely to
be where many subtle issues lie, and analyses like this one support that concern.

Several other composition examples were already discussed on this list (for previous drafts).
For example, when composing 0-RTT with 1-RTT in the most natural way, many attacks appeared:
   (1) 0-RTT application data  may be replayed (See note (2) in 6.2.2.)
   (2) an unknown key share attack on 0-RTT encryption keys (leading to the inclusion of ServerCertificate in 0-RTT handshake hash in 7.2.1)
   (3) a key compromise impersonation attack on 0-RTT (See note (3) in 6.2.2)

The addition of resumption, PSK, and client-auth provide plenty of further composition possibilies
that are (in my surely biased opinion) best handled by automated formal analysis. 
So, I’m looking forward to the full Tamarin results!

Best,
Karthik

> On 31 Oct 2015, at 12:19, Sam Scott <[email-masked]> wrote:
> 
> Dear all,
> 
> We [1] are in the process of performing an automated symbolic analysis
> of the TLS 1.3 specification draft (revision 10) using the Tamarin
> prover [2], which is a tool for automated security protocol analysis.
> 
> While revision 10 does not yet appear to permit certificate-based client
> authentication in PSK (and in particular resumption using PSK), we modelled
> what we believe is the intended functionality. By enabling client
> authentication either in the initial handshake, or with a post- handshake
> signature over the handshake hash, our Tamarin analysis finds an attack. The
> result is a complete breakage of client authentication, as the attacker can
> impersonate a client when communicating with a server:
> 
> Suppose a client Alice performs an initial handshake with Charlie. Charlie,
> masquerading as Alice, subsequently performs a handshake with Bob. Following a
> PSK resumption, Bob requests authentication from Charlie (impersonating Alice).
> Charlie then requests authentication from Alice, and the returned signature
> will also be a valid signature for the session with Bob.
> 
>         Initial h/s                                      Initial h/s
>      |<-------------->|                               |<-------------->|
>      |  exchange PSK  |                               |  exchange PSK  |
>      |                |                               |                |
>      |Start PSK resume|                               |Start PSK resume|
>      |--------------->|                               |--------------->|
>      |client_random nc|                               |client_random nc|
>      |                |                               |                |
>      |  Accept resume |                               |  Accept resume |
> Alice|<---------------|(as Charlie) Charlie (as Alice)|<---------------|Bob
>      |server_random ns|                               |server_random ns|
>      |                |                               |                |
>      |                |                               |                |
>      |Client auth req |                               |Client auth req |
>      |<---------------|                               |<---------------|
>      |                |                               |                |
>      |  Client auth   |                               |  Client auth   |
>      |--------------->|                               |--------------->|
>        sign nc,ns,...                                  relay signature
> 
> 
> 
> This attack is possible because the client signature is over the handshake
> hash, which only covers the nonces and other easily duplicated information,
> and in particular does not contain the server certificate (because none is
> presented in PSK mode [3]) or the server Finished.
> 
> While the modifications proposed in PR#316 [4] explicitly allow client
> authentication in these contexts, the PR also redefines the client signature
> based on a new "Handshake Context" value which includes the server Finished
> message. Intuitively, this new definition appears to address the attack
> because the attacker cannot transplant the Finished message between
> connections. We are currently working towards a Tamarin proof that PR#316
> indeed prevents our attack.
> 
> Therefore we would like to support the inclusion of Finished as
> part of the handshake context, in order to address this problem.
> 
> Many thanks,
> 
> Sam Scott
> 
> [1] Cas Cremers, Marko Horvat - University of Oxford;
>     Thyla van der Merwe, Sam Scott - Royal Holloway, University of London.
> [2] http://www.infsec.ethz.ch/research/software/tamarin.html <http://www.infsec.ethz.ch/research/software/tamarin.html>
> [3] Except in 0-RTT where the server's Certificate is explicitly
>     included.
> [4] https://github.com/tlswg/tls13-spec/pull/316/ <https://github.com/tlswg/tls13-spec/pull/316/>_______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls