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

Justin Richer <jricher@mit.edu> Wed, 02 September 2020 14:05 UTC

Return-Path: <jricher@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 DBD5D3A07F9 for <oauth@ietfa.amsl.com>; Wed, 2 Sep 2020 07:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 WISpmeFsKrxM for <oauth@ietfa.amsl.com>; Wed, 2 Sep 2020 07:05:17 -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 A647A3A080C for <oauth@ietf.org>; Wed, 2 Sep 2020 07:05:16 -0700 (PDT)
Received: from [192.168.1.11] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 082E5BxJ003717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Sep 2020 10:05:12 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <9F55ECE2-EE65-4FF2-AE87-E62A0E03CCCE@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A823B95E-26D1-4E41-9966-30801559A1DF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Wed, 2 Sep 2020 10:05:11 -0400
In-Reply-To: <34dcadf9-521f-60ba-a28c-3faab4428254@free.fr>
Cc: Benjamin Kaduk <kaduk@mit.edu>, oauth <oauth@ietf.org>, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
To: Denis <denis.ietf@free.fr>
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>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/MkYZZkKzYxzR67DfWrGi1vYkDzU>
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: Wed, 02 Sep 2020 14:05:19 -0000

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 <denis.ietf@free.fr> 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.
> 
> 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 "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,
>> 
>> 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.
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth