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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
