From b0c1fa608a9f7e4fc0f56224fab900dc67d9ad6b Mon Sep 17 00:00:00 2001 From: ysheffer Date: Mon, 22 Sep 2025 15:11:24 +0300 Subject: [PATCH 1/4] More substantial edits --- draft-ietf-oauth-rfc8725bis.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/draft-ietf-oauth-rfc8725bis.md b/draft-ietf-oauth-rfc8725bis.md index a82d846..948cb09 100644 --- a/draft-ietf-oauth-rfc8725bis.md +++ b/draft-ietf-oauth-rfc8725bis.md @@ -58,7 +58,6 @@ venue: normative: - RFC2119: RFC6979: RFC7515: RFC7516: @@ -66,7 +65,6 @@ normative: RFC7519: RFC8017: RFC8037: - RFC8174: RFC8259: nist-sp-800-56a-r3: DOI.10.6028/NIST.SP.800-56Ar3 informative: @@ -91,6 +89,12 @@ informative: refcontent: National Vulnerability Database target: https://nvd.nist.gov/vuln/detail/CVE-2023-51774 title: CVE-2023-51774 Detail + JWT-Cracker: + author: + - ins: B. Rius + name: Brendan Rius + title: JWT Cracker + target: https://github.com/brendan-rius/c-jwt-cracker Kelsey: DOI.10.1007/3-540-45661-9_21 Langkemper: author: @@ -131,8 +135,8 @@ informative: - ins: A. Sanso name: Antonio Sanso date: March 2017 - target: https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html - title: Critical Vulnerability Uncovered in JSON Encryption + target: https://auth0.com/blog/critical-vulnerability-in-json-web-encryption/ + title: Critical Vulnerability in JSON Web Encryption Valenta: author: - ins: L. Valenta @@ -280,7 +284,7 @@ For mitigations, see {{algorithm-verification}} and {{appropriate-algorithms}}. "HS256", to sign tokens but supply a weak symmetric key with insufficient entropy (such as a human-memorable password). Such keys are vulnerable to offline brute-force or dictionary attacks once an -attacker gets hold of such a token {{Langkemper}}. +attacker gets hold of such a token {{Langkemper}}{{JWT-Cracker}}. For mitigations, see {{key-entropy}}. @@ -611,18 +615,13 @@ If the issuer, subject, or the pair are invalid, the application If the same issuer can issue JWTs that are intended for use by more - than one relying party or application, + than one relying party or application, or may do so in the future, 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. - In such cases, the relying party or application MUST - validate the audience value, -and if the audience value is not present or not associated with the recipient, -it MUST reject the JWT. - - - +In such cases, the relying party or application MUST validate the audience value, and if no audience +value is present or none of the values are associated with the recipient, it MUST reject the JWT. ## Do Not Trust Received Claims {#do-not-trust-claims} @@ -685,6 +684,7 @@ If more than one kind of JWT can be issued by the same issuer, the validation rules for those JWTs MUST be written such that they are mutually exclusive, rejecting JWTs of the wrong kind. + To prevent substitution of JWTs from one context into another, application developers may employ a number of strategies: From 0e149a42b98bde22b63dd243c4e338307cde8124 Mon Sep 17 00:00:00 2001 From: ysheffer Date: Tue, 23 Sep 2025 15:51:11 +0300 Subject: [PATCH 2/4] More comments --- draft-ietf-oauth-rfc8725bis.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/draft-ietf-oauth-rfc8725bis.md b/draft-ietf-oauth-rfc8725bis.md index 948cb09..4dac297 100644 --- a/draft-ietf-oauth-rfc8725bis.md +++ b/draft-ietf-oauth-rfc8725bis.md @@ -652,13 +652,13 @@ For instance, the {{RFC8417}} specification uses the "application/secevent+jwt" media type to perform explicit typing of Security Event Tokens (SETs). - Per the definition of "typ" in Section 4.1.9 of {{RFC7515}}, -it is RECOMMENDED that the "application/" prefix be omitted from the "typ" value. +Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/" prefix +be omitted from the "typ" Header Parameter value, compared to the associated media type. Therefore, for example, the "typ" value used to explicitly 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 name of the format -"application/example+jwt" be used, where "example" is replaced by the - identifier for the specific kind of JWT. + +When explicit typing is employed for a JWT, it is RECOMMENDED that a media type name of the +format "application/example+jwt" be used, where "example" is replaced by the identifier for the +specific kind of JWT. Therefore, for example, the media type name for a SET SHOULD be "application/secevent+jwt". When applying explicit typing to a Nested JWT, the "typ" Header Parameter containing the explicit type value MUST be present in the inner JWT of the Nested JWT (the JWT @@ -728,8 +728,9 @@ the number of hash iterations that can be performed when validating encrypted content using PBES2 encryption algorithms, so as to prevent attackers from imposing an unreasonable computational burden on recipients. -{{OWASP-Password-Storage}} states that an iteration count of 600,000 is required when using HMAC-SHA-256 to achieve FIPS-140 compliance. -Thus, rejecting inputs with a `p2c` (PBES2 Count) value over 1,200,000 (double that) is RECOMMENDED. +{{OWASP-Password-Storage}} states a specific iteration count (600,000 at time of publishing) +is required when using HMAC-SHA-256 to achieve FIPS-140 compliance. Rejecting inputs with a p2c +(PBES2 Count) value larger than double the recommended OWASP value is RECOMMENDED. ## Check JWT Format Type {#token-format} From 9a364d2471095ff5654689385f3b78aa66dafbcc Mon Sep 17 00:00:00 2001 From: ysheffer Date: Tue, 23 Sep 2025 15:56:38 +0300 Subject: [PATCH 3/4] More comments --- draft-ietf-oauth-rfc8725bis.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-oauth-rfc8725bis.md b/draft-ietf-oauth-rfc8725bis.md index 4dac297..2160b0c 100644 --- a/draft-ietf-oauth-rfc8725bis.md +++ b/draft-ietf-oauth-rfc8725bis.md @@ -734,7 +734,10 @@ is required when using HMAC-SHA-256 to achieve FIPS-140 compliance. Rejecting in ## Check JWT Format Type {#token-format} -Implementations MUST confirm the JWT is in a legal format while parsing it. Legal JWTs contain only the ASCII characters for letters, numbers, dash, underscore, and period. Content with any other characters - especially braces and quotation marks - is not a JWT and MUST be rejected. +Implementations MUST confirm the JWT is in a legal format while parsing it. Legal JWTs, +being dot-concatenated base64url strings, contain only the ASCII characters for letters, numbers, dash, +underscore, and period. Content with any other characters - especially braces and quotation +marks - is not a JWT and MUST be rejected. ## Limit JWE Decompression Size {#limit-decompression} From 88799023c6de7543dd0a01e094fa5bbebe12e5ed Mon Sep 17 00:00:00 2001 From: Yaron Sheffer Date: Mon, 29 Sep 2025 17:20:54 +0300 Subject: [PATCH 4/4] Apply suggestion from @selfissued Co-authored-by: Michael B. Jones --- draft-ietf-oauth-rfc8725bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-rfc8725bis.md b/draft-ietf-oauth-rfc8725bis.md index 2160b0c..175774e 100644 --- a/draft-ietf-oauth-rfc8725bis.md +++ b/draft-ietf-oauth-rfc8725bis.md @@ -729,7 +729,7 @@ when validating encrypted content using PBES2 encryption algorithms, so as to prevent attackers from imposing an unreasonable computational burden on recipients. {{OWASP-Password-Storage}} states a specific iteration count (600,000 at time of publishing) -is required when using HMAC-SHA-256 to achieve FIPS-140 compliance. Rejecting inputs with a p2c +is required when using HMAC-SHA-256 to achieve FIPS-140 compliance. Rejecting inputs with a `p2c` (PBES2 Count) value larger than double the recommended OWASP value is RECOMMENDED. ## Check JWT Format Type {#token-format}