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

Tomasz Kuczyński <tomasz.kuczynski@man.poznan.pl> Thu, 23 May 2024 11:45 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 9BBD0C18DB9C for <oauth@ietfa.amsl.com>; Thu, 23 May 2024 04:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 7zR2CORS4bxB for <oauth@ietfa.amsl.com>; Thu, 23 May 2024 04:45:48 -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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9764CC1840E4 for <oauth@ietf.org>; Thu, 23 May 2024 04:45:47 -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 44NBjbMK3287865; Thu, 23 May 2024 13:45:37 +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=1716464738; cv=none; b=egw0m//AiJ6/A8jlMZy3YrKQ0esRrow2wwsLQjAR85Z68sK4AG78Y2p6Vs0cwFXbFAblD94kQ5fMY23C2S32rQ7V+YObVi6I7poGwPwGWBddk9e0uTZdzN/o47g0YwB+1RunrVVxcP37FKSjMxPhep0lUhpGQ9fe/7Se4DnTtQE3w0/jWrKy7uXymkraOjLUGGVM/JjeXm4oGv9X9Bjz1Wn9oMbCzoAEU2wnlnClKGmxxgeRJKuw+ZlYwKCApK3x2UFeXSeQXs9/38TLn0SsPLLaBJ62stuI55/Kx0sDOnimK8aWo/joNykXJF5QpCEk5nhS9jMwlo6VAZM2k+oIOg==
ARC-Message-Signature: i=1; a=rsa-sha256; d=man.poznan.pl; s=sanicula202312-arc; t=1716464738; c=relaxed/simple; bh=gyX502TKnxTGRIx3429+bn+naPLeS2K7oBYMvyOTCbM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=GOPCiMOuQQHlSshs5BUJRdY7yPq8UD6dd3EI21oFSerOZMohKD4fcXG3oHl7dFGaeJVZ1h+b0Mbpvv+72AVHBUyKcchYTTzH1hZD0sj+yBZwrDQ0GrncNZyxPhkrX2R72s9rlSTTuHw+1nduvfw8pkUFMdOZ1R63rfR33EnTP/jUCRkryvI+2zBnGij7b9g5/CzePrFYFhpT+MsAJqmvdGuYZVLpZqxFS4ePeKsOJPlvM8yFA9c9kuKyw1qPhqnX/M5LmdOmeN70cZr0cKnj6OysYc0BI1PAjmJjFTxw6oRZ72H1JXRiLVSOqTERrLDHijJZnUS1O6wvRCjRLbdKmw==
ARC-Authentication-Results: i=1; sanicula.man.poznan.pl
DKIM-Filter: OpenDKIM Filter v2.11.0 sanicula.man.poznan.pl 44NBjbMK3287865
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 a1l1S7ABLPO0; Thu, 23 May 2024 13:45:22 +0200 (CEST)
Received: from [172.16.18.90] (pimpstar-openvpn.man.poznan.pl [150.254.169.100]) (authenticated bits=0) by sanicula.man.poznan.pl (8.15.2/8.15.2/MSA) with ESMTPSA id 44NBjJjh3287441 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 23 May 2024 13:45:20 +0200
Message-ID: <adf0ff35-11f1-4cc3-bcb6-f745ee988091@man.poznan.pl>
Date: Thu, 23 May 2024 13:45:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Justin Richer <jricher@mit.edu>, RFC Errata System <rfc-editor@rfc-editor.org>, "vittorio@auth0.com" <vittorio@auth0.com>, "bcampbell@pingidentity.com" <bcampbell@pingidentity.com>, "debcooley1@gmail.com" <debcooley1@gmail.com>, "paul.wouters@aiven.io" <paul.wouters@aiven.io>, "hannes.tschofenig@arm.com" <hannes.tschofenig@arm.com>, "rifaat.s.ietf@gmail.com" <rifaat.s.ietf@gmail.com>
References: <20240522183054.DCCFEC000063@rfcpa.rfc-editor.org> <LV8PR01MB8677AC4BEDE87DA9FC70CE3DBDEB2@LV8PR01MB8677.prod.exchangelabs.com>
From: Tomasz Kuczyński <tomasz.kuczynski@man.poznan.pl>
Content-Language: pl
In-Reply-To: <LV8PR01MB8677AC4BEDE87DA9FC70CE3DBDEB2@LV8PR01MB8677.prod.exchangelabs.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080500000407060005060206"
X-Greylist: ACL matched, not delayed by milter-greylist-4.6.2 (sanicula.man.poznan.pl [150.254.173.22]); Thu, 23 May 2024 13:45:20 +0200 (CEST)
X-MailFrom: tomasz.kuczynski@man.poznan.pl
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0
Message-ID-Hash: 5QXJX4VBQBZAYNEJGMMT3MHMLDC5PBXX
X-Message-ID-Hash: 5QXJX4VBQBZAYNEJGMMT3MHMLDC5PBXX
X-Mailman-Approved-At: Thu, 23 May 2024 05:10:27 -0700
CC: "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>
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>

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

-- 
Tomasz Kuczynski

Applications Division
Large Scale Applications and Services Department Manager
Poznan Supercomputing and Networking Center
Polish Academy of Sciences
Jana Pawla II 10, Room 1.28
61-139 Poznan, Poland
Tel.: +48 693 918 148