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

[Mike Jones]

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<https://ietf.org/meeting/98/>, 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<https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-jwt-security-update-00.pdf> 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<https://tools.ietf.org/html/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:

* https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00

An HTML-formatted version is also available at:

* http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html

-- Mike

P.S. This notice was also posted at http://self-issued.info/?p=1690 and as @selfissued<https://twitter.com/selfissued>.

[Neil Madden]

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

Hi,

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: https://neilmadden.wordpress.com/2017/05/17/so-how-do-you-validate-nist-ecdh-public-keys/
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.

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).
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.
https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00
http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html
-- Mike
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

Comments on draft-sheffer-oauth-jwt-bcp-00

1. Section 2 lists 7 known and possible threats and vulnerabilities with
JWT implementations and deployments.
In the OAuth Threat Model Document (RFC 6819) collusions between users
located inside of a system are not mentioned
but nevertheless need to be considered. One threat should be added in
this document: Client collusions

Text proposal:

2.8 Client collusions

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued
in January 2013 identifies security threats coming
from hostile parties but does not mention threats coming from
collaborating parties.

JWTs are issued to a token requestor and are normally intended to be
used by that token requestor. They are cases where
the forwarding of a JWT to another party is a desirable property so
that it can be used by that other party. This is typically the case
when a JWT is intended to be used for delegation purposes.

However, there are cases where a JWT does not contain a "sub" claim,
but other claims that do not allow to identify the token requestor.
This is typically the case when a JWT contains an attribute
specifying that the token holder is over 18. In such a case, the
forwarding of
such a JWT to another party would not be a desirable property and
should be detected by target servers.

Access token binding protection methods currently developed either
by the Token Binding WG [Token Binding WG] or by the OAuth WG [OAuth
WG]
do not allow to counter the forwarding of a JWT legitimately
obtained by a party to another party. Either the legitimate party
can provide keys
to the other party, or if it can't (because private keys are
protected by a secure element) it can send requests to his secure
element to perform
the cryptographic computations that the other party needs.

Whatever kind of cryptographic is being used, when two parties are
willing to collaborate, a software-only solution will be unable to
prevent the transfer of an attribute of a party that possesses it to
another party that does not possess it. The use of a secure element
will be mandatory.

However, the use of a secure element simply protecting the
confidentiality and the integrity of some secret key or private key
will be insufficient.
Additional functional and security properties will be required for
the secure elements.

The documents related to OAuth 2.0 do not currently specify how to
support secure elements so that the forwarding of a JWT legitimately
obtained
by a party to another party can be detected by the target server.
Unless some extensions are being defined, the OAuth 2.0 framework
will be unable
to support JWTs containing attributes that do not allow to fully
identify the token holder, typically a single attribute specifying
that the token holder
is over 18.


2. Section 3 lists some best practices. Section 3.8 is written as follows:

3.8. Use and Validate Audience
If the same issuer can issue JWTs that are intended for use by more
than one relying party or application, the JWT MUST contain an "aud"
(audience) claim that can be used to determine whether the JWT is
being used by an intended party or was substituted by an attacker at
an unintended party.

JWTs may be used in a number of contexts, in particular when the
resource owner and the target server are not collocated.

If the resource or the audience parameter is being used, the STS will
have the ability to know exactly which individual or entity
has accessed which target service and may keep a log of that activity.
It would thus be in a position to act as Big Brother.

Mandating implementations to have built-in Big Brother properties does
not seem to be a "good practice".

However, there is indeed the need to restrict the use of JWTs to
specific targets. The key point is that the target service must be able
to recognize itself that the token is indeed targeted to it. As an
example, a challenge may be requested to the target service and
that challenge may then be placed into a specific filed of the JWT. The
target service may then verify that the value included
in the JWT is the one that has been recently provided.

A parameter specifying the type of the control value and the value of
the control would need to be used.
This parameter would be called a target_id (tid). It would solve the Big
Brother case.

This parameter cannot be introduced in a BCP document, but this should
be done in another document.

When the resource owner and the target server are not collocated and
when privacy is a concern, the use of these parameters
should be deprecated and the use of a "tid" parameter should be
recommended.

In any case, stating that "the JWT MUST contain an "aud" (audience)
claim" is incorrect.

Denis

Post by Mike Jones
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
<https://ietf.org/meeting/98/>, 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
<https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-jwt-security-update-00.pdf>
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
JSON Web Tokens, also known as JWTs [RFC7519
<https://tools.ietf.org/html/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.
* https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00
* http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html
-- Mike
P.S. This notice was also posted at http://self-issued.info/?p=1690
<https://twitter.com/selfissued>.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

draft-sheffer-oauth-jwt-bcp-01 has been issued, butnone of the co-author
has responded to my comments.

These comments are copied below.

Both topics mentionned below have been presented and discussed during
the OAuth workshop in Zürich on July the 13 th.

Denis

Post by Denis
Comments on draft-sheffer-oauth-jwt-bcp-00
1. Section 2 lists 7 known and possible threats and vulnerabilities
with JWT implementations and deployments.
In the OAuth Threat Model Document (RFC 6819) collusions between users
located inside of a system are not mentioned
but nevertheless need to be considered. One threat should be added in
this document: Client collusions
2.8 Client collusions
RFC 6819 (OAuth 2.0 Threat Model and Security Considerations)
issued in January 2013 identifies security threats coming
from hostile parties but does not mention threats coming from
collaborating parties.
JWTs are issued to a token requestor and are normally intended to
be used by that token requestor. They are cases where
the forwarding of a JWT to another party is a desirable property
so that it can be used by that other party. This is typically the
case
when a JWT is intended to be used for delegation purposes.
However, there are cases where a JWT does not contain a "sub"
claim, but other claims that do not allow to identify the token
requestor.
This is typically the case when a JWT contains an attribute
specifying that the token holder is over 18. In such a case, the
forwarding of
such a JWT to another party would not be a desirable property and
should be detected by target servers.
Access token binding protection methods currently developed either
by the Token Binding WG [Token Binding WG] or by the OAuth WG
[OAuth WG]
do not allow to counter the forwarding of a JWT legitimately
obtained by a party to another party. Either the legitimate party
can provide keys
to the other party, or if it can't (because private keys are
protected by a secure element) it can send requests to his secure
element to perform
the cryptographic computations that the other party needs.
Whatever kind of cryptographic is being used, when two parties are
willing to collaborate, a software-only solution will be unable to
prevent the transfer of an attribute of a party that possesses it
to another party that does not possess it. The use of a secure
element
will be mandatory.
However, the use of a secure element simply protecting the
confidentiality and the integrity of some secret key or private
key will be insufficient.
Additional functional and security properties will be required for
the secure elements.
The documents related to OAuth 2.0 do not currently specify how to
support secure elements so that the forwarding of a JWT
legitimately obtained
by a party to another party can be detected by the target server.
Unless some extensions are being defined, the OAuth 2.0 framework
will be unable
to support JWTs containing attributes that do not allow to fully
identify the token holder, typically a single attribute specifying
that the token holder
is over 18.
3.8. Use and Validate Audience
If the same issuer can issue JWTs that are intended for use by more
than one relying party or application, the JWT MUST contain an "aud"
(audience) claim that can be used to determine whether the JWT is
being used by an intended party or was substituted by an attacker at
an unintended party.
JWTs may be used in a number of contexts, in particular when the
resource owner and the target server are not collocated.
If the resource or the audience parameter is being used, the STS will
have the ability to know exactly which individual or entity
has accessed which target service and may keep a log of that activity.
It would thus be in a position to act as Big Brother.
Mandating implementations to have built-in Big Brother properties does
not seem to be a "good practice".
However, there is indeed the need to restrict the use of JWTs to
specific targets. The key point is that the target service must be able
to recognize itself that the token is indeed targeted to it. As an
example, a challenge may be requested to the target service and
that challenge may then be placed into a specific filed of the JWT.
The target service may then verify that the value included
in the JWT is the one that has been recently provided.
A parameter specifying the type of the control value and the value of
the control would need to be used.
This parameter would be called a target_id (tid). It would solve the
Big Brother case.
This parameter cannot be introduced in a BCP document, but this should
be done in another document.
When the resource owner and the target server are not collocated and
when privacy is a concern, the use of these parameters
should be deprecated and the use of a "tid" parameter should be
recommended.
In any case, stating that "the JWT MUST contain an "aud" (audience)
claim" is incorrect.
Denis

Post by Mike Jones
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
<https://ietf.org/meeting/98/>, 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
<https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-jwt-security-update-00.pdf>
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
JSON Web Tokens, also known as JWTs [RFC7519
<https://tools.ietf.org/html/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.
* https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00
* http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html
-- Mike
P.S. This notice was also posted at http://self-issued.info/?p=1690
<https://twitter.com/selfissued>.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth