Subject: [OAUTH-WG] Regarding iat and nonce in DPoP Proofs

From: Jacob Ideskog <[email-masked]>
Date: Tue, 29 Mar 2022 16:22:17 +0200

Hi all,

We have encountered a situation in the wild which I would like to share and
discuss with you.

We have strict validation of the iat claim as per section 4.3 in the
specification where we allow a reasonable skew.

The problem we see is that some users (more than a few) have changed the
clock on their mobile device. This is commonly done for users playing games
where changing the clock gives them more credit in the game. This means
that the drift is more than reasonable as per the specification. It can be
hours to days.

The solution is to use the newer "nonce" parameter (which wasn't in the
early drafts) to be able to manage the TTL server side, since the server
controls the nonce and can therefore control the TTL of any proof received.

However, the wording in section 4.3 states that:

the iat claim value is within an acceptable timeframe and,
        within a reasonable consideration of accuracy and resource
        utilization, a proof JWT with the same jti value has not
        previously been received at the same resource during that time
        period (see Section 11.1
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-07#section-11.1>),

And in section 11.1 this limits it to seconds or minutes.

So, even though using nonces could solve clock sync issues, it's not
possible due to the strictness of the iat claim verification.

Could we relax the wording of the iat claim verification to let the nonce
be the main solution in some cases:

Suggestion:
the iat claim value is within an acceptable timeframe and,
        within a reasonable consideration of accuracy and resource
        utilization, a proof JWT with the same jti value has not
        previously been received at the same resource during that time
        period (see Section 11.1), *unless the clock syncronization can be
made to depend on the issuance of the nonce values.*

Regards
Jacob

-- 
Jacob Ideskog
CTO
Curity AB
-------------------------------------------------------------------
Sankt Göransgatan 66, Stockholm, Sweden
M: +46 70-2233664
j <[email-masked]>[email-masked]
curity.io
-------------------------------------------------------------------

---

From: Filip Skokan <[email-masked]>
Date: Wed, 30 Mar 2022 15:51:20 +0200

Hello Jacob, dear Authors,

If the server (AS or RS) utilizes the `nonce` mechanism to limit the
acceptance timeframe of DPoP Proof JWTs it would appear the need to check
the `iat` claim for "freshness" is redundant. If we're making the client
jump through hoops to enforce fresh proofs via `nonce` it seems counter
intuitive that the validation could still fail due to client or server side
clock skews (regardless of how unreasonable they may be).

Changes would need to be introduced in (source
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-07>)

   - section 4.3. point 11
      - the iat claim value is within an acceptable timeframe and, within a
      reasonable consideration of accuracy and resource utilization, a
proof JWT
      with the same jti value has not previously been received at the same
      resource during that time period (see Section 11.1)
      - section 11.1
      - To prevent this, servers MUST only accept DPoP proofs for a limited
      time window after their iat time, preferably only for a relatively brief
      period (on the order of seconds or minutes).

Proposal:

Section 4.3. point 11
*if the server did not provide a nonce value to the client that was
verified in the previous point*, that the iat claim value is within an
acceptable timeframe and, within a reasonable consideration of accuracy and
resource utilization, a proof JWT with the same jti value has not
previously been received at the same resource during that time period (see
Section 11.1)

Section 11.1 upon a second read may not need an update afteral due to the
following language "Server-provided nonces are an effective means of
preventing DPoP proof replay.". That being said, server-provided nonces do
nothing about replay within a short time window, they ensure freshness, so
may need a bit of language afterall.

S pozdravem,
*Filip Skokan*

On Tue, 29 Mar 2022 at 16:23, Jacob Ideskog <[email-masked]> wrote:

> Hi all,
>
> We have encountered a situation in the wild which I would like to share
> and discuss with you.
>
>         period (see Section 11.1 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-07#section-11.1>),
>
>         period (see Section 11.1), *unless the clock syncronization can
> be made to depend on the issuance of the nonce values.*
>
> Regards
> Jacob
>
> --
> Jacob Ideskog
> CTO
> Curity AB
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>