[OAUTH-WG] Comments on draft-ietf-oauth-pop-key-distribution-03

[Denis <[e-mail]>]

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