draft-ietf-oauth-jwt-bcp-05.txt   draft-ietf-oauth-jwt-bcp-06.txt 
OAuth Working Group Y. Sheffer OAuth Working Group Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Intended status: Best Current Practice D. Hardt Intended status: Best Current Practice D. Hardt
Expires: October 18, 2019 Expires: December 9, 2019
M. Jones M. Jones
Microsoft Microsoft
April 16, 2019 June 07, 2019
JSON Web Token Best Current Practices JSON Web Token Best Current Practices
draft-ietf-oauth-jwt-bcp-05 draft-ietf-oauth-jwt-bcp-06
Abstract Abstract
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security
tokens that contain a set of claims that can be signed and/or tokens that contain a set of claims that can be signed and/or
encrypted. JWTs are being widely used and deployed as a simple encrypted. JWTs are being widely used and deployed as a simple
security token format in numerous protocols and applications, both in security token format in numerous protocols and applications, both in
the area of digital identity, and in other application areas. The the area of digital identity, and in other application areas. The
goal of this Best Current Practices document is to provide actionable goal of this Best Current Practices document is to provide actionable
guidance leading to secure implementation and deployment of JWTs. guidance leading to secure implementation and deployment of JWTs.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 18, 2019. This Internet-Draft will expire on December 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Target Audience . . . . . . . . . . . . . . . . . . . . . 4 1.1. Target Audience . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 4 1.2. Conventions used in this document . . . . . . . . . . . . 4
2. Threats and Vulnerabilities . . . . . . . . . . . . . . . . . 4 2. Threats and Vulnerabilities . . . . . . . . . . . . . . . . . 4
2.1. Weak Signatures and Insufficient Signature Validation . . 4 2.1. Weak Signatures and Insufficient Signature Validation . . 4
2.2. Weak symmetric keys . . . . . . . . . . . . . . . . . . . 5 2.2. Weak symmetric keys . . . . . . . . . . . . . . . . . . . 5
2.3. Multiplicity of JSON encodings . . . . . . . . . . . . . 5 2.3. Incorrect Composition of Encryption and Signature . . . . 5
2.4. Incorrect Composition of Encryption and Signature . . . . 5 2.4. Plaintext Leakage through Analysis of Ciphertext Length . 5
2.5. Insecure Use of Elliptic Curve Encryption . . . . . . . . 5 2.5. Insecure Use of Elliptic Curve Encryption . . . . . . . . 5
2.6. Substitution Attacks . . . . . . . . . . . . . . . . . . 5 2.6. Multiplicity of JSON encodings . . . . . . . . . . . . . 5
2.7. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 6 2.7. Substitution Attacks . . . . . . . . . . . . . . . . . . 6
2.8. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 6
2.9. Indirect Attacks on the Server . . . . . . . . . . . . . 6
3. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 6 3. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Perform Algorithm Verification . . . . . . . . . . . . . 6 3.1. Perform Algorithm Verification . . . . . . . . . . . . . 7
3.2. Use Appropriate Algorithms . . . . . . . . . . . . . . . 6 3.2. Use Appropriate Algorithms . . . . . . . . . . . . . . . 7
3.3. Validate All Cryptographic Operations . . . . . . . . . . 7 3.3. Validate All Cryptographic Operations . . . . . . . . . . 8
3.4. Validate Cryptographic Inputs . . . . . . . . . . . . . . 7 3.4. Validate Cryptographic Inputs . . . . . . . . . . . . . . 8
3.5. Ensure Cryptographic Keys have Sufficient Entropy . . . . 8 3.5. Ensure Cryptographic Keys have Sufficient Entropy . . . . 8
3.6. Avoid Length-Dependent Encryption Inputs . . . . . . . . 8 3.6. Avoid Length-Dependent Encryption Inputs . . . . . . . . 8
3.7. Use UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Use UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Validate Issuer and Subject . . . . . . . . . . . . . . . 8 3.8. Validate Issuer and Subject . . . . . . . . . . . . . . . 9
3.9. Use and Validate Audience . . . . . . . . . . . . . . . . 9 3.9. Use and Validate Audience . . . . . . . . . . . . . . . . 9
3.10. Do Not Trust Received Claims . . . . . . . . . . . . . . 9 3.10. Do Not Trust Received Claims . . . . . . . . . . . . . . 9
3.11. Use Explicit Typing . . . . . . . . . . . . . . . . . . . 9 3.11. Use Explicit Typing . . . . . . . . . . . . . . . . . . . 10
3.12. Use Mutually Exclusive Validation Rules for Different 3.12. Use Mutually Exclusive Validation Rules for Different
Kinds of JWTs . . . . . . . . . . . . . . . . . . . . . . 10 Kinds of JWTs . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Document History . . . . . . . . . . . . . . . . . . 14 Appendix A. Document History . . . . . . . . . . . . . . . . . . 15
A.1. draft-ietf-oauth-jwt-bcp-05 . . . . . . . . . . . . . . . 14 A.1. draft-ietf-oauth-jwt-bcp-06 . . . . . . . . . . . . . . . 15
A.2. draft-ietf-oauth-jwt-bcp-04 . . . . . . . . . . . . . . . 14 A.2. draft-ietf-oauth-jwt-bcp-05 . . . . . . . . . . . . . . . 15
A.3. draft-ietf-oauth-jwt-bcp-03 . . . . . . . . . . . . . . . 14 A.3. draft-ietf-oauth-jwt-bcp-04 . . . . . . . . . . . . . . . 15
A.4. draft-ietf-oauth-jwt-bcp-02 . . . . . . . . . . . . . . . 14 A.4. draft-ietf-oauth-jwt-bcp-03 . . . . . . . . . . . . . . . 15
A.5. draft-ietf-oauth-jwt-bcp-01 . . . . . . . . . . . . . . . 14 A.5. draft-ietf-oauth-jwt-bcp-02 . . . . . . . . . . . . . . . 15
A.6. draft-ietf-oauth-jwt-bcp-00 . . . . . . . . . . . . . . . 14 A.6. draft-ietf-oauth-jwt-bcp-01 . . . . . . . . . . . . . . . 15
A.7. draft-sheffer-oauth-jwt-bcp-01 . . . . . . . . . . . . . 14 A.7. draft-ietf-oauth-jwt-bcp-00 . . . . . . . . . . . . . . . 15
A.8. draft-sheffer-oauth-jwt-bcp-00 . . . . . . . . . . . . . 14 A.8. draft-sheffer-oauth-jwt-bcp-01 . . . . . . . . . . . . . 15
A.9. draft-sheffer-oauth-jwt-bcp-00 . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON- 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 based security tokens that contain a set of claims that can be signed
and/or encrypted. The JWT specification has seen rapid adoption and/or encrypted. The JWT specification has seen rapid adoption
because it encapsulates security-relevant information in one, easy to because it encapsulates security-relevant information in one, easy to
protect location, and because it is easy to implement using widely- protect location, and because it is easy to implement using widely-
available tools. One application area in which JWTs are commonly available tools. One application area in which JWTs are commonly
used is representing digital identity information, such as OpenID used is representing digital identity information, such as OpenID
skipping to change at page 4, line 47 skipping to change at page 4, line 47
cryptographic agility. This, in conjunction with design flaws in cryptographic agility. This, in conjunction with design flaws in
some libraries and applications, have led to several attacks: some libraries and applications, have led to several attacks:
- The algorithm can be changed to "none" by an attacker, and some - The algorithm can be changed to "none" by an attacker, and some
libraries would trust this value and "validate" the JWT without libraries would trust this value and "validate" the JWT without
checking any signature. checking any signature.
- An "RS256" (RSA, 2048 bit) parameter value can be changed into - An "RS256" (RSA, 2048 bit) parameter value can be changed into
"HS256" (HMAC, SHA-256), and some libraries would try to validate "HS256" (HMAC, SHA-256), and some libraries would try to validate
the signature using HMAC-SHA256 and using the RSA public key as the signature using HMAC-SHA256 and using the RSA public key as
the HMAC shared secret. the HMAC shared secret (see [McLean] and CVE-2015-9235).
For mitigations, see Section 3.1 and Section 3.2. For mitigations, see Section 3.1 and Section 3.2.
2.2. Weak symmetric keys 2.2. Weak symmetric keys
In addition, some applications sign tokens using a weak symmetric key In addition, some applications sign tokens using a weak symmetric key
and a keyed MAC algorithm such as "HS256". In most cases, these keys and a keyed MAC algorithm such as "HS256". In most cases, these keys
are human memorable passwords that are vulnerable to dictionary are human memorable passwords that are vulnerable to dictionary
attacks [Langkemper]. attacks [Langkemper].
For mitigations, see Section 3.5. For mitigations, see Section 3.5.
2.3. Multiplicity of JSON encodings 2.3. Incorrect Composition of Encryption and Signature
Previous versions of the JSON format [RFC8259] allowed several
different character encodings: UTF-8, UTF-16 and UTF-32. This is not
the case anymore, with the latest standard only allowing UTF-8.
However older implementations may result in the JWT being
misinterpreted by its recipient, and this could be used by a
malicious sender to bypass the recipient's validation checks.
For mitigations, see Section 3.7.
2.4. Incorrect Composition of Encryption and Signature
Some libraries that decrypt a JWE-encrypted JWT to obtain a JWS- Some libraries that decrypt a JWE-encrypted JWT to obtain a JWS-
signed object do not always validate the internal signature. signed object do not always validate the internal signature.
For mitigations, see Section 3.3. For mitigations, see Section 3.3.
2.4. Plaintext Leakage through Analysis of Ciphertext Length
Many encryption algorithms leak information about the length of the
plaintext, with a varying amount of leakage depending on the
algorithm and mode of operation. This problem is exacerbated when
the plaintext is initially compressed, because the length of the
compressed plaintext and thus, the ciphertext, depends not only on
the length of the original plaintext but also on its content. See
[Kelsey] for general background on compression and encryption, and
[Alawatugoda] for a specific example of attacks on HTTP cookies.
For mitigations, see Section 3.6.
2.5. Insecure Use of Elliptic Curve Encryption 2.5. Insecure Use of Elliptic Curve Encryption
Per [Sanso], several JOSE libraries fail to validate their inputs Per [Sanso], several JOSE libraries fail to validate their inputs
correctly when performing elliptic curve key agreement (the "ECDH-ES" correctly when performing elliptic curve key agreement (the "ECDH-ES"
algorithm). An attacker that is able to send JWEs of its choosing algorithm). An attacker that is able to send JWEs of its choosing
that use invalid curve points and observe the cleartext outputs that use invalid curve points and observe the cleartext outputs
resulting from decryption with the invalid curve points can use this resulting from decryption with the invalid curve points can use this
vulnerability to recover the recipient's private key. vulnerability to recover the recipient's private key.
For mitigations, see Section 3.4. For mitigations, see Section 3.4.
2.6. Substitution Attacks 2.6. Multiplicity of JSON encodings
Previous versions of the JSON format such as the obsoleted [RFC7159]
allowed several different character encodings: UTF-8, UTF-16 and UTF-
32. This is not the case anymore, with the latest standard [RFC8259]
only allowing UTF-8. However older implementations may result in the
JWT being misinterpreted by its recipient, and this could be used by
a malicious sender to bypass the recipient's validation checks.
For mitigations, see Section 3.7.
2.7. Substitution Attacks
There are attacks in which one recipient will have a JWT intended for There are attacks in which one recipient will have a JWT intended for
it and attempt to use it at a different recipient that it was not it and attempt to use it at a different recipient that it was not
intended for. If not caught, these attacks can result in the intended for. If not caught, these attacks can result in the
attacker gaining access to resources that it is not entitled to attacker gaining access to resources that it is not entitled to
access. For instance, if an OAuth 2.0 [RFC6749] access token is access. For instance, if an OAuth 2.0 [RFC6749] access token is
presented to an OAuth 2.0 protected resource that it is intended for, presented to an OAuth 2.0 protected resource that it is intended for,
that protected resource might then attempt to gain access to a that protected resource might then attempt to gain access to a
different protected resource by presenting that same access token to different protected resource by presenting that same access token to
the different protected resource, which the access token is not the different protected resource, which the access token is not
intended for. intended for.
For mitigations, see Section 3.8 and Section 3.9. For mitigations, see Section 3.8 and Section 3.9.
2.7. Cross-JWT Confusion 2.8. Cross-JWT Confusion
As JWTs are being used by more different protocols in diverse As JWTs are being used by more different protocols in diverse
application areas, it becomes increasingly important to prevent cases application areas, it becomes increasingly important to prevent cases
of JWT tokens that have been issued for one purpose being subverted of JWT tokens that have been issued for one purpose being subverted
and used for another. Note that this is a specific type of and used for another. Note that this is a specific type of
substitution attack. If the JWT could be used in an application substitution attack. If the JWT could be used in an application
context in which it could be confused with other kinds of JWTs, then context in which it could be confused with other kinds of JWTs, then
mitigations MUST be employed to prevent these substitution attacks. mitigations MUST be employed to prevent these substitution attacks.
For mitigations, see Section 3.8, Section 3.9, Section 3.11, and For mitigations, see Section 3.8, Section 3.9, Section 3.11, and
Section 3.12. Section 3.12.
2.9. Indirect Attacks on the Server
Various JWT claims are used by the recipient to perform lookup
operations, e.g. database and LDAP searches. Others include URLs
that are similarly looked up by the server. Any of these claims can
be used by an attacker as vectors for injection attacks or server-
side request forgery (SSRF) attacks.
For mitigations, see Section 3.10.
3. Best Practices 3. Best Practices
The best practices listed below should be applied by practitioners to The best practices listed below should be applied by practitioners to
mitigate the threats listed in the preceding section. mitigate the threats listed in the preceding section.
3.1. Perform Algorithm Verification 3.1. Perform Algorithm Verification
Libraries MUST enable the caller to specify a supported set of Libraries MUST enable the caller to specify a supported set of
algorithms and MUST NOT use any other algorithms when performing algorithms and MUST NOT use any other algorithms when performing
cryptographic operations. The library MUST ensure that the "alg" or cryptographic operations. The library MUST ensure that the "alg" or
skipping to change at page 7, line 19 skipping to change at page 7, line 44
perfectly acceptable. The "none" algorithm should only be used when perfectly acceptable. The "none" algorithm should only be used when
the JWT is cryptographically protected by other means. JWTs using the JWT is cryptographically protected by other means. JWTs using
"none" are often used in application contexts in which the content is "none" are often used in application contexts in which the content is
optionally signed; then the URL-safe claims representation and optionally signed; then the URL-safe claims representation and
processing can be the same in both the signed and unsigned cases. processing can be the same in both the signed and unsigned cases.
JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly
requested to do by the caller. requested to do by the caller.
Applications SHOULD follow these algorithm-specific recommendations: Applications SHOULD follow these algorithm-specific recommendations:
- Avoid all RSA-PKCS1 v1.5 encryption algorithms, preferring RSA- - Avoid all RSA-PKCS1 v1.5 [RFC2313] encryption algorithms,
OAEP. preferring RSA-OAEP ([RFC8017], Sec. 7.1).
- ECDSA signatures require a unique random value for every message - ECDSA signatures [ANSI-X962-2005] require a unique random value
that is signed. If even just a few bits of the random value are for every message that is signed. If even just a few bits of the
predictable across multiple messages then the security of the random value are predictable across multiple messages then the
signature scheme may be compromised. In the worst case, the security of the signature scheme may be compromised. In the worst
private key may be recoverable by an attacker. To counter these case, the private key may be recoverable by an attacker. To
attacks, JWT libraries SHOULD implement ECDSA using the counter these attacks, JWT libraries SHOULD implement ECDSA using
deterministic approach defined in [RFC6979]. This approach is the deterministic approach defined in [RFC6979]. This approach is
completely compatible with existing ECDSA verifiers and so can be completely compatible with existing ECDSA verifiers and so can be
implemented without new algorithm identifiers being required. implemented without new algorithm identifiers being required.
3.3. Validate All Cryptographic Operations 3.3. Validate All Cryptographic Operations
All cryptographic operations used in the JWT MUST be validated and All cryptographic operations used in the JWT MUST be validated and
the entire JWT MUST be rejected if any of them fail to validate. the entire JWT MUST be rejected if any of them fail to validate.
This is true not only of JWTs with a single set of Header Parameters This is true not only of JWTs with a single set of Header Parameters
but also for Nested JWTs, in which both outer and inner operations but also for Nested JWTs, in which both outer and inner operations
MUST be validated using the keys and algorithms supplied by the MUST be validated using the keys and algorithms supplied by the
skipping to change at page 8, line 24 skipping to change at page 8, line 49
followed. In particular, human-memorizable passwords MUST NOT be followed. In particular, human-memorizable passwords MUST NOT be
directly used as the key to a keyed-MAC algorithm such as "HS256". directly used as the key to a keyed-MAC algorithm such as "HS256".
In particular, passwords should only be used to perform key In particular, passwords should only be used to perform key
encryption, rather than content encryption, as described in encryption, rather than content encryption, as described in
Section 4.8 of [RFC7518]. Note that even when used for key Section 4.8 of [RFC7518]. Note that even when used for key
encryption, password-based encryption is still subject to brute-force encryption, password-based encryption is still subject to brute-force
attacks. attacks.
3.6. Avoid Length-Dependent Encryption Inputs 3.6. Avoid Length-Dependent Encryption Inputs
Many encryption algorithms leak information about the length of the It is RECOMMENDED to avoid any compression of data before encryption
plaintext, with a varying amount of leakage depending on the since such compression often reveals information about the plaintext.
algorithm and mode of operation. Sensitive information, such as
passwords, SHOULD be padded before being encrypted. It is
RECOMMENDED to avoid any compression of data before encryption since
such compression often reveals information about the plaintext. See
[Kelsey] for general background on compression and encryption, and
[Alawatugoda] for a specific example of attacks on HTTP cookies.
3.7. Use UTF-8 3.7. Use UTF-8
[RFC7515], [RFC7516], and [RFC7519] all specify that UTF-8 be used [RFC7515], [RFC7516], and [RFC7519] all specify that UTF-8 be used
for encoding and decoding JSON used in Header Parameters and JWT for encoding and decoding JSON used in Header Parameters and JWT
Claims Sets. This is also in line with the latest JSON specification Claims Sets. This is also in line with the latest JSON specification
[RFC8259]. Implementations and applications MUST do this, and not [RFC8259]. Implementations and applications MUST do this, and not
use or admit the use of other Unicode encodings for these purposes. use or admit the use of other Unicode encodings for these purposes.
3.8. Validate Issuer and Subject 3.8. Validate Issuer and Subject
skipping to change at page 9, line 5 skipping to change at page 9, line 25
When a JWT contains an "iss" (issuer) claim, the application MUST When a JWT contains an "iss" (issuer) claim, the application MUST
validate that the cryptographic keys used for the cryptographic validate that the cryptographic keys used for the cryptographic
operations in the JWT belong to the issuer. If they do not, the operations in the JWT belong to the issuer. If they do not, the
application MUST reject the JWT. application MUST reject the JWT.
The means of determining the keys owned by an issuer is application- The means of determining the keys owned by an issuer is application-
specific. As one example, OpenID Connect [OpenID.Core] issuer values specific. As one example, OpenID Connect [OpenID.Core] issuer values
are "https" URLs that reference a JSON metadata document that are "https" URLs that reference a JSON metadata document that
contains a "jwks_uri" value that is an "https" URL from which the contains a "jwks_uri" value that is an "https" URL from which the
issuer's keys are retrieved as a JWK Set [RFC7517]. This same issuer's keys are retrieved as a JWK Set [RFC7517]. This same
mechanism is used by [I-D.ietf-oauth-discovery]. Other applications mechanism is used by [RFC8414]. Other applications may use different
may use different means of binding keys to issuers. means of binding keys to issuers.
Similarly, when the JWT contains a "sub" (subject) claim, the Similarly, when the JWT contains a "sub" (subject) claim, the
application MUST validate that the subject value corresponds to a application MUST validate that the subject value corresponds to a
valid subject and/or issuer/subject pair at the application. This valid subject and/or issuer/subject pair at the application. This
may include confirming that the issuer is trusted by the application. may include confirming that the issuer is trusted by the application.
If the issuer, subject, or the pair are invalid, the application MUST If the issuer, subject, or the pair are invalid, the application MUST
reject the JWT. reject the JWT.
3.9. Use and Validate Audience 3.9. Use and Validate Audience
skipping to change at page 9, line 32 skipping to change at page 10, line 5
MUST validate the audience value and if the audience value is not MUST validate the audience value and if the audience value is not
present or not associated with the recipient, it MUST reject the JWT. present or not associated with the recipient, it MUST reject the JWT.
3.10. Do Not Trust Received Claims 3.10. Do Not Trust Received Claims
The "kid" (key ID) header is used by the relying application to The "kid" (key ID) header is used by the relying application to
perform key lookup. Applications should ensure that this does not perform key lookup. Applications should ensure that this does not
create SQL or LDAP injection vulnerabilities, by validating and/or create SQL or LDAP injection vulnerabilities, by validating and/or
sanitizing the received value. sanitizing the received value.
Similarly, blindly following a "jku" (JWK set URL) header, which may Similarly, blindly following a "jku" (JWK set URL) or "x5u" (X.509
contain an arbitrary URL, could result in server-side request forgery URL) header, which may contain an arbitrary URL, could result in
(SSRF) attacks. Applications should protect against such attacks, server-side request forgery (SSRF) attacks. Applications should
e.g., by matching the URL to a whitelist of allowed locations, and protect against such attacks, e.g., by matching the URL to a
ensuring no cookies are sent in the GET request. whitelist of allowed locations, and ensuring no cookies are sent in
the GET request.
3.11. Use Explicit Typing 3.11. Use Explicit Typing
Confusion of one kind of JWT for another can be prevented by having Confusion of one kind of JWT for another can be prevented by having
all the kinds of JWTs that could otherwise potentially be confused all the kinds of JWTs that could otherwise potentially be confused
include an explicit JWT type value and include checking the type include an explicit JWT type value and include checking the type
value in their validation rules. Explicit JWT typing is accomplished value in their validation rules. Explicit JWT typing is accomplished
by using the "typ" header parameter. For instance, the by using the "typ" header parameter. For instance, the [RFC8417]
[I-D.ietf-secevent-token] specification uses the "application/ specification uses the "application/secevent+jwt" media type to
secevent+jwt" media type to perform explicit typing of Security Event perform explicit typing of Security Event Tokens (SETs).
Tokens (SETs).
Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is
RECOMMENDED that the "application/" prefix be omitted from the "typ" RECOMMENDED that the "application/" prefix be omitted from the "typ"
value. Therefore, for example, the "typ" value used to explicitly value. Therefore, for example, the "typ" value used to explicitly
include a type for a SET SHOULD be "secevent+jwt". When explicit include a type for a SET SHOULD be "secevent+jwt". When explicit
typing is employed for a JWT, it is RECOMMENDED that a media type typing is employed for a JWT, it is RECOMMENDED that a media type
name of the format "application/example+jwt" be used, where "example" name of the format "application/example+jwt" be used, where "example"
is replaced by the identifier for the specific kind of JWT. is replaced by the identifier for the specific kind of JWT.
When applying explicit typing to a Nested JWT, the "typ" header When applying explicit typing to a Nested JWT, the "typ" header
skipping to change at page 11, line 28 skipping to change at page 11, line 49
implementing and deploying JSON Web Tokens. implementing and deploying JSON Web Tokens.
5. IANA Considerations 5. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
6. Acknowledgements 6. Acknowledgements
Thanks to Antonio Sanso for bringing the "ECDH-ES" invalid point Thanks to Antonio Sanso for bringing the "ECDH-ES" invalid point
attack to the attention of JWE and JWT implementers. Tim McLean attack to the attention of JWE and JWT implementers. Tim McLean
published the RSA/HMAC confusion attack. Thanks to Nat Sakimura for [McLean] published the RSA/HMAC confusion attack. Thanks to Nat
advocating the use of explicit typing. Thanks to Neil Madden for his Sakimura for advocating the use of explicit typing. Thanks to Neil
numerous comments, and to Carsten Bormann, Brian Campbell, Brian Madden for his numerous comments, and to Carsten Bormann, Brian
Carpenter and Eric Rescorla for their reviews. Campbell, Brian Carpenter, Roman Danyliw and Eric Rescorla for their
reviews.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 12, line 17 skipping to change at page 12, line 37
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/info/rfc8037>. <https://www.rfc-editor.org/info/rfc8037>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
skipping to change at page 12, line 39 skipping to change at page 13, line 18
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
7.2. Informative References 7.2. Informative References
[Alawatugoda] [Alawatugoda]
Alawatugoda, J., Stebila, D., and C. Boyd, "Protecting Alawatugoda, J., Stebila, D., and C. Boyd, "Protecting
Encrypted Cookies from Compression Side-Channel Attacks", Encrypted Cookies from Compression Side-Channel Attacks",
Financial Cryptography and Data Security pp. 86-106, Financial Cryptography and Data Security pp. 86-106,
DOI 10.1007/978-3-662-47854-7_6, 2015. DOI 10.1007/978-3-662-47854-7_6, 2015.
[I-D.ietf-oauth-discovery] [ANSI-X962-2005]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 "American National Standard X9.62: The Elliptic Curve
Authorization Server Metadata", draft-ietf-oauth- Digital Signature Algorithm (ECDSA)", November 2005.
discovery-10 (work in progress), March 2018.
[I-D.ietf-secevent-token]
Hunt, P., Jones, M., Denniss, W., and M. Ansari, "Security
Event Token (SET)", draft-ietf-secevent-token-13 (work in
progress), May 2018.
[Kelsey] Kelsey, J., "Compression and Information Leakage of [Kelsey] Kelsey, J., "Compression and Information Leakage of
Plaintext", Fast Software Encryption pp. 263-276, Plaintext", Fast Software Encryption pp. 263-276,
DOI 10.1007/3-540-45661-9_21, 2002. DOI 10.1007/3-540-45661-9_21, 2002.
[Langkemper] [Langkemper]
Langkemper, S., "Attacking JWT Authentication", September Langkemper, S., "Attacking JWT Authentication", September
2016, <https://www.sjoerdlangkemper.nl/2016/09/28/ 2016, <https://www.sjoerdlangkemper.nl/2016/09/28/
attacking-jwt-authentication/>. attacking-jwt-authentication/>.
[McLean] McLean, T., "Critical vulnerabilities in JSON Web Token
libraries", March 2015, <https://auth0.com/blog/
critical-vulnerabilities-in-json-web-token-libraries//>.
[nist-sp-800-56a-r3] [nist-sp-800-56a-r3]
Barker, E., Chen, L., Keller, S., Roginsky, A., Vassilev, Barker, E., Chen, L., Keller, S., Roginsky, A., Vassilev,
A., and R. Davis, "Recommendation for Pair-Wise Key A., and R. Davis, "Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Establishment Schemes Using Discrete Logarithm
Cryptography, Draft NIST Special Publication 800-56A Cryptography, Draft NIST Special Publication 800-56A
Revision 3", April 2018, Revision 3", April 2018,
<https://doi.org/10.6028/NIST.SP.800-56Ar3>. <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C. Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C.
Mortimore, "OpenID Connect Core 1.0", November 2014, Mortimore, "OpenID Connect Core 1.0", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
RFC 2313, DOI 10.17487/RFC2313, March 1998,
<https://www.rfc-editor.org/info/rfc2313>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
"Security Event Token (SET)", RFC 8417,
DOI 10.17487/RFC8417, July 2018,
<https://www.rfc-editor.org/info/rfc8417>.
[Sanso] Sanso, A., "Critical Vulnerability Uncovered in JSON [Sanso] Sanso, A., "Critical Vulnerability Uncovered in JSON
Encryption", March 2017, Encryption", March 2017,
<https://blogs.adobe.com/security/2017/03/ <https://blogs.adobe.com/security/2017/03/
critical-vulnerability-uncovered-in-json-encryption.html>. critical-vulnerability-uncovered-in-json-encryption.html>.
[Valenta] Valenta, L., Sullivan, N., Sanso, A., and N. Heninger, "In [Valenta] Valenta, L., Sullivan, N., Sanso, A., and N. Heninger, "In
search of CurveSwap: Measuring elliptic curve search of CurveSwap: Measuring elliptic curve
implementations in the wild", March 2018, implementations in the wild", March 2018,
<https://ia.cr/2018/298>. <https://ia.cr/2018/298>.
Appendix A. Document History Appendix A. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
A.1. draft-ietf-oauth-jwt-bcp-05 A.1. draft-ietf-oauth-jwt-bcp-06
- Second AD review.
- Removed unworkable recommendation to pad encrypted passwords.
A.2. draft-ietf-oauth-jwt-bcp-05
- Genart review comments. - Genart review comments.
A.2. draft-ietf-oauth-jwt-bcp-04 A.3. draft-ietf-oauth-jwt-bcp-04
- AD review comments. - AD review comments.
A.3. draft-ietf-oauth-jwt-bcp-03 A.4. draft-ietf-oauth-jwt-bcp-03
- Acknowledgements. - Acknowledgements.
A.4. draft-ietf-oauth-jwt-bcp-02 A.5. draft-ietf-oauth-jwt-bcp-02
- Implemented WGLC feedback. - Implemented WGLC feedback.
A.5. draft-ietf-oauth-jwt-bcp-01 A.6. draft-ietf-oauth-jwt-bcp-01
- Feedback from Brian Campbell. - Feedback from Brian Campbell.
A.6. draft-ietf-oauth-jwt-bcp-00 A.7. draft-ietf-oauth-jwt-bcp-00
- Initial WG draft. No change from the latest individual version. - Initial WG draft. No change from the latest individual version.
A.7. draft-sheffer-oauth-jwt-bcp-01 A.8. draft-sheffer-oauth-jwt-bcp-01
- Added explicit typing. - Added explicit typing.
A.8. draft-sheffer-oauth-jwt-bcp-00 A.9. draft-sheffer-oauth-jwt-bcp-00
- Initial version. - Initial version.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
EMail: yaronf.ietf@gmail.com EMail: yaronf.ietf@gmail.com
Dick Hardt Dick Hardt
EMail: dick.hardt@gmail.com EMail: dick.hardt@gmail.com
Michael B. Jones Michael B. Jones
Microsoft Microsoft
EMail: mbj@microsoft.com EMail: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
 End of changes. 39 change blocks. 
94 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/