Re: [OAUTH-WG] [Technical Errata Reported] RFC7519 (7720)

[Brian Campbell <[e-mail]>]

I agree that the change in text is too much for an errata. But I am
sympathetic to the problem that the reporter has described. Perhaps it'd be
appropriate as an errata that, in the interest of interoperability,
mentions/reminds that 'iat' doesn't have defined semantics about rejection
and suggests (non-normatively) not to implement/enforce any (in the absence
of an application specific profile anyway)?

On Sun, Dec 3, 2023 at 4:43 AM Justin Richer <[e-mail]> wrote:

> This errata should be rejected, as stated in the write up, the change in
> text is too much for an errata. If the WG wants to revise JWT at this level
> it should be a full bis document.
>
> It's worth noting that the two other time based claims, nbf and exp, allow
> for clock skew in processing, but both of these claims have defined
> semantics about rejection whereas iat does not. One could argue that the
> libraries mentioned in the issue are doing things the spec doesn't say to
> do, but this kind of processing is extremely common.
>
> - Justin
>
> ------------------------------
> *From:* OAuth <[e-mail]> on behalf of RFC Errata System <
> [e-mail]>
> *Sent:* Friday, December 1, 2023 5:06 PM
> *To:* [e-mail] <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>
> *Subject:* [OAUTH-WG] [Technical Errata Reported] RFC7519 (7720)
>
> The following errata report has been submitted for RFC7519,
> "JSON Web Token (JWT)".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7720
>
> --------------------------------------
> Type: Technical
> Reported by: Timothy Vergenz <[e-mail]>
>
> Section: 4.1.6
>
> Original Text
> -------------
> 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.
>
> Corrected Text
> --------------
> 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.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7519 (draft-ietf-oauth-json-web-token-32)
> --------------------------------------
> Title               : JSON Web Token (JWT)
> Publication Date    : May 2015
> Author(s)           : M. Jones, J. Bradley, N. Sakimura
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._