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

[Brian Campbell <[e-mail]>]

Hello Filip, Jacob, co-authors, and WE participants,

Apologies from myself and fellow co-authors for the slow response. I was on
family vacation for much of WGLC and am slowly catching up.

Anyway, yeah, I definitely believe that one of the intentions when adding
the nonce was to allow the server to limit the acceptance timeframe of DPoP
Proof JWTs using its own notion of time somehow captured opaquely in/with
the nonce rather than using the client time via iat. I'll endeavor to
rework the text in sections 4.3 and 11.1 to be more clear that either can
be used alone in validating the timeliness of the proof.

Filip's last comment about section 11.1 shows, to me anyway, that there's
an inconsistency in the requirements (SHOULD level currently) for jti
tracking depending on whether iat or nonce is used for TTL. I think that
should change to have uniform treatment for both. And I think the jti
tracking requirement should be somewhat further de-emphasised - it can be
difficult/costly to do and there's no obvious threat (I don't think?)
that'd be prevented by catching the same proof being used more than once.






On Wed, Mar 30, 2022 at 7:53 AM Filip Skokan <[e-mail]> wrote:

> 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 <[e-mail]>
> 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: [phone]
>> j <[e-mail]>[e-mail]
>> curity.io
>> -------------------------------------------------------------------
>> _______________________________________________
>> 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._