[TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[Cas Cremers <[e-mail]>]

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.