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

Benjamin Kaduk <kaduk@mit.edu> Sat, 19 September 2020 22:06 UTC

Return-Path: <kaduk@mit.edu>
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 C97823A0138 for <oauth@ietfa.amsl.com>; Sat, 19 Sep 2020 15:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_3E8TVyrmgW for <oauth@ietfa.amsl.com>; Sat, 19 Sep 2020 15:06:34 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B1B3A0128 for <oauth@ietf.org>; Sat, 19 Sep 2020 15:06:33 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08JM6SAg021076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 19 Sep 2020 18:06:30 -0400
Date: Sat, 19 Sep 2020 15:06:27 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis <denis.ietf@free.fr>
Cc: oauth <oauth@ietf.org>
Message-ID: <20200919220627.GP89563@kduck.mit.edu>
References: <CH2PR00MB0678DA2BC7234C2AC1CE784DF5541@CH2PR00MB0678.namprd00.prod.outlook.com> <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> <D68FCD40-7365-446A-9F64-2BB59C11B7AE@mit.edu> <CAD9ie-uqeM5jwQKuvO+X4NC5oXZkoLrRu1NWC2rrE4CD=ypa+g@mail.gmail.com> <08D01F36-367B-4F23-9602-9C2A2AE49DA3@mit.edu> <CAD9ie-s+MmtFHRNzym74cHBcBxu-yKCSH+r898TJ_dtmPDMK2Q@mail.gmail.com> <65a7f2c0-c7e3-5c67-1be6-1dfb2b77779e@free.fr> <20200831224753.GP16914@kduck.mit.edu> <34dcadf9-521f-60ba-a28c-3faab4428254@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <34dcadf9-521f-60ba-a28c-3faab4428254@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yzAtkqxXTq_tAAOYJE44BiUHkuo>
Subject: Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2020 22:06:36 -0000

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