Denis
2017-03-24 08:51:18 UTC
I have 2 comments.
1.At the bottom of page 13, the text states:
Token replay is also not possible since an eavesdropper will also
have to obtain the corresponding private key or shared secret
that is bound to the access token.
Saying "Token replay is also not possible" is incorrect, since it is
only true in the case of an eavesdropper. So this case is restricted
to eavesdroppers only: this should be said upfront. Note that this is
the /stealing /of an access token by an eavesdropper.
Proposed change:
*Token stealing by an eavesdropper is not possible*since the
eavesdropper will also have to obtain the corresponding private key
or shared secret that is bound to the access token.
Since it is important to say first that confidentiality protection is
needed, this sentence should be moved on the next page after the
following sentences:
*The authorization server MUST offer confidentiality protection for
any interactions with the client.This step is extremely important
since the client will obtain the session key from the authorization
server for use with a specific access token.Not using
confidentiality protection exposes this secret (and the access token)
to an eavesdropper thereby making the OAuth 2.0 proof-of-possession
security model completely insecure.*
2.Then the text states:
*Similarly to the security recommendations for the bearer token
specification [12] developers MUST ensure that the ephemeral
credentials (i.e., the private key or the session key) is not leaked
to third parties.An adversary in possession of the ephemeral
credentials bound to the access token will be able to impersonate the
client.Be aware that this is a real risk with many smart phone app
and Web development environments.*
After that text, add:
Two users can voluntarily agree to use a specific piece of
software that will allow one user who has legitimately obtained an
access token
to transmit it to another user with the keying material or to
transmit it to another user while making the appropriate cryptographic
computations
for the benefit of the other user so that this other user can
successfully use that access token. As soon as someone will develop that
piece
of software and make it publicly available, everybody will be able
to use it.
RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in
January 2013 has not identified this threat and hence does not suggest
any means to counter it.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 this collusion attack. Additional functional and
security properties are required
for the secure element.
Denis
1.At the bottom of page 13, the text states:
Token replay is also not possible since an eavesdropper will also
have to obtain the corresponding private key or shared secret
that is bound to the access token.
Saying "Token replay is also not possible" is incorrect, since it is
only true in the case of an eavesdropper. So this case is restricted
to eavesdroppers only: this should be said upfront. Note that this is
the /stealing /of an access token by an eavesdropper.
Proposed change:
*Token stealing by an eavesdropper is not possible*since the
eavesdropper will also have to obtain the corresponding private key
or shared secret that is bound to the access token.
Since it is important to say first that confidentiality protection is
needed, this sentence should be moved on the next page after the
following sentences:
*The authorization server MUST offer confidentiality protection for
any interactions with the client.This step is extremely important
since the client will obtain the session key from the authorization
server for use with a specific access token.Not using
confidentiality protection exposes this secret (and the access token)
to an eavesdropper thereby making the OAuth 2.0 proof-of-possession
security model completely insecure.*
2.Then the text states:
*Similarly to the security recommendations for the bearer token
specification [12] developers MUST ensure that the ephemeral
credentials (i.e., the private key or the session key) is not leaked
to third parties.An adversary in possession of the ephemeral
credentials bound to the access token will be able to impersonate the
client.Be aware that this is a real risk with many smart phone app
and Web development environments.*
After that text, add:
Two users can voluntarily agree to use a specific piece of
software that will allow one user who has legitimately obtained an
access token
to transmit it to another user with the keying material or to
transmit it to another user while making the appropriate cryptographic
computations
for the benefit of the other user so that this other user can
successfully use that access token. As soon as someone will develop that
piece
of software and make it publicly available, everybody will be able
to use it.
RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in
January 2013 has not identified this threat and hence does not suggest
any means to counter it.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 this collusion attack. Additional functional and
security properties are required
for the secure element.
Denis