[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.