PSK handhanke works like session ticket resumption in TLS 1.2, but I found a set of PSK binder
for each identity(ticket) in TLS 1.3, why PSK binder
are needed in TLS 1.3 ? To protect some attacks?
-
$\begingroup$ PreShareKey 8gwifi.org/docs/tlsv13.jsp $\endgroup$– anishSep 12, 2018 at 14:02
1 Answer
The current TLS 1.3 draft (-28) talks about the binder value:
The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the session where the PSK was
established and the current session. This binding transitively
includes the original handshake transcript, because that transcript
is digested into the values which produce the Resumption Master
Secret. This requires that both the KDF used to produce the
resumption master secret and the MAC used to compute the binder be
collision resistant. See Appendix E.1.1 for more on this. Note: The binder does not cover the binder values from other PSKs, though they
are included in the Finished MAC.
So the idea seems to be that the binder value can be used to somewhat "prove" to the server that the client knows the pre-shared key associated with a given identity (and it's the same the server remembers). This also ensures that they won't just go ahead and run a PSK handshake when they don't actually have a PSK.
Additionally it binds the previous session ('s handshake) to the current session ('s handshake) which could e.g. allow the server to discover that the client previously suffered from a MitM attack when the attacker forwarded the identifier but naturally got a different PSK on both ends and is gone for the session resumption.
To see the first property have a look at section 4.2.11.2 and section 7.1. In section 7.1 you see that the binder_key
is rather immediately derived from the PSK
. Now for session resumption the PSK
is the resumption_master_secret
. But more importantly section 4.2.11.2 tells us
The PskBinderEntry is computed in the same way as the Finished
message (Section 4.4.4) but with the BaseKey being the binder_key
derived via the key schedule from the corresponding PSK which is
being offered
and so knowledge of the binder key immediately implies knowledge of the PSK. And knowledge of the binder key is confirmed by verifying the bound message.
-
$\begingroup$ I have dug through the TLS WG archives and binders were introduced here but the concept was there before this. $\endgroup$– SEJPMJul 23, 2018 at 12:38
-
$\begingroup$ Could you give me more information(example) about how the client can prove to server it knows psk and how the binders can protect the MitM. $\endgroup$– Nail JayJul 24, 2018 at 0:59