Re: [OAUTH-WG] OAuth SPOP Detailed Review
Hi. Thanks for the detailed comments. Here are the responses to the questions raised in [1] [1] http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc 3.1 [Question: Would it make sense to provide some information also in the Dynamic Client Registration specification? I am a bit unhappy about not specifying at least one mechanism for learning this information since it is important for the overall security -- to avoid downgrading attacks.] I would have included it if OAuth has defined a discovery document. n fact, it may be a good starting point to discuss whether we should have a discovery document for OAuth. If the client does the per client registration, then it will not be a public client so spop would not be needed. The clients as a class may register itself, but then each client instance would not know if the server knows that it is using spop, and assuming it without verifying is not very safe. 3.1 [Hannes: Can we make a more explicit reference to a feature in the OpenID Connect Discovery specification?] It will be an extension to section 3 of OpenID Connect Discovery. This specification may define a JSON name for such a parameter. Then, one can include it in the metadata. A candidate for such name would be: oauth_spop_supported_alg: and the value would be the strings representing supported algorithms. It could be drawn from JWA algs. A simpler alternative would be: oauth_spop_support: and the value would be true or false. However, we have no good place to advertise them as of now. 3.2 [Hannes: Do we really need this flexibility here?] It is there as an extension point. John has a draft that uses aymmetric algo. An early draft had HMAC as well. We could however drop it. I suppose we can add other algorithms later without breaking this one. [Hannes: The term 'front channel' is not defined anywhere.] Will define if this section survives. 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] The server may have other considerations before returning successful response. 5. [Hannes: Which request channel are you talking about? There are two types of request channels here, namely the Access Token Request/Response and the Authorization Request / Response channel. What do you mean by adequately protected here? How likely is it that this can be accomplished? If it is rather unlikely then it would be better to define a different transformation algorithm!] This is referring to the authorization request. On iOS as of the time of writing, not Jailbreaking seems to be adequate. For Android, only presenting the intended browser as the options to handle the request seems adequate. Similar considerations would be there per platform. Note: Authors do think that using other algorithms is better. However, it proved to be rather unpopular among the developers that they were in touch with and believe that we do need to provide this no-transform capability. For other corrections, I am still working on to prepare comments as word comments. Most of editorial changes will be accepted. Some proposed technical changes seems to be due to the clauses being unclear, so I will try to propose a clarification rather than just accepting them. Best, Nat 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig hannes.tschofe...@gmx.net: Hi John, Hi Nat, I went through the document in detail and suggest some changes (most of them editorial): http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.pdf My main concern at the moment are some optional features in the spec that make it less interoperable, such as the feature discovery, and the transformation function. The latter might go away depending on your answer to my question raised at http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html but the former requires some specification work. Ciao Hannes PS: I agree with James that the title of the document is a bit misleading when compared with the other work we are doing in the group. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Working Group Last Call on Symmetric Proof of Possession for the OAuth Authorization Code Grant
Responses inline: 2014-08-29 10:00 GMT+09:00 Mike Jones michael.jo...@microsoft.com: Here's some feedback on the document. First, while I believe that the document is a good first working group draft and this specification is important, it is not ready for last call, since there are open issues called out in the document that have not been discussed by the working group and aspects of the specification are incomplete. I’ll discuss those below. There are also significant ambiguities in the document at present that could lead to non-interoperable implementations. I believe that it would be more appropriate to bring the document to WGLC once these significant issues (and those that may be raised by other reviewers) have been addressed. 2. Terminology – I would list “code challenge” before “code verifier” both because it is used first and because it’s alphabetically first. The code verifier is listed before code challenge as the later uses the former in its definition. 2.1 code verifier – Is this an octet sequence to be sent as-is (with the requirement for %-escaping octets representing non-url-safe characters) or as the base64url encoding of the octet sequence? Previously, it was agreed to be octet sequence and it is to be sent as-is. The clarification will be added. 2.2 code challenge – Same question as above. Then I would just say that the code challenge value is a function of the code verifier value and discuss the possible functions in its own section or subsection. Same as above. It is an open question whether we want to preserver the extensibility in the transformation at this time. If we decide not, then this spec will be further simplified and this point will become subsumed. NOTE 1: This should be discussed in the section about the transformation function. Also, say here what criteria people might use to choose function. NOTE 2: Also fold this into the transformation function section. 3.2 Client registers its desired code challenge algorithm – A means of registering this algorithm using OAuth Dynamic Client Registration should be defined. Use of this method should be optional. Any metadata values defines should be registered in the appropriate registry. As stated above, if we do not need extensibility, we do not need this section. My sense is that we do not. See my response to Hannes' detailed review. 3.4 Client sends the code challenge – Is the code challenge octet sequence value sent or the base64url encoding of it? As above. 3.6 Client sends the code and the secret – Is the code verifier octet sequence value sent or the base64url encoding of it? As above. 4.1 OAuth Parameters Registry – The change controller should be “IESG”. Yes. 5. Security Considerations – The implications of choosing different kinds of transformation functions should be discussed. Will become unnecessary if we throw the extensibility away at this time. I would recommend running the HTML output of xml2rfc through a grammar and spelling checker, as numerous grammar nits would be caught by doing so. Thanks for the advise. Best, Nat -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, August 27, 2014 8:45 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Working Group Last Call on Symmetric Proof of Possession for the OAuth Authorization Code Grant Based on the reaction from a few I thought I should add a few words about this working group last call. There is no requirement to wait a specific timeframe after a document became a WG item to issue a working group last call. In this specific case, the document was around for a while and I didn't see a reason for not-finishing it as soon as possible. Additionally, since the document deals with a security vulnerability that is being exploited today I thought it might make sense to get the attention from the group to review it. Finally, it is also a fairly simple document (if there is something as simple in this working group). Ciao Hannes On 08/26/2014 09:32 PM, Hannes Tschofenig wrote: Hi all, This is a Last Call for comments on the Symmetric Proof of Possession for the OAuth Authorization Code Grant specification. The document can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ Please have your comments in no later than September 9th. Ciao Hannes Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
On #1, I know some have pushed for having the transformation options so I don't know if dropping it will work. But, if not removed entirely, the transformation stuff could definitely be deemphasized in favor of what will be the most common case of the client sending a random string value on the authorization request and then sending the same value on the token request. On #2, there are already implementations and deployments of this so I'd request that the parameter names not be changed. On #3, I agree that the title is confusing/misleading. Perhaps, Request Correlation for the OAuth Authorization Code Grant or something like that? On #4, on one hand you are right. On the other hand, this is the OAuth WG and this draft is addressing a very specific security issue in OAuth deployments. Having it be OAuth-centric seems right given the circumstances. On Thu, Aug 28, 2014 at 11:03 PM, Manger, James james.h.man...@team.telstra.com wrote: Couple of comments on draft-ietf-oauth-spop-00: The draft defines a nice little mechanism to link two requests: one from app-to-browser-to-server, the other from app-to-server. 1. The spec defines the bearer token version of linking the requests: pick a random value and send it in both requests. The spec repeatedly hints that other transformations are possible (and even mentions one in a note), but it doesn't define enough to make these other ones interoperable. I suggest just specifying the bearer version and dropping all the other text. If we want another transform standardized later then we write another spec (which can use its own field names). 2. Linking requests is orthogonal to whether or not the requests include a field called code. I suggest changing the labels code_challenge and code_verifier to drop the code reference. Perhaps replace both with session_id (sid for short?). 3. The spec is titled Symmetric Proof of Possession ... but defines a bearer mechanism, which you cannot really classify as proof-of-possession. Suggestion: change the title. 4. The text is totally OAuth-centric, though the mechanism is not really limited to this case. It would be much nicer to describe the mechanism more generically (eg app running on a user's computer wanting to link two requests made to a server over different channels). The abstract (and the start of the introduction) should be comprehensible without having to know what the phrase OAuth 2.0 public client means. There would still be some OAuth-specific sections describing how the mechanism applies to the code flow (and to register a field in the IANA OAuth registry). -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
Hi James and Brian, First, I apologize for taking a long time to respond to James. My responses inline: 2014-09-03 2:49 GMT+09:00 Brian Campbell bcampb...@pingidentity.com: On #1, I know some have pushed for having the transformation options so I don't know if dropping it will work. But, if not removed entirely, the transformation stuff could definitely be deemphasized in favor of what will be the most common case of the client sending a random string value on the authorization request and then sending the same value on the token request. Indeed, there have been some lengthy discussions around it, so I have not removed them. However, if the WG feels that it is ok to leave them out, I am fine with it. It would impact the name of the spec though, as it will not be PoP anymore. The justification for using PoP in the name is that in non-degenerate case, it is a PoP. On #2, there are already implementations and deployments of this so I'd request that the parameter names not be changed. Noted. On #3, I agree that the title is confusing/misleading. Perhaps, Request Correlation for the OAuth Authorization Code Grant or something like that? See #1. On #4, on one hand you are right. On the other hand, this is the OAuth WG and this draft is addressing a very specific security issue in OAuth deployments. Having it be OAuth-centric seems right given the circumstances. IMHO, this is a scoping issue. The current draft is scoped to solve a specific problem of OAuth public clients. More generic way can obviously be envisaged, but I am not sure if it is something to be worked on within OAuth WG. Nat On Thu, Aug 28, 2014 at 11:03 PM, Manger, James james.h.man...@team.telstra.com wrote: Couple of comments on draft-ietf-oauth-spop-00: The draft defines a nice little mechanism to link two requests: one from app-to-browser-to-server, the other from app-to-server. 1. The spec defines the bearer token version of linking the requests: pick a random value and send it in both requests. The spec repeatedly hints that other transformations are possible (and even mentions one in a note), but it doesn't define enough to make these other ones interoperable. I suggest just specifying the bearer version and dropping all the other text. If we want another transform standardized later then we write another spec (which can use its own field names). 2. Linking requests is orthogonal to whether or not the requests include a field called code. I suggest changing the labels code_challenge and code_verifier to drop the code reference. Perhaps replace both with session_id (sid for short?). 3. The spec is titled Symmetric Proof of Possession ... but defines a bearer mechanism, which you cannot really classify as proof-of-possession. Suggestion: change the title. 4. The text is totally OAuth-centric, though the mechanism is not really limited to this case. It would be much nicer to describe the mechanism more generically (eg app running on a user's computer wanting to link two requests made to a server over different channels). The abstract (and the start of the introduction) should be comprehensible without having to know what the phrase OAuth 2.0 public client means. There would still be some OAuth-specific sections describing how the mechanism applies to the code flow (and to register a field in the IANA OAuth registry). -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
I don't think the inclusion of a MAC transform to protect the request is necessary for it to be called proof of possession. The other way to protect the request is with a signed/encrypted request object. That is heaver weight than the HMAC transform. I may have come up with the trick of sending the hmac in the request and the key as the proof, so am a bit partial to it. On the other hand I don't know that the incremental value is that much. It may be better to skip that and add a way for a client to specify it's public key (JWK) as part of it's authorization request to the AS. I see that more as part of the full OAuth PoP spec for access tokens. That way the access tokens would also be bound to the client. That would let us keep SPOP for code as simple as possible. John B. On Sep 2, 2014, at 2:32 PM, Nat Sakimura sakim...@gmail.com wrote: Hi James and Brian, First, I apologize for taking a long time to respond to James. My responses inline: 2014-09-03 2:49 GMT+09:00 Brian Campbell bcampb...@pingidentity.com: On #1, I know some have pushed for having the transformation options so I don't know if dropping it will work. But, if not removed entirely, the transformation stuff could definitely be deemphasized in favor of what will be the most common case of the client sending a random string value on the authorization request and then sending the same value on the token request. Indeed, there have been some lengthy discussions around it, so I have not removed them. However, if the WG feels that it is ok to leave them out, I am fine with it. It would impact the name of the spec though, as it will not be PoP anymore. The justification for using PoP in the name is that in non-degenerate case, it is a PoP. On #2, there are already implementations and deployments of this so I'd request that the parameter names not be changed. Noted. On #3, I agree that the title is confusing/misleading. Perhaps, Request Correlation for the OAuth Authorization Code Grant or something like that? See #1. On #4, on one hand you are right. On the other hand, this is the OAuth WG and this draft is addressing a very specific security issue in OAuth deployments. Having it be OAuth-centric seems right given the circumstances. IMHO, this is a scoping issue. The current draft is scoped to solve a specific problem of OAuth public clients. More generic way can obviously be envisaged, but I am not sure if it is something to be worked on within OAuth WG. Nat On Thu, Aug 28, 2014 at 11:03 PM, Manger, James james.h.man...@team.telstra.com wrote: Couple of comments on draft-ietf-oauth-spop-00: The draft defines a nice little mechanism to link two requests: one from app-to-browser-to-server, the other from app-to-server. 1. The spec defines the bearer token version of linking the requests: pick a random value and send it in both requests. The spec repeatedly hints that other transformations are possible (and even mentions one in a note), but it doesn't define enough to make these other ones interoperable. I suggest just specifying the bearer version and dropping all the other text. If we want another transform standardized later then we write another spec (which can use its own field names). 2. Linking requests is orthogonal to whether or not the requests include a field called code. I suggest changing the labels code_challenge and code_verifier to drop the code reference. Perhaps replace both with session_id (sid for short?). 3. The spec is titled Symmetric Proof of Possession ... but defines a bearer mechanism, which you cannot really classify as proof-of-possession. Suggestion: change the title. 4. The text is totally OAuth-centric, though the mechanism is not really limited to this case. It would be much nicer to describe the mechanism more generically (eg app running on a user's computer wanting to link two requests made to a server over different channels). The abstract (and the start of the introduction) should be comprehensible without having to know what the phrase OAuth 2.0 public client means. There would still be some OAuth-specific sections describing how the mechanism applies to the code flow (and to register a field in the IANA OAuth registry). -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature ___ OAuth
Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
I support the use of public key. As I remember, our discussion started there. I still believe this is something that is needed to be standardized. However, for spop use case, we have determined that is overkill and best left for another draft. It looks like there is a strong support in the thread to droop the transform. I have not heard any strong desire to keep the extensibility. If any of you do, please voice it now. Otherwise, I will drop the transform related clauses from the next rev. Nat 2014-09-03 5:17 GMT+09:00 John Bradley ve7...@ve7jtb.com: I don't think the inclusion of a MAC transform to protect the request is necessary for it to be called proof of possession. The other way to protect the request is with a signed/encrypted request object. That is heaver weight than the HMAC transform. I may have come up with the trick of sending the hmac in the request and the key as the proof, so am a bit partial to it. On the other hand I don't know that the incremental value is that much. It may be better to skip that and add a way for a client to specify it's public key (JWK) as part of it's authorization request to the AS. I see that more as part of the full OAuth PoP spec for access tokens. That way the access tokens would also be bound to the client. That would let us keep SPOP for code as simple as possible. John B. On Sep 2, 2014, at 2:32 PM, Nat Sakimura sakim...@gmail.com wrote: Hi James and Brian, First, I apologize for taking a long time to respond to James. My responses inline: 2014-09-03 2:49 GMT+09:00 Brian Campbell bcampb...@pingidentity.com: On #1, I know some have pushed for having the transformation options so I don't know if dropping it will work. But, if not removed entirely, the transformation stuff could definitely be deemphasized in favor of what will be the most common case of the client sending a random string value on the authorization request and then sending the same value on the token request. Indeed, there have been some lengthy discussions around it, so I have not removed them. However, if the WG feels that it is ok to leave them out, I am fine with it. It would impact the name of the spec though, as it will not be PoP anymore. The justification for using PoP in the name is that in non-degenerate case, it is a PoP. On #2, there are already implementations and deployments of this so I'd request that the parameter names not be changed. Noted. On #3, I agree that the title is confusing/misleading. Perhaps, Request Correlation for the OAuth Authorization Code Grant or something like that? See #1. On #4, on one hand you are right. On the other hand, this is the OAuth WG and this draft is addressing a very specific security issue in OAuth deployments. Having it be OAuth-centric seems right given the circumstances. IMHO, this is a scoping issue. The current draft is scoped to solve a specific problem of OAuth public clients. More generic way can obviously be envisaged, but I am not sure if it is something to be worked on within OAuth WG. Nat On Thu, Aug 28, 2014 at 11:03 PM, Manger, James james.h.man...@team.telstra.com wrote: Couple of comments on draft-ietf-oauth-spop-00: The draft defines a nice little mechanism to link two requests: one from app-to-browser-to-server, the other from app-to-server. 1. The spec defines the bearer token version of linking the requests: pick a random value and send it in both requests. The spec repeatedly hints that other transformations are possible (and even mentions one in a note), but it doesn't define enough to make these other ones interoperable. I suggest just specifying the bearer version and dropping all the other text. If we want another transform standardized later then we write another spec (which can use its own field names). 2. Linking requests is orthogonal to whether or not the requests include a field called code. I suggest changing the labels code_challenge and code_verifier to drop the code reference. Perhaps replace both with session_id (sid for short?). 3. The spec is titled Symmetric Proof of Possession ... but defines a bearer mechanism, which you cannot really classify as proof-of-possession. Suggestion: change the title. 4. The text is totally OAuth-centric, though the mechanism is not really limited to this case. It would be much nicer to describe the mechanism more generically (eg app running on a user's computer wanting to link two requests made to a server over different channels). The abstract (and the start of the introduction) should be comprehensible without having to know what the phrase OAuth 2.0 public client means. There would still be some OAuth-specific sections describing how the mechanism applies to the code flow (and to register a field in the IANA OAuth registry). -- James Manger ___ OAuth mailing list OAuth@ietf.org
Re: [OAUTH-WG] Last Call Review of draft-ietf-oauth-json-web-token-25
Thanks for the review, Tom. I've cc'ed the OAuth working group so that they're aware of the contents of your review. -- Mike -Original Message- From: Tom Taylor [mailto:tom.taylor.s...@gmail.com] Sent: Saturday, August 23, 2014 8:39 PM To: draft-ietf-oauth-json-web-token@tools.ietf.org; Gen Art Subject: Last Call Review of draft-ietf-oauth-json-web-token-25 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-oauth-json-web-token-25 Reviewer: Tom Taylor Review Date: 23/08/2014 IETF LC End Date: 3/09/2014 IESG Telechat date: TBD Summary: This draft is good to go. IDNits complains about the non-use of RFC 4648 (normative) but this is the Base64 specification invoked by base64url. I did not re-verify the examples (done by the Document Shepherd). Major issues: Minor issues: Nits/editorial comments: ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
