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

"Nat Sakimura" <n-sakimura@nri.co.jp> Mon, 30 January 2017 10:14 UTC

Return-Path: <n-sakimura@nri.co.jp>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1877F12943B for <oauth@ietfa.amsl.com>; Mon, 30 Jan 2017 02:14:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHW5sJt0ixGz for <oauth@ietfa.amsl.com>; Mon, 30 Jan 2017 02:14:01 -0800 (PST)
Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459301293F4 for <oauth@ietf.org>; Mon, 30 Jan 2017 02:14:01 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs03.index.or.jp (Postfix) with ESMTP id 9E08C17EA47; Mon, 30 Jan 2017 19:14:00 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 1EF334E0046; Mon, 30 Jan 2017 19:14:00 +0900 (JST)
Received: from nriea02.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id v0UAE0wm019195; Mon, 30 Jan 2017 19:14:00 +0900
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp with ESMTP id v0UADxFm019193; Mon, 30 Jan 2017 19:13:59 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v0UADxXw022681; Mon, 30 Jan 2017 19:13:59 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v0UADxS1022680; Mon, 30 Jan 2017 19:13:59 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v0UADx5Z022677; Mon, 30 Jan 2017 19:13:59 +0900
From: Nat Sakimura <n-sakimura@nri.co.jp>
To: oauth@ietf.org, 'John Bradley' <ve7jtb@ve7jtb.com>
References: <148577085049.29921.13673476753538866150.idtracker@ietfa.amsl.com>
In-Reply-To: <148577085049.29921.13673476753538866150.idtracker@ietfa.amsl.com>
Date: Mon, 30 Jan 2017 19:13:58 +0900
Message-ID: <003801d27ae1$926ddef0$b7499cd0$@nri.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQIb0y+5WOj4f+xR2RrOKxoyGx+1t6C+Gx9Q
Content-Language: ja
X-MailAdviser: 20141126
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7atF0M5908YbhJxC1XwuhP68ACw>
Cc: 'Steve KENT' <steve.kent@raytheon.com>
Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-jwsreq-11.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 10:14:04 -0000

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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Monday, January 30, 2017 7:08 PM
> To: Nat Sakimura <n-sakimura@nri.co.jp>; John Bradley <ve7jtb@ve7jtb.com>
> 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