Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft

Neil Madden <> Sun, 04 June 2017 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5E56129505 for <>; Sun, 4 Jun 2017 07:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U7_tMEkqeOU9 for <>; Sun, 4 Jun 2017 07:11:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 904C712704B for <>; Sun, 4 Jun 2017 07:11:35 -0700 (PDT)
Received: by with SMTP id d73so6458919wma.0 for <>; Sun, 04 Jun 2017 07:11:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BSTRq1WvWU6dVa5FqWjVrHC+CTTA7VWsZLih/YEdeaU=; b=EcTlDyb1gxHHLllU8MWyZ3LFzArxWiW4O9ylET9hQ1h/8047EmOWvfjB5KBmnpmRyd 9Sf+JvtkGq8yhHhdWjQ49WbiLYNSr61Psp1JEy5BkJ8FLYFSpBRSP7SYZQzD0s0PMNrF +TVpB9tlhb4OtNQ7uidYc7Ja3CwwtD822OHVQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BSTRq1WvWU6dVa5FqWjVrHC+CTTA7VWsZLih/YEdeaU=; b=UJjftNxPDRMZAvLENeUu8c8I4qPlY4HBQgNOjugY6c83mDmAb1qK5dyxz/OvbZLn70 YrEKTuItFAcmb14wBAlfdbDRArUGLknewdI4xUBaKwGG14sWwKZxI8tbMNf8z1Px0RYx hAthUKdPos+FYmmsuN7Eh5c4fYBxxH2ywhiWGhTEqd0OPo5g0qm3XQvzlcywOKRUr623 /swzDLmwKhMhwT/92/p3IHjFUO7L86/Hpjsk0RF+UUPhHz2EK4mM1VZt63+apk9tz6AE Y8BbkD+5K0D0OCP+e2uAIwi/LXrRcA3trl3s1xyCho+sqiwU0XDnnAt8kTkNc1Odi88Q 2IBw==
X-Gm-Message-State: AODbwcCMXJzwQZMPN2WmzCqc9GhKDAPDV8JZj3ZvfECeiNDJrEMswwKv 6dIUTYKTWh0sAGAN9gY1sLpKXkpYUQ4aLEQjg1lOqmUDQXApUZcNEFtdrlmwajIRwOW22InvCp0 iVPsnrEnLdcmycdrPxX/mhoR+vXH556wjH8D7pgQrhn+VLfhplz/yyg==
X-Received: by with SMTP id 13mr5014898wma.19.1496585493654; Sun, 04 Jun 2017 07:11:33 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id n49sm8719873wrn.30.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 07:11:32 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-92E41BD3-AF70-4ED0-AFBC-CF5E0D1B9B85"
Mime-Version: 1.0 (1.0)
From: Neil Madden <>
X-Mailer: iPhone Mail (14F89)
In-Reply-To: <>
Date: Sun, 04 Jun 2017 15:11:31 +0100
Cc: "" <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <>
To: Mike Jones <>
Archived-At: <>
Subject: Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Jun 2017 14:11:40 -0000

I originally set this message just to the BCP authors. As requested by Mike Jones, I am sending it here too:


I've just seen this draft best-practice guide for JWTs pop up. I have a number of suggestions for improvements. Mostly, I think the advice is good but should be spelt out a bit more clearly. Here are some suggestions:

1. Explicitly spell out the ECDH-ES public key validation routines from NIST. I have a blog post summarising them:
2. Recommend that (despite the -ES) ECDH is safest when *both* keys are ephemeral (eg you use some initial step to retrieve a fresh authenticated ephemeral key from the other party). 
3. Spell out how to authenticate ECDH ephemeral keys. For instance, include an inner signed JWT that repeats the epk and possibly the apu/apv claims too. 
4. Recommend that the apu and apv claims as a bare minimum include a hash of both public keys and SHOULD include any other known identifiers. 
5. Recommend that the receiving party recalculates the apu and apv claims from known inputs to check they match. (Or leave these out of the JWT and require the other party to recalculate them).
6. Provide explicit key lifetime requirements. E.g., for AES GCM this should not exceed 2^32 messages for randomly-generated IVs, and not exceed 2^64 *blocks* in total (so unless you restrict JWT lengths to less than 2^32 blocks and use a message counter as IV then this also limits to 2^32 messages). For CBC it should not exceed 2^48 messages. 
7. Require that the "alg" and "enc" claims are ONLY used to reject unexpected algorithms, NEVER to select an algorithm (even amongst a "supported" set). Cryptographic agility should be achieved by using "kid" claims that reference one of a set of known keys and the key should specify the algorithm (either explicitly or by the key parameters/size). 
8. Deprecate or strongly recommend against all of the RSA encryption modes except OAEP-256. 
9. Strongly discourage any use of compression with encrypted JWEs - it is too easy to leak sensitive information. 
10. Recommend that if a JWE is used to encrypt a password or other value for which knowing the length may be a weakness, that such fields are explicitly padded by the application or at least use CBC mode to reduce the amount of length information leaked to a multiple of the AES block size. 
11. Require constant-time comparisons of HMAC tags. 
12. Recommend using deterministic ECDSA signatures as described in RFC 6979 to minimise the risk of leaking the private key. 
13. Recommend that if the ECDH calculation produces an all-zero shared secret that this is rejected. 
14. Never produce a signed JWT containing a "sub" claim unless you are explicitly vouching for the identity of that subject. It is far too easy to accidentally produce valid OIDC id tokens from unrelated code!

Generally I think all of the RSA usage should be deprecated. JWTs are primarily used for short tokens and RSA adds too much space overhead there and is fraught with peril. Elliptic curve crypto is also fraught with peril, but that peril can be managed by explicitly spelling out the validation required and using ephemeral keys wherever possible. 

I hope these comments are useful. 

Kind regards,

Neil Madden
Security Director, ForgeRock. 

> On 4 Jun 2017, at 14:12, Mike Jones <> wrote:
> JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) functions underlying them are now being widely used in diverse sets of applications.  During IETF 98 in Chicago, we discussed reports of people implementing and using JOSE and JWTs insecurely, the causes of these problems, and ways to address them.  Part of this discussion was an invited JOSE/JWT Security Update presentation that I gave to two working groups, which included links to problem reports and describes mitigations.  Citing the widespread use of JWTs in new IETF applications, Security Area Director Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written for JSON Web Tokens (JWTs).
> I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have produced an initial draft of a JWT BCP.  Its abstract is:
> JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.
> In Section 2, we describe threats and vulnerabilities.  In Section 3, we describe best practices addressing those threats and vulnerabilities.  We believe that the best practices in Sections 3.1 through 3.8 are ready to apply today.  Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) describes several possible best practices on that topic to serve as a starting point for a discussion on which of them we want to recommend under what circumstances.
> We invite input from the OAuth Working Group and other interested parties on what best practices for JSON Web Tokens and the JOSE functions underlying them should be.  We look forward to hearing your thoughts and working on this specification together.
> The specification is available at:
> An HTML-formatted version is also available at:
>                                                        -- Mike
> P.S. This notice was also posted at and as @selfissued.
> _______________________________________________
> OAuth mailing list