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 protected]> wrote: > 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 protected]>[email protected] > curity.io > ------------------------------------------------------------------- > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
