Re: [secdir] SECDIR review of draft-ietf-oauth-jwsreq-09.txt
"Nat Sakimura" <n-sakimura@nri.co.jp> Mon, 30 January 2017 08:48 UTC
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B9F126B6D for <secdir@ietfa.amsl.com>; Mon, 30 Jan 2017 00:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.969
X-Spam-Level:
X-Spam-Status: No, score=-6.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 odHhJLqoDoiT for <secdir@ietfa.amsl.com>; Mon, 30 Jan 2017 00:48:57 -0800 (PST)
Received: from PCH.mit.edu (pch.mit.edu [18.7.21.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13EE1293EC for <secdir@ietf.org>; Mon, 30 Jan 2017 00:48:56 -0800 (PST)
Received: from pch.mit.edu (localhost.localdomain [127.0.0.1]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id v0U8mthW011664 for <secdir@ietf.org>; Mon, 30 Jan 2017 03:48:55 -0500
Received: from mailhub-dmz-2.mit.edu (mailhub-dmz-2.mit.edu [18.7.62.37]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id v0U8mpte011661 for <secdir@mailman.mit.edu>; Mon, 30 Jan 2017 03:48:52 -0500
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id v0U8mV9Y008955 for <secdir@mit.edu>; Mon, 30 Jan 2017 03:48:51 -0500
X-AuditID: 1209190c-2afff70000006de5-44-588efdef1d4b
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by (Symantec Messaging Gateway) with SMTP id 42.26.28133.0FDFE885; Mon, 30 Jan 2017 03:48:50 -0500 (EST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id 211061968E0; Mon, 30 Jan 2017 17:48:47 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 8489F4E0046; Mon, 30 Jan 2017 17:48:46 +0900 (JST)
Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id v0U8mkEu029636; Mon, 30 Jan 2017 17:48:46 +0900
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp with ESMTP id v0U8mjaI029630; Mon, 30 Jan 2017 17:48:46 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v0U8mjwN001716; Mon, 30 Jan 2017 17:48:45 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v0U8mjDA001715; Mon, 30 Jan 2017 17:48:45 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v0U8mjS1001712; Mon, 30 Jan 2017 17:48:45 +0900
From: Nat Sakimura <n-sakimura@nri.co.jp>
To: 'Steve KENT' <steve.kent@raytheon.com>, secdir@mit.edu
References: <67adb90acb8c4a23beaeb5d0b39800bf@CY1PR0601MB023.008f.mgd2.msft.net>
In-Reply-To: <67adb90acb8c4a23beaeb5d0b39800bf@CY1PR0601MB023.008f.mgd2.msft.net>
Date: Mon, 30 Jan 2017 17:48:45 +0900
Message-ID: <001201d27ad5$aa82d790$ff8886b0$@nri.co.jp>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJOm09WvX4P5pGJ5FM9qeQSqgTlmaBQaMUw
Content-Language: ja
X-MailAdviser: 20141126
Authentication-Results: symauth.service.identifier
X-Brightmail-Tracker: H4sIAAAAAAAAA1VSa0hTYRj23dnlbO7Icd4+TUsXgmSzDM0sEf+U5p/0R7QKzKM7udE2bWeK mtAqvCBmAyFqlGWS4KW85m1iMhBRhlkmBJEKRopa4gwqUeycHWf25+N93+d5n+f5+D4cU7wS h+B0sZk2GSm9UiwTlm9ugsq1Xas+vvom6lTFN7s4BdLuOkexDLgiS9LQel0RbTqWnC3Tbj10 YQV9g1C8YhkXW2DhBVSDFEdkHJqb+iOqBhmuIHsAzTkHJHzTBKhrfEnIN/WA3jc2YXzTAqh5 vQP4pgbQ8MbYrsAAoN5fbbs7dYDqBqwYb5ODRqZ6d/ebAf2en2NZOC4mo9FkdTjH8SeTkXXe 4o6FkanI1W1z7yrIDPRgZF7I1VIyE9V82XTP/cgk1LBT7p4LyUg09mNJzEkSZAJ6ao/jxgTp i8YffxXykldRy+qWgI8TjuyuURFvewKN1w9JeI4/aumf2I0chDomn7njAMuxTy6LrBBs2ydr 2ydr27duY1NgZAyq6AR+fAj1fX+C8bUK7Sx66mjU1LCCPQdJC4RpDKUqA6XTM3SuismljEba pIqNMejMMbSmsAvYt1ZIg+X94FxNdwCJg1JOfPKrVStEVBFTYnBAMC5QBhC16+zIJydfU6Kl GO01U6GeZhyAcEzpTzRvsRihoUpKaVO+BzqAC5VBBIq6o1aQeZSZvkHTBbTJgwpwiQNCcVyJ iHj2kyl8TXQeXXxdpzfv50i5Q8bZyFmbdrcNU0AZGF0eT5qAiJAgYo4DSA7QFhr3BDy/+AOE hfgR4OXlpZCzCdiL/48vQxB7aT9ihlOR64zmPfVl1ljAGqcuu43N1D8oxAJZwsGy+5VxjZce zUfad1p7vBNt9MiZo/qNIVuM97nhdmu2v1o3W9Uav+0SWG6np87cNJx+OTKoyUxYS6UWJYk5 PuerijsrV8OdIlt3RNvFg4GHpjsLLqRkveu41V32uumk7vPHaWlgxuGMywuzyY6B0HtMV8Da z46zCWlLb9eN9Uoho6Vij2AmhvoLS6eeocADAAA=
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: multipart/mixed; boundary="===============3145403237061402658=="
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/BhBVCoBCDQ6ElRxQv3phiQwWpvU>
Subject: Re: [secdir] SECDIR review of draft-ietf-oauth-jwsreq-09.txt
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 08:48:59 -0000
Hello. Sorry to have taken more than a week to reply. I have pushed -10 which hopefully has addressed all the issues raised. I have recorded all your comments into the issue tracker [1] of my working repository and was recording the changes so you can see how I tried to resolve them there as well. [1] <https://bitbucket.org/Nat/oauth-jwsreq/issues?q=SECDIR> https://bitbucket.org/Nat/oauth-jwsreq/issues?q=SECDIR 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. From: Steve KENT [mailto:steve.kent@raytheon.com] Sent: Tuesday, January 17, 2017 5:14 AM To: secdir@mit.edu Cc: ve7jtb@ve7jtb.com; n-sakimura@nri.co.jp; Hannes.Tschofenig@gmx.net; derek@ihtfp.com Subject: SECDIR review of draft-ietf-oauth-jwsreq-09.txt I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document proposes a mechanism to enable secure communication of OAuth 2.0 Authorization Requests using a JSON Web Token (JWT). This mechanism represents an improvement over the current way that OAuth Authorization Requests are transmitted, i.e., encoded as an (unprotected) URI. The document notes that the current Authorization Request mechanism fails to provide integrity, authentic, or confidentiality. JSON is already used for OAuth responses, so using JWT to protect requests seems like an appropriate choice. (XML signatures and encryption were rejected as too complex.) Section 4 defines the Request Object format and provides examples. The text here is a bit confusing. It seems to state that only integrity and authenticity are mandated by this specification; confidentiality is an optional feature. However, when discussing the use of encryption that does not provide authentication, the text says that a signature "should" (not SHOULD"") be applied. The text then says that "In this case, it [the token] MUST be signed then encrypted ." This combination of sentences is confusing and OUGHT :) to be revised. Section 6 describes how to validate a received JWT request token. Section 6.1 appears to not mandate use of a signature for an encrypted token, suggesting that authentication and integrity need not be provided if the requestor encrypts the token (and does not employ an authenticated encryption algorithm). Section 10 describes Security Considerations in addition to the ones already describes in RFC 6119 (OAuth 2.0). The wording of Section 10.1 is odd: " .it MUST either be JWS signed with then considered appropriate algorithm or encrypted using [RFC7516]." Why is there no cite of 7515 for JWS algorithms here, to parallel the cite of JWE? Section 10.2 indicates that a client and server might agree, a priori, to use the non-protected parameters transmitted in a request. It does not indicate how this might have been done (hopefully, in a secure fashion). Section 10.3 finally mandates authentication of the request source, something that was ambiguous in earlier sections of this document. There are some ambiguous statement here, e.g. "Since Request Object URI can be replayed, the lifetime of the Request Object URI MUST be short and preferably one-time use. The entropy of the Request Object URI MUST be sufficiently large." The lack of guidance of what constitutes a "short" lifetime or a "sufficiently large" amount of entropy (in a short URI) is worrisome. In (d) there is a typo: "The same requirements as (b) above applies." -> "The same requirements as (b) above apply". Section 10.4 includes several typos: "Although this specification does not require them, researchs such as ." -> "Although this specification does not require them, research such as ." This is the beginning of a run-on sentence. "The endpoints that comes into question ." -> The endpoints that come into question ." The wording in several places is awkward, e.g., missing articles. This section ends with the statement "An extension specification should be created." Presumably the intent here is to suggest that an extension is needed to remedy the vulnerability resulting from the lack of explicit endpoint identifiers. This should be more clearly stated. Section 11 discusses Privacy Considerations an unusual element of an RFC. (The authors state that ISO/IEC 29100 is freely accessible. That seems to be true only if one follows the URL in the Informative References. A search for this ISO document tends to yield copies available for a non-trivial fee, i.e., ~ $150 USD.) Since there is standards language in this section (SHOULD and MUST) I think 29100 needs to be a Normative (not Informational) reference. The text here raises some good privacy concerns and suggests some means by which these concerns might be addressed. However, the wording here needs to be significantly improved. There are extraneous articles and missing articles that make the text harder to read. The ambiguous comment about entropy that appeared in 10.3 appears here as well.
_______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir
- [secdir] SECDIR review of draft-ietf-oauth-jwsreq… Steve KENT
- Re: [secdir] SECDIR review of draft-ietf-oauth-jw… John Bradley
- Re: [secdir] SECDIR review of draft-ietf-oauth-jw… Nat Sakimura
- Re: [secdir] SECDIR review of draft-ietf-oauth-jw… Steve KENT
- Re: [secdir] SECDIR review of draft-ietf-oauth-jw… Nat Sakimura