[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)
Brian Campbell <bcampbell@pingidentity.com> Mon, 05 August 2024 18:22 UTC
Return-Path: <bcampbell@pingidentity.com>
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 C54CFC14F5F3 for <oauth@ietfa.amsl.com>; Mon, 5 Aug 2024 11:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxC3wBaEXroU for <oauth@ietfa.amsl.com>; Mon, 5 Aug 2024 11:22:03 -0700 (PDT)
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF290C151980 for <oauth@ietf.org>; Mon, 5 Aug 2024 11:22:03 -0700 (PDT)
Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-4f52cc4d3beso3917182e0c.3 for <oauth@ietf.org>; Mon, 05 Aug 2024 11:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; t=1722882122; x=1723486922; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NpWHYHt2j0Ppo23uvXsilNgxmi7LiOyhd13gILWIPlQ=; b=Y9sjFK2o7Qst01yyqpzLKFO+q/u7/bj7F/M+m+/+z+BllWFdEAq8iKseokXZJDgxPB GjS321yMwTGAVZ9PTjEhxGUAutgBuzCCUN2rRSwrb5FooG8WNXKgAskfn5SK/S3PdY8S DZjxoaArP0qbaZpRf1x9C2ADm18VAKzuu+1UoCHcDyCpSX+fdOSqm+9ZaoTYrAX+tHmj wPiLBFoVDwYvFaoLpNoIH2cph485kf6n4e9ufmvIWGtXnA2bXA2nfa2nVh465MKa7SQU ElF5O20h3B0LhXvUHTXnhNJf6tiLXWRFIQkwABdogcH31KMwpKFewBwMS2FycVlG4UiI vxIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722882122; x=1723486922; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NpWHYHt2j0Ppo23uvXsilNgxmi7LiOyhd13gILWIPlQ=; b=EQdpqjOUqdxlGolSgAknrfn/MtOtMRVbBuTLFVbalcVOn5Kx7PktvpaDRrRbRrL87w f3iw170rsljmWRM8hSJKeNtkvcdQo/xZ3k8KLO3upUQh4mYQnrGQyK+qQ/UKLWFEKrPb Uf0J4eluqtNCOwqmumAFRsa7eeb22f+fk99HPy2Iu9f8K9hek/tjLO3b9KeHPc04B/cG FewjTNE1XTXlx1aJJqhRCF3hNvA0e2OaDzBi1kC8STSUbhpTU1uefGBWjEfc8rbpV8EY kdt0VkZBJ0mDVCeGP+scmbSi2oGuxMVkXk/25LzJE+WAb4PFaA/g0ZkwjnoEUsKAKrLB lDyA==
X-Forwarded-Encrypted: i=1; AJvYcCXMzW+tWR00NcpjgZ279pQUn1aSlNKD1ejRNExRU5/1MPfxruB6lfPjwhPunkzpo4dMLsA0fb42qFUBbKGzUw==
X-Gm-Message-State: AOJu0YzzKLmPZvIeZKDzq9ouioKW2s2lmzi/nHZAqEQOVq1NRvWhsPBq +l4EIM66ThO243oblpWJC/BgQvCvM0okc0kk8tGv6217ETVFUJrLhUcAa792GJLmbYEaTOLXoVa IGXBySX4ZUWZY2GvM0//lMlOYFghVwjdBqsR8V60qiXXIUt5bIdE9xqqoUu0hTlRQv+a38Sepfk Xg6v0i6WN52A==
X-Google-Smtp-Source: AGHT+IGXEmvlBB6UT59pd89TJZWtXEccrqXTrD3QUHBZnKsLCJ9dDHn1k/O8SZPbITv8oOYnZgKWwKxX4OxNnjDEqzg=
X-Received: by 2002:a05:6122:2029:b0:4e4:e90f:6749 with SMTP id 71dfb90a1353d-4f8a0003573mr16079655e0c.10.1722882122307; Mon, 05 Aug 2024 11:22:02 -0700 (PDT)
MIME-Version: 1.0
References: <20240522183054.DCCFEC000063@rfcpa.rfc-editor.org> <LV8PR01MB8677AC4BEDE87DA9FC70CE3DBDEB2@LV8PR01MB8677.prod.exchangelabs.com> <adf0ff35-11f1-4cc3-bcb6-f745ee988091@man.poznan.pl> <CA+k3eCRxxjJJtX1G=xwcwKkJVD0aReS9M7_gRxRb-_PoqfB2Mw@mail.gmail.com> <10d5176e-35b7-4fda-9e7c-1bbdc1c91022@man.poznan.pl>
In-Reply-To: <10d5176e-35b7-4fda-9e7c-1bbdc1c91022@man.poznan.pl>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 05 Aug 2024 12:21:35 -0600
Message-ID: <CA+k3eCR0fD01ZsLFbsirdQz_pnoMCDibTY2VvhAewp5PZeTh8w@mail.gmail.com>
To: Tomasz Kuczyński <tomasz.kuczynski@man.poznan.pl>
Content-Type: multipart/alternative; boundary="000000000000e3fc28061ef3c0ae"
Message-ID-Hash: Q4REJYQBWRA2OQEK7H4ZTSCGEBLRQLK5
X-Message-ID-Hash: Q4REJYQBWRA2OQEK7H4ZTSCGEBLRQLK5
X-MailFrom: bcampbell@pingidentity.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: RFC Errata System <rfc-editor@rfc-editor.org>, "vittorio@auth0.com" <vittorio@auth0.com>, "paul.wouters@aiven.io" <paul.wouters@aiven.io>, "oauth@ietf.org" <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-JI2dcP0g5iveVIzAinqGq-RYf0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>
I believe this errata should be verified, if that wasn't clear from my prior message. The errata process remains somewhat opaque to me, however, so I'm not sure what happens next. But I don't think anything is needed from your side at this point. On Mon, Aug 5, 2024 at 4:22 AM Tomasz Kuczyński < tomasz.kuczynski@man.poznan.pl> wrote: > It took some time since the last message in the thread. Could you please > let me know if there is any additional information or action required from > my side for the verification process? Or is it simply a matter of waiting > for the process to complete? > > Best regards > Tomasz Kuczyński > W dniu 30.05.2024 o 17:28, Brian Campbell pisze: > > I suspect a variety of not-entirely-improbable rational could be provided > to explain why it might make sense. But the reality is that it's just a > mistake in the document where somewhere along the way updates were made to > the examples that didn't fully align with content already in those > examples. I try to be careful with details like that but apparently wasn't > careful enough in this case. > > On Thu, May 23, 2024 at 5:45 AM Tomasz Kuczyński < > tomasz.kuczynski@man.poznan.pl> wrote: > >> The introspection response should rather reflect facts related to the >> access token sent for the introspection. So even in case, a new >> authentication event took place after the token issuance, it should not be >> included in the response as the authentication event is not related to the >> introspected access token. >> The inclusion of that information in the introspection response should be >> treated as a vulnerability. >> >> Regardless of the above, the "exp" in response is also earlier than the >> "auth_time", which means that the introspected token is beyond the time >> window of its validity and in fact, the introspection response should >> contain nothing more than {"active": false}. >> >> Best regards >> Tomasz Kuczyński >> W dniu 23.05.2024 o 01:06, Justin Richer pisze: >> >> This seems to be logical - the authentication event would always be >> before the token was issued in the usual case. However, assuming that the >> AS "upgrades" an existing token in-place during a step up, isn't it >> possible for the latest relevant authentication event to come after the >> token was initially issued? >> >> - Justin >> ------------------------------ >> *From:* RFC Errata System <rfc-editor@rfc-editor.org> >> <rfc-editor@rfc-editor.org> >> *Sent:* Wednesday, May 22, 2024 2:30 PM >> *To:* vittorio@auth0.com <vittorio@auth0.com> <vittorio@auth0.com>; >> bcampbell@pingidentity.com <bcampbell@pingidentity.com> >> <bcampbell@pingidentity.com>; debcooley1@gmail.com <debcooley1@gmail.com> >> <debcooley1@gmail.com>; paul.wouters@aiven.io <paul.wouters@aiven.io> >> <paul.wouters@aiven.io>; hannes.tschofenig@arm.com >> <hannes.tschofenig@arm.com> <hannes.tschofenig@arm.com>; >> rifaat.s.ietf@gmail.com <rifaat.s.ietf@gmail.com> >> <rifaat.s.ietf@gmail.com> >> *Cc:* tomasz.kuczynski@man.poznan.pl <tomasz.kuczynski@man.poznan.pl> >> <tomasz.kuczynski@man.poznan.pl>; oauth@ietf.org <oauth@ietf.org> >> <oauth@ietf.org>; rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> >> <rfc-editor@rfc-editor.org> >> *Subject:* [OAUTH-WG] [Technical Errata Reported] RFC9470 (7951) >> >> The following errata report has been submitted for RFC9470, >> "OAuth 2.0 Step Up Authentication Challenge Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7951 >> >> -------------------------------------- >> Type: Technical >> Reported by: Tomasz Kuczyński <tomasz.kuczynski@man.poznan.pl> >> <tomasz.kuczynski@man.poznan.pl> >> >> Section: 6.2 >> >> Original Text >> ------------- >> "exp": 1639528912, >> "iat": 1618354090, >> "auth_time": 1646340198, >> >> Corrected Text >> -------------- >> "exp": 1639528912, >> "iat": 1618354090, >> "auth_time": 1618354090, >> >> Notes >> ----- >> I noticed a small inconsistency in the example "Figure 7: Introspection >> Response". It seems that the time for the user-authentication event should >> be less than or equal to the time of token issuance to ensure logical >> coherence. >> >> 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. >> >> -------------------------------------- >> RFC9470 (draft-ietf-oauth-step-up-authn-challenge-17) >> -------------------------------------- >> Title : OAuth 2.0 Step Up Authentication Challenge Protocol >> Publication Date : September 2023 >> Author(s) : V. Bertocci, B. Campbell >> Category : PROPOSED STANDARD >> Source : Web Authorization Protocol >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-leave@ietf.org >> >> > *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.* > > -- _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._
- [OAUTH-WG] [Technical Errata Reported] RFC9470 (7… RFC Errata System
- [OAUTH-WG] Re: [Technical Errata Reported] RFC947… Justin Richer
- [OAUTH-WG] Re: [Technical Errata Reported] RFC947… Tomasz Kuczyński
- [OAUTH-WG] Re: [Technical Errata Reported] RFC947… Brian Campbell
- [OAUTH-WG] Re: [Technical Errata Reported] RFC947… Tomasz Kuczyński
- [OAUTH-WG] Re: [Technical Errata Reported] RFC947… Brian Campbell