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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
