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

From: Denis <[email-masked]>
Date: Mon, 7 Nov 2016 18:54:23 +0100

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 speciﬁcation
speciﬁes whether the credentials issued according to this speciﬁcation 
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 Veriﬁer 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.

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 11 Nov 2016 07:27:12 +0000

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

On Tue, Nov 8, 2016 at 2:54 AM Denis <[email-masked]> wrote:

> 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.
>
> 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 creates an account on a resource server. Later on, the resource
> server asks her (or him ?) to demonstrate that she (or his ?)
> and in the future she will not need to demonstrate it again. She will keep
> the advantages related to this attribute associated
> 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.
>
> Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.2
> available at:
> speciﬁes whether the credentials issued according to this speciﬁcation are
> to employ key binding or not.
>
> so that the Veriﬁer can be sure that the rightful owner of the credential
> was involved in the creation of the presentation token.
> 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
> attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently
> The threat related to the ABC attack should be identified in the security
> considerations section
> The threat related to the ABC attack should be identified in the security
> considerations section
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 13 Nov 2016 15:08:28 +0900

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.

Am 11.11.2016 um 16:27 schrieb 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:
>       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
>
> On Tue, Nov 8, 2016 at 2:54 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     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).
>
>     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.
>
>     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
>     Section 2.3 of the ABC4Trust project about key-binding in
>     Deliverable D2.2 available at:
>     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 speciﬁcation
>     speciﬁes whether the credentials issued according to this
>     speciﬁcation 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,
>     As an extra protection layer, the credentials can also be bound to
>     a trusted physical device, such as a smart card, by keeping
>     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
>     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.*
>
>     and the core of the document should attempt to identify one or
>     more ways to counter it.
>
>     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
>     *draft-ietf-oauth-token-exchange-06 **should take into
>     consideration the ABC attack.*
>
>     and the core of the document should attempt to identify one or
>     more ways to counter it.
>
>     Denis
>
>     [email-masked] <mailto:[email-masked]>

---

From: Denis <[email-masked]>
Date: Sun, 13 Nov 2016 23:58:16 +0100

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

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?

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

>> 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:
>>
The assumption is correct.

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

>>  *

Not exactly.

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

>>       o For something like Age verification, recognizing such
>>         attacks, it probably is a bad practice to rely on
>>         refresh/access token.

Same comment as above.

Denis

>>     Section 5 of "draft-ietf-oauth-pop-architecture-08.txt"
>>     identifies requirements.
>>     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
>>     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 speciﬁcation
>>     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
>>     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

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 14 Nov 2016 10:38:06 +0000

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

On Mon, Nov 14, 2016 at 7:58 AM Denis <[email-masked]> wrote:

> So far, I'm struggeling to understand how this attack is performed from a
> practical perspective.
> 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
> 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
> be required for the secure element
> the list of threats.
> Torsten et al. are updating Threat Model and Security Considerations so it
> could potentially be included in there.
>
> Some remarks:
>
>    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.
>
>
>    -
> Whatever kind of cryptographic is being used, when two users collaborate,
> a software-only solution will be unable
>       probably is a bad practice to rely on refresh/access token.
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --

Nat Sakimura

---

From: Denis <[email-masked]>
Date: Mon, 14 Nov 2016 16:16:40 +0100

Nat,

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

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

>
> Best,
>
> Nat
>
> On Mon, Nov 14, 2016 at 7:58 AM Denis <[email-masked] 
>>     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..
>>     So far, I'm struggeling to understand how this attack is
>>     performed from a practical perspective.
>     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
>>     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?
>
>         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 
>
>         properties will be required for the secure element
>>>     Torsten et al. are updating Threat Model and Security
>>>         credentials with Alice: Otherwise, sharing the credential
>>>         would achieve something worse.
>>>
>>>         Alice: Otherwise, something similar to ABC attack can be
>>>         achieved by Bob
>>>         giving Alice his Laptop or Phone, and I guess this happens
>     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.
>
>>>      *
>>>
>>>
>>>           o It looks like a variation of token injection attack that
>>>             we have been talking about for many years.
>>>
>
>     Not exactly.
>
>
>
>         to prevent the transfer of an attribute of a user that possess
>         it to another user that does not possess it .
>
>
>>>             The service should do more active check, e.g., through
>>>             OpenID Connect.
>>>
>
>     Same comment as above.
>
>
>     Denis
>
>
>>>     Best,
>>>
>>>     Nat
>>>
>>>         This threat addresses the case of "/collusion between
>>>         servers"/ while the case of "/collusion between clients"/
>>>         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
>>>         RFC 6819 (OAuth 2.0 Threat Model and Security
>>>         Considerations) issued in January 2013 has omitted to take
>>>         into consideration
>>>         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
>>>         speciﬁcation
>>>         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 Veriﬁer 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.
>>>
>>>         real-time in the creation of the presentation token but in
>>>         the collaboration scenario,
>>>         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.
>>>
>>>         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
>>>         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
>>>