Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-jwsreq-11.txt

["Nat Sakimura" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> Sent: Monday, January 30, 2017 7:08 PM
> To: Nat Sakimura <[e-mail]>; John Bradley <[e-mail]>
> 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