Subject: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

From: Denis <[email-masked]>
Date: Wed, 2 Sep 2020 10:39:07 +0200

Hi Ben,

This new thread, i.e."Towards an RFC Errata to RFC 7662 ?" is used to 
discuss one of the topics raised in:
Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT 
Response for OAuth Token Introspection) to Proposed Standard

Only the text relevant to this topic has been left.

The text that has been discussed and polished would perfectly fit into 
the Privacy Consideration section from RFC 7662.

Here it is again:

    Implementers should be aware that a token introspection request lets
    the AS know when the client is accessing the RS, which can also
    indicate when the user is using the client. If this implication is
    not acceptable, implementers can use other means to carry access
    token data, e.g. directly transferring the data needed by the RS
    within the access token.

Privacy considerations sections do not change the protocol but only 
provide some warnings. Warning the implementers is fine,
but warning the users and the clients should also be considered.

Thanks to your observations, I noticed that the sentence "thecall 
described in OAuth Introspection [RFC 7662] should be avoided"
is not appropriate.So I propose an additional text which is relevant for 
the users:

    Token introspection is an optional feature primarily intended for
    clients that are unable to support structured access tokens,
    including their validation. However, the use of this call allows an
    AS to track where and exactly when clients or users have indeed
    presented an issued access token to a RS.

    Some users or clients may be concerned that such a feature allows
    the AS to accurately trace them. If no Token introspection endpoint
    is published by an AS,
    users and clients can be confident that such tracing cannot happen.
    On the contrary, when an introspection_endpoint is published by an
    AS [RFC8414],
    users and clients have no way to know whether the RS will be allowed
    to use it, nor whether it will effectively use it.If these
    implications are not acceptable,
    users or clients should not use an AS that publishes an
    introspection_endpoint.

Denis

> Hi all,
>
> On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote:
>> The last text that has been proposed on the list about this thread is
>> the following:
>>
>> Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS,
>> which can also indicate when the user is using the client.  If this implication is not acceptable, implementers can use
>> other means to carry access token data, e.g. directly transferring the data needed by the RS within the access token.
>>
>> The concerns of the implementers have nothing to do with the concerns of
>> the Users. Such a text proposal has nothing to do with a "User consent".
>>
>> *Towards an RFC Errata to RFC 7662*
>>
>> Mike Jones wrote:
>>
>> I agree with Dick’s observation about the privacy implications of using
>> an Introspection Endpoint. That’s why it’s preferable to not use one at all
>>         and instead directly have the Resource understand the Access
>> Token. One way of doing this is the JWT Access Token spec. There are
>> plenty of others.
>>
>> I fully agree.
>>
>> RFC 7662 should have incorporated a more detailed content such as:
>>
>>        In OAuth 2.0 [RFC6749], the contents of tokens are opaque to
>> clients. However, the contents of tokens is not intended to be opaque to
>> RSs.
>>        Token introspection is an OPTIONAL feature of an AS described in
>> OAuth Introspection [RFC 7662] intended for clients that are unable
>>        to support structured access tokens including their validation.
>> The use of this call allows an AS to track where and when its clients
>> have indeed
>>        presented an issued access token. As soon as the RS knows the
>> format of the access token, e.g. using structured token formats such as
>>        JWT [RFC7519], and is able to validate its security features, the
>> call described in OAuth Introspection [RFC 7662] should be avoided,
>> otherwise
>>        the AS will know exactly when the introspection call has been made
>> and thus be able to make sure which client has attempted perform an access
>>        to that RS and at which instant of time. As soon as this call is
>> supported by an AS, the client or the user have no way to prevent the RS
>> to use it.
>>
>> It might be useful to add it, e.g. using an RFC Errata.
> I do not believe this would be an appropriate usage of an Errata Report --
> it changes the meaning of the RFC away from what the WG intended at the
> time of publication.
>
> Use of tokens that are just opaque DB handles (along with some form of
> introspection) is desirable when a prominent threat is leakage of token
> contents from the browser.  We have had numerous discussions over the years
> of various ways in which information can leak from the browser, including
> history APIs, malicious javascript, and more.  While these threats are not
> always applicable in all deployment models, they are still present, just as
> the threats that you propose we defend against are not always of concern in
> all deployment models.  AFAICT, given the technologies currently available,
> there is not one universal solution that will address all concerns, and
> deployments will have to make a trade-off.  I think we need to acknowledge
> that there are different deployment models and that (for example) giving
> the user visibility into the token contents is not always desired, given
> the other risks that the current mechanisms for providing that visibility
> open up.
>
> -Ben
>
> P.S. your usage of the phrase "the User and his client" (below) suggests
> that you are still picturing the client as being local to the user, as is
> the case for, e.g., a TLS client or an IMAP client.  This is not the
> original model for an OAuth, where the client can just as well be a
> headless server in a cloud somewhere.
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 2 Sep 2020 10:05:11 -0400

I’m not sure that adding this amount of text to the privacy considerations section is appropriate for an errata. If we wanted to do this, I believe we’d need to do a new revision of 7662.

 — Justin

> On Sep 2, 2020, at 4:39 AM, Denis <[email-masked]> wrote:
> 
> Hi Ben,
> 
> This new thread, i.e."Towards an RFC Errata to RFC 7662 ?" is used to discuss one of the topics raised in: 
> Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
> 
> The text that has been discussed and polished would perfectly fit into the Privacy Consideration section from RFC 7662.
> 
> Here it is again:
> 
> Privacy considerations sections do not change the protocol but only provide some warnings. Warning the implementers is fine, 
> Thanks to your observations, I noticed that the sentence "the call described in OAuth Introspection [RFC 7662] should be avoided" 
> is not appropriate. So I propose an additional text which is relevant for the users:
> 
> Token introspection is an optional feature primarily intended for clients that are unable to support structured access tokens, including their validation. 
> However, the use of this call allows an AS to track where and exactly when clients or users have indeed presented an issued access token to a RS. 
> Some users or clients may be concerned that such a feature allows the AS to accurately trace them. If no Token introspection endpoint is published by an AS, 
> users and clients can be confident that such tracing cannot happen. On the contrary, when an introspection_endpoint is published by an AS [RFC8414], 
> users and clients have no way to know whether the RS will be allowed to use it, nor whether it will effectively use it. If these implications are not acceptable, 
> users or clients should not use an AS that publishes an introspection_endpoint.
> Denis
> 
>> Hi all,
>> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James" <[email-masked]>
Date: Thu, 3 Sep 2020 01:14:32 +0000

> Token introspection is an optional feature primarily intended for clients

No.

The abstract of RFC 7662 (OAuth Introspection) starts:

   This specification defines a method for a protected resource to query
   an OAuth 2.0 authorization server to determine the active state of an
   OAuth 2.0 token and to determine meta-information about this token

Introspection is primarily for resource servers (RSs), not clients.

Denis, you are putting a lot of effort into improving privacy handling in OAuth. But by repeatedly using the wrong terms and attributing actions to the wrong entities your suggested text is not usable.

> If no Token introspection endpoint is published by an AS,
users and clients can be confident that such tracing cannot happen

Wow. That is a huge leap of faith. Any extra interactions between an RS & AS are somehow prevented (“cannot happen”) because AS metadata shown to another party (a client) is missing a URL?
The whole point of RFC 7662 (as discussed in its introduction) is that various “proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses)” have been developed to convey token info between AS & RS. So a standard could be helpful option for AS/RSs considering proprietary options. None of those proprietary mechanisms are mentioned in OAuth metadata published to clients.
--
James Manger

From: OAuth <[email-masked]> On Behalf Of Denis
Sent: Wednesday, 2 September 2020 6:39 PM
To: Benjamin Kaduk <[email-masked]>
Cc: [email-masked]; oauth <[email-masked]>; Torsten Lodderstedt <torsten=[email-masked]>; Mike Jones <Michael.Jones=[email-masked]>
Subject: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

Hi Ben,

Here it is again:

Denis

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 19 Sep 2020 15:06:27 -0700

Hi Denis,

> Only the text relevant to this topic has been left.

Thank you for starting a new thread.  My apologies for taking so long to
reply to it; I have not been entirely healthy for a couple weeks and many
things have been left behind.

I do agree with Justin that a document update is the best way to
incorporate this kind of considerations -- with the caveat that generally
Roman, as responsible AD for the WG, would be processing errata reports
against the OAuth specs, if I was to be processing these proposals I would
probably have to mark them as "Hold for Document Update" due to the need to
ensure that they reflect WG consensus.  One further note inline...

>     users and clients can be confident that such tracing cannot happen.

I don't think that users and clients can be confident about this; AFAIK
out-of-band configuration of an introspection endpoint is possible.

-Ben