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

Eric Rescorla <ekr@rtfm.com> Sat, 31 October 2015 13:56 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E711B37D5 for <tls@ietfa.amsl.com>; Sat, 31 Oct 2015 06:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5lA618Crx_L for <tls@ietfa.amsl.com>; Sat, 31 Oct 2015 06:56:05 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE9C1B37DA for <tls@ietf.org>; Sat, 31 Oct 2015 06:56:04 -0700 (PDT)
Received: by ykft191 with SMTP id t191so101528156ykf.0 for <tls@ietf.org>; Sat, 31 Oct 2015 06:56:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RpPcJXD+MjmAH2Z0857l7rpCOV3hrU0vvKFCUSDaXGI=; b=iTHlq1h+p/bk2guSzawGOmUVN/IN6yfer8hs8/Sguz0qxze/Vb9jseuybZbrjapfnq hKvu8o5rtL38jZNgVabHdCuxjNXsUP8ZYGIoZEVGnp1GivV2vRser6N8GC1SWj35tLh0 Seq+lqEDKuDtAY8uZiVCYzQWVZAIXiWd/kAFtcMwqW1NDbHaxaoyCMwbxaTw5MjUhp0o W2QQZtdRrkYnwQZ/rKFEqruxmicu3dWB9xsYHm9fE+ob5Zwb57H4DTnFlinHc0mnlOOO OLqxB9v/YGkDIU8EWUkoeaQIn9MQ9hCDznfC2ez9NnMxOaX8C2cmkKVyD0/joJ+q2NCg wCPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RpPcJXD+MjmAH2Z0857l7rpCOV3hrU0vvKFCUSDaXGI=; b=cETiAq6AkBN0Pgij33KwwN7kVcBRDAbTyg5xuM1mOPhy5ENnSWFtGdiBOIi4/R0erH eqJx/CaAVmgvQGv3pN7Zyt4tFsgGTu4RCARWRkw9lycvAm84w78+vqiRZigeYH+FaV2p MbKbT7We6ZfSQgwTlhqelV7IcCpUrtNS0HS8tRz7zUcF9rneAjc8c9Hc76L+Me9+Pscu xHqU8B9Q20OWRkuZxkk+ZB43knBEHtry/2JZcemTzIs0dXG8VomtILFh5PBjfl2/xvwx o42cL7m44OouhCS4NWMeHxAXw13Oo2c43gQfEddVreEugNArWjAYcL/sQSirEMR7qNQl LwJQ==
X-Gm-Message-State: ALoCoQmV3d7DfnqLtrizrT7yV6LUDmjMPTHaekfJM6GFOT94rW8gqGNlnpiefG2Q+dtL+PtDy8Kl
X-Received: by 10.129.130.6 with SMTP id s6mr10131878ywf.155.1446299764061; Sat, 31 Oct 2015 06:56:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Sat, 31 Oct 2015 06:55:24 -0700 (PDT)
In-Reply-To: <5634A3B8.7070701@gmail.com>
References: <5634A3B8.7070701@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 31 Oct 2015 22:55:24 +0900
Message-ID: <CABcZeBPNHPzywr89wLgV4zWKjKXXk_kyxoV75pYOuuuK=QO9=A@mail.gmail.com>
To: Sam Scott <sam.scott89@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c07c35ead29fb052366e74b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/VPM2kbxqaBYo1xWvsGMFPeiR6rs>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2015 13:56:07 -0000

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 <sam.scott89@gmail.com> 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
> [3] Except in 0-RTT where the server's Certificate is explicitly
>     included.
> [4] https://github.com/tlswg/tls13-spec/pull/316/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>