Last Call Review of draft-ietf-oauth-jwsreq-11
review-ietf-oauth-jwsreq-11-secdir-lc-kent-2017-02-08-00

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>
Sent: Monday, January 30, 2017 3:48:45 AM
To: Steve KENT; 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

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

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