[TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
Cas Cremers <cas.cremers@cs.ox.ac.uk> Fri, 10 February 2017 12:44 UTC
Return-Path: <cas.cremers@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E8F12962B for <tls@ietfa.amsl.com>; Fri, 10 Feb 2017 04:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sijLcHcLLwBq for <tls@ietfa.amsl.com>; Fri, 10 Feb 2017 04:44:19 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 D2D381295E0 for <tls@ietf.org>; Fri, 10 Feb 2017 04:44:18 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id x1so20687544lff.0 for <tls@ietf.org>; Fri, 10 Feb 2017 04:44:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=FVlpW/jcXyOw6/HfkFxoRlbwVO9F0guo62LstWMyirg=; b=pOGjKXVsbo1jixY+hP71B7JnyArKeoABzGYQqfhjYafgnabW9KZxK6P0FcOwBdoG5a f25VgbhMjU3COzNYKs3fs9DKpdIGjXuDq57chTX9rPSQtw+tgPoVfmC/MaBoetCRq4aH Kr/M1rlSm/CXCN2zR0zRTdOlUBoa+V2C6zBa8PioXvkFV0k7ae+oMMtootOomuIyGt4X kLhQJlZd+ZrJTaQaPz98kw+dYqtT/71EpFva4m2stdPYJpY1hprhZuIPM4LcnpU+bw4j hoPSrG5qL696dHms6NeINNrp85P8RFm0ZWygLlyCrzjP6XM2e76dkQ/Xzefn2M6f+mKe OI5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=FVlpW/jcXyOw6/HfkFxoRlbwVO9F0guo62LstWMyirg=; b=RsOfZzoRu8SCjWSOsYaLGWDg/O/9spCt7rmqRkdLRmTXmm9MEFvocSTDFEHjNqKXVa Cz9K3O2PXNE47dUfvAq1NEgGenWO3ecEbF2yMXRF/tZE0eW9A2jJXVnkiiJOWx3KHPuF TddPDW1EZLdO2/BsRQLmRWU2NXwrkv8cu5mQvguojKkWo6wOeMTzp8gLIUf5v3C8bglU nNVmbnQAX/8O28CgP48WNc468VV4TCMTELLfChj6ETdy7BaGtBr64KL/LYQlnb3iU7qy HZ+qFpRh/fMvrVrStq7FtH5+GlHT7D2UASwYx7zXDrrUAl8VynG4iAlAajOmLw/NjkdP HM8A==
X-Gm-Message-State: AMke39kWOmYeiVx4KU99b8bU+IyzJl3RpjFaIC5Xsg29Te+eFzmbmwvZvLRlYpsQ1EmEuDHZ6BeA8rnWvw2RmQ==
X-Received: by 10.25.40.4 with SMTP id o4mr2986443lfo.1.1486730656873; Fri, 10 Feb 2017 04:44:16 -0800 (PST)
MIME-Version: 1.0
Sender: cas.cremers@gmail.com
Received: by 10.46.0.164 with HTTP; Fri, 10 Feb 2017 04:43:56 -0800 (PST)
From: Cas Cremers <cas.cremers@cs.ox.ac.uk>
Date: Fri, 10 Feb 2017 12:43:56 +0000
X-Google-Sender-Auth: pV01NsbctYxnYURN7FF9jsrPw18
Message-ID: <CABdrxL53Fd7tY6+qF-p=acvCDa=hvbPov83XSd-Y8-gB3c33Ag@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a11410e58ae04ce05482c743f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/crdSCgiW-94z2joulYJtuA52E9E>
Subject: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 10 Feb 2017 12:44:22 -0000
Dear all, In the process of completing our Tamarin analysis of TLS 1.3 revision 18, we hit upon some behaviour that may lead to applications making incorrect assumptions. It is not an immediate attack, but we can imagine scenarios where it can cause problems. We describe it below, and show that it is possible to adapt the protocol (leveraging existing mechanisms) to avoid a mismatch. Currently, the post-handshake client authentication does not cause updates to the transcript, and does not necessarily trigger key updates. As a result, the post-handshake client authentication offers substantially lower guarantees *for the client* than the normal mutual authentication. To see why this is the case, consider the following two properties that hold for the mutually authenticated handshake: (A) After the mutually authenticated handshake, a client who sends some data can be sure that if the server receives it, the server will be aware that it comes from an authenticated client. (B) After the mutually authenticated handshake, a client who receives some data can be sure that when the server sent it, the server was aware that it was sending it to an authenticated client. (Formally: upon receiving data, the client has agreement with the server on the status (unilateral/mutual) of the connection.) >From our analysis we have concluded that no such properties hold for the post-handshake client authentication. The reason is that the post-handshake client authentication does not change the transcript, and does not trigger a key update: effectively, the server has no way of informing the client that it has actually processed the post-handshake client authentication. Thus, the client will get identical future messages, irrespective of whether the server received the client authentication. Generally speaking, a unilaterally authenticated connection should have a different context, and therefore different keys, than a mutually authenticated connection. Currently, this is not the case for the post-handshake authentication. Potential problem scenario Assume that the server has two security policies: if a message is received from an authenticated client, it is marked as "top secret" and stored safely. If a message is received from an unauthenticated client, it is stored in plaintext or even published in a log. After a mutual authentication handshake, if the client sends some critical data then it can be sure this is stored securely. However, this is not the case for a post-handshake client authentication. After performing a post-handshake authentication (in which the client sends its certificate), and possibly after exchanging further messages with the server, the client may send some critical data. This data may be stored insecurely as there will be a mismatch between the client and server’s respective views of authentication if the post-handshake authentication messages are not processed by the server and/or dropped by an attacker. Option 1: Fix In our view, the unilateral/mutual authentication status should be part of the context, and thus correspond to different keys. We are aware that the server’s request for post-handshake authentication is desired to be asynchronous (since user input might be needed). The most natural fix to the problem therefore is to include the client's response authentication messages (certificate etc.) in the message transcript, and require key updates. Option 2: Partial fix It is also possible to simply update the keys, leaving the transcript as is. This allows the client to infer whether his authentication message was received. However it does still allow for re-ordering of some messages. This has the disadvantage that the client certificate is still not included in the context, which may be problematic further down the line. Option 3: Don’t fix (“Somebody Else’s Problem shield”) If we do not change the protocol, the draft should be updated to explicitly state that after a post-handshake authentication, the client can make no assumptions on the authentication status of the connection (mutual or unilateral). If the client would like to know the perceived status, it could ask the application layer. We do not advocate this solution, since the resulting difference between the guarantees of a regular mutually authenticated handshake and a post-handshake client authentication will surely lead to problems somewhere, and client applications will wrongly assume that after they send the post-handshake certificate, the server is aware that the connection is mutually authenticated. Tamarin analysis Using Tamarin, we showed that the properties (A) and (B) hold for the normal mutually authenticated handshake. We also showed that similar properties do not hold after the post-handshake client authentication, and we obtain the obvious counter-examples. If we apply the partial fix (2), the counter-examples indeed disappear. Conclusion In revision 18, the client can not be sure that the server agrees on the client’s authentication status after post-handshake authentication, even after exchanging further messages. To avoid problems at the application level, we would prefer this agreement to be ensured. Best wishes, Cas Cremers, Marko Horvat, Jonathan Hoyland, Sam Scott, and Thyla van der Merwe.
- [TLS] Awkward Handshake: Possible mismatch of cli… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… Ilari Liusvaara
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Victor Vasiliev
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Benjamin
- Re: [TLS] Awkward Handshake: Possible mismatch of… Ilari Liusvaara
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Thomson
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Rex
- Re: [TLS] Awkward Handshake: Possible mismatch of… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Benjamin
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Rex