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

Sam Scott <sam.scott89@gmail.com> Sat, 31 October 2015 11:19 UTC

Return-Path: <sam.scott89@gmail.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 03B221B3792 for <tls@ietfa.amsl.com>; Sat, 31 Oct 2015 04:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level:
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] 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 gXoZr8lg_teU for <tls@ietfa.amsl.com>; Sat, 31 Oct 2015 04:19:23 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 B712B1B377F for <tls@ietf.org>; Sat, 31 Oct 2015 04:19:22 -0700 (PDT)
Received: by wmll128 with SMTP id l128so28961738wml.0 for <tls@ietf.org>; Sat, 31 Oct 2015 04:19:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type; bh=D7XfdGf/lbJoGa1226zEtY/pzsYNaGU6p3a4dIdwRjA=; b=Vkh9fKIyf+LMPdkW1De0yXG0Hg2PsQwHcMMTwFs1oxWZTS69tY2VyGmWxkSihaKiLP 4xF+AVJ20QqK2I1K5l0CDlrHqdJdQxSv57ywiRds9MIOJPhkn7fYOQGOz9H3ToS+iurU vioV+gyBxakpOfajGbcbLPQDPUicov4M2AZVxRxjQkzHhCxEmPePe1svlPAnBb8n9RDT MPVzbZnsa+DqF+kZ5q0USEh4HvZYW6hK8fKljkVj5OtSeVwLE7cUEQUoxFJa8V/z6wia idNzDcb8oSoUrbBBliRodukrUfXEkhW13a4Ifch7Na5KIDj8LKnsrsBgPNPVizas29gR Ob9Q==
X-Received: by 10.28.143.79 with SMTP id r76mr3378504wmd.102.1446290361376; Sat, 31 Oct 2015 04:19:21 -0700 (PDT)
Received: from [192.168.0.11] (97e4ce0a.skybroadband.com. [151.228.206.10]) by smtp.gmail.com with ESMTPSA id 5sm7435727wmg.14.2015.10.31.04.19.20 for <tls@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Oct 2015 04:19:20 -0700 (PDT)
From: Sam Scott <sam.scott89@gmail.com>
To: tls@ietf.org
Message-ID: <5634A3B8.7070701@gmail.com>
Date: Sat, 31 Oct 2015 11:19:20 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------060906030009050808090007"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA>
Subject: [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 11:20:33 -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/