[secdir] Review of: draft-ietf-oauth-json-web-token

Warren Kumari <warren@kumari.net> Mon, 01 September 2014 22:40 UTC

Return-Path: <warren@kumari.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFCF1A0B06 for <secdir@ietfa.amsl.com>; Mon, 1 Sep 2014 15:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.922
X-Spam-Level: *
X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 ch1XN71ysWll for <secdir@ietfa.amsl.com>; Mon, 1 Sep 2014 15:40:31 -0700 (PDT)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2001F1A0AFF for <secdir@ietf.org>; Mon, 1 Sep 2014 15:40:30 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id y10so5980388wgg.8 for <secdir@ietf.org>; Mon, 01 Sep 2014 15:40:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=dfZlS2UNF2cC0rBwdmOFRZhMQzb8UMHrJwBGw3uacB8=; b=PK0LF4r8aC58Run9S527Q37Z8tYOIVSzXQcA8PiR+vdG7rRbUFrzp0y735YDpHFUx2 +cK0+uqloN7lOS7cFWuLQbxArIprNh0Ng5YNeFRacp+qjRRGtMZunLkNVygkquJn650B I556BFqEJNFS/NvUYVflgPFWMIjzt44CqBdrKocNF5YYbe7Bb8sYYNCwfaPBM+jE7rWO YiqHIbM4OpwwCzTOTeRBH02VGIXNeB1TcPukLIbGyD5iC0sFuO4X9CqsWDucUy9IwDIU gIoN9AoMMHDtfzCDcEOZv0L2eNK74Ny3GqqnodQ42unrwTFjjdqWMBZa9kaFVDRLJrh1 ZY6Q==
X-Gm-Message-State: ALoCoQlPKTd1xdYmu5u2OvIxN4MyHu+kpcRUnNp5+X3oUQ9eXcJndWvh10j6DKW0lgjvJ1nhUMS/
MIME-Version: 1.0
X-Received: by 10.180.210.231 with SMTP id mx7mr24019514wic.42.1409611229452; Mon, 01 Sep 2014 15:40:29 -0700 (PDT)
Received: by 10.194.62.39 with HTTP; Mon, 1 Sep 2014 15:40:29 -0700 (PDT)
Date: Mon, 1 Sep 2014 18:40:29 -0400
Message-ID: <CAHw9_iJqA=frT15_UFCFUCvTkqTsKSOOOyBct-3UeE19ge7AFw@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-oauth-json-web-token.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/paJUtmBuccF4PN1lNOqzfTaagdg
Subject: [secdir] Review of: draft-ietf-oauth-json-web-token
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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, 01 Sep 2014 22:40:35 -0000

Be ye not afraid -- I have reviewed 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 primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

Disclaimer: I know next to nothing about JOSE. In reading this
document I also went off and read some other JOSE work / WG documents.
The main thing that I learnt was that them thar JOSE folk sure do like
their acronyms.. :-) My unfamiliarity with JOSE means that, unlike
what the above boilerplate says, you should treat these less seriously
than any other last call comments!


Summary:
Needs some work, nothing major.


Notes:
In a number of places the document says things like: "If any of the
listed steps fails then the JWT MUST be rejected for processing." -
does it actually *mean* to reject a JWT? What should an application do
when it rejects a JTW (yes, I realize that this is somewhat
application specific, but a general "Explode, killing everybody
inside" vs "Simply pretend you didn't notice this" would be helpful).


I'm a little confused by something in the Terminology section (Section 2):
Plaintext JWT
 A JWT whose Claims are not integrity protected or encrypted.


The term plaintext to me means something like "is readable without
decrypting / much decoding" (something like, if you cat the file to a
terminal, you will see the information). Integrity protecting a string
doesn't make it not easily readable. If this document / JOSE uses
"plaintext" differently (and a quick skim didn't find anything about
this) it might be good to clarify. Section 6 *does* discuss plaintext
JWTs, but doesn't really clarify the (IMO) unusual meaning of the term
"plaintext" here.


MACed does not seem to be a well known term - surprisingly enough even
MAC doesn't have an asterisk at
https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt


Section 4:
"...  recipients MUST either reject JWTs with duplicate
 Claim Names or use a JSON parser that returns only the lexically last
 duplicate member name..."

This somewhat made me itch - some implementations will reject a given
JWT, some will accept it -- I know very little about parsing JSON, but
could you suggest which an implementation should prefer? Can I
instruct standard parsers to do X in this case?


Section 4.1.4. "exp" (Expiration Time) Claim (and other time based Claims:
What should my behavior be if I simply don't know what the time is?
(I'm just a dumb device, and my RTC is claiming it is Jan1st, 1970) -
I'm assuming I must not process this JWT? Does this create
bootstrapping issues?


5.3. Replicating Claims as Header Parameters
This section scares me, and I hope I'm simply not understanding what
is being proposed. If you send the unencrypted version of some
encrypted Claims some implementations will make important security
decisions based upon those unencrypted claims, even if you tell them
in a serious voice not to. http://xkcd.com/1181/
Also, the SHOULD in "If such replicated Claims are present, the
application receiving them SHOULD verify that their values are
identical, ..." - why is this not a MUST? And if an application *does*
compare them and they are not identical, what should it do?  Perhaps a
much stronger justification for carrying 2 copies of the data is in
order.



Editorial:
The intro is almost identical to the abstract. Making the abstract
more abstract, or the intro more introductory (I have no idea what
many of the acronyms were!) would be nice. Something short explaining
what a JWT is, why I'd like one,what they get used for, why I should
keep reading this document would be very helpful - basically a
background type section...



Nits:
Abstract
O: is a compact URL-safe means
P: is a compact, URL-safe means

3.  JSON Web Token (JWT) Overview
O: The contents of the JOSE Header describe
P: Spell out JOSE; first use in document as far as I could see


5.2 "cty" (Content Type) Header Parameter
O: normal case where nested signing
P: normal case in which nested signing


8.  Implementation Requirements
O: For instance, an application might require support
   for encrypted JWTs and Nested JWTs; another might require support
P: For instance, one application might require support [...], while
another might require support [...]


11. Security Considerations
O: The entire list of security considerations is beyond the scope of
   this document, but some significant considerations are listed here.
P: The entire list of security considerations is beyond the scope of
this document.
R: A few of the considerations are already listed above; we don't need
to restate that they are listed here -- and if we do, the assumption
is that said list would follow, not be above.


11.2 Signing and Encryption Order
O: While syntactically, the signing and encryption operations for Nested
   JWTs may be applied in any order,
P: While syntactically the signing and encryption operations for Nested
   JWTs may be applied in any order,




-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf