Subject: [Unbearable] reference in HTTPSTB to TBPROTO out of sync

From: Brian Campbell <[email-masked]>
Date: Thu, 29 Dec 2016 13:45:32 -0700

https://tools.ietf.org/html/draft-ietf-tokbind-https-07#section-4 has "See
[I-D.ietf-tokbind-protocol] Section 6 for general guidance regarding
binding of security tokens and their subsequent validation" but Section 6
is IANA Considerations. I believe it should refer to Section 5.  Bound
Security Token Creation and Validation.

I created https://github.com/TokenBinding/Internet-Drafts/issues/91 for it.
But posting here too 'cause Leif said it doesn't count unless it's on the
list ;)

---

From: Denis <[email-masked]>
Date: Fri, 30 Dec 2016 10:25:45 +0100

Brian,

It seems that you missed two of my messages sent to the list on November 
31, 2016 and on December 21, 2016
under the subject "WGLC on draft-ietf-tokbind-https".

This approach is not resistant to the ABC attack (Alice and Bob 
collusion attack).
In this attack, Bob who is older than 18 collaborates with Alice and 
transmits an access token
to Alice who is only 14 so that she can demonstrate to a RS that she is 
older than 18.

This kind of attack is not mentioned in the security considerations section.

Would you be able to respond to these emails ?

Denis

> https://tools.ietf.org/html/draft-ietf-tokbind-https-07#section-4 has 
> "See [I-D.ietf-tokbind-protocol] Section 6 for general guidance 
> regarding binding of security tokens and their subsequent validation" 
> but Section 6 is IANA Considerations. I believe it should refer to 
> Section 5.  Bound Security Token Creation and Validation.
>
> I created https://github.com/TokenBinding/Internet-Drafts/issues/91 
> for it. But posting here too 'cause Leif said it doesn't count unless 
> it's on the list ;)
>
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Brian Campbell <[email-masked]>
Date: Fri, 30 Dec 2016 10:13:01 -0700

Denis,

I sent a message aiming to correct a minor inconsistency in the section
numbering of two of the WG documents. What about that suggested to you that
I should be singled out as responsible for responding to the pet issue that
you've been pushing?

I did not miss the many messages you've sent. I just didn't feel that it is
was necessarily my place to respond. But because you've asked me directly,
I will say that I don't believe that explicitly preventing or even
mentioning the so called "ABC attack" is in scope for this work. It's not
in the charter and isn't part of a threat model that's particularly
relevant to most applications and/or isn't already addressed by the
inclusion of other specific identity attributes in (or referenced by) the
application specific security tokens.

On Fri, Dec 30, 2016 at 2:25 AM, Denis <[email-masked]> wrote:

> This approach is not resistant to the ABC attack (Alice and Bob collusion
> attack).
> "See [I-D.ietf-tokbind-protocol] Section 6 for general guidance regarding
> I created https://github.com/TokenBinding/Internet-Drafts/issues/91 for
> it. But posting here too 'cause Leif said it doesn't count unless it's on
> the list ;)
>
>
> Unbearable mailing [email-masked]://www.ietf.org/mailman/listinfo/unbearable
>
>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Dec 2016 14:43:56 -0300

As a reminder this is our charter: https://datatracker.ietf.org/wg/tokbind/charter/ <https://datatracker.ietf.org/wg/tokbind/charter/>

Per design objective #1 "Allow applications and services to prevent unauthorized replay of security tokens.”

The issue that Denis is raising is a collusion attack where Bob authorizes Alice to use the token by providing key material or a signed Token Binding header over a EKM provided by Alice.
The attack is on the token validator, and not Bob.

This working group is not designing a Attribute Based Credential (ABC) system, token binding might however be used by someone as part of such a system.

I think it would be helpful for the editors if some security consideration text were proposed to clarify that token binding prevents unauthorized replay of security tokens but not authorized replay of security tokens, when there is collusion between the parties.

Are there other security concerns related to this that should be mentioned?

Other people are working on the ABC problem eg https://abc4trust.eu/ <https://abc4trust.eu/>.

Regards
John B.

> On Dec 30, 2016, at 2:13 PM, Brian Campbell <[email-masked]> wrote:
> 
> Denis,
> 
> I sent a message aiming to correct a minor inconsistency in the section numbering of two of the WG documents. What about that suggested to you that I should be singled out as responsible for responding to the pet issue that you've been pushing?
> 
> I did not miss the many messages you've sent. I just didn't feel that it is was necessarily my place to respond. But because you've asked me directly, I will say that I don't believe that explicitly preventing or even mentioning the so called "ABC attack" is in scope for this work. It's not in the charter and isn't part of a threat model that's particularly relevant to most applications and/or isn't already addressed by the inclusion of other specific identity attributes in (or referenced by) the application specific security tokens.
> 
>  
> 
>  
> 
> On Fri, Dec 30, 2016 at 2:25 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
> Brian,
> 
> It seems that you missed two of my messages sent to the list on November 31, 2016 and on December 21, 2016 
> This approach is not resistant to the ABC attack (Alice and Bob collusion attack).
> In this attack, Bob who is older than 18 collaborates with Alice and transmits an access token 
> to Alice who is only 14 so that she can demonstrate to a RS that she is older than 18.
> 
>> https://tools.ietf.org/html/draft-ietf-tokbind-https-07#section-4 <https://tools.ietf.org/html/draft-ietf-tokbind-https-07#section-4> has "See [I-D.ietf-tokbind-protocol] Section 6 for general guidance regarding binding of security tokens and their subsequent validation" but Section 6 is IANA Considerations. I believe it should refer to Section 5.  Bound Security Token Creation and Validation.
>> 
>> I created https://github.com/TokenBinding/Internet-Drafts/issues/91 <https://github.com/TokenBinding/Internet-Drafts/issues/91> for it. But posting here too 'cause Leif said it doesn't count unless it's on the list ;) 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> 
>

---

From: Denis <[email-masked]>
Date: Fri, 30 Dec 2016 19:14:13 +0100

Brian and John,

It is indeed within the terms of reference of the charter of this WG. 
Hereafter is a copy and paste of two sentences from the charter
available at: https://datatracker.ietf.org/wg/tokbind/charter/

It is a goal of this working group to enable defense against attacks 
that involve unauthorized replay of security tokens.
Other issues associated with the use of security tokens are out of 
scope. Another goal of this working group is to design
the Token Binding protocol such that it would be also useable with 
application protocols *other than HTTPS*.

The second task of the group which happened to be "Specify the use of 
the Token Binding protocol in combination with HTTPS"
failed to meet the terms of the charter, since it is not resistant to 
the ABC attack.

So a Token Binding protocol "useable with application protocols other 
than HTTPS" should be considered.

I am not asking in any way to consider in this WG Attribute Based 
Credential (ABC) systems, like Idemix from IBM or U-Prove from Microsoft.

For your information, both Idemix from IBM and U-Prove from Microsoft 
are subject to the ABC attack, since when used with secure elements,
only the secrets keys are protected. In the case of the ABC attack, Bob 
can still perform all the computations that Alice needs. The protection
of secret keys in secure elements or HSMs is thus insufficient.

I contacted the two project leaders (one by phone, the other one by 
email) and they both turned a blind eye to this issue
and hid their heads in the sand.

Denis

> As a reminder this is our charter: 
> https://datatracker.ietf.org/wg/tokbind/charter/
>
> The issue that Denis is raising is a collusion attack where Bob 
> authorizes Alice to use the token by providing key material or a 
> signed Token Binding header over a EKM provided by Alice.
> This working group is not designing a Attribute Based Credential (ABC) 
> system, token binding might however be used by someone as part of such 
> a system.
>
> I think it would be helpful for the editors if some security 
> consideration text were proposed to clarify that token binding 
> prevents unauthorized replay of security tokens but not authorized 
> replay of security tokens, when there is collusion between the parties.
>
> Other people are working on the ABC problem eg https://abc4trust.eu/.
>
> Regards
> John B.
>
>
>> On Dec 30, 2016, at 2:13 PM, Brian Campbell 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Denis,
>>
>> I sent a message aiming to correct a minor inconsistency in the 
>> section numbering of two of the WG documents. What about that 
>> suggested to you that I should be singled out as responsible for 
>> responding to the pet issue that you've been pushing?
>>
>> I did not miss the many messages you've sent. I just didn't feel that 
>> it is was necessarily my place to respond. But because you've asked 
>> me directly, I will say that I don't believe that explicitly 
>> preventing or even mentioning the so called "ABC attack" is in scope 
>> for this work. It's not in the charter and isn't part of a threat 
>> model that's particularly relevant to most applications and/or isn't 
>> already addressed by the inclusion of other specific identity 
>> attributes in (or referenced by) the application specific security 
>> tokens.
>>
>>
>>
>>
>>
>>     It seems that you missed two of my messages sent to the list on
>>     November 31, 2016 and on December 21, 2016
>>>     https://tools.ietf.org/html/draft-ietf-tokbind-https-07#section-4
>>>     <https://tools.ietf.org/html/draft-ietf-tokbind-https-07#section-4>
>>>     has "See [I-D.ietf-tokbind-protocol] Section 6 for general
>>>     guidance regarding binding of security tokens and their
>>>     subsequent validation" but Section 6 is IANA Considerations. I
>>>     believe it should refer to Section 5.  Bound Security Token
>>>     Creation and Validation.
>>>
>>>     I created
>>>     https://github.com/TokenBinding/Internet-Drafts/issues/91
>>>     <https://github.com/TokenBinding/Internet-Drafts/issues/91> for
>>>     it. But posting here too 'cause Leif said it doesn't count
>>>     unless it's on the list ;)
>>>
>>>
>>>     <https://www.ietf.org/mailman/listinfo/unbearable>
>>
>> _______________________________________________ Unbearable mailing 
>> list [email-masked] <mailto:[email-masked]>