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

Dick Hardt <dick.hardt@gmail.com> Mon, 31 August 2020 18:10 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1943C3A1856; Mon, 31 Aug 2020 11:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TfYe65hgpFts; Mon, 31 Aug 2020 11:09:58 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 DB3A23A1854; Mon, 31 Aug 2020 11:09:57 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id r13so7828902ljm.0; Mon, 31 Aug 2020 11:09:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xtv7KVXgy6jUQPItqnTjxD11ia9j/qko559pgKd15g0=; b=d0nS8ngTQcC3eLz6Nd/5MCwonbdEsZxxSdAn3vDdqVIxFFKJceilK5uKJbMPkTh6e7 mRgRKjXfEEmOeJWUwqINwGtz2yQFUJpPIkYhKCfEmwZWXGMjipjW3aFOwxIfRD/GOAVt OOEHNUKPyk2SusJAA04bLEICN5iqRNMViCmk4w9j3cNS51U4mvSlGmMt2rHy0p28GJLV uVv33tv172A084+YhcY9vXbyWxl7mHaqbcZr0cv0Ww67RppJVSx5+d20cJcbfYn16ZUN 9+7E5mjD4y5kC/zj/0db0ZRK8Ha1hdXHD1Sqc6JiElCGxpfxt7L9yGszsqAEyD8Lbnv0 BJmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xtv7KVXgy6jUQPItqnTjxD11ia9j/qko559pgKd15g0=; b=T1p4+KLVvbi8KhLB+S0G+vjvvWoYGiNpfO2nlFSal3YH1qr5YQLpQN+kJOfJLACjZP 6awrciZGBRvHBfV5HziHpJe1ChvpBYuHa2x/dko5LPcuoJTPBZTGARUYqd6A5HEXuq5l 61s9kQLhAKrc+rDJCuplSJXX7Nv5YUOL666aE9YKwwCBGPfU2EbfwUgeLoHiAbuhKjYL EkBG6fquaueYTqx90dOub166X/A6unp8HY1PAcXcZDOppg/RZuguHQ5Qx87XmzQQZKsC xxFGXiMhBuQfvKceLk71EQ4KTL9et6aLvGS4ecdtsrvJPUZ0+wNbeSBmYLjNCzvVREdn 410A==
X-Gm-Message-State: AOAM531DKQKYyONccs9VSwfmEfKWvdQRGZmmOs1mMvB+Ya03OJ18N5VT iMuOmGA6xmlrNRsKqb4Vo3ygSUA8BIi03HWv+SE=
X-Google-Smtp-Source: ABdhPJxZqj+6u793law+fb45r14pzUHb2dvphrJ7//xZkeJ74yLtf7e1tnQ9iMJ3o7DrAHCOgLVTSL4wF7sEEDn81cY=
X-Received: by 2002:a2e:81d7:: with SMTP id s23mr1226904ljg.69.1598897395646; Mon, 31 Aug 2020 11:09:55 -0700 (PDT)
MIME-Version: 1.0
References: <CH2PR00MB0678DA2BC7234C2AC1CE784DF5541@CH2PR00MB0678.namprd00.prod.outlook.com> <32F1225F-1366-46BB-A17C-396854D553FB@forgerock.com> <CAKhDPzM1pwaeevfp=hbrb-MEn=Ks5mvSKNxCozD1VQJDOfe+Zw@mail.gmail.com>
In-Reply-To: <CAKhDPzM1pwaeevfp=hbrb-MEn=Ks5mvSKNxCozD1VQJDOfe+Zw@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 31 Aug 2020 11:09:19 -0700
Message-ID: <CAD9ie-sYfBPX6Gb6pnYJ8jhxGeq0N26fcge4UwJVLyb3o7JjRw@mail.gmail.com>
To: Jeff Craig <jeffcraig=40google.com@dmarc.ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com>, "last-call@ietf.org" <last-call@ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004cc45405ae304ffd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/YRDQzUIooGrIctUPeCsM3pfAz1U>
Subject: Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2020 18:10:00 -0000

Another approach to address the privacy implications of a token refresh
is a client can obfuscate usage by the user by doing regular token
refreshes independent of user activity.

ᐧ

On Mon, Aug 31, 2020 at 10:41 AM Jeff Craig <jeffcraig=
40google.com@dmarc.ietf.org> 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. 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.
>
> 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. 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 <40lodderstedt.net@dmarc.ietf..org>>
>> wrote:
>>
>> Hi Denis,
>>
>> > On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr
>> <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
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>