Subject: [Unbearable] Updated I-Ds

From: Andrei Popov <[email-masked]>
Date: Thu, 16 Feb 2017 20:26:50 +0000

The updated versions of TBPROTO, TBNEGO and HTTPSTB have been uploaded:
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12
https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07
https://tools.ietf.org/html/draft-ietf-tokbind-https-08

The updated documents address the comments from the unbearable mailing list and GitHub.

Cheers,

Andrei

---

From: John Bradley <[email-masked]>
Date: Thu, 16 Feb 2017 17:40:56 -0300

Thanks.

> On Feb 16, 2017, at 5:26 PM, Andrei Popov <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 <https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12>
> https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 <https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07>
> https://tools.ietf.org/html/draft-ietf-tokbind-https-08 <https://tools.ietf.org/html/draft-ietf-tokbind-https-08>
>  
> _______________________________________________
> Unbearable mailing 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: Thu, 16 Feb 2017 21:54:04 +0100

Andrei,

You said:

    The updated documents address the comments from the unbearable
    mailing list.

I don't believe that this is the case. I copy and paste a message sent 
on Wed, 21 dec 2016 at 11:16:52
under the topic: "WGLC on draft-ietf-tokbind-https".

Denis
=========================================================================================

On November 31, 2016, I sent a message saying:

This set of documents failed to meet the terms of references of the WG 
charter.

It is not resistant to the ABC attack (Alice and Bob collusion attack).
In this attack Bob who is older than 18 colloborates with Alice and 
transmits a token to Alice
who is only 14 so that she can demonstrat to a RS that she is older than 18.

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

This set of documents should not be progressed to IETF last call unless 
the attack can be countered.

========================================================================

There are two options:

*Option A*: drop this series of documents, i.e. :

   draft-ietf-tokbind-protocol
   draft-ietf-tokbind-https
   draft-ietf-tokbind-negotiation

or *
*

*Option B*: clearly mention that the ABC attack cannot be countered 
using TLS binding.

In case, the latter decision would be taken by the WG, I propose a few 
text replacements.

*

Current text:

*AbstractThis document describes a collection of mechanisms that allow 
HTTP servers to cryptographically bind authentication tokens (such 
ascookies and OAuth tokens) to TLS [RFC5246 
<https://tools.ietf.org/html/rfc5246>] connections.We describe both 
_first-party_ and _federated_ scenarios.In afirst-party scenario, an 
HTTP server is able to cryptographicallybind the security tokens it 
issues to a client, and which the clientsubsequently returns to the 
server, to the TLS connection between theclient and server.Such bound 
security tokens are protected frommisuse since the server can generally 
detect if they are replayedinappropriately, e.g., over other TLS 
connections.Federated token bindings, on the other hand, allow servers 
to cryptographically bind security tokens to a TLS connection that 
theclient has with a _different_ server than the one issuing the token. 
This Internet-Draft is a companion document to The Token BindingProtocol 
[I-D.ietf-tokbind-protocol 
<https://tools.ietf.org/html/draft-ietf-tokbind-https-07#ref-I-D.ietf-tokbind-protocol>]*Proposed 
additions in blue*Abstract This document describes a collection of 
mechanisms that allow HTTP servers to cryptographically bind 
authentication tokens (such ascookies and OAuth tokens) to TLS [RFC5246 
<https://tools.ietf.org/html/rfc5246>] connections. We describe both 
_first-party_ and _federated_ scenarios.In afirst-party scenario, an 
HTTP server is able to cryptographicallybind the security tokens it 
issues to a client, and which the client subsequently returns to the 
server, to the TLS connection between the client and server.Such bound 
security tokens are protected from misuse since the server can generally 
detect if they are replayedinappropriately, e.g., over other TLS 
connections.*However, the binding a security token to a TLS connection 
is **unable to counter collaboration attacks between two clients since 
**one client can compute the necessary information for the other 
**client without the need to release his key(s) to the other client. For 
an effective protection against collaboration attacks, an **appropriate 
format of the security token, together with an **appropriate validation 
of some fields of it, must be used.*Federated token bindings, on the 
other hand, allow servers tocryptographically bind security tokens to a 
TLS connection that theclient has with a _different_ server than the one 
issuing the token. This Internet-Draft is a companion document to The 
Token BindingProtocol [I-D.ietf-tokbind-protocol 
<https://tools.ietf.org/html/draft-ietf-tokbind-https-07#ref-I-D.ietf-tokbind-protocol>]

*Current text: *

7.1. Security Token Replay

The goal of the Federated Token Binding mechanisms is to 
preventattackers from exporting and replaying tokens used in 
protocolsbetween the client and Token Consumer, thereby 
impersonatinglegitimate users and gaining access to protected 
resources.Bound tokens can still be replayed by malware present in the 
client.Inorder to export the token to another machine and successfully 
replay it, the attacker also needs to export the corresponding private 
key.The Token Binding private key is therefore a high-value asset 
andMUST be strongly protected, ideally by generating it in a hardware 
security module that prevents key export

*Proposed replacement*

      <https://tools.ietf.org/html/draft-ietf-tokbind-https-07#section-7.1>7.1.
      Security Token Export andReplayThe goal of the Federated Token
      Binding mechanisms is to preventattackers from exporting and
      replaying tokens used in protocols between the client and Token
      Consumer, thereby impersonatinglegitimate users and gaining access
      to protected resources.Boundtokens can still be replayed by
      malware present in the client.

      *They can also be exported and re-used when a client collaborates
      **with another client.In order to export the token to another
      **machine and successfully use it, a client may export the
      **corresponding private key to the other client or may perform all
      **the necessary computations for the other client without
      exporting **the corresponding private**.Protecting the Token
      Binding private **key, e.g. in a hardware security module that
      prevents key export is **a good practice, but in such a case, it
      is inefficient to counter **the clients collaboration attack.*

Some other changes might need to be done in the same spirit. Denis

> Thanks.
>
>
>> On Feb 16, 2017, at 5:26 PM, Andrei Popov <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> https://www.ietf.org/mailman/listinfo/unbearable
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Andrei Popov <[email-masked]>
Date: Thu, 16 Feb 2017 21:29:02 +0000

Hi Denis,

I don't mind adding language (probably in the security considerations) saying that the Token Binding protocol does not prevent cooperating clients from sharing a bound token.
So far I do not sense much enthusiasm for this in the WG though...

Cheers,

Andrei

From: Denis [mailto:[email-masked]]
Sent: Thursday, February 16, 2017 12:54 PM
To: John Bradley <[email-masked]>; Andrei Popov <[email-masked]>
Cc: IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] Updated I-Ds

Andrei,

You said:
The updated documents address the comments from the unbearable mailing list.
I don't believe that this is the case. I copy and paste a message sent on Wed, 21 dec 2016 at 11:16:52
under the topic: "WGLC on draft-ietf-tokbind-https".

Denis

This set of documents failed to meet the terms of references of the WG charter.

It is not resistant to the ABC attack (Alice and Bob collusion attack).
In this attack Bob who is older than 18 colloborates with Alice and transmits a token to Alice
who is only 14 so that she can demonstrat to a RS that she is older than 18.

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

This set of documents should not be progressed to IETF last call unless the attack can be countered.

There are two options:

Option A: drop this series of documents, i.e. :

or

Option B: clearly mention that the ABC attack cannot be countered using TLS binding.

In case, the latter decision would be taken by the WG, I propose a few text replacements.
Current text:

 Abstract

       This document describes a collection of mechanisms that allow HTTP

   servers to cryptographically bind authentication tokens (such as

   cookies and OAuth tokens) to TLS [RFC5246<https://tools.ietf.org/html/rfc5246>] connections.

      We describe both _first-party_ and _federated_ scenarios.  In a

   first-party scenario, an HTTP server is able to cryptographically

   bind the security tokens it issues to a client, and which the client

   subsequently returns to the server, to the TLS connection between the

   client and server.  Such bound security tokens are protected from

   misuse since the server can generally detect if they are replayed

   inappropriately, e.g., over other TLS connections.

   Federated token bindings, on the other hand, allow servers to

   cryptographically bind security tokens to a TLS connection that the

   client has with a _different_ server than the one issuing the token.

   This Internet-Draft is a companion document to The Token Binding

   Protocol [I-D.ietf-tokbind-protocol<https://tools.ietf.org/html/draft-ietf-tokbind-https-07#ref-I-D.ietf-tokbind-protocol>]

Proposed additions in blue

Abstract

   This document describes a collection of mechanisms that allow HTTP

   servers to cryptographically bind authentication tokens (such as

   cookies and OAuth tokens) to TLS [RFC5246<https://tools.ietf.org/html/rfc5246>] connections.

   We describe both _first-party_ and _federated_ scenarios.  In a

   first-party scenario, an HTTP server is able to cryptographically

   bind the security tokens it issues to a client, and which the client

   subsequently returns to the server, to the TLS connection between the

   client and server.  Such bound security tokens are protected from

   misuse since the server can generally detect if they are replayed

   inappropriately, e.g., over other TLS connections.

   However, the binding a security token to a TLS connection is

   unable to counter collaboration attacks between two clients since

   one client can compute the necessary information for the other

   client without the need to release his key(s) to the other client.

   For an effective protection against collaboration attacks, an

   appropriate format of the security token, together with an

    appropriate validation of some fields of it, must be used.

   Federated token bindings, on the other hand, allow servers to

   cryptographically bind security tokens to a TLS connection that the

   client has with a _different_ server than the one issuing the token.

   This Internet-Draft is a companion document to The Token Binding

   Protocol [I-D.ietf-tokbind-protocol<https://tools.ietf.org/html/draft-ietf-tokbind-https-07#ref-I-D.ietf-tokbind-protocol>]

Current text:

   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.

   The Token Binding private key is therefore a high-value asset and

   MUST be strongly protected, ideally by generating it in a hardware

Proposed replacement
7.1. Security Token Export and 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.
   They can also be exported and re-used when a client collaborates
  with another client.  In order to export the token to another
   machine and successfully use it, a client may export the
   corresponding private key to the other client or may perform all
   the necessary computations for the other client without exporting
   the corresponding private.  Protecting the Token Binding private
   key, e.g. in a hardware security module that prevents key export is
   a good practice, but in such a case, it is inefficient to counter
   the clients collaboration attack.

Some other changes might need to be done in the same spirit.

Denis

Thanks.

On Feb 16, 2017, at 5:26 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Andrei
_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

Unbearable mailing list

[email-masked]<mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 16 Feb 2017 18:39:51 -0300

I suspect it is just one of those things we all think is self evident.

I don’t think having a security consideration will hurt anything.

John B.
> On Feb 16, 2017, at 6:29 PM, Andrei Popov <[email-masked]> wrote:
> 
> Hi Denis,
>  
> I don’t mind adding language (probably in the security considerations) saying that the Token Binding protocol does not prevent cooperating clients from sharing a bound token.
> So far I do not sense much enthusiasm for this in the WG though…
>  
> Cheers,
>  
> Andrei
>  
>    cookies and OAuth tokens) to TLS [RFC5246 <https://tools.ietf.org/html/rfc5246>] connections.
>    
>    Protocol [I-D.ietf-tokbind-protocol <https://tools.ietf.org/html/draft-ietf-tokbind-https-07#ref-I-D.ietf-tokbind-protocol>]
>  
>  
>    cookies and OAuth tokens) to TLS [RFC5246 <https://tools.ietf.org/html/rfc5246>] connections.
>  
>    Protocol [I-D.ietf-tokbind-protocol <https://tools.ietf.org/html/draft-ietf-tokbind-https-07#ref-I-D.ietf-tokbind-protocol>]
>  
>  
> Current text:
> On Feb 16, 2017, at 5:26 PM, Andrei Popov <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Nick Harper <[email-masked]>
Date: Thu, 16 Feb 2017 13:50:00 -0800

I think that we don't need to do any more than add a sentence to 7.1 of
TBPROTO saying something along the lines of "the Token Binding protocol
does not prevent cooperating clients from sharing a bound token" (i.e. what
Andrei said). I'm also fine if we don't add anything.

On Thu, Feb 16, 2017 at 1:39 PM, John Bradley <[email-masked]> wrote:

> I don’t mind adding language (probably in the security considerations)
> saying that the Token Binding protocol does not prevent cooperating clients
> from sharing a bound token.
> *From:* Denis [mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, February 16, 2017 12:54 PM
> *To:* John Bradley <[email-masked]>; Andrei Popov <
> [email-masked]>
> *Cc:* IETF TokBind WG <[email-masked]>
> *Subject:* Re: [Unbearable] Updated I-Ds
>
> Andrei,
>
> You said:
>
> *Option B*: clearly mention that the ABC attack cannot be countered using
> TLS binding.
>
> *Current text:*
> *Proposed additions **in blue*
>
>
>
> Abstract
>
>
>
> *   However, the binding a security token to a TLS connection is*
>
> *   unable to counter collaboration attacks between two clients since*
>
> *   one client can compute the necessary information for the other*
>
> *   client without the need to release his key(s) to the other client.*
>
>
>
> *   For an effective protection against collaboration attacks, an*
>
> *   appropriate format of the security token, together with an*
>
>   *  appropriate validation of some fields of it, must be used.*
>
>
>
> *Current text:*
> 7.1. Security Token Export and 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.   They can also be exported and re-used when a client
> collaborates  with another client.  In order to export the token to
> another   machine and successfully use it, a client may export the   corresponding
> private key to the other client or may perform all   the necessary
> computations for the other client without exporting   the corresponding
> private.  Protecting the Token Binding private    key, e.g. in a hardware
> security module that prevents key export is   a good practice, but in
> such a case, it is inefficient to counter   the clients collaboration
> attack.
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 16 Feb 2017 21:54:37 +0000

Sounds good, I’ll add language in the security considerations to address this and upload another version today.

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, February 16, 2017 1:40 PM
To: Andrei Popov <[email-masked]>
Cc: Denis <[email-masked]>; IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] Updated I-Ds

John B.
On Feb 16, 2017, at 6:29 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Denis,

Cheers,

Andrei

From: Denis [mailto:[email-masked]]
Sent: Thursday, February 16, 2017 12:54 PM
To: John Bradley <[email-masked]<mailto:[email-masked]>>; Andrei Popov <[email-masked]<mailto:[email-masked]>>
Cc: IETF TokBind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] Updated I-Ds

Andrei,

You said:

Denis

There are two options:

or

 Abstract

Abstract

Current text:

Proposed replacement

Denis

Thanks.

Cheers,

Andrei

Unbearable mailing list

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Feb 2017 00:46:30 +0100

On 2017-02-16 22:50, Nick Harper wrote:
> does not prevent cooperating clients from sharing a bound token" (i.e.
> what Andrei said). I'm also fine if we don't add anything.

I sense consensus forming around adding a sentence in the security
considerations section.

I propose to start another WGLC right now and deal with this issue
as part of the WGLC comments.

	Cheers Leif

---

From: John Bradley <[email-masked]>
Date: Thu, 16 Feb 2017 21:53:18 -0300

I just looked at diff of Andrei’s proposed addition to security considerations, and it is fine.

Lets rev protocol to 13 and go with that.

> On Feb 16, 2017, at 8:46 PM, Leif Johansson <[email-masked]> wrote:
>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 17 Feb 2017 01:19:11 +0000

Uploaded TBPROTO-13 with added language concerning cooperating clients (see section 7.1):
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, February 16, 2017 4:53 PM
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Unbearable] Updated I-Ds

>> I think that we don't need to do any more than add a sentence to 7.1 
>> of TBPROTO saying something along the lines of "the Token Binding 
>> protocol does not prevent cooperating clients from sharing a bound token" (i.e.
> I propose to start another WGLC right now and deal with this issue as 
> part of the WGLC comments.
> 
> 	Cheers Leif
>

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Feb 2017 06:53:54 +0100

I guess our messaged collided in mid air but the result is the same I guess

Skickat från min iPhone

> 17 feb. 2017 kl. 02:19 skrev Andrei Popov <[email-masked]>:
>