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
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Kathleen Moriarty