Subject: [OAUTH-WG] Comments on draft-ietf-oauth-token-binding-01

From: Denis <[email-masked]>
Date: Wed, 21 Dec 2016 14:37:18 +0100

There has been a WGLC in the Token Binding (tokbind) WG about the 
following documents:

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

I have posted the following comments:

    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 demonstrate to a RS that she is older
    than 18.

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

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

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 tokbind WG, I have 
proposed a few text replacements.

*1 - *In *draft-ietf-tokbind-protocol*, change the abstract in the 
following way
(and modify the content of the document in accordance):

This document specifies Version 1.0 of the Token Binding protocol. The 
Token Binding protocol allows client/server applications tocreate 
long-lived, uniquely identifiable TLS [RFC5246 
<https://tools.ietf.org/html/rfc5246>] bindingsspanning multiple TLS 
sessions and connections.Applications arethen enabled to 
cryptographically bind security tokens to the TLSlayer. *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.*To protect 
privacy, the Token Binding identifiers are only transmitted encrypted 
and can be reset by the user at any time.

Also the introduction states:

(...)

    In order to successfully export and replay a bound security token,
the attacker needs to also be able to export the client's private
key, which is hard to do in the case of the key generated in a secure
hardware module.Proposed replacement

This should be replaced with:

(...)

*In order to successfully export and replay a bound security token,
**a client does not need to export the client's private**key, since
    it can perform all the necessary computations in the **case of a
    collaboration attack.

*

*2 -* In *draft-ietf-tokbind-https* add two additional paragraphs in the 
abstract
(and modify the content of the document in accordance):

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>] 
In section 7.1, change the text in the following way:

      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.*

*3 - draft-ietf-oauth-token-binding-01* is based on the same foundations 
and hence is suject to the ABC attack.

The same kind of decision is facing the OAuth WG:

    *Option A*: drop draft-ietf-oauth-token-binding.

    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 OAuth WG, the 
abstract should be changed
(and the content of the document should be modified in accordance).

The current abstract states:

    This specification enables OAuth 2.0 implementations to apply Token
    Binding to Access Tokens and Refresh Tokens.  This cryptographically
    binds these tokens to the TLS connections over which they are
    intended to be used.  This use of Token Binding protects these tokens
    from man-in-the-middle and token export and replay attacks.

This should be changed into:

*    This specification enables OAuth 2.0 implementations to apply Token 
    Binding to Access Tokens and Refresh Tokens.  This cryptographically 
    binds these tokens to the TLS connections over which they are    
intended to be used.  This use of Token Binding protects these tokens    
from man-in-the-middle attacks, but does not protect in case two    
clients agree to collaborate, since one client can compute the necessary 
information for the other client without the need to release his key(s) 
to the other client.*

**

**
Denis

---

From: Denis <[email-masked]>
Date: Wed, 21 Dec 2016 20:17:43 +0100

Comments on draft-ietf-oauth-pop-architecture-08 : OAuth 2.0 
Proof-of-Possession (PoP) Security Architecture

This document identifies the four following threats in Section 4:

  * Token manufacture/modification,
  * Token disclosure,
  * Token redirect, and
  * Token reuse.

However, this section is omitting to consider 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 resource server that she 
is older than 18.

Since the remaining of the document is only considering the threats 
mentioned in Section 4, it does not mandate
any requirement to counter the ABC attack nor suggests a means to 
counter it.

In section 5, various requirements are considered. On page 9, under the 
wording "Collusion",
there are the following explanations

*Resource servers that collude can be prevented from using
information related to the resource owner to track the individual.

*

*That is, two different resource servers can be prevented from
determining that the same resource owner has authenticated to both
of them.Authorization servers MUST bind different keying
material to access tokens used for resource servers from different
origins (or similar concepts in the app world).*

Two cases should be considered instead: (a) *Server Collusions*, where 
the current text may fit, and (b) *Client Collusions*.

Client Collusions might be defined in the following way:**

*Clients Collusion*

**

*Clients may collude, i.e. a client can obtain a token and pass it
to another client that can then use it for its own benefits. As
an example, in a scenario described as ABC attack (Alice and Bob
collusion 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 server that she is older than 18.
The protection of binding keys in an hardware security module is
       a first step to counter such a scenario, but is insufficient by
itself since the Bob can still perform all the computations that
Alice needs and transmit the results to her.*

**

*Clients collusion can however be prevented if such an hardware
security module (or secure element) protects the keys but also
supports additional security properties.*

**

In section 5, Channel Binding is being considered with the following 
explanations:

*A solution MUST enable support for channel bindings.The concept*

*of channel binding, as defined in [RFC5056], allows applications*

*to establish that the two end-points of a secure channel at one*

*network layer are the same as at a higher layer by binding*

*authentication at the higher layer to the channel at the lower*

*layer.*

As explained in other emails, channel binding is efficient to counter 
man-in-the-middle attacks but is inefficient to counter
the ABC attack. Hence the use of the word "MUST" is not appropriate. The 
first sentence should be removed.
The paragraph should be changed into :

*Channel Binding*

*The concept of channel binding, as defined in [RFC5056], allows
applications to establish that the two end-points of a secure
channel at one network layer are the same as at a higher layer
by binding authentication at the higher layer to the channel at
the lower layer.  While efficient to counter man-in-the-middle
attacks, channel binding is unable to counter clients collusions.*

**

At the end of section 6.3. (Key Confirmation), a paragraph should be added.

**

*Whatever kind of cryptography is being used, such methods when
       used in isolation are unable to counter collusions between clients.*

**

The last sentence of section 6.4 states:

**

*In all cases above it has to be ensured that the client is able to*

*keep the credentials secret.*

**

After that sentence, the following sentence should be added:

**

*However, when two clients agree to collaborate, these approaches,
     used alone, are unable to counter clients collusions.*

**

Section 8 states:

**

*8.Security Considerations*

**

*The purpose of this document is to provide use cases, requirements,*

*and motivation for developing an OAuth security solution extending*

*Bearer Tokens.As such, this document is only about security.*

**

This should be replaced by:

**

*8.Security Considerations*

**

*This document considers various threats. In the case where two users
    agree to collaborate, a client can obtain an access token and pass it
    to another client which can then use it for its own benefits. This
    document does not specify in details the means to counter such a 
threat.

*

*   The use of secure elements or of ***hardware security modules* 
protecting
    the private keys or/and the secret keys used by a given client would
    be ***one way to counter *that threat but additional security 
properties
    would also need to be supported by such **secure elements or 
***hardware
    security modules*****.
*

*
*

**

There are two options for this WG:

*Option A*: incorporate the proposed additions and hence implicitly 
recognize that the ABC attack is not countered
by this architecture.

or
**

*Option B*: attempt to propose solutions to counter the ABC attack and 
hence continue to work on this document
This implies working on a rather different PoP Architecture.

There exists different solutions.

1) One of them mandates the deployment of secure elements, but the 
architecture is very complex and requires
up to 45 exchanges most of them using secure messaging (See EN 419212-2 
: Application Interface for smart cards
used as Secure Signature Creation Devices). Privacy has not been 
considered when the architecture has been built
and hence this solution is not privacy friendly. In particular, Resource 
Servers are able to correlate their user accounts.
Resource Servers are also required to use hardware security modules.

2) Another one does not mandate the use of a secure element (or of an 
hardware security module). Resource Servers are
unable to correlate their user accounts which is a nice privacy 
property, ... but most of the time receive a set of attributes
that is sufficient to fully identify the user ! (this could be changed, 
but it is how the current architecture has been deployed).
The currently deployed solution mandates the use of a single 
Authorization Server that knows where each access token
it generates will be used. In addition, the Authorization Server knows 
all the identity attributes of each user and is able to track
the accesses of each user. Hence, this single Authorization Server 
(managed by a government) would have (or has ?) the
perfect position to act as Big Brother.

3) Another one has been built from the very beginning with privacy in 
mind and hence has been using a "Privacy by Design"
approach and, during its construction, the ABC attack has been 
specifically considered. It mandates the use of secure elements
(or of hardware security modules) with specific properties and mandates 
the use of protocols with specific characteristics
both between clients and Authorization Servers and between clients and 
Resource Servers. Authorization Servers and Resource
Servers are NOT required to use any hardware security module.

One of the side benefits of this solution is that Authorization Servers 
are unable to know where the access tokens they generate
for a given client will be used. Hence their ability to act as Big 
Brother is limited.

4) Other solutions may exist.
**

Since the ABC attack is about to cheat that a person is older than 18, 
privacy considerations are of utmost importance.
The current document has a "Security Considerations" section but is 
lacking a "Privacy Considerations" section.
Both are of equal importance.

Denis

**