Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

Takahiko Kawasaki <taka@authlete.com> Mon, 02 March 2020 16:52 UTC

Return-Path: <taka@authlete.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 90B233A0BDD for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2020 08:52:52 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.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 uZQPLH-eLOxx for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2020 08:52:50 -0800 (PST)
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 977C43A0BBF for <oauth@ietf.org>; Mon, 2 Mar 2020 08:52:49 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id q8so617141wrm.4 for <oauth@ietf.org>; Mon, 02 Mar 2020 08:52:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f3hmyfWZvagpyittKl6sQS+ohvB4+YahiZEdZGqex+c=; b=HMUZw/Mhn4jqRZQ5mlBaZwtiah7fS9nIUIPi/SqbpTe22fndw39VMo84kiXqM9HAyC leN/N0yjlxmjhezNKI7Bj79egiGrKWO7MLaQrAcznIgA0QQbotd6hD2HsRtF3yr+P3Dz 6sWJKMKdrSnLuz9E6glQraKkXo9rEOmWdCSE/czNUADXEpn9SEaGWKr4M+nYQ4Ao+fTr mfN3eJHMXuwTBOKbk8s94yQW2AaHwzvH1h3qBuQMqX7bqKgvkl0Kh65q6CcxQ3jAy41G /uK04js/+11UAGBeCKuYM9yecaHw53VR2F6DfVket56IiQbx/MDBPJadXH+NXI0GWEla n3UA==
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=f3hmyfWZvagpyittKl6sQS+ohvB4+YahiZEdZGqex+c=; b=EyOePLXhS4AEF/PlJxl7oJvadO0NhdOQsevMzkEcSorQnmu7Rbzq8Ssuiae5LhXkrJ Or7N+7XXnHdeepnUXoeoEk32Jy+CYRMQq7i9y9HBoZJAlPSKxsR2M+BTU4d+Wv+hgSHR sM7m6rC39DSBZMZeUxdJyEn71d5eDHWZbsENhWC85EqBKUy9N9bFDNzV/ngOz5xSXXuC YuTSyWi3CqX8tE0dsjkd7hs4LaCh6MiNMdva8XeCQFjGOs0NWV4Pk23P0Xsq/QxNS2TQ 1tyDvsC0K4tlW8OxGv0+CB3NKSpo8UnXAm22ueGogzHdu09k8lPb5vDN1Rw2tCUzC7Mw sWyA==
X-Gm-Message-State: ANhLgQ0/qBnkyWByHi30poDmyUnYUd5aNcFzACBuRxewVvCafZFuxBMs KrESgBf/WlvLEUFOWpbfWO3zfUgB9w4a4SOpfSLByg==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsnCGc/eDKCREU8YeA8lvJDEnSfDgsM/er0Buyd?= =?utf-8?q?IhKvZl90XDNnn9qVKTfR9xdHxryGxWU+/pPMKVa2/z17glw=3D?=
X-Received: by 2002:adf:b601:: with SMTP id f1mr519322wre.103.1583167967981; Mon, 02 Mar 2020 08:52:47 -0800 (PST)
MIME-Version: 1.0
References: <158267113813.11133.3835985962594781644.idtracker@ietfa.amsl.com> <D11F6A3B-BC9F-41C4-AF7D-52AF5A48A195@lodderstedt.net> <20200302010341.GZ98042@kduck.mit.edu> <E3486BD5-7977-4100-AFDC-1EDAA269E101@lodderstedt.net>
In-Reply-To: <E3486BD5-7977-4100-AFDC-1EDAA269E101@lodderstedt.net>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Tue, 3 Mar 2020 01:53:03 +0900
Message-ID: <CAHdPCmOk407OUTbR9nU2XTOZdy8ZZoXXXE-3gw+CDamaAtzPPQ@mail.gmail.com>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: Benjamin Kaduk <kaduk@mit.edu>, oauth-chairs@ietf.org, The IESG <iesg@ietf.org>, oauth <oauth@ietf.org>, draft-ietf-oauth-jwt-introspection-response@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005a02ff059fe204ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yAJcipCRiop04m2GpgUy6u40n7o>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
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, 02 Mar 2020 16:52:56 -0000

Hi Torsten,

draft-ietf-oauth-jwt-introspection-response-08 says as follows.

*The "jti" claim is a unique identifier for the access token passed in the
introspection request.  This identifier MUST be stable for all
introspection calls for a given access token.*


This requirement expects that the second introspection call with the same
access token will receive a response including the same "jti" value
("abc234567") as was included in the first response. That is, the first JWT
(the first introspection response) and the second JWT (the second
introspection response) have the same jti value. This is what Ben pointed
out.

The requirement for "jti" described
in draft-ietf-oauth-jwt-introspection-response-08 is problematic.

Taka


On Mon, Mar 2, 2020 at 11:19 PM Torsten Lodderstedt <torsten=
40lodderstedt.net@dmarc.ietf.org> wrote:

> Hi Ben,
>
> >>
> >>>
> >>> I don't think the new semantics for "jti" in the introspection response
> >>> are compatible with the RFC 7519 definition.  Specifically, we say that
> >>> "jti" will be tied to the input access token, but 7519 says that "jti"
> >>> has to change when the contents of the JWT change ("MUST be assigned in
> >>> a manner that ensures that there is a negligible probability that the
> >>> same value will be accidentally assigned to a different data object"),
> >>> and we admit at least the possibility of "active" and "iat" changing.
> >>
> >> I think the key word is “accidentally”. This spec causes the AS to
> purposefully issue JWTs with the same “jti” in order to allow replay
> detection with respect to the introspected access token. “iat” is changed
> in order to give the RS an indication and proof when the introspection
> response was minted by the AS.
> >
> > I think "accidentally" is just there to emphasize that there's a risk of
> > accidental collision when using a random string as an identifier, since
> "of
> > course you wouldn't deliberately reuse a token identifier".  This stance
> > seems to supported by "[t]he 'jti' (JWT ID) claim provides a unique
> > identifier for the JWT".  It's really hard for me to read that sentence
> as
> > allowing the use of a single identifier for two different JWT values,
> since
> > it then ceases to be a *unique* identifier.
> >
> > I seem to have forgotten how this replay detection is supposed to work;
> > would you mind giving me a pointer and/or refresher?
>
> Sure.
>
> 1) Let’s assume a client obtains access token “123456789”, which obviously
> is a handle the RS needs to resolve using Introspection.
> 2) The RS calls the introspection endpoint, the AS looks up the access
> token data and responds with a JWT formatted introspection response
> (including a fresh jti “abc234567”).
> 3) The RS stores the jti in its replay cache (long with the tokens max
> lifetime)
>
> 4) The client calls the RS again using the same token “123456789”
> 5) The RS calls the introspection endpoint again, the AS looks up the
> access token data and responds with a JWT formatted introspection response
> (including a fresh jti “abc8912345”).
> 6) The RS compares the jti with its replay cache, no hit - it thinks all
> is good and performs the requested transaction.
>
> But it just accepted the same token for the 2nd time.
>
> If the AS would have created JWT formatted introspection responses with
> the same jti, the RS would had a cache hit in step (6) and refused the
> request.
>
> >
> >>
> >> “Active" does not really change, since the introspection response of an
> inactive token is empty except the “active” element.
> >
> > I mean, the token artifact still changes.  What am I supposed to
> interpret
> > "the JWT" as meaning if not the actual encoded artifact?
>
> Sorry I don't understand. Can you please elaborate?
>
> >
> >> So I don’t see issues regarding RFC 7519.
> >>
> >>>
> >>> Section 5 says that:
> >>>
> >>>  If the access token is considered active, it MUST contain the claims
> >>>  "iss" and "aud" in order to prevent misuse of the JWT as an ID or
> >>>  access token (see Section 8.1).
> >>>
> >>> But I don't think the predicate is correct -- misuse is still possible
> >>> by services that do not check the "active" claim's value.  Shouldn't
> the
> >>> "iss"+"aud" requirements be unconditional?
> >>
> >> Introspection responses for inactive tokens won’t contain any data
> except “active”:false. I don’t see how they could be misused and therefore
> think the text is ok.
> >
> > Could you give me a pointer where in the text it says that if "active" is
> > false, no other claims are present?  ("active" only appears three times,
> > but none of them seem to say this.)
>
> Jaap Francke already gave you the pointer.
> @Jaap: thanks.
>
> best regards,
> Torsten.
>
> >
> > -Ben
> >
> >> Please let me know whether you agree with my statements. I would then
> quickly publish a new revision (including changes to address your comments).
> >>
> >> best regards,
> >> Torsten.
> >>
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>> COMMENT:
> >>> ----------------------------------------------------------------------
> >>>
> >>> [New comments on the added text in the diff from -07 to -08.]
> >>>
> >>> Section 3
> >>>
> >>>  To support encrypted token introspection response JWTs, the
> >>>  authorization server MUST also be provided with the respective
> >>>  resource server encryption keys and algorithms.
> >>>
> >>> IIRC, based on some list discussion this text was going to be tweaked
> to
> >>> avoid implying that JWE is mandatory.  (Unfortunately, this is the
> >>> thread that evolved into "client certs and TLS Terminating Reverse
> >>> Proxies", so it's hard to be sure whether I saw any other followups.)
> >>>
> >>>  The AS MUST restrict the use of client credentials by a RS to the
> >>>  calls it requires, e.g. the AS MAY restrict such a client to call the
> >>>  token introspection endpoint only.  How the AS implements this
> >>>  restriction is beyond the scope of this specification.
> >>>
> >>> This should probably be clarified a bit more, in the context of "client
> >>> credentials tend to be used by privileged, fixed endpoints, and the
> >>> default may just be to allow them all access to all endpoints".  Right
> >>> now it's not clear what's being restricted (and who "it" is that
> >>> requires calls)
> >>>
> >>> Section 5
> >>>
> >>>  This specification registers the "application/token-
> >>>  introspection+jwt" media type, which is used as value of the "typ"
> >>>  header parameter of the JWT to indicate that the payload is a token
> >>>  introspection response.
> >>>
> >>> Do we also want to note that checking 'jti' is not mandatory and so
> this
> >>> does not necessarily provide full protection?  (I guess Section 8.1
> >>> covers this in more detail.)
> >>>
> >>>  The value of the "aud" claims MUST identify the resource server
> >>>  receiving the token introspection response.
> >>>
> >>> We may want to dig into this a bit more: should there be any
> >>> relationship between this "aud" value and the "client_id" that an RS
> >>> might be using (as obtained from dynamic registration)?
> >>> Does this value need to be different from the audience that is used in
> >>> access tokens for which this RS is the audience?  (Should it be the
> >>> same?)  My instincts lean towards "different" but I would like broader
> >>> input.
> >>>
> >>>  exp     The "exp" claim indicates when the access token passed in the
> >>>          introspection request will expire.
> >>>
> >>> On the face of it this seems divergent from RFC 7519's "the expiration
> >>> time on or after which the JWT MUST NOT be accepted for processing",
> >>> though upon further examination the distinction is not quite so large.
> >>> That is, it's in effect saying that the introspection response should
> >>> not be accepted for processing after the base token has expired, which
> >>> usually makes sense.  There is a bit of a complication, though, in that
> >>> the "active" claim implies that we might still have RSes that plan to
> >>> use the introspection response after the "exp" date has passed, which
> >>> sounds a lot like a DISCUSS-level internal inconsistency.
> >>>
> >>>  If possible, the AS MUST narrow down the "scope" value to the scopes
> >>>  relevant to the particular RS.
> >>>
> >>> This sounds kind of like a "SHOULD"...
> >>>
> >>>  The example response header contains the following JSON document:
> >>>
> >>> I think this is the JOSE header in the HTTP response (body), not the
> >>> (HTTP) response header.
> >>>
> >>> Section 8.1
> >>>
> >>>  As an alternative approach, such an attack can be prevented like any
> >>>  other token substitution attack by restricting the audience of the
> >>>
> >>> I'd suggest avoiding describing these as "alternatives"; they seem more
> >>> like complementary approaches as part of a defense-in-depth solution
> >>> (especially since we are basically mandating both of them).
> >>>
> >>>  "aud" value set to the resource server's identifier.  Any recipient
> >>>  of an JWT MUST check these values in order to detect substitution
> >>>  attacks.
> >>>
> >>> This "MUST" might be out of place -- this is a requirement from RFC
> >>> 7519, and not an attempt by this document to make new requirements on
> >>> the behavior of all JWT consumers (if it was, that would be a DISCUSS
> >>> point!).
> >>>
> >>>  Resource servers MUST additionally apply the countermeasures against
> >>>  replay as described in [I-D.ietf-oauth-security-topics], section 3.2.
> >>>
> >>> In a similar vein, which set of resources servers is this normative
> >>> "MUST" intended to be binding upon?
> >>>
> >>> Section 9
> >>>
> >>>  In any case, the AS MUST ensure that the scope of the legal basis is
> >>>  enforced throughout the whole process.  The AS MUST retain the scope
> >>>  of the legal basis with the access token, e.g. in the scope value,
> >>>  and the AS MUST determine the data a resource server is allowed to
> >>>  receive based on the resource server's identity and suitable token
> >>>  data, e.g. the scope value.
> >>>
> >>> I suspect I'm just being dense, but could you walk me through how the
> >>> access token "scope" value can encode the legal basis for data
> transfer?
> >>>
> >>>
> >>>
> >>
> >
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>