[OAUTH-WG] Comments on draft-ietf-oauth-pop-architecture-08

[Denis <[e-mail]>]

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

**