Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

[Denis <[e-mail]>]

Hi Nat,

At present, I do not support the adoption of this document as a WG 
document since the different techniques
that are being proposed have severe problems:

  * When the JWT contains a jwk , jwkt#s256 or jwe, the method is
    ineffective in case of a collusion between two users (ABC attack).
  * When the JWT contains a x5t#s256, the JWT is linked to a hash value
    of a certificate included in the JWT.
    The server then knows a unique identifier of the user. Such a method
    allows an easy linkage between all the accounts
    of a given user on different resource servers, even when the JWT
    only contains non-directly identifiable attributes.
    Hence, it does not respect 'privacy by design' principles.

In addition, if a fixed value is being used for the audience restriction 
parameter, e.g. a URL of the server, then the authorization server
can easily know where the access tokens will be used and thus it will be 
in a position to act as Big Brother.

You may however continue to progress this document as an individual 
contribution.

Denis

PS. I will not subscribe to bitbucket.org because I don't agree with the 
conditions of this site.


> Hi Denis,
>
> Thanks.
>
> Is it possible to file these separately at 
> https://bitbucket.org/Nat/oauth-rjwtprof/issues?status=new&status=open so 
> that each issue can be closed separately? (You need to login to 
> bitbucket to do so.) Pull request would be nice, too, but we are going 
> to do a bit of surgery on the spec as of now, so it might be wise to 
> wait till after that to avoid conflicts.
>
> Also, it is not yet a WG document so please support it become one.
>
> Best,
>
> Nat Sakimura
>
> On Wed, Mar 22, 2017 at 5:15 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Nat,
>
>
>     I have several comments on draft-sakimura-oauth-jpop-01 related to
>     security or privacy.
>
>
>     1.The abstract states:
>
>     Only the party in possession of a corresponding cryptographic key
>     with the Jpop token can use it to get access
>     to the associated resources unlike in the case of the bearer token
>     described in [RFC6750] where any party
>     in possession of the access token can access the resource.
>
>     This is incorrect.
>
>     Replace with:
>
>     Any party able to use a corresponding private cryptographic key
>     with the Jpop token can use it to get access
>     to the associated resources unlike in the case of the bearer token
>     described in [RFC6750] where any party
>     in possession of the access token can access the resource.
>
>     2.In section 3, the text states:
>
>     audThe identifier of the resource server.
>
>     According to the content of RFC 7800:
>
>     The "aud" (audience) claim identifies the recipients that the JWT
>     is intended for. The interpretation of audience values is
>     application specific.
>
>     Replace with:
>
>     audThe recipients that the JWT is intended for (the interpretation
>     of audience values is application specific).
>
>     3.In section 3, the text states:
>
>     cnfThe confirmation method.
>
>     Their semantics are defined in [RFC7519] and [RFC7800]
>
>
>     This is incorrect: cnf is neither defined in [RFC7519] nor in
>     [RFC7800].
>
>     4.In section 6.2, the text states:
>
>     For this, the following steps are taken:
>
>     1.The client prepares a nonce.
>
>     2.The client creates JWS compact serialization over the nonce
>
>
>         JSON Web Token Claims are listed at:
>         https://www.iana.org/assignments/jwt/jwt.xhtml
>
>     "nonce" has not been defined by the IANA, but is mentioned in
>     OpenID Connect Core 1.0 incorporating errata set 1. It is
>     described as :
>
>     nonce
>
>     String value used to associate a Client session with an ID Token,
>     and to mitigate replay attacks. The value is passed through
>     unmodified from the Authentication Request to the ID Token. If
>     present in the ID Token, Clients MUST verify that the nonce
>     Claim Value is equal to the value of the nonceparameter sent in
>     the Authentication Request. If present in the Authentication Request,
>     Authorization Servers MUST include a nonceClaim in the ID Token
>     with the Claim Value being the nonce value sent in the
>     Authentication Request.
>     Authorization Servers SHOULD perform no other processing on
>     noncevalues used. The noncevalue is a case sensitive string.
>
>     I have several observations:
>
>     a)there is some difficulty to mandate the use of a parameter that
>     is not registered by IANA.
>
>     b)the further processing of the nonce is not indicated in the text
>
>     c) The last sentence from the above description states:
>     "Authorization Servers SHOULD perform no other processing on
>     noncevalues used"
>     There is a practical problem with such a sentence since
>     Authorization Servers would need to remember nonces for ever.
>     Either that sentence should be deleted or the nonce shall be only
>     used with a UTC time parameter included in the Authentication Request.
>
>     In any case, the definition of a nonce as specified in OpenID
>     Connect Core 1.0 incorporating errata set 1 should not be used and
>     another parameter
>     (e.g. rdn for random) should be defined and registered by IANA and
>     used in combination with a UTC time parameter included in the
>     Authentication Request.
>     In this way, only the rdn received during the last X minutes will
>     need to be remembered by the Authorization Servers.
>
>
>     5.The title of section 9.1 is: "Certificate validation"
>
>     Change the title of this section into :
>
>     "9.1. Common Name Constrained Token"
>
>     6.In section 9.1, the text states:
>
>     The "cn" JWT confirmation method relies its security property on the
>
>     X.509 client certificate authentication.
>
>     Replace with:
>
>     The "cn" JWT confirmation method relies its security property by
>     the inclusion of the Common Name (CN)
>     that is part of the Distinguished Name (DN) of an X.509
>     certificate. The JWT is linked to the common name
>     included in the certificate. Such a method is not privacy friendly
>     since it allows an easy linkage between
>     all the accounts of a given user on different resource servers.
>
>     7.Add a new section 9.2 to deal with the case of the cid.
>
>     Proposed text:
>
>     9.2. Client ID Constrained Token
>
>     The "cid" JWT confirmation method relies its security property on
>     the assumption that the cid legitimately
>     used by one server cannot be used by another user. It also relies
>     on the assumption that the authentication data
>     associated with "cid" combined with the "iss" will only be used by
>     the legitimate user. This method is ineffective
>     in case of a collusion between two users, since one user can
>     perform all the computations needed by the other user.
>
>     8.In section 9.2, the text states:
>
>     The client’s secret key must be kept securely. Otherwise, the
>     notion of PoP breaks down.
>
>     The PKIX group from the IETF is using the vocabulary private key /
>     public key when asymmetric cryptography is being used
>     and secret key when symmetric algorithms are being used (let us
>     call a spade a spade).
>
>     However, keeping a client's private key securely is not the right
>     wording either. If the key is kept securely in a secure element
>     (e.g. smart card), this is not enough, since the holder of the
>     secure element may use this key for himself ... or worse for the
>     benefit of someone else.
>
>     Proposed change :
>
>     9.3. Key Constrained Token
>
>     This method has four variants.
>
>     When the JWT contains a jwk, the JWT confirmation method relies
>     its security property on the assumption that the private key
>     associated with the public key contained in the access token will
>     only be used by the legitimate user. In order to avoid an easy linkage
>     between user's accounts, this method presents the advantage that
>     the key pair can be changed for every JWT. However, this method
>     is ineffective in case of a collusion between two users, since one
>     user can perform all the computations needed by the other user.
>
>     When the JWT contains a jwkt#s256, the server must have a prior
>     knowledge of the public key and the method relies its security
>     property
>     on the assumption that the private key associated with the public
>     key contained in the access token will only be used by the
>     legitimate user.
>     Hence, this method is ineffective in case of a collusion between
>     two users, since one user can perform all the computations needed
>     by the other user.
>
>     When the JWT contains a x5t#s256, the server must have a prior
>     knowledge of the public key certificate. The JWT is then linked to
>     a hash value
>     of a certificate included in the JWT. The server knows a unique
>     identifier of the user. Such a method is not privacy friendly
>     since it allows
>     an easy linkage between all the accounts of a given user on
>     different resource servers.
>
>     When the JWT contains a jwe, the JWT confirmation method relies
>     its security property on the assumption that the secret key included
>     in the JWT will only be used by the legitimate user. In order to
>     avoid an easy linkage between user's accounts, this method presents
>     the advantage that the secret key can be changed for every JWT.
>     However, this method is ineffective in case of a collusion between
>     two users,
>     since one user can perform all the computations needed by the
>     other user.
>
>     9.The text states in section 9.3:
>
>     9.3.Audi_a_nce Restriction
>
>     When using the signature method the client must specify to the AS
>     the aud it intends to send the token to, so that it can be
>     included in the AT.
>
>     A malicious RS could receive a AT with no aud or a logical
>     audience and then replay the AT and jws-on-nonce to the actual server.
>
>
>     Proposed change in order to address privacy concerns :
>
>     9.4.Audi_e_nce Restriction
>
>     When using the signature method, the client must specify to the AS
>     the aud it intends to send the token to, so that it can be
>     included in the AT.
>
>     RFC 7800 states that the interpretation of audience values is
>     application specific. If a fixed value is being used, e.g. a URL
>     of the server,
>     then the authorization server can easily know where the access
>     tokens will be used and thus is in a position to act as Big Brother.
>     It is thus recommended to use a different value in the aud claims
>     for each access token that contains no semantics in it but that
>     the resource server
>     can easily recognize.//
>
>     If a malicious RS receives an AT with no aud or a logical audience
>     in it then it can replay the AT and jws-on-nonce to another server.
>
>     Denis
>
>
>>     HI Chairs,
>>
>>     I would also like to ask 5 min. on Monday (as I cannot be on
>>     Friday) for
>>     The OAuth 2.0 Authorization Framework: JWT Pop Token Usage [1].
>>
>>     [1] https://tools.ietf.org/html/draft-sakimura-oauth-jpop-01
>>
>>     It is capturing strong and rather urgent demands from the
>>     financial sector and would be great if it can be considered in
>>     the WG.
>>
>>     Best,
>>
>>     Nat Sakimura
>>
>>     On Tue, Mar 21, 2017 at 10:28 PM Antonio Sanso <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         hi Torsten,
>>
>>         good one. I personally I am looking forward to see this
>>         particular document find its way.
>>
>>         IMHO this is something much needed.
>>
>>         regards
>>
>>         antonio
>>
>>         On Mar 21, 2017, at 2:08 PM, Torsten Lodderstedt
>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>>         Hi Chairs,
>>>
>>>         I would like to request 5 minutes on Monday to briefly
>>>         present the status of the security document. This is mainly
>>>         to raise awareness in the group since I didn’t get that much
>>>         input on it since Seoul.
>>>
>>>         kind regards,
>>>         Torsten.
>>>
>>>>         Am 18.03.2017 um 01:52 schrieb Mike Jones
>>>>         <[e-mail]
>>>>         <mailto:[e-mail]>>:
>>>>
>>>>         Hi Chairs,
>>>>
>>>>         I'd like to request that the following presentations be
>>>>         added to the agenda:
>>>>
>>>>         OAuth Token Exchange (draft-ietf-oauth-token-exchange) -
>>>>         Mike Jones - 15 minutes
>>>>         OAuth Authorization Server Metadata
>>>>         (draft-ietf-oauth-discovery) - Mike Jones - 15 minutes
>>>>
>>>>         I'd also talked with Brian Campbell and I think he wants to
>>>>         lead this discussion, in part based on his implementation
>>>>         experience:
>>>>
>>>>         OAuth Token Binding (draft-ietf-oauth-token-binding) -
>>>>         Brian Campbell - 30 minutes
>>>>
>>>>         (Brian may suggest a different amount of time)
>>>>
>>>>         I agree that William Dennis should present about the OAuth
>>>>         Device Flow (draft-ietf-oauth-device-flow).
>>>>
>>>>         For completeness, I don't think a presentation is needed
>>>>         about OAuth AMR Values (draft-ietf-oauth-amr-values)
>>>>         because it's now completed its IESG review.
>>>>
>>>>         I'll look forward to seeing many of you in just over a week!
>>>>
>>>>         -- Mike
>>>>
>>>>         -----Original Message-----
>>>>         From: OAuth [mailto:[e-mail]] On Behalf Of
>>>>         "IETF Secretariat"
>>>>         Sent: Friday, March 3, 2017 3:55 PM
>>>>         To: [e-mail] <mailto:[e-mail]>;
>>>>         [e-mail] <mailto:[e-mail]>
>>>>         Cc: [e-mail] <mailto:[e-mail]>
>>>>         Subject: [OAUTH-WG] oauth - Requested sessions have been
>>>>         scheduled for IETF 98
>>>>
>>>>         Dear Stephanie McCammon,
>>>>
>>>>         The session(s) that you have requested have been scheduled.
>>>>         Below is the scheduled session information followed by the
>>>>         original request.
>>>>
>>>>         oauth Session 1 (2:30:00)
>>>>           Friday, Morning Session I 0900-1130
>>>>           Room Name: Zurich C size: 100
>>>>           ---------------------------------------------
>>>>           oauth Session 2 (1:00:00)
>>>>           Monday, Afternoon Session III 1710-1810
>>>>           Room Name: Zurich C size: 100
>>>>           ---------------------------------------------
>>>>
>>>>
>>>>
>>>>         Request Information:
>>>>
>>>>
>>>>         ---------------------------------------------------------
>>>>         Working Group Name: Web Authorization Protocol Area Name:
>>>>         Security Area Session Requester: Stephanie McCammon
>>>>
>>>>         Number of Sessions: 2
>>>>         Length of Session(s):  2.5 Hours, 1 Hour Number of
>>>>         Attendees: 50 Conflicts to Avoid:
>>>>         First Priority: saag core tls tokbind
>>>>
>>>>
>>>>
>>>>
>>>>         People who must be present:
>>>>         Hannes Tschofenig
>>>>         Kathleen Moriarty
>>>>         Derek Atkins
>>>>
>>>>         Resources Requested:
>>>>         Projector in room
>>>>
>>>>         Special Requests:
>>>>         Please avoid conflict with sec area BoFs.
>>>>         ---------------------------------------------------------
>>>>
>>>>         _______________________________________________
>>>>         OAuth mailing list
>>>>         [e-mail] <mailto:[e-mail]>
>>>>         https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463058106&sdata=FYIqTvgn1%2Fpjyqw%2BtGhDWgiB0G0ATuL30ap%2B3bLX6aQ%3D&reserved=0
>>>>
>>>>
>>>>         _______________________________________________
>>>>         OAuth mailing list
>>>>         [e-mail] <mailto:[e-mail]>
>>>>         https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463058106&sdata=FYIqTvgn1%2Fpjyqw%2BtGhDWgiB0G0ATuL30ap%2B3bLX6aQ%3D&reserved=0
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463068122&sdata=5CIJnWs2VdLM9FUWt%2FWlOxIilp5N2vfr7b9elwhL%2BA4%3D&reserved=0
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>     -- 
>>
>>     Nat Sakimura
>>
>>     Chairman of the Board, OpenID Foundation
>>
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
>
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>