Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding

From: Karthik Bhargavan <[email-masked]>
Date: Tue, 22 Mar 2016 17:36:50 +0100

I was staring at the latest draft of draft-ietf-tokbind-https-03 and the text on man-in-the-middle detection in Section 4.3 seems a bit too strong, and I would suggest adding caveats here, or in the security considerations.

By using EKM, and by relying on extended master secret, the token binding protocol indeed protects against MitM attacks where either
(a) the attacker has a mis-issued certificate for the server (token consumer or token provider), or
(b) the attacker has fooled the user agent into accepting a bogus certificate for the server, or
(c) the attacker is a malicious server who is seeking to forward the user’s token to a different server.

However, there are other MitM scenarios that are not protected by Token Binding
(d) if the server’s certificate private key is compromised and the TLS connection between the client and server uses RSA key transport, 
   then the attacker can tamper with the connection (and hence with the Token Binding HTTPS headers) without being detected
(e) if the server is vulnerable to RSA Bleichenbacher attacks (as in Drown), 
   then the attacker can obtain the PMS, hence the MS, and again tamper with the application data without being detected
(f)  if the attacker obtains the session master secret between the client and server, 
   either by stealing it from a session cache, or by breaking the ticket encryption key,
   then in subsequent resumption handshakes the attacker can tamper with the application data without being detected.

These last three scenarios are undoubtedly very strong attackers and may be out-of-scope for Token Binding, but I think
it is important not to give the impression that the use of EKM + EMS in token binding will prevent all MitM attacks on TLS.

If it is indeed important to prevent (d,e,f), then Token Binding should further recommend that the TLS client or server
should only enable forward-secure DHE/ECDHE ciphersuites  (this is what ChannelId did) and warn about the risks
of compromised session secrets or ticket encryption keys.

Best,
Karthik

---

From: Andrei Popov <[email-masked]>
Date: Tue, 22 Mar 2016 17:43:50 +0000

Thanks for reviewing the I-Ds, Karthik.

(d), (e) and (f) essentially involve total breakage of TLS. Truly, if one's binding is to a completely broken TLS channel, then the binding does not help at all. This seems to be fairly obvious, but perhaps we can add this caveat to the security considerations if the group believes it's useful.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Karthik Bhargavan
Sent: Tuesday, March 22, 2016 9:37 AM
To: [email-masked]
Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding

These last three scenarios are undoubtedly very strong attackers and may be out-of-scope for Token Binding, but I think it is important not to give the impression that the use of EKM + EMS in token binding will prevent all MitM attacks on TLS.

If it is indeed important to prevent (d,e,f), then Token Binding should further recommend that the TLS client or server should only enable forward-secure DHE/ECDHE ciphersuites  (this is what ChannelId did) and warn about the risks of compromised session secrets or ticket encryption keys.

Best,
Karthik
_______________________________________________
Unbearable mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d

---

From: Dirk Balfanz <[email-masked]>
Date: Tue, 22 Mar 2016 18:15:28 +0000

Hi Karthik,

can you explain a little more? Token Binding doesn't (claim to) prevent any
of these - (a) through (f). What it *does* claim is that authentication
tokens obtained as a side effect of such attacks won't be usable by anyone
other than the legitimate client to which they were issued.

For an attacker to be able to successfully use a stolen authentication
token, he would have to produce a legitimate signature over the EKM of a
new connection, using the client's private key. Since none of the attacks
assume that the attacker actually knows the client's private key, the
attacker can only do this if he can create a connection to the server with
an EKM that is identical to previous connection (and re-use a previous
signature). It's not sufficient to *know* what the MS (and EKM) of that
previous connection is - he must be able to *establish a new connection*
with that same EKM with the server (so that he can re-play a previous
signature to that server). Are you saying that (d) through (f) allow the
attacker to do that?

Dirk.

On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov <[email-masked]>
wrote:

> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if
> one's binding is to a completely broken TLS channel, then the binding does
> not help at all. This seems to be fairly obvious, but perhaps we can add
> this caveat to the security considerations if the group believes it's
> useful.
>
> Cheers,
>
> Andrei
>
> I was staring at the latest draft of draft-ietf-tokbind-https-03 and the
> text on man-in-the-middle detection in Section 4.3 seems a bit too strong,
> and I would suggest adding caveats here, or in the security considerations.
>
> By using EKM, and by relying on extended master secret, the token binding
> protocol indeed protects against MitM attacks where either
> (d) if the server’s certificate private key is compromised and the TLS
> connection between the client and server uses RSA key transport,
>    then the attacker can tamper with the connection (and hence with the
> Token Binding HTTPS headers) without being detected
>    then the attacker can obtain the PMS, hence the MS, and again tamper
> with the application data without being detected
>    then in subsequent resumption handshakes the attacker can tamper with
> the application data without being detected.
>
> These last three scenarios are undoubtedly very strong attackers and may
> be out-of-scope for Token Binding, but I think it is important not to give
> the impression that the use of EKM + EMS in token binding will prevent all
> MitM attacks on TLS.
>
> If it is indeed important to prevent (d,e,f), then Token Binding should
> further recommend that the TLS client or server should only enable
> forward-secure DHE/ECDHE ciphersuites  (this is what ChannelId did) and
> warn about the risks of compromised session secrets or ticket encryption
> keys.
>
> Best,
> Karthik
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Karthik Bhargavan <[email-masked]>
Date: Tue, 22 Mar 2016 19:32:42 +0100

Hi Dirk, Andrei,

To be clear, I am not really claiming that Token Binding should protect against these kinds of attacks,
because as Andrei points out, a binding to a broken channel is not all that useful. 
I am mainly concerned that the text in 4.3 referring to a man-in-the-middle attacker may need
to be toned down to clarify what kinds of man-in-the-middle attackers can be detected by binding mismatch.

For example, if the server’s certificate private key is known to the attacker, then he can mount
a man-in-the-middle attack where he relays all TLS handshake messages unchanged to the
real server, resulting in the same EKM on both connections. At this point Token Binding cannot
detect the attacker. (Of course, this kind of attacker can break RSA connections at leisure and is quite powerful.)

Similarly, an attacker who knows the MS can MitM a resumption handshake in a way that the EKM on
both connections is the same. 

Perhaps surprisingly, forward-secure TLS handshakes (such as ECDHE/DHE) cannot obviously be attacked this
way, but resumption and RSA can. That is all I meant to indicate.

Best,
Karthik

> On 22 Mar 2016, at 19:15, Dirk Balfanz <[email-masked]> wrote:
> 
> Hi Karthik, 
> 
> can you explain a little more? Token Binding doesn't (claim to) prevent any of these - (a) through (f). What it *does* claim is that authentication tokens obtained as a side effect of such attacks won't be usable by anyone other than the legitimate client to which they were issued. 
> 
> For an attacker to be able to successfully use a stolen authentication token, he would have to produce a legitimate signature over the EKM of a new connection, using the client's private key. Since none of the attacks assume that the attacker actually knows the client's private key, the attacker can only do this if he can create a connection to the server with an EKM that is identical to previous connection (and re-use a previous signature). It's not sufficient to *know* what the MS (and EKM) of that previous connection is - he must be able to *establish a new connection* with that same EKM with the server (so that he can re-play a previous signature to that server). Are you saying that (d) through (f) allow the attacker to do that?
> 
> Dirk.
> 
> 
> On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov <[email-masked] <mailto:[email-masked]>> wrote:
> From: Unbearable [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Karthik Bhargavan
> To: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>

---

From: Karthik Bhargavan <[email-masked]>
Date: Tue, 22 Mar 2016 20:21:44 +0100

> For an attacker to be able to successfully use a stolen authentication token, he would have to produce a legitimate signature over the EKM of a new connection, using the client's private key. Since…

I am saying that there are certain powerful attackers (d-f) that can persistently MitM connections between the client and the server.
In that case, they don’t need to now the client’s private key, they can simply forward the client’s signature over the EKM along with 
the token-bound credentials to the server, and then freely tamper with the connection afterward.  
This is an obvious “attack” on the HTTPS channel and arguably should not be Token Binding’s concern. 
Perhaps this is already clear to Token Binding users, but if not, adding a sentence to clarify the claims would perhaps be useful.

-K

---

From: Vinod Anupam <[email-masked]>
Date: Tue, 22 Mar 2016 12:28:45 -0700

On Tue, Mar 22, 2016 at 12:21 PM, Karthik Bhargavan <
[email-masked]> wrote:

> I am saying that there are certain powerful attackers (d-f) that can
> persistently MitM connections between the client and the server.
> In that case, they don’t need to now the client’s private key, they can
> simply forward the client’s signature over the EKM along with
> Perhaps this is already clear to Token Binding users, but if not, adding a
> sentence to clarify the claims would perhaps be useful.
>
> -K
>
>
>
Per https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02,
Token Binding negotiation requires that
Extended Master Secret [RFC7627] and
Renegotiation Indication [RFC5746] TLS extensions have also been negotiated.

Does that not address the attack that you are referring to?

cheers,
-Anupam

---

From: Dirk Balfanz <[email-masked]>
Date: Tue, 22 Mar 2016 20:59:35 +0000

> be Token Binding’s concern.

Well, Token Binding does, in a sense, claim to protect the user when
certain things break in TLS. So the specs should be clear about what those
"certain things" are. :-)

For example, the hearbleed attack was a flaw in (some implementations of)
TLS that exposed authentication tokens. Token Binding inoculates the user
against such vulnerabilities.

On the other hand, we thought (until the triple-handshake attack was
discovered) that a man-in-the-middle couldn't force the same EKM on two
unrelated connections, and that therefore Token Binding protects the user
from MitM attacks. Now that the triple-handshake attack is known, we
require the extended master secret for Token Binding, again putting us in a
position where we believe a MitM can't force the same EKM on two unrelated
connections. MitMs not being able to do that (even if they can "break" TLS
in other ways, like in heartbleed) is an important precondition for the
security claims of Token Binding.

But it's certainly possible that saying "the extended master secret
guarantees that no MitM can force the same EKM on two unrelated
connections" is too strong. Maybe a MitM in possession of the server's
private key, using RSA modes, can still force the EKM to be the same on two
different connections? I'm not sure whether that was within the threat
model of the triple handshake attack, or the extended master secret
remediation. If such a MitM can still force the same EKM, I'd agree that
(d) is indeed a situation that we need to explain we don't protect against.

What do you think? Is (d) an example in which the same EKM can be forced on
two connections? How about (e) and (f)?

Dirk.

---

From: Karthik Bhargavan <[email-masked]>
Date: Tue, 22 Mar 2016 23:08:44 +0100

> But it's certainly possible that saying "the extended master secret guarantees that no MitM can force the same EKM on two unrelated connections" is too strong. Maybe a MitM in possession of the server's private key, using RSA modes, can still force the EKM to be the same on two different connections? I'm not sure whether that was within the threat model of the triple handshake attack, or the extended master secret remediation. If such a MitM can still force the same EKM, I'd agree that (d) is indeed a situation that we need to explain we don't protect against. 

Yes, you got it right. As you can guess I am worried about people expecting too much from RFC7627 :)
(d), (e), and (f) and more generally any TLS attack that exposes the record encryption key to the attacker
without the need for an active attack on the handshake will result in a case that the attacker can make the EKM on two connections the same.
Whether these two connections are “unrelated” is debatable, since the attacker is forwarding messages from one connection to the other,
until the point that the handshake is complete. 

> What do you think? Is (d) an example in which the same EKM can be forced on two connections? How about (e) and (f)?

Yes, compromised server private key (for RSA connections), DROWN, compromised ticket encryption key (for resumption), are all
cases where the attacker can force EKM on two connections to be the same (simply by forwarding messages from one to another.)

The above are powerful attackers but the reason for EKM synchronization is pretty trivial: i.e the attacker breaks the TLS key.
Another, more expensive attack I can think of is when because of the SLOTH attack, the attacker can force the EKM on both connections to be the
same by causing a transcript collision in the session hash (this costs 2^128 SHA-256 hashes in TLS 1.2 and 2^77 SHA-1 hashes in TLS 1.0/1.1).

Best,
Karthik