Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt

From: [email-masked]
Date: Fri, 21 Jul 2017 02:06:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Token Binding WG of the IETF.

        Title           : Token Binding over HTTP
        Authors         : Andrei Popov
                          Magnus Nyström
                          Dirk Balfanz
                          Adam Langley
                          Nick Harper
                          Jeff Hodges
	Filename        : draft-ietf-tokbind-https-10.txt
	Pages           : 22
	Date            : 2017-07-21

Abstract:
   This document describes a collection of mechanisms that allow HTTP
   servers to cryptographically bind security tokens (such as cookies
   and OAuth tokens) to TLS 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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tokbind-https-10
https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Denis <[email-masked]>
Date: Fri, 21 Jul 2017 11:21:19 +0200

This ID is still lacking to indicate that  this mechanism will be 
ineffective in case of a collusion between clients.

This should be clearly indicated in the Security Considerations section.

Denis

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

---

From: Nick Harper <[email-masked]>
Date: Fri, 21 Jul 2017 02:30:49 -0700

draft-ietf-tokbind-protocol-15 already has language which says "The
Token Binding protocol does not prevent cooperating clients from
sharing a bound token.  A client could intentionally export a bound
token with the corresponding Token Binding private key, or perform
signatures using this key on behalf of another client." I don't think
we need any additional language in this draft regarding client
collusion. That clients could collude is a property of the Token
Binding protocol, so it doesn't need to be repeated in this
application profile for using Token Binding.

---

From: Denis <[email-masked]>
Date: Fri, 21 Jul 2017 11:40:12 +0200

Nick,

A person reading draft-ietf-tokbind-https will not necessarily also read 
draft-ietf-tokbind-protocol.

So, I believe it is necessary to warn again the reader in the Security 
Considerations section.
Duplication of the text you quoted in that section would address my concern.

You said that the fact that clients could collude is a*property *of the 
Token Binding protocol.
I would rather say that it is a *limitation *or a *deficiency *of the 
Token Binding protocol.

Denis

---

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Jul 2017 12:04:04 +0200

> draft-ietf-tokbind-protocol.

Since there is text in draft-ietf-tokbind-https with normative
references to draft-ietf-tokbind-protocol I don't believe that
is a reasonable assumption.

	Cheers Leif

---

From: Denis <[email-masked]>
Date: Fri, 21 Jul 2017 13:03:06 +0200

Leif,

The text that was quoted is in the Security Considerations section under 
section "7.1.  Security Token Replay"
from draft-ietf-tokbind-protocol.

I already said on the list that the text does not fit under section 7.1 
since it is not a security token *replay* in any sense,
since the legitimate client is not playing anything, so it cant' be a 
replay.

It should be under a specific section called, e.g.: Client collusion.

It is particularly important that readers realize that this protection 
is not effective under some circumstances.

Is there any harm to warn the user in both documents  ?

Denis

---

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Jul 2017 13:26:08 +0200

Skickat från min iPhone

> 21 juli 2017 kl. 13:03 skrev Denis <[email-masked]>:
> 
> Leif,
> 
> The text that was quoted is in the Security Considerations section under section "7.1.  Security Token Replay" 

I was not responding to that but to your claim that it is not reasonable to expect implementors to read the full set of specs. It is.

> 
> I already said on the list that the text does not fit under section 7.1 since it is not a security token replay in any sense, 
> since the legitimate client is not playing anything, so it cant' be a replay.
> 
> It is particularly important that readers realize that this protection is not effective under some circumstances.
>

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 22 Jul 2017 03:17:31 +1200

On 21/07/17 23:26, Leif Johansson wrote:
> 
> Skickat från min iPhone
> 
> 21 juli 2017 kl. 13:03 skrev Denis:
> 
>> Leif,
>>
>> The text that was quoted is in the Security Considerations section 
>> under section "7.1.  Security Token Replay"
> I was not responding to that but to your claim that it is not reasonable 
> to expect implementors to read the full set of specs. It is.
> 
>>
>> I already said on the list that the text does not fit under section 
>> 7.1 since it is not a security token *replay* in any sense,

It is perhapse best to be aware that HTTP itself is stateless. This 
document focus is on how tokens are embeded into a single HTTP message, 
and what manipulations occur to that embedding during transfer. Not the 
content/values of those tokens, nor the content/values of the things 
bound with the token.

There is no need to consider this collusion attack because in HTTP 
context there is only ever *one* client for a given message. There is no 
possibility of multiple clients sending a single message - that would be 
multiple messages in HTTP terms, even if they had identical headers and 
tokens.

Each of those messages sent by the colluding clients MUST be interpreted 
through the draft-ietf-tokbind-protocol procedures independent of all 
other messages (even those really from the same client). Whether those 
procedures are relevant to the attack is a detail for that other 
document to address.

Amos