Re: [OAUTH-WG] My review of draft-ietf-oauth-json-web-token-11

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 23 April 2014 08:41 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949F61A0134 for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 01:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.273
X-Spam-Level:
X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
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 LLmuHrzoPdWx for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 01:41:33 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id E2CD91A012E for <oauth@ietf.org>; Wed, 23 Apr 2014 01:41:32 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M8JyQ-1WpaIp21WU-00vtSS; Wed, 23 Apr 2014 10:41:25 +0200
Message-ID: <53577C32.5060604@gmx.net>
Date: Wed, 23 Apr 2014 10:39:14 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>, oauth mailing list <oauth@ietf.org>
References: <1373E8CE237FCC43BCA36C6558612D2AA347D1@USCHMBX001.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739439A0A956A@TK5EX14MBXC286.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A0A956A@TK5EX14MBXC286.redmond.corp.microsoft.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PSPTctst4rODBX7iGeVHMPIPdP0NShqWG"
X-Provags-ID: V03:K0:VMwxkKEilhHf/lLRFPmleivsi1WAcy7aEiIM07nXz2vJQ9m362o 4eGO+ATdhbsscEk4FelhLdHZokvOJOIdBHrwdXKQCv00uBRgWT7vYKxEdUXoQ7wMFw6g4Fj zwSt7FRmGOR3oz9TuldX4HdWXpkOtuGxsarGb4l7aVwyuF2xwg7VMuRSwGr2PCqPuIPrBwN 6i3qFKtSJQ5RzuivpHLpw==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HQu9bO_KjaShzfnCz90pKAp9dxA
Subject: Re: [OAUTH-WG] My review of draft-ietf-oauth-json-web-token-11
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 08:41:37 -0000

Hi Mike,

thanks for the clarifications. My comments are addressed.

Ciao
Hannes


On 03/03/2014 11:22 PM, Mike Jones wrote:
> Hi Hannes,
> 
>  
> 
> My replies to your comments follow in-line.  Thanks again for writing
> these up.
> 
>  
> 
>                                                             -- Mike
> 
>  
> 
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, September 12, 2013 1:07 AM
> To: oauth mailing list
> Subject: [OAUTH-WG] My review of draft-ietf-oauth-json-web-token-11
> 
>  
> 
> Hi Mike, Hi all,
> 
>  
> 
> As part of preparing the shepherd write-up I have read the draft and
> here are a few comments.
> 
>  
> 
> In general, the draft looks good. The comments are fairly minor.
> 
>  
> 
> 1. Section 4: JWT Claims
> 
>  
> 
> In the first paragraph you write:
> 
> "
> 
> The Claim Names within a JWT Claims Set MUST be unique; recipients MUST
> either reject JWTs with duplicate Claim Names or use a JSON parser that
> returns only the lexically last duplicate member name "
> 
>  
> 
> I think what you want to write here is that the sender of a JWT must
> ensure that the claims are unique. If a JWT is, however, received with
> non-unique claims then some decision must be taken. You list two choices
> and I am wondering why not just have one. Let's just reject the JWT if
> that happens to ensure consistent behavior.
> 
>  
> 
> This was extensively discussed within JOSE and the language used is the
> same.  Ideally, yes, we’d reject duplicate names, but both the old and
> new JSON specs allow duplication, so if we’re to use existing deployed
> parsers, that isn’t really a practical option.  (We used to require
> rejection of duplicate names, but objections were raised to that.)
> 
>  
> 
> I believe it might be good to clarify that unique here means that claims
> may appear more than once in a JWT but you are concerned about having
> two claims that actually have a different semantic. Correct?
> 
>  
> 
> No, the issue is that either parsers will only return one (they will
> overwrite each other) or duplicates will cause a parsing error. 
> Therefore, for things to always work regardless of parser, producers
> can’t include any duplicates.
> 
>  
> 
> You write: "However, in the absence of such requirements, all claims
> that are not understood by implementations SHOULD be ignored."
> 
>  
> 
> The 'SHOULD' is not good enough here. Either you ignore claims that you
> don't understand or you do something else. Since there does not seem to
> be a way to declare claims as "critical" to understand I suggest to turn
> this into a MUST.
> 
>  
> 
> Agreed.  I made this change in -18.
> 
>  
> 
> With every claim you add "Use of this claim is OPTIONAL.". I would
> suggest to move that sentence to the front and avoid repeating it with
> every claim. In fact you have that necessary sentence currently in
> Section 4.1 "None of the claims defined below are intended to be
> mandatory to use, but rather, provide a starting point for a set of
> useful, interoperable claims."
> 
>  
> 
> For what it’s worth, Jim Schaad had requested the opposite – that the
> “OPTIONAL” statements be on a per-name basis – so each definition could
> be easily read in isolation.
> 
>  
> 
> Since you describe the "use" there is obviously the question about the
> "implementation". So, what claims in this document are mandatory to
> implement? All? None?
> 
>  
> 
> None.  It’s up to the application what claims are MTI for its use case. 
> I added text clarifying this.
> 
>  
> 
> Claim Types: You distinguish between three types of claims, namely
> Reserved Claim Names, Public Claim Names, and Private Claim Names.
> 
>  
> 
> - Reserved claims are those that are registered with IANA.
> 
>  - Public Claims are (interestingly enough) also registered via IANA or
> use a Collision Resistant Namespace.
> 
>  - Private Claims are those that may produce collisions
> 
>  
> 
> Clear I would suggest to change the definition of a public claim. Let's
> just call the claims that are registered via IANA reserved claims.
> 
>  
> 
> “Reserved” was changed to “registered”, both here and in JOSE, as a
> result of review comments from both working groups.
> 
>  
> 
> I also wonder why we need private claims at all when it is so easy to
> construct public claims?
> 
>  
> 
> In practice, people will use unregistered names in some contexts. 
> (There was a 1/2 hour presentation in AppsAWG today about this very
> thing!)  Given we really can’t prevent this and it will happen, it’s
> better to clearly describe the downsides and alternatives than to
> pretend that private names won’t be used.  At least this way, people
> will have been warned about the consequences of their choices.
> 
>  
> 
> Section 4.1.1: "iss" (Issuer) Claim
> 
>  
> 
> You write:
> 
> "
> 
> The iss (issuer) claim identifies the principal that issued the JWT. The
> processing of this claim is generally application specific.
> 
> "
> 
>  
> 
> Would it be useful to say what people use this claim for. It might also
> be useful to indicate that this value cannot be relied on for any trust
> or access control decisions without proper cryptographic assurance. I
> can already see people who base their security decisions on this value
> without any relationship to the actual crypto of the JWT. So, one might
> wonder what the relationship of the crypto and the iss claim is.
> 
>  
> 
> I added language about making trust decisions in the Security
> Considerations section.  Did you have particular language in mind about
> what the claim is used for, beyond stating that it identifies the issuer?
> 
>  
> 
> Section 4.1.3: "aud" (Audience) Claim
> 
>  
> 
> You write:
> 
> "
> 
> The aud (audience) claim identifies the audiences that the JWT is
> intended for.
> 
> "
> 
>  
> 
> That's not a good description. You could instead write: "The aud
> (audience) claim identifies the recipient the JWT is intended for."
> 
>  
> 
> Agreed – done.
> 
>  
> 
> You write:
> 
> "
> 
> In the special case when the JWT has one audience, the aud value MAY be
> a single case sensitive string containing a StringOrURI value.
> 
> "
> 
>  
> 
> Shouldn't this read:
> 
> "
> 
> In the special case when the JWT has one audience, the aud value is a
> single case sensitive string containing a StringOrURI value.
> 
> "
> 
>  
> 
> No – because either “aud”:”foo” or “aud”:[“foo”] are legal and mean the
> same thing.
> 
>  
> 
> Section 4.1.8. "typ" (Type) Claim
> 
>  
> 
> You write:
> 
> "
> 
> The typ (type) claim MAY be used to declare a type for the contents of
> this JWT Claims Set in an application-specific manner in contexts where
> this is useful to the application. The typ value is a case sensitive
> string. Use of this claim is OPTIONAL.
> 
>  
> 
> The values used for the typ claim come from the same value space as the
> typ header parameter, with the same rules applying.
> 
> "
> 
>  
> 
> I believe the first sentence should say: "The typ (type) claim is used
> to declare a type for the contents of this JWT Claims Set ....". I don't
> understand what the "MAY" here was supposed to indicate since if it does
> not declare the type of the claims then what else does it do?
> 
>  
> 
> Why is the typ claim actually there when there is already the same claim
> in the header?
> 
>  
> 
> The “typ” claim was removed as part of the JOSE change to use MIME type
> names for “typ” and “cty” header parameter values.
> 
> Section 5.1. "typ" (Type) Header Parameter
> 
>  
> 
> You write:
> 
> "
> 
> The typ (type) header parameter MAY be used to declare the type of this
> JWT in an application-specific manner in contexts where this is useful
> to the application. This parameter has no effect upon the JWT
> processing. If present, it is RECOMMENDED that its value be either JWT
> or urn:ietf:params:oauth:token-type:jwt to indicate that this object is
> a JWT.
> 
> "
> 
>  
> 
> Here again I would write: " The typ (type) header parameter is used to
> declare the type of this JWT in an application-specific manner in
> contexts where this is useful to the application."
> 
>  
> 
> Why doesn't this value have any impact on the processing? It appears to
> be useless? Would it be good to mandate that it is set to JWT or
> urn:ietf:params:oauth:token-type:jwt when the content is a JWT? Why do
> you leave two options for what the value is set to? Why would anyone use
> the longer string?
> 
>  
> 
> The URN value was removed as part of the JOSE change to use MIME type
> names for “typ” and “cty” header parameter values.
> 
>  
> 
> Section 5.2. "cty" (Content Type) Header Parameter
> 
>  
> 
> What is the relationship between cty and typ?
> 
>  
> 
> As described in the JOSE specs that define them, “typ” is the type of
> the entire object, whereas “cty” is the type of the message contained in
> the JWS or JWE.  Both are now MIME type values.  “cty” is used by JWTs
> in the specific way specified whereas “typ” can be used as needed by
> applications using JWTs.
> 
>  
> 
> Section 5.3. Replicating Claims as Header Parameters
> 
>  
> 
> I am not sure why you would want to have encryption of the claims and
> then again include them in cleartext. That would defeat the purpose of
> encryption. Then, you could as well just provide them in cleartext (only
> signed, for example).
> 
>  
> 
> Putting the sub value into the header does not seem to be a good idea
> since this may be personal data.
> 
>  
> 
> This showed up in a use case that Dick Hardt had, in which case he
> wanted to route the contents of the JWT to the recipient without being
> able to read the contents of the JWT itself.  In his case, there was an
> intermediary handling the JWT that did not have the decryption key.
> 
>  
> 
> It’s application-specific whether the audience is private information or
> not.
> 
>  
> 
> Putting these fields into the header in general does not strike me as a
> good idea since you loose the ability to sign these values. They will be
> exposed to all security threats since they cannot be protected. Why not
> use a nested JWT instead?
> 
>  
> 
> They are still integrity-protected, because JWE uses only authenticated
> encryption.  They are protected from tampering or alteration.
> 
>  
> 
> The 'SHOULD' in this sentence particularly makes me nervous: "If such
> replicated Claims are present, the application receiving them SHOULD
> verify that their values are identical." This essentially means that if
> you have protected claims and someone adds unprotected stuff into the
> header it may mean that an application would accept that. Not a good idea!
> 
>  
> 
> Per the above, you can’t add stuff, because of the authenticated
> encryption used.
> 
>  
> 
> Section 6 Plaintext JWTs
> 
>  
> 
> Why do we want plaintext JWTs? I thought that the threat analysis
> concluded that sending this stuff of information around without any
> security protection is a bad idea.
> 
>  
> 
> The JWT can either be cryptographically protected by a signature and/or
> encryption in the JWT itself or by signature and/or encryption of a data
> structure in which the JWT is conveyed.  For instance, if it is returned
> from an OAuth Token Endpoint, it is integrity protected by the channel’s
> use of TLS and so may not need to be signed and/or encrypted in some
> application contexts.  OpenID Connect uses this capability in several
> places, for instance, as does Phil Hunt’s OAuth Authentication draft.
> 
>  
> 
> Section 7. Rules for Creating and Validating a JWT
> 
>  
> 
> I am curious why this section is so extensive given that we are
> essentially just applying JWS and JWE here. Wouldn't a pointer to the
> JWS/JWE spec be sufficient?
> 
>  
> 
> It’s longer because the JWT adds two things:  First, the contents can be
> either a JWS or JWE, and so there’s logic described for the slightly
> different actions taken in the two cases.  Second, the JWT can be
> nested, so the logic for nesting and detecting nested JWTs is defined. 
> It **does** just rely on JWS and JWE for the creation and verification
> aspects of the JWS and JWE aspects of JWTs.
> 
>  
> 
> That said, I did remove a step that was actually a pure duplication of a
> corresponding JWS/JWE step.
> 
>  
> 
> Ciao
> 
> Hannes
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> _______________________________________________
> 
> OAuth mailing list
> 
> OAuth@ietf.org
> 
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>