Subject: [Unbearable] WGLC on draft-ietf-tokbind-https

From: Denis <[email-masked]>
Date: Wed, 21 Dec 2016 11:16:52 +0100

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