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

[Denis]

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.

[Nat Sakimura]

Thanks Denis for pointing it out. It may be desirable to add ABC attack to
the list of threats. Torsten et al. are updating Threat Model and Security
Considerations so it could potentially be included in there.

Some remarks:

- I suppose the assumption is that the Bob does not share his
credentials with Alice: Otherwise, sharing the credential would achieve
something worse.
- In addition, it assumes that Bob does not give his device to Alice:
Otherwise, something similar to ABC attack can be achieved by Bob giving
Alice his Laptop or Phone, and I guess this happens more often than
shipping Bob's access token to Alice.
- With these assumptions:
- It looks like a variation of token injection attack that we have
been talking about for many years.
- If we token bind the refresh and access tokens, the ABC attack as
described does not work.
- For something like Age verification, recognizing such attacks, it
probably is a bad practice to rely on refresh/access token. The service
should do more active check, e.g., through OpenID Connect.

Best,

Nat

Post by Denis
Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies
requirements.
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
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.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Torsten Lodderstedt]

I agree, we should analyse the threat. From my first impression it feels
like injection with some specialties.

@Denis:
So far, I'm struggeling to understand how this attack is performed from
a practical perspective. Every token/assertion issued to the uncle is
bound to its identity. So it the niece wants to "upgrade" her age, she
would need to somehow mix identity data for two identities (her's and
her uncle's identity) into a single token, which needs to be signed by
the respective AS. How is this gone work?

kind regards,
Torsten.

Post by Nat Sakimura
Thanks Denis for pointing it out. It may be desirable to add ABC
attack to the list of threats. Torsten et al. are updating Threat
Model and Security Considerations so it could potentially be included
in there.
* I suppose the assumption is that the Bob does not share his
credentials with Alice: Otherwise, sharing the credential would
achieve something worse.
* In addition, it assumes that Bob does not give his device to
Alice: Otherwise, something similar to ABC attack can be achieved
by Bob giving Alice his Laptop or Phone, and I guess this happens
more often than shipping Bob's access token to Alice.
o It looks like a variation of token injection attack that we
have been talking about for many years.
o If we token bind the refresh and access tokens, the ABC attack
as described does not work.
o For something like Age verification, recognizing such attacks,
it probably is a bad practice to rely on refresh/access token.
The service should do more active check, e.g., through OpenID
Connect.
Best,
Nat
Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies
requirements.
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
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.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

Nat and Torsten,

My responses ares embedded in your text.

Post by Torsten Lodderstedt
I agree, we should analyse the threat. From my first impression it
feels like injection with some specialties.

Not exactly. In most scenario attacks, we have two good guys (Alice and
Bob) and one bad guy (Carol) acting as the single attacker..
In this scenario, we have two bad guys (Alice and Bob willing to
collaborate) and one good guy (Carol) acting as a relying party.

Post by Torsten Lodderstedt
So far, I'm struggeling to understand how this attack is performed
from a practical perspective.
Every token/assertion issued to the uncle is bound to its identity.

This key question is to which "identity" since I am considering a scheme
where privacy considerations are as important as security considerations.
So the goal is only to reveal to the third party that the user making
the access is more than 18, without revealing anything else than the
relying party
would already know about the user making the access request.

Post by Torsten Lodderstedt
So if the niece wants to "upgrade" her age, she would need to somehow
mix identity data for two identities
(her's and her uncle's identity) into a single token, which needs to
be signed by the respective AS. How is this gone work?

As yourself, I don't believe this is a solution. As I already said:

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
(i.e. some physical device with security properties).

Post by Torsten Lodderstedt
kind regards,
Torsten.

Post by Nat Sakimura
Thanks Denis for pointing it out. It may be desirable to add ABC
attack to the list of threats.
Torsten et al. are updating Threat Model and Security Considerations
so it could potentially be included in there.
* I suppose the assumption is that the Bob does not share his
credentials with Alice: Otherwise, sharing the credential would
achieve something worse.

The assumption is correct.

Post by Torsten Lodderstedt

Post by Nat Sakimura
* In addition, it assumes that Bob does not give his device to
Alice: Otherwise, something similar to ABC attack can be achieved
by Bob
giving Alice his Laptop or Phone, and I guess this happens more
often than shipping Bob's access token to Alice.

The assumption is correct. If Bob is using a smart card that protects
some keys, he will never give the smart card nor the PIN to Alice.

Post by Torsten Lodderstedt

Post by Nat Sakimura
*
o It looks like a variation of token injection attack that we
have been talking about for many years.

Not exactly.

Post by Torsten Lodderstedt

Post by Nat Sakimura
o If we token bind the refresh and access tokens, the ABC
attack as described does not work.

I am not sure I understand what you mean here, since my belief is still :

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 .

Post by Torsten Lodderstedt

Post by Nat Sakimura
o For something like Age verification, recognizing such
attacks, it probably is a bad practice to rely on
refresh/access token.
The service should do more active check, e.g., through OpenID
Connect.

Same comment as above.

Denis

Post by Torsten Lodderstedt

Post by Nat Sakimura
Best,
Nat
Section 5 of "draft-ietf-oauth-pop-architecture-08.txt"
identifies requirements.
One of them (which, BTW, should be moved into Section 4 -
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
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.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Nat Sakimura]

Torsten,

I think what Denis is referring to is the case where two bad actors, Alice
and Bob collude and take advantage of the "bearer token".
By doing so, instead of Bob buying Vodka for Alice, Alice can order Vodka
disguised as Bob. So, the increased risk here is that Alice does not have
to bother Bob to get additional vodka.

Note: In this case, the token does not identify Alice nor Bob to the
relying party but just provides the authorization to perform some action.

Mitigation 1: If the token is Token Bound, then the attack does not work,
and Alice has to ask Bob to get her Vodka every time so the risk stays the
same as pre-attack.
Mitigation 2: If the AS provides only very short lived access/refresh
token, then Alice has to get Bob act for her every time and so it becomes
the same as Bob buying vodka for Alice every time so the risk stays the
same as pre-attack.

Best,

Nat

Post by Denis
Nat and Torsten,
My responses ares embedded in your text.
I agree, we should analyse the threat. From my first impression it feels
like injection with some specialties.
Not exactly. In most scenario attacks, we have two good guys (Alice and
Bob) and one bad guy (Carol) acting as the single attacker..
In this scenario, we have two bad guys (Alice and Bob willing to
collaborate) and one good guy (Carol) acting as a relying party.
So far, I'm struggeling to understand how this attack is performed from a
practical perspective.
Every token/assertion issued to the uncle is bound to its identity.
This key question is to which "identity" since I am considering a scheme
where privacy considerations are as important as security considerations.
So the goal is only to reveal to the third party that the user making the
access is more than 18, without revealing anything else than the relying
party
would already know about the user making the access request.
So if the niece wants to "upgrade" her age, she would need to somehow mix
identity data for two identities
(her's and her uncle's identity) into a single token, which needs to be
signed by the respective AS. How is this gone work?
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
(i.e. some physical device with security properties).
kind regards,
Torsten.
Thanks Denis for pointing it out. It may be desirable to add ABC attack to
the list of threats.
Torsten et al. are updating Threat Model and Security Considerations so it
could potentially be included in there.
- I suppose the assumption is that the Bob does not share his
credentials with Alice: Otherwise, sharing the credential would achieve
something worse.
The assumption is correct.
Otherwise, something similar to ABC attack can be achieved by Bob
giving Alice his Laptop or Phone, and I guess this happens more often
than shipping Bob's access token to Alice.
The assumption is correct. If Bob is using a smart card that protects some
keys, he will never give the smart card nor the PIN to Alice.
-
- It looks like a variation of token injection attack that we have
been talking about for many years.
Not exactly.
- If we token bind the refresh and access tokens, the ABC attack as
described does not work.
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 .
- For something like Age verification, recognizing such attacks, it
probably is a bad practice to rely on refresh/access token.
The service should do more active check, e.g., through OpenID
Connect.
Same comment as above.
Denis
Best,
Nat
Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies
requirements.
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
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.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

[Denis]

Nat,

Cheers ! The use case of buying Vodka is a nice illustration. :-)

Post by Denis
Torsten,
I think what Denis is referring to is the case where two bad actors,
Alice and Bob collude and take advantage of the "bearer token".
By doing so, instead of Bob buying Vodka for Alice, Alice can order
Vodka disguised as Bob. So, the increased risk here is that Alice does
not have to bother Bob
to get additional vodka.
Note: In this case, the token does not identify Alice nor Bob to the
relying party but just provides the authorization to perform some action.
Mitigation 1: If the token is Token Bound, then the attack does not
work, and Alice has to ask Bob to get her Vodka every time so the risk
stays the same as pre-attack.

Are you referring to draft-ietf-oauth-token-binding-01 ? The
document addresses the cases of the man-in-the-middle, token export
and replay attacks,
but will not be an appropriate protection when Alice et Bob
collaborate together. If you are referring to something else, would
you be more precise ?

Mitigation 2: If the AS provides only very short lived access/refresh
token, then Alice has to get Bob act for her every time and so it
becomes the same
as Bob buying vodka for Alice every time so the risk stays the same as
pre-attack.

Two observations:

a) In some cases, an access will be granted because it is needed
to present more than one attribute. A server application normally
memorizes
by default the attributes that it has accepted (in some case
during one year only), but if a user makes an access everyday, the
user will find
annoying to present everyday the attributes that are needed.

b) Secondly, reducing the risk to the same as pre-attack does not
mean that the risk does not exist anymore. The key point is to use a
mechanism
that prevents Bob to help Alice, even if Bob is willing to
collaborate with Alice. Whatever Bob will be doing, he will not be
able to help Alice to buy
her Vodka.Every time Alice would like to buy a bottle a Vodka
on-line, the single solution would be for Alice to ask Bob to buy
one bottle for himself
and then to send it to her.

Denis

Post by Denis
Best,
Nat
Nat and Torsten,
My responses ares embedded in your text.

Post by Torsten Lodderstedt
I agree, we should analyse the threat. From my first impression
it feels like injection with some specialties.

Not exactly. In most scenario attacks, we have two good guys
(Alice and Bob) and one bad guy (Carol) acting as the single
attacker..
In this scenario, we have two bad guys (Alice and Bob willing to
collaborate) and one good guy (Carol) acting as a relying party.

Post by Torsten Lodderstedt
So far, I'm struggeling to understand how this attack is
performed from a practical perspective.
Every token/assertion issued to the uncle is bound to its identity.

This key question is to which "identity" since I am considering a
scheme where privacy considerations are as important as security
considerations.
So the goal is only to reveal to the third party that the user
making the access is more than 18, without revealing anything else
than the relying party
would already know about the user making the access request.

Post by Torsten Lodderstedt
So if the niece wants to "upgrade" her age, she would need to
somehow mix identity data for two identities
(her's and her uncle's identity) into a single token, which needs
to be signed by the respective AS. How is this gone work?

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
(i.e. some physical device with security properties).

Post by Torsten Lodderstedt
kind regards,
Torsten.

Post by Nat Sakimura
Thanks Denis for pointing it out. It may be desirable to add ABC
attack to the list of threats.
Torsten et al. are updating Threat Model and Security
Considerations so it could potentially be included in there.
* I suppose the assumption is that the Bob does not share his
credentials with Alice: Otherwise, sharing the credential
would achieve something worse.

The assumption is correct.

Post by Torsten Lodderstedt

Post by Nat Sakimura
* In addition, it assumes that Bob does not give his device to
Alice: Otherwise, something similar to ABC attack can be
achieved by Bob
giving Alice his Laptop or Phone, and I guess this happens
more often than shipping Bob's access token to Alice.

The assumption is correct. If Bob is using a smart card that
protects some keys, he will never give the smart card nor the PIN
to Alice.

Post by Torsten Lodderstedt

Post by Nat Sakimura
*
o It looks like a variation of token injection attack that
we have been talking about for many years.

Not exactly.

Post by Torsten Lodderstedt

Post by Nat Sakimura
o If we token bind the refresh and access tokens, the ABC
attack as described does not work.

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 .

Post by Torsten Lodderstedt

Post by Nat Sakimura
o For something like Age verification, recognizing such
attacks, it probably is a bad practice to rely on
refresh/access token.
The service should do more active check, e.g., through
OpenID Connect.

Same comment as above.
Denis

Post by Torsten Lodderstedt

Post by Nat Sakimura
Best,
Nat
Section 5 of "draft-ietf-oauth-pop-architecture-08.txt"
identifies requirements.
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
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.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation