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

From: Sam Scott <[email-masked]>
Date: Sat, 31 Oct 2015 11:19:20 +0000

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
[3] Except in 0-RTT where the server's Certificate is explicitly
     included.
[4] https://github.com/tlswg/tls13-spec/pull/316/

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 31 Oct 2015 15:32:31 +0200

On Sat, Oct 31, 2015 at 11:19:20AM +0000, Sam Scott wrote:
> what we believe is the intended functionality.

Eh, I thought that using static client certificate auth with PSK is not
supposed to be possible.

BTW: TLS 1.2 doesn't seem to explicitly prohibit client auth with PSK, and
if client and server try to use client certs with PSK, bad things happen...

> indeed prevents our attack.

By my reading, #316 does not permit static client authentication with
PSK (it only permits dynamic auth, which didn't even exist previously),
most definitely not explicitly.

Also, found out that -10 looks to be at least unclear about if the
server Finished is included in the data to be signed or not...

I also searched when this got broken. Looks to be part of "DH-based
key exchange" changes in -07 (in -06, hashes definitely did include
finished messages).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 31 Oct 2015 22:55:24 +0900

Sam,

Thanks for posting this. It's great to see people doing real formal
analysis of the TLS 1.3 draft; this is really helpful in guiding the design.

As you say, the current draft-10 doesn't permit certificate-based client
authentication when PSK is used [0], but it's clear that we want to at least
be able to have this in the post-handshake case (since otherwise you
wouldn't be able to do on-the-fly client auth with a resumed handshake),
and this shows that we have to be very careful when we do that.
Note: It's less clear we want to allow this in the initial handshake, if
only
because it complicates the state machine.

This result motivates and confirms the need to modify the handshake hashes
to contain the server Finished when we add post-handshake authentication
as is done in PR#316, which of course we'll be discussing in Yokohama.
I'd be very interested in learning of the results you get when you model
that.

Thanks again for your contribution here. It's really important to have
this kind of analysis, especially at this stage before the design is
completely
hardened.

Best,
-Ekr

[0] Client auth doesn't appear in the PSK diagram in Figure 4
and Section 6.3.5 requires that CertificateRequest appear after a
Certificate
which clearly isn't possible with PSK:

      A non-anonymous server can optionally request a certificate from
      the client, if appropriate for the selected cipher suite.  This
      message, if sent, will immediately follow the server's Certificate
      message.

https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-6.3.5

On Sat, Oct 31, 2015 at 8:19 PM, Sam Scott <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 31 Oct 2015 16:29:46 +0200

> I'd be very interested in learning of the results you get when you model

Looking at the issue at wider angle, this soundness hole appears anytime
handshake_messages and configuration do not jointly represent the static
secret (the inclusion of server Finished fixes it for client signature,
because server Finished represents the static secret).

If TLS ever gets mode that combines that non-representation with static
server certificate auth (no idea what such mode could be), one gets
problems with server auth.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 1 Nov 2015 04:36:43 +0900

> problems with server auth.

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.

Thanks,
-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 1 Nov 2015 03:39:32 +0000

> this kind of analysis, especially at this stage before the design is

+many,

Thanks,
S.