Hi Nat, Thanks for making the updates from my review and the SecDir review. I already pulled this from this week's telechat. I can put it on the next telechat, I just need to run IETF last call first.
I will request to start last call. Discussions on changes fromt he SecDir review can continue during last call as that's the normal timing for SecDir reviews anyway. Thanks, Kathleen On Mon, Jan 30, 2017 at 5:13 AM, Nat Sakimura <[email protected]> wrote: > Hi OAuthers: > > I have finally pushed -10 and -11 which hopefully resolved all the comments > provided by Jan 17. > > Changes are as follows. > > #20: KM1 -- some wording that is awkward in the TLS section. > > Accepted the suggested edit. > > #21: KM2 - the additional attacks against OAuth 2.0 should also have a pointer > > Accepted. > Added the references to the security considerations in RFC7515, 7516, 7518. > > #22: KM3 -- Nit: in first line of 10.4: > > Accepted. > s/researchs/research/ > > #23: KM4 -- Mention RFC6973 in Section 11 in addition to ISO 29100 > > Accepted in principle. > Added a paragraph on RFC6973. > > #24: SECDIR review: Section 4 -- Confusing requirements for sign+encrypt > > Accepted in principle. Modified as follows: > > - JWS signature should also be applied. > - In this case, it MUST be signed then encrypted, > - with the result being a Nested JWT, as defined in > - <xref target="RFC7519">JWT</xref>. > + JWS signature SHOULD also be applied so that the source > authentication > + can be done. > + When both signature and encryption are being applied, > + the JWT MUST be signed then encrypted as advised in > + the section 11.2 of <xref target="RFC7519" />. > + The result is a Nested JWT, as defined in > + <xref target="RFC7519" />. > > - <t>The Authorization Request Object may be sent by value as > + <t>The Authorization Request Object MAY be sent by value as > > #36: DP - More precise qualification on Encryption needed. > > Accepted in principle. > > - <t>JWE encrypted; or </t> > + <t>JWE encrypted (when symmetric keys are being > used); or </t> > > #25: SECDIR review: Section 6 -- authentication and integrity need not be > provided if the requestor encrypts the token? > > Superseded by #36 > > #26: SECDIR Review: Section 10 -- why no reference for JWS algorithms? > > Accepted by modifying as: > > - JWS signed with then considered appropriate algorithm > - or encrypted using <xref target="RFC7516"/>. </t> > + signed using <xref target="RFC7515">JWS</xref> > + or encrypted using <xref target="RFC7516">JWE</xref> > + with then considered appropriate algorithm. </t> > > #27: SECDIR Review: Section 10.2 - how to do the agreement between client and > server "a priori"? > > Accepted. Resolved by adding the following: > > + Note that the such agreement needs to be done in a > + secure fashion. For example, the developers from the > + server side and the client side can have a face to face > + meeting to come to such an agreement. > > #28: SECDIR Review: Section 10.3 - Indication on "large entropy" and "short > lifetime" should be indicated > > Accepted. Resolved by adding: > > + The adequate shortness of the validity and > + the entropy of the Request Object URI depends > + on the risk calculation based on the value > + of the resource being protected. A general guidance > + for the validity time would be less than a minute > + and the Request Object URI is to include a cryptographic > + random value of 128bit or more at the time of the > + writing of this specification. > > #29: SECDIR Review: Section 10.3 - Typo > > Accepted. > > - applies. In addition, the Authorization Server > + apply. In addition, the Authorization Server > > #30: SECDIR Review: Section 10.4 - typos and missing articles > > Fixed several. According to grammarly.com, there is no errors left, but there > may be more... > > #31: SECDIR Review: Section 10.4 - Clearer statement on the lack of endpoint > identifiers needed > > Accepted. Resolved by modifying as: > > - An extension specification should be created. > + An extension specification should be created > + as a preventive measure to address > + potential vulnerabilities that has not yet been identified. > > #32: SECDIR Review: Section 11 - ISO29100 needs to be moved to normative > reference > > Accepted. > > #33: SECDIR Review: Section 11 - Better English & Entropy language needed > > Accepted. Modified as: > > - of one-time use and MUST have large enough entropy > + used only once, have short validity period, and MUST have large > enough entropy > > + The adequate shortness of the validity and > + the entropy of the Request Object URI depends > + on the risk calculation based on the value > + of the resource being protected. A general guidance > + for the validity time would be less than a minute > + and the Request Object URI is to include a cryptographic > + random value of 128bit or more at the time of the > + writing of this specification. > > #34: Section 4: Typo > > Fixed the errors spotted by grammarly.com > > #35: More Acknowledgement > > Added Denis Pinkas, Kathleen Moriarty (as AD), and Steve Kent (as SECDIR). > > > Please let me know if there are other changes needed. > > Best, > > Nat Sakimura > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Monday, January 30, 2017 7:08 PM >> To: Nat Sakimura <[email protected]>; John Bradley <[email protected]> >> Subject: New Version Notification for draft-ietf-oauth-jwsreq-11.txt >> >> >> A new version of I-D, draft-ietf-oauth-jwsreq-11.txt has been successfully >> submitted by Nat Sakimura and posted to the IETF repository. >> >> Name: draft-ietf-oauth-jwsreq >> Revision: 11 >> Title: The OAuth 2.0 Authorization Framework: JWT Secured >> Authorization Request (JAR) >> Document date: 2017-01-30 >> Group: oauth >> Pages: 24 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-11.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-11 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-11 >> >> Abstract: >> The authorization request in OAuth 2.0 described in RFC 6749 utilizes >> query parameter serialization, which means that Authorization Request >> parameters are encoded in the URI of the request and sent through >> user agents such as web browsers. While it is easy to implement, it >> means that (a) the communication through the user agents are not >> integrity protected and thus the parameters can be tainted, and (b) >> the source of the communication is not authenticated. Because of >> these weaknesses, several attacks to the protocol have now been put >> forward. >> >> This document introduces the ability to send request parameters in a >> JSON Web Token (JWT) instead, which allows the request to be JWS >> signed and/or JWE encrypted so that the integrity, source >> authentication and confidentiality property of the Authorization >> Request is attained. The request can be sent by value or by >> reference. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > -- Best regards, Kathleen _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
