RFC Errata
Found 4 records.
Status: Reported (2)
RFC 7519, "JSON Web Token (JWT)", May 2015
Note: This RFC has been updated by RFC 7797, RFC 8725
Source of RFC: oauth (sec)
Errata ID: 5906
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Erdem Memisyazici
Date Reported: 2019-11-13
Section 7.2 says:
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWT can be successfully validated, unless the algorithms used in the JWT are acceptable to the application, it SHOULD reject the JWT.
It should say:
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWT can be successfully validated, unless the algorithms used in the JWT are acceptable to the application, it MUST reject the JWT.
Notes:
A vulnerability exists in certain implementations in the wild where applications simply look for valid JWT tokens which includes the "none" algorithm (https://medium.com/swlh/hacking-json-web-tokens-jwts-9122efe91e4a). A fairly popular library is auth0's java-jwt and at verification (https://github.com/auth0/java-jwt/blob/master/lib/src/main/java/com/auth0/jwt/JWTVerifier.java) quite reasonably you cannot initialize the class without an algorithm. Given all capital SHOULD may be interpreted as a recommendation and as this RFC dictates the algorithm "none" MUST be implemented as a default algorithm under Section 8, one could argue JWTVerifier in the example doesn't have to verifyAlgorithm leading to the vulnerability pointed out in the first article while still complying by the specification. There is no good reason why an algorithm unacceptable to the application must not be rejected as it does more harm than good and all popular library implementations interpret it as such.
Errata ID: 7720
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Timothy Vergenz
Date Reported: 2023-12-01
Section 4.1.6 says:
4.1.6. "iat" (Issued At) Claim The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
It should say:
4.1.6. "iat" (Issued At) Claim The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL. Implementors MUST NOT reject otherwise-valid JWTs with "iat" claims that appear to be from the future; token issuers desiring this behavior may require it by including an "nbf" claim.
Notes:
There is substantial confusion and disagreement among JWT library implementors about whether to reject JWTs with `iat` claims that appear to be from the future due to clock drift. This confusion has led to over half a dozen Github issues & PRs over the years in libraries in many different ecosystems, and lots of strong disagreement among library developers and users.
Based on a sample of the top Google search results for jwt client libraries in 11 different language ecosystems, the majority (7) of the libraries sampled do not reject future `iat` claims, while the remaining 4 *do* reject future `iat` claims by default. Of those 4 who do, *all* of them have had Github issues filed (by different unique users) in which the user was having a JWT unexpectedly rejected by a token validator using the library whose clock had drifted from that of the token issuer enough to trigger `iat`-based rejection.
I propose we update the spec to explicitly prohibit rejection of future-`iat` JWTs (especially since token issuers have always been able to opt into this behavior using an `nbf` claim). Since this RFC has been published and cannot be edited, a new superseding RFC will have to be published and this one deprecated in order for the suggested change to make it out of the errata and into an actual RFC doc.
I'm not sure if this merits a full RFC republish -- but as a data point for impact consideration, it's worth noting that this confusion has almost certainly wasted at least multiple hours per person (on average) of *dozens* of developers' time over the years, and led to at least half a dozen production bugs that I've seen mentioned. One of these bugs cropped up in my own organization on 2023-11-31 and has been observed previously but was misunderstood and not resolved; the 2023-11-31 occurence involved 10+ people in discussion. One Github issue I saw described an elongated full web server outage attributed to this confusion which cropped up during a leap-second-related clock drift issue. I'm filing this errata request on calendar day 3+ of discussing this issue in my organization (if you include past times this issue has cropped up).
Thanks for your consideration! I look forward to hearing back.
Status: Rejected (2)
RFC 7519, "JSON Web Token (JWT)", May 2015
Note: This RFC has been updated by RFC 7797, RFC 8725
Source of RFC: oauth (sec)
Errata ID: 5648
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy Delcambre
Date Reported: 2019-03-08
Rejected by: Roman Danyliw
Date Rejected: 2024-01-12
Section 1 says:
JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization. The suggested pronunciation of JWT is the same as the English word "jot".
It should say:
JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization.
Notes:
The suggested pronunciation is strange and confusing. It makes it hard to onboard new people verbally and always requires an explanation of the pronunciation. The standard already has a perfectly reasonable initialism of JWT that clearly refers to JSON Web Tokens. It is jarring to suggest a pronunciation that does not map to the letters of the spec, and in my experience often leads to confusion when used.
--VERIFIER NOTES--
This guidance was produced with the consensus of the WG. Per https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/, "Errata are items that were errors at the time the document was published"
Errata ID: 6622
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Padmanarayanan SR
Date Reported: 2021-06-25
Rejected by: Benjamin Kaduk
Date Rejected: 2021-07-04
Section 11 says:
All the security considerations in the JWS specification also apply to JWT, as do the JWE security considerations when encryption is employed. In particular, Sections <a href="#section-10.12">10.12</a>
It should say:
All the security considerations in the JWS specification also apply to JWT, as do the JWE security considerations when encryption is employed. In particular, Sections <a href="/doc/html/rfc7515#section-10.12">10.12</a>
Notes:
The link appears to be broken. It is intended to point to rfc7515#section-10.12 whereas it is pointing to the non-existent section of the same document.
--VERIFIER NOTES--
The "text" publication format (the only official format for RFCs prior to 8650) does not include HTML links, so the "original text" section of this report does not match the version of the RFC that this tool is used for. Accordingly, the submission has to be rejected as invalid.