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

[Benjamin Kaduk <[e-mail]>]

Hi Denis,

On Wed, Sep 02, 2020 at 10:39:07AM +0200, Denis 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
> 
> 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...

> 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.

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

>     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.
> >
>