Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
On 31 May 2020, at 12:47, Barry Leiba wrote: But https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, in particular: Only errors that could cause implementation or deployment problems or significant confusion should be Verified. Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update. Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update. Did something change these criteria? They're guidelines, not absolute rules, and judgment is expected. Sure, but I was replying to Ben's statement that, "The new text is clearly the right thing, and there is no need to debate it if/when the document gets updated. 'Don't hold it; do it now', so to speak". That's not what Verified ever meant before. If the meaning has changed, that's fine, but someone should let the community know and update the IESG Statement. (Personally, I'm all for that, as I've found the current definitions absurd and confusing. All clearly wrong Editorial errata should be marked "Verified", IMO.) But that's not about applying judgement; that's changing the definition of the terms used. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
But https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, in particular: 1. Only errors that could cause implementation or deployment problems or significant confusion should be Verified. 2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update. 5. Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update. Did something change these criteria? pr On 30 May 2020, at 23:09, Benjamin Kaduk wrote: The new text is clearly the right thing, and there is no need to debate it if/when the document gets updated. "Don't hold it; do it now", so to speak -- and noting that (my understanding/recollection of) the plan for https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only verified errata, not those in other states, will be displayed. (Yes, that link 404s at the moment, I assume a caching issue.) -Ben On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote: "Verified", not "Hold For Document Update"? pr On 30 May 2020, at 20:34, RFC Errata System wrote: The following errata report has been verified for RFC7800, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6187 -- Status: Verified Type: Editorial Reported by: Pete Resnick Date Reported: 2020-05-26 Verified by: Benjamin Kaduk (IESG) Section: 7.1 Original Text - [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7157, May 2015, <http://www.rfc-editor.org/info/rfc7517>. Corrected Text -- [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>. Notes - DOI has a typo: 7157 instead of 7517. -- RFC7800 (draft-ietf-oauth-proof-of-possession-11) -- Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Publication Date: April 2016 Author(s) : M. Jones, J. Bradley, H. Tschofenig Category: PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)
"Verified", not "Hold For Document Update"? pr On 30 May 2020, at 20:34, RFC Errata System wrote: The following errata report has been verified for RFC7800, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6187 -- Status: Verified Type: Editorial Reported by: Pete Resnick Date Reported: 2020-05-26 Verified by: Benjamin Kaduk (IESG) Section: 7.1 Original Text - [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7157, May 2015, <http://www.rfc-editor.org/info/rfc7517>. Corrected Text -- [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>. Notes - DOI has a typo: 7157 instead of 7517. -- RFC7800 (draft-ietf-oauth-proof-of-possession-11) -- Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Publication Date: April 2016 Author(s) : M. Jones, J. Bradley, H. Tschofenig Category: PROPOSED STANDARD Source : Web Authorization Protocol Area: Security Stream : IETF Verifying Party : IESG -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
On 10/17/14 12:09 PM, Mike Jones wrote: This is the standard mitigation for a known set of actual attacks. We shouldn't even consider making it optional. Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
On 10/16/14 7:56 AM, Brian Campbell wrote: Thanks for your review and feedback on this one too, Pete. Replies are inline below... On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick presn...@qti.qualcomm.com mailto:presn...@qti.qualcomm.com wrote: 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. Apologies for any haphazardness. No worries. As you've discovered, throughout the organization we're pretty bad about consistent use of it, so if you use other RFCs for examples, you get weird results. I'm very happy to see that you're trying to get this right. But the second one buries what *might* be a proper and important use of MUST (you MUST NOT try to stick in two SAML Assertions) with a simple definitional one. (And that assumes that it's even plausible to try to use more than one SAML Assertion. If you simply can't, it's just s/MUST contain/contains.) It's intended to be both definitional and restrictive - that it contains an assertion but not more than one. The Response document in SAML Web SSO allows for multiple assertions and it has turned out to be quite a pain to deal with in practice while not adding any real value. While it's not entirely clear how one might try and stick more than one assertion in this parameter given the serialization, I still wanted to explicitly preclude it. Ah, good. Then some sort of MUST is appropriate. Given that explanation of the intent, would you suggest an alternative wording of that sentence? Or is it okay as is? I think it's OK as is, but would be better if you had the requirement on the right thing: The value of the assertion parameter contains a single SAML 2.0 Assertion. It MUST NOT contain more than one SAML 2.0 assertion. That makes it clear that you're not simply saying Put the SAML 2.0 Assertion in here. You're saying, Don't try to squeeze in more than one. The base64url encoding MUST is fine, because you don't want people sticking in raw XML, but the SHOULD NOTs for line wrapping and pad I am curious about: Isn't a parser going to have to check for line wrapping and pad anyway and undo it (because it's not a MUST NOT), and therefore this SHOULD NOT really isn't about interoperability so much as neatness (in which case they SHOULD NOTs are not appropriate)? Yes, the base64 decoder still has to be prepared to deal with line wrapping and padding. In my experience most decoders are very capable of it. And stripping the white-space and =s prior to decoding is easy enough for those using a decoder that can't. The SHOULD NOT is about neatness but also in a way about interop in that it's intended to help avoid common implementation problems that can arise with urlencoding the parameter value (either not encoding or double encoding, etc.). Base64url without line wraps and padding dosn't need urlencoding and doesn't change if urlencoding is applied. That was the thinking behind the SHOULD NOTs there. As I try and articulate the reasoning, it does feel like maybe it should have been a MUST NOT. I guess I was looking to channel Postel a bit in being somewhat liberal in what is accepted with padding/no padding and line wraps/no line wraps while using the SHOULD NOTs to suggest that clients be conservative in what they send. Thoughts about what to do with it, given that reasoning? I agree with your gut: If implementations are going to bump into other implementations that fail to encode properly or double encode when encountering line wraps and padding, then you should say MUST NOT. You might even want to say, Due to some poor implementations, you MUST NOT use line wrapping or padding when you create these things, but you MUST decode them if you receive them. 3 - Subpoint 2: Just for clarification, I like the non-passive sentence better: The Authorization Server MUST reject any assertion that does not contain its own identity as the intended audience. Yes, on seeing it written that way, I also like it better. Just to make sure I'm on the same page. The sentence you suggest would replace the second to last sentence in #2 that currently says, Assertions that do not identify [...] MUST be rejected.? Correct. Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not conflicting? Can you not have an authenticated subject with an autonomously acting client? Perhaps I've misused the words but, yes, that's the idea. An autonomously acting client is meant to describe a client that's acting without the user being present. The act of direct user authentication with the assertion issuer seems like the way to differentiate between the user being present for things and the client doing things in the background for the user. Both are valid use cases. Item 7 is looking to provide the AS with some clue as to which is happening. Ah, so what you mean by the Assertion issuer
Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)
On 10/15/14 6:06 PM, Brian Campbell wrote: Thanks for your review and feedback, Pete. Replies are inline below... Thanks for addressing the comments, including Barry's followup. Just on the questions: On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick presn...@qti.qualcomm.com mailto:presn...@qti.qualcomm.com wrote: scope [...] As such, the requested scope MUST be equal or lesser than the scope originally granted to the authorized accessor. s/MUST/will (unless you explain whether it's the server or the client that's supposed to be obeying that MUST, and for what reason) They are both supposed to obey it - the client shouldn't ask for more and the server will reject the request, if it does. Is will more appropriate than MUST here? Or maybe a non 2119 should? Ah, so you're saying that a client could conceivably (either purposely or accidentally) try to sneak through a larger scope than it should, and the client MUST NOT do that, and the server MUST reject if it gets one. OK, that makes sense. (I do tend to like active MUSTs -- the foo MUST do X or the bar MUST NOT do Y -- but this is probably OK as is.) Here and throughout: s/non-normative example/example (As far as I know, there are no other kinds in IETF documents.) I thought I picked that language up from some other draft or RFC but I'm now not sure where it came from and can't easily find other examples of the same thing. So I am happy to remove the non-normative throughout, if it is already understood and/or not customary to say so. Yeah, we've seen other RFCs with such language. I've whined about it in the past. Some authors roll their eyes at me. You are welcome to roll your eyes if you like, but I find such text silly. :-) Thanks for the rest of the planned changes. Looks good. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)
Pete Resnick has entered the following ballot position for draft-ietf-oauth-assertions-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ -- COMMENT: -- 3 - Assertions used in the protocol exchanges defined by this specification MUST always be protected against tampering using a digital signature or a keyed message digest applied by the issuer. Why is that? Aren't you using assertions over a protected channel (as required by the spec) and therefore not need to sign the assertions? Indeed, why would a self-issued Bearer Assertion need to be signed at all? Does that even make sense? 4.1 - grant_type REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI. That MUST is unnecessary. It's just definitional from 6749, 4.5 (which, as it happens, doesn't use 2119 language for this). s/MUST/will assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents. The serialization MUST be encoded for transport within HTTP forms. It is RECOMMENDED that base64url be used. The MUST seems weird here. Are you saying that the profile could not possibly have a serialization for an assertion that did not require further encoding? But the RECOMMENDED seems downright wrong: Either an implementer *needs* to know the encoding independently of the profile, and therefore this needs to be a MUST, or the profile is going to describe the encoding, which could be base64url or could be something else, and the implementation will do whatever the profile says. If you really want to say something here, I suggest replacing the last two sentences with: If the assertion is going to be transported within HTTP forms, the profile document needs to describe what (if any) encoding will be needed to do so. The base64url encoding is widely implemented and therefore suggested. scope [...] As such, the requested scope MUST be equal or lesser than the scope originally granted to the authorized accessor. s/MUST/will (unless you explain whether it's the server or the client that's supposed to be obeying that MUST, and for what reason) If the scope parameter and/or value are omitted, the scope MUST be treated as equal to the scope originally granted to the authorized accessor. The Authorization Server MUST limit the scope of the issued access token to be equal or lesser than the scope originally granted to the authorized accessor. In the first sentence, is this MUST for the server? (That is, shouldn't it be, If the scope parameter and/or value are omitted, the server MUST use the value of the scope originally granted to the authorized accessor.?) And anyway, don't these two sentences contradict 6749, which says: The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. [...] If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. Here and throughout: s/non-normative example/example (As far as I know, there are no other kinds in IETF documents.) 4.1.1 - s/MUST construct/constructs 4.2, client_assertion_type and client_assertion: See comments from 4.1 regarding grant_type and assertion. 4.2.1 - s/MUST construct/constructs 5.2 - s/MUST identify/identifies For clarification: OLD Assertions that do not identify the Authorization Server as an intended audience MUST be rejected. NEW The Authorization Server MUST reject any assertion that does not contain the its own identity as the intended audience. END ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Pete Resnick has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ -- COMMENT: -- 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. The first MUST be is obviously silly and should simply be is. But the second one buries what *might* be a proper and important use of MUST (you MUST NOT try to stick in two SAML Assertions) with a simple definitional one. (And that assumes that it's even plausible to try to use more than one SAML Assertion. If you simply can't, it's just s/MUST contain/contains.) The base64url encoding MUST is fine, because you don't want people sticking in raw XML, but the SHOULD NOTs for line wrapping and pad I am curious about: Isn't a parser going to have to check for line wrapping and pad anyway and undo it (because it's not a MUST NOT), and therefore this SHOULD NOT really isn't about interoperability so much as neatness (in which case they SHOULD NOTs are not appropriate)? 3 - Subpoint 2: Just for clarification, I like the non-passive sentence better: The Authorization Server MUST reject any assertion that does not contain its own identity as the intended audience. Subpoint 5: OLD The SubjectConfirmation element MUST contain a SubjectConfirmationData element, unless the Assertion has a suitable NotOnOrAfter attribute on the Conditions element, in which case the SubjectConfirmationData element MAY be omitted. That one's sure to get misquoted somewhere and confuse someone. Instead: NEW If the Assertion does not have a suitable NonOnOrAfter attribute on the Conditions element, the SubjectConfirmation element MUST contain a SubjectConfirmationData element. Subpoint 6: OLD The authorization server MUST verify that the NotOnOrAfter instant has not passed, subject to allowable clock skew between systems. An invalid NotOnOrAfter instant on the Conditions element invalidates the entire Assertion. An invalid NotOnOrAfter instant on a SubjectConfirmationData element only invalidates the individual SubjectConfirmation. NEW The authorization server MUST reject the entire Assertion if the NotOnOrAfter instant on the Conditions element has passed (subject to allowable clock skew between systems). The authorization server MUST reject the SubjectConfirmation (but MAY still use the rest of the Assertion) if the NotOnOrAfter instant on the SubjectConfirmationData has passed (subject to allowable clock skew). Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not conflicting? Can you not have an authenticated subject with an autonomously acting client? Subpoint 9: As I asked in the -assertions document, is this really a requirement? Subpoint 11: Again, it would be better to put the MUST on the action (e.g., MUST reject) to make it clear who is doing what. 3.1/3.2 - s/MUST construct/constructs 4 - s/Though non-normative// 9 - Seems like OASIS.saml-deleg-cs and OASIS.saml-sec-consider-2.0-os are Normative, not Informative. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT)
Pete Resnick has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ -- COMMENT: -- I'm not going to repeat stuff that is identical to draft-ietf-oauth-saml2-bearer (and I did find that using https://www.ietf.org/rfcdiff?url1=draft-ietf-oauth-saml2-bearer-21difftype=--htmlsubmit=Go%21url2=draft-ietf-oauth-jwt-bearer-10 was very helpful). Please refer to my comments on that document. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
