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
**
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
