Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard

Neil Madden <neil.madden@forgerock.com> Mon, 31 August 2020 18:51 UTC

Return-Path: <neil.madden@forgerock.com>
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 72A063A1888 for <oauth@ietfa.amsl.com>; Mon, 31 Aug 2020 11:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
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 EuyGG80Oh7f9 for <oauth@ietfa.amsl.com>; Mon, 31 Aug 2020 11:51:10 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD5A3A18A1 for <oauth@ietf.org>; Mon, 31 Aug 2020 11:51:09 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id w5so6957649wrp.8 for <oauth@ietf.org>; Mon, 31 Aug 2020 11:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1l4fVQedbqIv6e8wIa747DJ9aApyFi0oHorKSf4883I=; b=R6UeA4Ktvp9MdYQIdVsuAmXa6mxKKvOA60gS9pM1DBki9yCGGCOSPPc1bHACwvFLL0 Az/PdyTF/hvDWDzuiybzMVIQ/Mjl0oo1zQhKPiIEMPdpHsQykU/YlxH3VyFcz/Q7+Jhf p02KjLjSVuhvmkOF+Sknd1bTRCcXDMayu07Yo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1l4fVQedbqIv6e8wIa747DJ9aApyFi0oHorKSf4883I=; b=ptg8etaD6yYOklCirfaoS8oVN3y+6l8D8x+TA88A/fsQ41RBjHrUbnE6Xu7GIs3Ub7 s8P+GjYqQx2cPOlqBntzoFmUCMhn15RDAeNZfcyagyDkX2HOSJD8GYSLgG9dhl///cQ9 iP56629FVsvE+7iKhoW+qVcC574dIbMlUuqdMFNmynQG2PW7yZxWNKgLrhOgiLOzl6E9 jB2cP8tjBAAR92EWDHbGgnJkVWpfXJ+ORxcsU7+FwOBv1KAszJwW7+eeXiTDNn8O9+GX DFgkw+s42eyKXl6QaCxQ9/OKZ7swY3xWlEdxz/ufp/pN40AFNBiwNwB4VjDnHJIfAViq 4BsQ==
X-Gm-Message-State: AOAM530LqYjT7TN4Lw3Wta/9m7NPBVKDI3IogMvFwxYtTh4AY0sM8aoV dYLoAMJMsafXdlxhUzjOJgwfDQ==
X-Google-Smtp-Source: ABdhPJzp9iFBOsdFjl3VpAnc4X+i0VFPeqK6NSAbnpjRLLPBwZfyVBO+8tE4TCLcaNBpxyhn+sUKGA==
X-Received: by 2002:adf:dfd1:: with SMTP id q17mr3103733wrn.347.1598899867647; Mon, 31 Aug 2020 11:51:07 -0700 (PDT)
Received: from [10.0.0.3] (38.227.143.150.dyn.plus.net. [150.143.227.38]) by smtp.gmail.com with ESMTPSA id o2sm579284wmo.37.2020.08.31.11.51.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2020 11:51:07 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-B2EFC8E0-2872-4FD4-8EC0-6C40B58AFA47"
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 31 Aug 2020 19:51:06 +0100
Message-Id: <4D84C4C3-3BCF-4BA9-A182-2CF2CAFE10A5@forgerock.com>
References: <CAKhDPzM1pwaeevfp=hbrb-MEn=Ks5mvSKNxCozD1VQJDOfe+Zw@mail.gmail.com>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, oauth <oauth@ietf.org>, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
In-Reply-To: <CAKhDPzM1pwaeevfp=hbrb-MEn=Ks5mvSKNxCozD1VQJDOfe+Zw@mail.gmail.com>
To: Jeff Craig <jeffcraig@google.com>
X-Mailer: iPhone Mail (17G80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Hup-KpLfnUsuSAYTbiYx4go3Jeo>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
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: Mon, 31 Aug 2020 18:51:13 -0000

> On 31 Aug 2020, at 18:41, Jeff Craig <jeffcraig@google.com> wrote:
> 
> 
> I think that the argument is that token refreshing isn't as strong a signal about usage patterns as introspection calls would be, which I agree with.

It’s usually pretty similar in my experience (see below).  

> I also think that if a RS knows it's using an external AS, they've generally accepted this information leakage. This is not to say it's not worth mentioning in the document, but rather that I doubt it will significantly move implementations one way or the other.

Right. 

> 
> Generally speaking, I don't like JWTs as Access Tokens. They're verbose, they leak information to clients that clients don't need, and if the RS makes a mistake in their JWT validation, they can create security vulnerabilities.  That said, I do think they are preferable to Introspection at request time, and the RS's that I've worked with generally don't want the overhead of Introspection on every usage of the token.

Generally you’d cache the result of the introspection call to mitigate this overhead. (Eg some reverse proxies or API gateways can do this). The two approaches are pretty similar: either you have 10 second access tokens and refresh, or you introspect and cache the response for 10 seconds. 

I much prefer introspection because there are far fewer ways to mess it up, but the JWT approach can be useful if you have clients accessing a lot of different RSes. 

> I generally argue a shared secret between the RS and the AS is a better solution, but in my experience most cloud-hosted ASes don't offer that option.
> 
> For this cloud AS situation, I have been tracking draft-ietf-oauth-token-exchange-19 as a means for RSes to setup a Token Endpoint to convert the AS access token into a access token (w/o Refresh) that the RS can accept, thus limiting Introspection to the Refresh flow, but I don't currently have a RS interested in trying to try this flow, but I think that it's a reasonable approach to limiting introspection on every request to the RS, though it does add an additional point of failure during the Token Refresh. This has the same leakage problem that is under discussion here, obviously.
> 
>> On Mon, Aug 31, 2020 at 3:34 AM Neil Madden <neil.madden@forgerock.com> wrote:
>> But if you want to handle revocation (and you do), then the alternative is short-lived access tokens with frequent refreshing, which also informs the AS of activity. So is this any better?
>> 
>> If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) then there are privacy implications to that arrangement, regardless of the specific technology used for token validation.
>> 
>>>> On 26 Aug 2020, at 22:16, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> 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.
>>> 
>>>  
>>> 
>>> The downsides of using an Introspection Endpoint should be described in the Privacy Considerations section.
>>> 
>>>  
>>> 
>>>                                                        -- Mike
>>> 
>>>  
>>> 
>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
>>> Sent: Wednesday, August 26, 2020 9:52 AM
>>> To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
>>> Cc: last-call@ietf.org; oauth <oauth@ietf.org>
>>> Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
>>> 
>>> Hi Denis,
>>> 
>>> > On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote:
>>> 
>>> > The fact that 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. The use of this call allows an AS to track where and when 
>>> > its clients have indeed presented an issued access token.
>>> 
>>> That is a fact. I don’t think it is an issue per se. Please explain the privacy implications.
>>> 
>>>  
>>> 
>>> As I see it, the privacy implication is that the AS knows when the client (and potentially the user) is accessing the RS, which is also an indication of when the user is using the client.
>>> 
>>>  
>>> 
>>> I think including this implication would be important to have in a Privacy Considerations section.
>>> 
>>>  
>>> 
>>> /Dick
>>> 
>>> ᐧ
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth