Subject: [Unbearable] Possible attack on Token Binding with RSA key exchange

From: Nick Harper <[email-masked]>
Date: Fri, 1 Sep 2017 15:03:37 -0700

I came across an attack on Token Binding today, which I think is worth
addressing in TBPROTO in some fashion (likely another paragraph in
Security Considerations). This attack involves an adversary with the
private key of a server it wishes to impersonate, and was mentioned in
draft-balfanz-tls-channelid in the last paragraph of its Security
Considerations.

In brief, if an attacker has possession of a server's private key, it
can hijack a TLS connection between client and server if the
connection uses RSA key exchange instead of (EC)DHE key exchange,
which allows the attacker to exercise the bound token without
possession of the Token Binding private key.

I realize that we're past WGLC at this point, but I think this should
be addressed. On one end, we could require forward-secret key exchange
modes with Token Binding. We could also describe this specific attack
in the Security Considerations, or we could expand the Security
Considerations to describe what attacks are and aren't in the Token
Binding threat model, to say that attacks where the adversary has the
server's private key are out of scope.

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 1 Sep 2017 22:24:25 +0000

+1 to requiring that token binding only be used with forward secure cipher suites.

I believe the extended master secret requirement of token binding prevents the attack on forward secure suites, i.e. an attacker cannot change the DH share advertised by the real server and thus needs to get the private key for it.

Subodh

________________________________
From: Unbearable <[email-masked]> on behalf of Nick Harper <[email-masked]>
Sent: Friday, September 1, 2017 3:03:37 PM
To: IETF Tokbind WG
Subject: [Unbearable] Possible attack on Token Binding with RSA key exchange

_______________________________________________
Unbearable mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_unbearable&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=aK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&s=B0sKQEO8i8hDpLizsh7X8ins9EGGwOwcckYqZku7zEE&e=

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 1 Sep 2017 22:28:08 +0000

Having said that, even if we only support forward secure ciphers, I do not think we can reasonably claim that we are secure against the threat of stolen private keys.

I like the the carrot opportunity this brings to encourage adoption of forward secure cipher suites.

Subodh

________________________________
From: Subodh Iyengar
Sent: Friday, September 1, 2017 3:24:25 PM
To: Nick Harper; IETF Tokbind WG
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange

Subodh

---

From: Andrei Popov <[email-masked]>
Date: Mon, 4 Sep 2017 22:59:30 +0000

It seems clear that binding tokens to broken TLS channels does one no good, but I don't mind adding some statements to this effect in the security considerations.
The statements would need to be general enough to cover TLS client and server compromise, PFS and non-PFS.

Nick, please feel free to author a PR. If we get to IESG review someday, there will be more edits, and we can incorporate this as well.

I don't think it makes sense to limit TB to (EC)DHE, especially if we're going to allow TB in combination with TLS 1.3 0-RTT mode.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Subodh Iyengar
Sent: Friday, September 1, 2017 3:28 PM
To: Nick Harper <[email-masked]>; IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange

Subodh

Subodh

________________________________
From: Unbearable <[email-masked]<mailto:[email-masked]>> on behalf of Nick Harper <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 1, 2017 3:03:37 PM
To: IETF Tokbind WG
Subject: [Unbearable] Possible attack on Token Binding with RSA key exchange

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_unbearable&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=aK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&s=B0sKQEO8i8hDpLizsh7X8ins9EGGwOwcckYqZku7zEE&e=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_unbearable%26d%3DDwICAg%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3Dh3Ju9EBS7mHtwg-wAyN7fQ%26m%3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM%26s%3DB0sKQEO8i8hDpLizsh7X8ins9EGGwOwcckYqZku7zEE%26e%3D&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cd5cf44853d4f4d49fdd008d4f188bfbd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636399017020307291&sdata=3NraAZRhD041W4k4OzbGj64Y9PCQweJOggRlUa9QswM%3D&reserved=0>

---

From: Nick Harper <[email-masked]>
Date: Tue, 5 Sep 2017 17:22:47 -0700

I agree that at this point it doesn't make sense to limit TB to (EC)DHE.

I'm fine with writing a PR to cover this, but I'm unsure what to put
in it. I liked how draft-balfanz-tls-channelid started its security
considerations by describing 4 classes of network attackers, and I'd
like to do something similar here. However, it's unclear to me which
of those classes of network attackers are considered as part of the
threat model for Token Binding. Would it be reasonable to say that
defending against attackers with possession of a server's private key
is outside of the scope of Token Binding?

On Mon, Sep 4, 2017 at 3:59 PM, Andrei Popov <[email-masked]> wrote:
> It seems clear that binding tokens to broken TLS channels does one no good,
> but I don’t mind adding some statements to this effect in the security
> considerations.
>
> The statements would need to be general enough to cover TLS client and
> server compromise, PFS and non—PFS.
>
>
>
> Nick, please feel free to author a PR. If we get to IESG review someday,
> there will be more edits, and we can incorporate this as well.
>
>
>
> I don’t think it makes sense to limit TB to (EC)DHE, especially if we’re
> going to allow TB in combination with TLS 1.3 0-RTT mode.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> Having said that, even if we only support forward secure ciphers, I do not
> think we can reasonably claim that we are secure against the threat of
> stolen private keys.
>
> I believe the extended master secret requirement of token binding prevents
> the attack on forward secure suites, i.e. an attacker cannot change the DH
> share advertised by the real server and thus needs to get the private key
> for it.
>
> Subodh
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 6 Sep 2017 00:33:26 +0000

> Would it be reasonable to say that defending against attackers with possession of a server's private key is outside of the scope of Token Binding?
Server's private key, and/or client private key, and/or master secret... anything that enables the attacker to MITM a user's TLS session, or to duplicate a user's EKM on the attacker's TLS connection, will break TB.

-----Original Message-----
From: Nick Harper [mailto:[email-masked]] 
Sent: Tuesday, September 5, 2017 5:23 PM
To: Andrei Popov <[email-masked]>
Cc: Subodh Iyengar <[email-masked]>; IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange

I'm fine with writing a PR to cover this, but I'm unsure what to put in it. I liked how draft-balfanz-tls-channelid started its security considerations by describing 4 classes of network attackers, and I'd like to do something similar here. However, it's unclear to me which of those classes of network attackers are considered as part of the threat model for Token Binding. Would it be reasonable to say that defending against attackers with possession of a server's private key is outside of the scope of Token Binding?

On Mon, Sep 4, 2017 at 3:59 PM, Andrei Popov <[email-masked]> wrote:
> It seems clear that binding tokens to broken TLS channels does one no 
> good, but I don’t mind adding some statements to this effect in the 
> security considerations.
>
> Nick, please feel free to author a PR. If we get to IESG review 
> someday, there will be more edits, and we can incorporate this as well.
>
>
>
> I don’t think it makes sense to limit TB to (EC)DHE, especially if 
> we’re going to allow TB in combination with TLS 1.3 0-RTT mode.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> Having said that, even if we only support forward secure ciphers, I do 
> not think we can reasonably claim that we are secure against the 
> threat of stolen private keys.
>
> +1 to requiring that token binding only be used with forward secure 
> +cipher
> suites.
>
> I believe the extended master secret requirement of token binding 
> prevents the attack on forward secure suites, i.e. an attacker cannot 
> change the DH share advertised by the real server and thus needs to 
> get the private key for it.
>
> Subodh
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furlde
> fense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_l
> istinfo_unbearable%26d%3DDwICAg%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3Dh3J
> u9EBS7mHtwg-wAyN7fQ%26m%3DaK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM%
> 26s%3DB0sKQEO8i8hDpLizsh7X8ins9EGGwOwcckYqZku7zEE%26e&data=02%7C01%7CA
> ndrei.Popov%40microsoft.com%7Cc4377a40e8734b28e71808d4f4bd73ea%7C72f98
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636402541906078858&sdata=l4HHrX6
> 7T4Dn1FVfBHlw1xVUv%2B3BSJ867Pf5ezGF3%2B0%3D&reserved=0=

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 06 Sep 2017 01:28:04 +0000

+1  out of scope

encourage using (EC)DHE key exchange in the security consideration ?

Nick Harper <[email-masked]>于2017年9月2日周六 上午6:11写道：

> https://www.ietf.org/mailman/listinfo/unbearable
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan