Subject: [Unbearable] Token Binding spec edits to be more OAuth-friendly

From: Dirk Balfanz <[email-masked]>
Date: Fri, 18 Nov 2016 12:40:15 +0000

Hi Brian,

can you check that the two changes I just committed address your needs re/
OAuth and Token Binding:

https://github.com/TokenBinding/Internet-Drafts/commit/96526be5fc14dc9dddf846b6709426ca23fe195b

https://github.com/TokenBinding/Internet-Drafts/commit/dd05f0f678b3836618938284d0c2032c8731d96e

Thanks,

Dirk.

---

From: Denis <[email-masked]>
Date: Fri, 18 Nov 2016 14:57:27 +0100

Hello,

I subscribed to this list this week. I read draft-ietf-tokbind-https-06. 
The text states in section 6.1:

    6.  Security Considerations

    6.1.  Security Token Replay

        The goal of the Federated Token Binding mechanisms is to prevent
        attackers from exporting and replaying tokens used in protocols
        between the client and Token Consumer, thereby impersonating
        legitimate users and gaining access to protected resources. Bound
        tokens can still be replayed by malware present in the client.  In
        order to export the token to another machine and successfully replay
        it, the attacker also needs to export the corresponding private key.

This approach looks fine as long as the client is used by an honest user 
or an honest entity.
Alas, this is not always the case.

The approach is not resistant to the ABC attack, i.e. the Alice and Bob 
Collusion attack.

In this scenario Bob is willing to collaborate with Alice so that he can 
export a token
that can be re-used by Alice. Alice will not necessarily impersonate Bob 
but will only be re-using a token
that has been legitimately originally obtained by Bob. If this token 
contains an attribute saying "older than 18",
Alice can present it to a protected resource that can remember this 
attribute. If she is older than 18
today, tomorrow she will obviously be older than 18 and such an 
attribute does not need to be renewed.
So she can keep advantage of it until she will really be 18.

This means that this approach is not able to fill-in the original 
charter of this WG, which is :

    It is a goal of this working group to enable defense against attacks
    that involve unauthorized replay of security tokens.

since the Alice and Bob Collusion attack defeats this approach.

Also note that in the ABC attack, in order to export the token to 
another machine and successfully replay it,
Bob *does not need to export the corresponding private key*.

Denis

---

From: Brian Campbell <[email-masked]>
Date: Fri, 18 Nov 2016 14:12:49 -0700

Yes, those look good. Thanks for doing that.