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 <denis.i...@free.fr> 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: > > aud The 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: > > aud The recipients that the JWT is intended for (the interpretation of > audience values is application specific). > > > > 3. In section 3, the text states: > > cnf The 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 nonce parameter sent in the > Authentication Request. If present in the Authentication Request, > Authorization Servers MUST include a nonce Claim 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 nonce values > used. The nonce value 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 nonce values 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 <asa...@adobe.com> 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 <tors...@lodderstedt.net> > 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 <michael.jo...@microsoft.com>: > > 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:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] On > Behalf Of "IETF Secretariat" > Sent: Friday, March 3, 2017 3:55 PM > To: oauth-cha...@ietf.org; smccam...@amsl.com > Cc: oauth@ietf.org > 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 > OAuth@ietf.org > > > 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 > OAuth@ietf.org > > > 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 > OAuth@ietf.org > > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
