Re: [secdir] SECDIR review of draft-ietf-oauth-jwsreq-09.txt

"Nat Sakimura" <n-sakimura@nri.co.jp> Wed, 01 February 2017 07:11 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 04683129416 for <secdir@ietfa.amsl.com>; Tue, 31 Jan 2017 23:11:33 -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 25v33Y8bhDwX for <secdir@ietfa.amsl.com>; Tue, 31 Jan 2017 23:11:30 -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 0C5841293E8 for <secdir@ietf.org>; Tue, 31 Jan 2017 23:11:29 -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 v117BTPw005790 for <secdir@ietf.org>; Wed, 1 Feb 2017 02:11:29 -0500
Received: from mailhub-dmz-3.mit.edu (mailhub-dmz-3.mit.edu [18.9.21.42]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id v117BQhM005787 for <secdir@mailman.mit.edu>; Wed, 1 Feb 2017 02:11:26 -0500
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id v1178u8Y026754 for <secdir@mit.edu>; Wed, 1 Feb 2017 02:11:26 -0500
X-AuditID: 1209190c-2b3ff70000002704-dd-58918a1acfaa
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by (Symantec Messaging Gateway) with SMTP id C5.E7.09988.B1A81985; Wed, 1 Feb 2017 02:11:24 -0500 (EST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id EC1BD472EDF; Wed, 1 Feb 2017 16:11:21 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 525684E0046; Wed, 1 Feb 2017 16:11:21 +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 v117BLD6025112; Wed, 1 Feb 2017 16:11:21 +0900
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp with ESMTP id v117BKZU025017; Wed, 01 Feb 2017 16:11:21 +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 v117BKlN036023; Wed, 1 Feb 2017 16:11:20 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v117BKko036022; Wed, 1 Feb 2017 16:11:20 +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 v117BKWb036019; Wed, 1 Feb 2017 16:11:20 +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>, <001201d27ad5$aa82d790$ff8886b0$@nri.co.jp> <6904c3ea12444b64b827b4d3de176fe2@CY1PR0601MB023.008f.mgd2.msft.net>
In-Reply-To: <6904c3ea12444b64b827b4d3de176fe2@CY1PR0601MB023.008f.mgd2.msft.net>
Date: Wed, 1 Feb 2017 16:11:21 +0900
Message-ID: <00c301d27c5a$64291300$2c7b3900$@nri.co.jp>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJOm09WvX4P5pGJ5FM9qeQSqgTlmQJxuPp/AhArlwigN244QA==
Content-Language: ja
x-mailadviser: 20141126
Authentication-Results: symauth.service.identifier
X-Brightmail-Tracker: H4sIAAAAAAAAA1VSa0hTYRj23dnm2dqp09HYq2npipJsdiGoH1ESlRIZRQVWYp3a0a22JTtn 3vCHqzbUtLwSbpFZdNsPKY00/FEO/NEKuyEVSEqU0bILXUxMs3M80+zP4Xm+5/me5335Dkkw LepYkisUOIedtRrUWqV7dBSMcRU1mSs/+Feu8wx2qlMh/cSjbmIn7NeuN3FWSz7nWLHhkNbc 4NuaVz0OhSN3P0MpuPuhAjQk0mvwYWO5sgK0JEPfBuz3VYFMrgLW+prUMrkA+PlVT5jcAPx+ 1qeSSSVg7+3aMOkAbLl2P5xWC3hlJKCSaw5jx71xQhauAw79domEJNV0MvZUJEieaHoDVg+U To5F0Gn4rc0b9ncB+p+2E5KgoXdhS9WTydAoej02T7iVElbSi/Gl68ckpui1eGG0jpDxXHzQ +FYphx5A953e8EAJ2PmtWyUXb8If7i9hTzT6O4KE7NHj8FDf5EBAr8bOnpCqGmK8M2K9M2K9 M657xdUIOgU9t0A+Xojtn84TMjbixPspnIxXmz8SFyHSD/EmW7HRxlqsPHfEyB9h7XbOYVyV YrMIKZzJ2QriYzOaGF0HPBraFgCaBIOO+vqwOpNRsfl8kS0AMaTCMI/KLROPZh8+bioys7z5 oMNp5fgAIEkYoqlUT00mQ5nYomLOcXxKmk8qDXoKk1yZDJ3LCtwxjsvjHFOqgowMQBxJGpDS lYu35zq4XK4wx2IVZno00kcr1ejEmgWSkeLzWBtvyZVNQUiM1VNCmSjQkmB22qcDpn7jZxAf G0VBREQEoxMnEBf/Xw+BXlw6isqW4nUWuzCdHhKLFWJxWuiMVCyw/6TYUgjGGM79+hN83lbC juw5ebry+ov62rG333eXbMxetMOz2GNd90Zhbb70cp+i6pWecQXiJ9qGh0uq+rJcSQPBrjlD ugyrZvtYf4nQ8LoVfm72YeJT7cmeeYPROXsFU2LIvmVPOnP03fKfdYX+pYPOgib2MVkQ1XQ5 PWPJqVmam/VZBiVvZlctIxw8+xcTLkvtwQMAAA==
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: multipart/mixed; boundary="===============4356363951258756955=="
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4UECkkF48s1Eyc-yaoKSZ7DKQB0>
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: Wed, 01 Feb 2017 07:11:33 -0000

Steve, 

 

Thanks very much. I am in the process of incorporating OpsDir comments. That
might solve some of your concerns re: awkward wordings. At the same time, if
you could send me the concrete text replacement for awkward phrases, I can
incorporate them in the process as well. 

 

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: Wednesday, February 1, 2017 12:08 AM
To: Nat Sakimura <n-sakimura@nri.co.jp>jp>; secdir@mit.edu
Cc: ve7jtb@ve7jtb.com; Hannes.Tschofenig@gmx.net; derek@ihtfp.com
Subject: Re: SECDIR review of draft-ietf-oauth-jwsreq-09.txt

 

Nat,

 

The revised text in the -11 version addressed my comments. There are still
several places where the wording is rather awkward, but I'll defer to the
RFC Editor to help you with these issues.

Steve

 

  _____  

From: Nat Sakimura <n-sakimura@nri.co.jp <mailto:n-sakimura@nri.co.jp> >
Sent: Monday, January 30, 2017 3:48:45 AM
To: Steve KENT; secdir@mit.edu <mailto:secdir@mit.edu> 
Cc: ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com> ; Hannes.Tschofenig@gmx.net
<mailto:Hannes.Tschofenig@gmx.net> ; derek@ihtfp.com
<mailto:derek@ihtfp.com> 
Subject: RE: SECDIR review of draft-ietf-oauth-jwsreq-09.txt 

 

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 <mailto:secdir@mit.edu> 
Cc: ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com> ; n-sakimura@nri.co.jp
<mailto:n-sakimura@nri.co.jp> ; Hannes.Tschofenig@gmx.net
<mailto:Hannes.Tschofenig@gmx.net> ; derek@ihtfp.com
<mailto: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