[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)

Tomasz Kuczyński <tomasz.kuczynski@man.poznan.pl> Mon, 05 August 2024 10:22 UTC

Return-Path: <tomasz.kuczynski@man.poznan.pl>
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 EDA5BC151095 for <oauth@ietfa.amsl.com>; Mon, 5 Aug 2024 03:22:15 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 dR5kQxohYc7B for <oauth@ietfa.amsl.com>; Mon, 5 Aug 2024 03:22:12 -0700 (PDT)
Received: from sanicula.man.poznan.pl (srs.man.poznan.pl [IPv6:2001:808::173:47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0059C151520 for <oauth@ietf.org>; Mon, 5 Aug 2024 03:22:09 -0700 (PDT)
Received: from localhost (lepidium.man.poznan.pl [150.254.173.57]) by sanicula.man.poznan.pl (8.15.2/8.15.2/AV) with ESMTP id 475ALxPF1230183; Mon, 5 Aug 2024 12:21:59 +0200
Authentication-Results: sanicula.man.poznan.pl; arc=none smtp.remote-ip=150.254.173.57
ARC-Seal: i=1; a=rsa-sha256; d=man.poznan.pl; s=sanicula202312-arc; t=1722853319; cv=none; b=RjXTgZQhTkHy5YqKv1iPk+FDQWCCq/j6YEqHG6yswXgL5p1rb/nUqJGZet+M7YtGQ830IVarHPz+m7tWC91QeFO06uQfXJK925PzpMWIO0Ie2mWii66Eug0PYbngKVfE85z8759V3hTjiRjQVpsj8514Bap7PbXEivQl+XPx+syEJnC3FpdT1TIUjYc2O9ouEJUh9ZU2lH3jwAH4HMfM4JNAWBx266McAecQ3JpilJD4iYaj0ztP2Oph9pnlq8HggAShjzRlEImxwpIyqevyYJB2Km+kNMkfjg+11J+1HsUQjIUm8Kc+OrVmBioaQrlGoZRGHKooM+EoTShdihcSBA==
ARC-Message-Signature: i=1; a=rsa-sha256; d=man.poznan.pl; s=sanicula202312-arc; t=1722853319; c=relaxed/simple; bh=RQRwbL5Jhyst051TLppKtsKWHsKDl9YAuYXYR213aYw=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=r5FXGymuJRvoF4v4ta8oPlaZRJjusaVUka9WgMWUC2bfei+KIMoJMms22T3hRDavM9qieGxTqzJHu3Cr/FNF9xwgEa7jUMTBT0AfLonjlbCXgFo2z/aUcGI1b5GseC3IAeSB7YmcGikDeh+P1gYSKB9DmIuVkMb1uYfaJmgAa2WmqgiXlTO/nhlMIxGdZkxvUWByaha+ZEsLV0O6z9vVTB3tYZTNinuXYOKYqZ0iFddYGAYlbsLKNnkw8aiDEVvnoaxLkC6Blv0ie8iwKpBLwdJJIzDL+XtrPziwd6zuwkOSgn7k4swraTxwj2bhFMkbKvwwQ2bov1dRb+0a6fhnfw==
ARC-Authentication-Results: i=1; sanicula.man.poznan.pl
DKIM-Filter: OpenDKIM Filter v2.11.0 sanicula.man.poznan.pl 475ALxPF1230183
X-Virus-Scanned: by PSNC antivirus scanner at man.poznan.pl
Received: from sanicula.man.poznan.pl ([150.254.173.22]) by localhost (lepidium.man.poznan.pl [150.254.173.57]) (amavisd-new, port 10028) with ESMTP id JdXDKdPLQ-PA; Mon, 5 Aug 2024 12:21:42 +0200 (CEST)
Received: from [10.230.20.123] ([10.230.20.123]) (authenticated bits=0) by sanicula.man.poznan.pl (8.15.2/8.15.2/MSA) with ESMTPSA id 475ALdZY1229737 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 5 Aug 2024 12:21:40 +0200
Message-ID: <10d5176e-35b7-4fda-9e7c-1bbdc1c91022@man.poznan.pl>
Date: Mon, 05 Aug 2024 12:21:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Brian Campbell <bcampbell@pingidentity.com>
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>
From: Tomasz Kuczyński <tomasz.kuczynski@man.poznan.pl>
Content-Language: pl
In-Reply-To: <CA+k3eCRxxjJJtX1G=xwcwKkJVD0aReS9M7_gRxRb-_PoqfB2Mw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms030205090802090904060307"
X-Greylist: ACL matched, not delayed by milter-greylist-4.6.2 (sanicula.man.poznan.pl [150.254.173.22]); Mon, 05 Aug 2024 12:21:40 +0200 (CEST)
Message-ID-Hash: 4GGA3KM3GY6K5IURUBF5X7K2VEO4CC6I
X-Message-ID-Hash: 4GGA3KM3GY6K5IURUBF5X7K2VEO4CC6I
X-MailFrom: tomasz.kuczynski@man.poznan.pl
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/enFic3HTDyoGTG8brL9gwmDmrgM>
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>

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>
>>     <mailto:rfc-editor@rfc-editor.org>
>>     *Sent:* Wednesday, May 22, 2024 2:30 PM
>>     *To:* vittorio@auth0.com <vittorio@auth0.com>
>>     <mailto:vittorio@auth0.com>; bcampbell@pingidentity.com
>>     <bcampbell@pingidentity.com> <mailto:bcampbell@pingidentity.com>;
>>     debcooley1@gmail.com <debcooley1@gmail.com>
>>     <mailto:debcooley1@gmail.com>; paul.wouters@aiven.io
>>     <paul.wouters@aiven.io> <mailto:paul.wouters@aiven.io>;
>>     hannes.tschofenig@arm.com <hannes.tschofenig@arm.com>
>>     <mailto:hannes.tschofenig@arm.com>; rifaat.s.ietf@gmail.com
>>     <rifaat.s.ietf@gmail.com> <mailto:rifaat.s.ietf@gmail.com>
>>     *Cc:* tomasz.kuczynski@man.poznan.pl
>>     <tomasz.kuczynski@man.poznan.pl>
>>     <mailto:tomasz.kuczynski@man.poznan.pl>; oauth@ietf.org
>>     <oauth@ietf.org> <mailto:oauth@ietf.org>;
>>     rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>
>>     <mailto: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>
>>     <mailto: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./