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

John Bradley <> Mon, 16 January 2017 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC49612963D for <>; Mon, 16 Jan 2017 12:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.36
X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 13OAUr3ZUD1M for <>; Mon, 16 Jan 2017 12:18:16 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24D6F129535 for <>; Mon, 16 Jan 2017 12:18:16 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.12.8) with ESMTP id v0GKIFiY020834 for <>; Mon, 16 Jan 2017 15:18:15 -0500
Received: from ( []) by (8.13.8/8.12.8) with ESMTP id v0GKIDLU020826 for <>; Mon, 16 Jan 2017 15:18:13 -0500
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id v0GKI7Yi009164 for <>; Mon, 16 Jan 2017 15:18:13 -0500
X-AuditID: 1209190f-67fff70000006f3d-1d-587d2a83dca6
Received: from ( []) (using TLS with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 0F.9E.28477.48A2D785; Mon, 16 Jan 2017 15:18:12 -0500 (EST)
Received: by with SMTP id k15so120052381qtg.3 for <>; Mon, 16 Jan 2017 12:18:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5mnqldKaW1weXQrgzdCDeiXRnZbZ1Zp5/x6IBnhxCwk=; b=2OO65T4bqqDfs9OTh6MMcg2pdcwRnWzXV5dQwrQZjCdk1jXwqJlWv48EFFNAGH3fLt /BvwfGY9/5fUAaLns1pr1p7zq409ZBHWlOuQUS8croJ6/x+oexI/pZN288fXltTCchFX hChkAILTAISV87BgB7U1doFOVw2LBPZu8VNzn2GcOXCv1GOeGEOrtsqOoEvg0sZF553B jB6NDS05OfZXmarW5h43gD80ikkwRUzLJf/R8u47oxI3KnPf/UMgTAdxBiCGZ7s/XQEd qCQiwF7pqZeWagxxU8mu6HqSIV74MSf2D8vosyMku62iDbYF9ZqP3m4KoZBx+J6Enp0w ePzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5mnqldKaW1weXQrgzdCDeiXRnZbZ1Zp5/x6IBnhxCwk=; b=YSS1DTFl+gvOURDdVqX3TooO0fnTzPNkHtXkkCO40UtzyXyRVai7EiaN8qqQ3feIrK ysB0vG/k+MKbR5HUQ0dNtKZGr3YYxXOj71GD8dTyryvqA12A6jfqFiEXRnUAd5nW6jUb xydTK/cTee4XU7isz4d3Ki0LOHw3570HyW1Y75WH9tYMwngzYUZ2aQq1urswKGvn7E97 R0kxfcnPMxwowB8f4Y7gYhlKWe7sqgXaLAmz+zqISXxsOxEQJC3jIwCqAkQx9Dg61cmN oOpyqkp73XJDgMylepV8zrfWnOc5nmQwHqIeVlU/JcUCF+JxqSYKTzLY8IYOr/R1ikIz Xrfw==
X-Gm-Message-State: AIkVDXLWhmr9KMbLzJtqoo26+6v1pFBDZX8DBfgDkioX0wT16x2b1GSQqpKRoW7l0qyO3rYo
X-Received: by with SMTP id t1mr30288901qkt.274.1484597891629; Mon, 16 Jan 2017 12:18:11 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id u29sm17026625qki.4.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 12:18:10 -0800 (PST)
From: John Bradley <>
Message-Id: <>
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 16 Jan 2017 17:18:01 -0300
In-Reply-To: <>
To: Steve KENT <>
References: <>
X-Mailer: Apple Mail (2.3259)
Authentication-Results: symauth.service.identifier
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBJsWRWlGSWpSXmKPExsVyMfTGat0WrdoIgydTLS3anu1mc2D0aDpz lDmAMYrLJiU1J7MstUjfLoEro7/1BUvB7i+MFctX/WdtYPx9nbGLkZNDQsBE4uH0AyxdjFwc QgKLmSSOnutjg3C6GSXWTuxmB3FYBBaxSkxe2ssM4kgILGOVmPjiCjNEf4zE7uuzoexqiasP N7CB2EICChLds/6xQ4z6zyjx6dFOVpAEm4CaxNYZ+8GKeAVsJV4dXQ02lVlgCqPEzBWrmCES +hKzz1xiAbGFBWwkTi39DHYti4CqxJRPl8AGcQoESvTc/QXVvIRRYspXiNUiAhoS13d/YoI4 I0Ci/8ADFojzZCXe/loCtoBRwEhi97lXrBMYRWchWz4LyXIQm1kgSWLzpXNsELa2xLKFr5kh bE2J/d3LWTDFNSQ6v01khbBNJZ683Q7Vay3xc84jRghbUWJK90P2BYxcqxhlU3KrdHMTM3OK U5N1i5MT8/JSi3RN9HIzS/RSU0o3MQKjWIhTkn8H45wG70OMAhyMSjy8M+7WRAixJpYVV+Ye YpTkYFIS5bVVrY0Q4kvKT6nMSCzOiC8qzUktPsSoArTr0YbVFxilWPLy81KVRHg3KwDV8aYk VlalFuXDlElzsCiJ81atqIwQEkhPLEnNTk0tSC2CyTJxsB9ilOHgUJLgfaIB1C1YlJqeWpGW mVOCrIYTRHAdYpTg4AFao6sJsqa4IDG3ODMdougUoyVHT9fpl0wce3ZdBpJzbl99ySQEdpeU OO9HkMkCIA0ZpXlwg2EJ/BKjrJQwLyMDA4MQD9BlwMBBlX/FKA4MGGHeTpC1PJl5JXBbXwEd xAR00HWdapCDShIRUlINjNPLw3cfeXpn5j8HNveFqUm37Da1bnqaWzn/Q2Dhm7OF2wt0/I9t 0s88/+6pQoOgRUI6s/1tV6awYGuhcrbFz7uvPmZc1nxo6uKXJaVL5rVu5w8w3Ha8mXFhc9/f 9+dX9er7nPQsOGfoflT7b5qyQU7eLTa9LWcKGuyPP/Ndc739eMJV2YWbUpVYijMSDbWYi4oT AXuQ0a/bAwAA
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: multipart/mixed; boundary="===============7137822468120896674=="
Archived-At: <>
Cc: "" <>, Nat Sakimura <>
Subject: Re: [secdir] SECDIR review of draft-ietf-oauth-jwsreq-09.txt
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jan 2017 20:18:19 -0000

Thanks for the review. 

Nat and I will review and address your comments.

John B.

> On Jan 16, 2017, at 5:14 PM, Steve KENT <> wrote:
> 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 J 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 ashort 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