< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/