[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)
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.kuczyn...@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.kuczyn...@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
>>
>> *Sent:* Wednesday, May 22, 2024 2:30 PM
>> *To:* vitto...@auth0.com ;
>> bcampb...@pingidentity.com
>> ; debcool...@gmail.com
>> ; paul.wout...@aiven.io
>> ; hannes.tschofe...@arm.com
>> ;
>> rifaat.s.i...@gmail.com
>>
>> *Cc:* tomasz.kuczyn...@man.poznan.pl
>> ; oauth@ietf.org
>> ; rfc-edi...@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
>>
>>
>> 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-le...@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
[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)
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
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
*Sent:* Wednesday, May 22, 2024 2:30 PM
*To:* vitto...@auth0.com
; bcampb...@pingidentity.com
;
debcool...@gmail.com
; paul.wout...@aiven.io
;
hannes.tschofe...@arm.com
; rifaat.s.i...@gmail.com
*Cc:* tomasz.kuczyn...@man.poznan.pl
; oauth@ietf.org
;
rfc-edi...@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
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-le...@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 communicati
[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)
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.kuczyn...@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
>
> *Sent:* Wednesday, May 22, 2024 2:30 PM
> *To:* vitto...@auth0.com ;
> bcampb...@pingidentity.com
> ; debcool...@gmail.com
> ; paul.wout...@aiven.io
> ; hannes.tschofe...@arm.com
> ;
> rifaat.s.i...@gmail.com
>
> *Cc:* tomasz.kuczyn...@man.poznan.pl
> ; oauth@ietf.org
> ; rfc-edi...@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
>
>
> 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-le...@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
>
>
--
_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 mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)
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
*Sent:* Wednesday, May 22, 2024 2:30 PM
*To:* vitto...@auth0.com ;
bcampb...@pingidentity.com ;
debcool...@gmail.com ; paul.wout...@aiven.io
; hannes.tschofe...@arm.com
; rifaat.s.i...@gmail.com
*Cc:* tomasz.kuczyn...@man.poznan.pl ;
oauth@ietf.org ; rfc-edi...@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
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-le...@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
smime.p7s
Description: Kryptograficzna sygnatura S/MIME
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)
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 Sent: Wednesday, May 22, 2024 2:30 PM To: vitto...@auth0.com ; bcampb...@pingidentity.com ; debcool...@gmail.com ; paul.wout...@aiven.io ; hannes.tschofe...@arm.com ; rifaat.s.i...@gmail.com Cc: tomasz.kuczyn...@man.poznan.pl ; oauth@ietf.org ; rfc-edi...@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 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-le...@ietf.org ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
