[OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack)

[Denis <[e-mail]>]

Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies 
requirements.
One of them (which, BTW, should be moved into Section 4 - Threats) is :

Collusion:

Resource servers that collude ...

This threat addresses the case of "/collusion between servers"/ while 
the case of "/collusion between clients"/
has not been considered. When access tokens are being used, /collusion 
between clients /is of primary importance.

Let us consider the following "Alice and Bob Collusion attack" (ABC attack).

An uncle (Bob) is willing to collaborate with his young niece (Alice) 
who is less than 18 during a short period of time.
The niece is opening her own session and creates an account on a server. 
The uncle does not hand over his own session to her niece
at any point of time.

Let us assume that some crypto expert has written two specific pieces of 
software. One has been installed on the laptop
of the uncle and another one on the laptop of the niece. The two laptops 
are able to communicate using a network (e.g. a WAN or a LAN).

The niece creates an account on a resource server. Later on, the 
resource server asks her (or him ?) to demonstrate that she (or his ?)
is more than 18. She forwards the information received from the resource 
server to her uncle using the network. The uncle receives
that information and connects to an Authorization Server. The uncle 
requests an access token containing information demonstrating
that he is older than 18 and passed it back to his niece. The niece then 
presents it to the resource server. The access token is accepted.

Since the niece has been able to demonstrate once that she is more than 
18, the resource server will remember this attribute
and in the future she will not need to demonstrate it again. She will 
keep the advantages related to this attribute associated
with her account on that resource server until she does not need it 
anymore, i.e. when she will really be over 18.

    Whatever kind of cryptographic is being used, when two users
    collaborate, a software-only solution will be
    unable to prevent the transfer of an attribute of a user that
    possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and 
the integrity of some secret key or private key will be ineffective
to counter the Alice and Bob collusion attack. Additional properties 
will be required for the secure element.

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in 
January 2013 has omitted to take into consideration
the Alice and Bob Collusion attack.

Section 2.3 of the ABC4Trust project about key-binding in Deliverable 
D2.2 available at:
https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 :

To prevent “credential pooling”, i.e., multiple Users sharing their 
credentials, credentials can optionally be bound to a secret key,
i.e. a cryptographically strong random value that is assumed to be known 
only to a particular user. The credential specification
specifies whether the credentials issued according to this specification 
are to employ key binding or not.

A presentation token derived from such a key-bound credential always 
contains an implicit proof of knowledge of the underlying secret key,
so that the Verifier can be sure that the rightful owner of the 
credential was involved in the creation of the presentation token.
As an extra protection layer, the credentials can also be bound to a 
trusted physical device, such as a smart card, by keeping
the secret key in a protected area of the device. That is, the key 
cannot be extracted from the device, but the device does participate
in the presentation token generation to include an implicit proof of 
knowledge of this key in the token. Thus, for credentials that are 
key-bound
to a physical device it is impossible to create a presentation token 
without the device.

The rightful owner of the credential was indeed involved in real-time in 
the creation of the presentation token but in the collaboration scenario,
the key binding mechanism is not sufficient to counter that specific 
attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft)are currently
not resistant to the "ABC attack".

The IRMA card project (https://www.irmacard.org/) based on the use of a 
smart card and of the Idemix scheme claims to provide security
and privacy simultaneously. However, this project will not be resistant 
either to the ABC attack.

*draft-ietf-oauth-pop-architecture-08 should take into consideration the 
ABC attack.*

The threat related to the ABC attack should be identified in the 
security considerations section
and the core of the document should attempt to identify one or more ways 
to counter it.

The scope of draft-ietf-oauth-token-exchange-06 is limited to the 
definition of a basic request and response protocol for
an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security 
Considerations) has omitted to take into consideration
the ABC attack and therefore the currently described "basic request and 
response protocol" will allow Bob to obtain an access
token and to pass it successfully to Alice so that she can use it.

*draft-ietf-oauth-token-exchange-06 **should take into consideration the 
ABC attack.*

The threat related to the ABC attack should be identified in the 
security considerations section
and the core of the document should attempt to identify one or more ways 
to counter it.

Denis

PS. I have recently registered to the OAuth mailing list.