[OAUTH-WG] Regarding iat and nonce in DPoP Proofs
Jacob Ideskog <jacob.ideskog@curity.io> Tue, 29 March 2022 14:22 UTC
Return-Path: <jacob.ideskog@curity.io>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A723A108F for <oauth@ietfa.amsl.com>; Tue, 29 Mar 2022 07:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=curity-io.20210112.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ng7shTDgWDn for <oauth@ietfa.amsl.com>; Tue, 29 Mar 2022 07:22:30 -0700 (PDT)
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4203A1994 for <oauth@ietf.org>; Tue, 29 Mar 2022 07:22:30 -0700 (PDT)
Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-2e592e700acso185237507b3.5 for <oauth@ietf.org>; Tue, 29 Mar 2022 07:22:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=dpRZQ125gQVEN7xs4XzkVihC9kiOVBivcLU2sa67AKo=; b=JpuNhfgxbQxUZ8qppxpK/TuY7CEcbldiQaG4ioLxam37HDyb2VgUzfO/vJuitkIWUV KnNbKJa6AsDQvO2Bkz0R3N/udLWfnV8oM5B4DCGJb30HWBEXBjQcvu/Vj9UK7hZ19SWn oBrK985ZOxUvoCRKjl3SlI/lz5UW4CtGm0dkLVrDf8VNQ32xo3A3mIys+uZiKaxO+zDP IX6kXU/1Z6bOSjatbMcmu6QBVMkNjeQRDiV7cO9YWIJK6gqTYjPVrdzWCG5L5VnHpPZf Z5av19mES8zFT8bYfPt40jnQ2IU6I3FSsE2+XixCl/OstxIGCuBAe8qAXiIWB3DzDNxE vfhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dpRZQ125gQVEN7xs4XzkVihC9kiOVBivcLU2sa67AKo=; b=yhoongNpqH91emGvsQHpBq6G3iy/mRvpeyOnXDlMaNmBdDsllQGB8gleGHNB/PAnpN RMdWPS3aKhcTgtSdnpSnSQRtSDbAH5WoGYtYC2QFJn3Fg6G6jdJ3SWzoMzFaa7F813L6 WlZWO3pFb9lRigmx8K+7Jr+Gf5+0BT78VgtovDr7ers6Q220JvqV7Onk2li40bfNKJ0K VGDzgA4U9ZmqlszuqT9T3noxlDVxzldxnb/5ufNbzitdT4a/eQFtj3QNBZUaVoEQBOls qZ2cqPtXQGD8HT2vc9Vz+93je2W9Ff2BwKVEgMYSWpOmh96lRGEkgDh1R9g2FOyYdeTu GsKQ==
X-Gm-Message-State: AOAM532kG8wuMHN/SjphnTj4XQpixq5Vr7mR5TOI8Ir4VzbiEs9JW3UJ csRXcpgrtNEkx5pdlUgqWy4d7rQGsIFcovy3BVEtkRSA4vJT8w==
X-Google-Smtp-Source: ABdhPJzYZxswAfGSSQZKI1yE9xZWu9ai0qiPrWibxoNhdLtd6mPTG0dBb2BW0vGbZkChq54Myi+fLNSIQ7rqDyPrX8Q=
X-Received: by 2002:a81:7c4:0:b0:2e6:bdd9:f86f with SMTP id 187-20020a8107c4000000b002e6bdd9f86fmr30161359ywh.300.1648563748869; Tue, 29 Mar 2022 07:22:28 -0700 (PDT)
MIME-Version: 1.0
From: Jacob Ideskog <jacob.ideskog@curity.io>
Date: Tue, 29 Mar 2022 16:22:17 +0200
Message-ID: <CAKL4o=G9wO-LCgkWipsAEV3_sVUThTsQcaHd-Vf2o08KTA5UKg@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a4298605db5c2820"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/UefXj7zWMg-2--q91Z5IXvcRrLk>
Subject: [OAUTH-WG] Regarding iat and nonce in DPoP Proofs
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2022 14:22:35 -0000
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 <jacob@twobo.com>acob@curity.io curity.io -------------------------------------------------------------------
- [OAUTH-WG] Regarding iat and nonce in DPoP Proofs Jacob Ideskog
- Re: [OAUTH-WG] Regarding iat and nonce in DPoP Pr… Filip Skokan
- Re: [OAUTH-WG] Regarding iat and nonce in DPoP Pr… Brian Campbell
- Re: [OAUTH-WG] Regarding iat and nonce in DPoP Pr… Brian Campbell