Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

Neil Madden <neil.madden@forgerock.com> Fri, 25 May 2018 10:49 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 A5990126DC2 for <oauth@ietfa.amsl.com>; Fri, 25 May 2018 03:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 nkwbPdMPi8kD for <oauth@ietfa.amsl.com>; Fri, 25 May 2018 03:49:46 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 A0E02126D85 for <oauth@ietf.org>; Fri, 25 May 2018 03:49:46 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id x9-v6so8432157wrl.13 for <oauth@ietf.org>; Fri, 25 May 2018 03:49:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mxuz63i8lZKDGG6JEmdUrkcEoFxRlCQdix3pMSi+Lx4=; b=DEQlmFP8HGLSYMf/nFutIIyqN0yVXEBgubyMpjg+dSii2MMDw6RdRkNtPZtGHQhLos QDSIV2SvpJZZSkE6Vr5xMDX3TSVAn3WzEq9ZxDWTmqaCZNBPbQ8CCDvARA0Vm4zxkUc9 HIUuzk1gEn3lo0RfGCpkBJdM39KweumkTaqkQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mxuz63i8lZKDGG6JEmdUrkcEoFxRlCQdix3pMSi+Lx4=; b=Rz322uY9d/5BT+ApfmQXJ4P1M3h3mf8ZkGJCm1RH553kymZ09eabxsRVjZXv/E+06G PFO3uyUESjvgbKnf+eKfUgBZehUvxqJ4NXLGybZBG5W1CbXhGf/Dpjbaqfiu3m1nQDW1 GZe8OIGesKpqB7Oz4vHLHnz6cSufI7xGlZVLFlezyk97WFXytjwj0T8NG2BUHC2lXRfR ROk+kGUC8IkxFluwUY2xf4YPWG5u4J871peIwEnsWH8dU17ioQ/f96+uWBuv+eT8/a5C B/nTWa/jiABJ/Vrj9vMFM5HW9vXFiEiyXocCP5T8eKKdbGNImhrQr4vfWxFuZ4jg083Z EULg==
X-Gm-Message-State: ALKqPwf3vRUtTZL210Ic12neVLD15SMFs8McsF0EiHSgvhb39U7wnzsL SFMSlZkkg0cySis2w7Ke9T+RnpZLY8g=
X-Google-Smtp-Source: AB8JxZrki1Yj3OnkxA1DJPG53tiqMyYtkBee50O+/6GerY49Y7CBaFtcCCXP+urhLM35fqLn8FXuRQ==
X-Received: by 2002:adf:b722:: with SMTP id l34-v6mr1848455wre.85.1527245384675; Fri, 25 May 2018 03:49:44 -0700 (PDT)
Received: from guest2s-mbp.lan (235.91.125.91.dyn.plus.net. [91.125.91.235]) by smtp.gmail.com with ESMTPSA id u8-v6sm5829819wmc.40.2018.05.25.03.49.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 May 2018 03:49:43 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <D395D8A6-EEC5-43B3-90FF-B9828DEEA43D@forgerock.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_96FA6BD7-D847-45CA-B22C-BB80D839940B"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Fri, 25 May 2018 11:49:41 +0100
In-Reply-To: <90B044A3-14E2-4125-9A81-F49BEA144EF3@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <1452DCC9-3D8A-42E5-94A4-87B5D2B291AC@forgerock.com> <90B044A3-14E2-4125-9A81-F49BEA144EF3@lodderstedt.net>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2oEjGnZdtl-BcfrAsxPnAfVrjLk>
Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 25 May 2018 10:49:50 -0000

Hi Torsten,

> On 25 May 2018, at 10:35, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> 
> Hi Neil,
> 
>> Am 28.03.2018 um 17:41 schrieb Neil Madden <neil.madden@forgerock.com>om>:
>> 
>> I like this draft, but I want to clarify if it is intended that the response JWT could be interpreted as an OpenID Connect ID Token? As the set of claims can overlap (in particular, all required ID token claims are valid token introspection response fields) and it seems highly likely that an AS will use the same keys for signing both (and it definitely will when the client_secret is used for signing), the signed response JWT could well be indistinguishable from an ID token (for the resource owner) with some additional claims.
> 
> Conceptually, the introspection response, an ID Token and even structured access tokens are quite the same if they carry user identifiers or claims. They identify the respective user account towards RP or RS and provide additional attributes, which, for example, can be used to meet access control decisions. And if JWT is the representation, they are also syntactically (nearly) equivalent. The main difference I see that an ID Token may contain a nonce, which is not required in access tokens.

Are they the same? An ID token authenticates (claims about) a user to the RP. I don’t think that is the intended interpretation of a token introspection response, and it’s not the purpose of an access token. My point is that as specified they can be syntactically identical and yet intended for different purposes.

> 
>> 
>> If this is not the case, then maybe consider adding a “crit”: [“scope”] claim to the response (https://tools.ietf.org/html/rfc7515#section-4.1.11) to indicate that the scope claim must be understood.
> 
> What do you want to achieve/prevent?

The sorts of issues discussed in https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03#section-2.7

As I said in a follow-up email, “crit” does not actually work here as it only applies to headers. If we wanted to distinguish them, we could use explicit typing as recommended in the BCP: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03#section-3.11 and have a type of “introspection+jwt” or something like that (with an appropriate media type registration).

> 
>> 
>> I can think of one potential use-case (I’ll let you decide the merits of it) where it might actually be useful to explicitly allow the response to be an ID Token. Consider an application (RS) that uses a traditional authorization model: it authenticates a user, sets a cookie, and then based on who that user is makes dynamic access control decisions to see what they are allowed to do (e.g., ACLs, RBAC, whatever). An easy way to upgrade this app to modern standards would be to replace the home-spun authentication system with OIDC, but leave the rest in place. Now the system uses OIDC to authenticate the user, sets the ID token as the cookie, and then still applies the same access control decisions that it always has done.
>> 
>> Now imagine that a new requirement comes in to support OAuth 2.0 access tokens to allow delegation to third-party apps. A really simple way to achieve that would be to put a filter/reverse proxy in front of the RS that extracts access tokens coming in, performs signed JWT token introspection against the AS to validate the token and then checks the the scopes are appropriate for the request. It can then simply replace the access token in the original request with the signed token introspection response (as ID token) and forward it on to the original RS server. As the introspection response is a valid ID token for the resource owner, the RS will then apply all its normal access control checks to ensure that the resource owner actually has the permissions that they have delegated to the client.
>> 
>> I think potentially that is quite an interesting application of this draft, but I don’t think it was intended! I think probably a decision should be made as to whether that kind of usage should be allowed and explicitly adjust the draft to either allow or deny it. If it is allowed, then possibly there should be a way for the caller to hint that they want the response to be a valid ID token.
> 
> I don’t currently see a way the introspection response could be abused as ID Token other than the recipient of the response (or an attacker able to obtain the response object) sets up a fake IDP and provides the response as an ID token to a RP. The RP should be able to detect this (as other ways to replay ID tokens) by utilizing the nonce.

As a client I can go and get an access token with some scope “a”. I now hit the token introspection endpoint and get back a signed JWT. That signed JWT happens to be syntactically identical to an OIDC ID Token and the AS happens to use the same key to sign both. So now I effectively have an ID Token for that user, although I never requested the “openid” scope. OK, so I don’t have an access token with the right scopes to hit the UserInfo endpoint, and I learn nothing that I could not get from a normal introspection response, but still it feels a bit surprising to me.

Furthermore, as the “aud” claim in the token introspection response is optional, and it has no nonce, I *might* be able to replay this JWT in other situations to other parties. For instance, if I can find an OIDC RP that does not use or validate nonces correctly (they are optional), then I may be able to use it to log in as the user at that other RP.

I don’t think these are huge issues as they depend on RPs already being careless about validation (e.g., ignoring a missing audience claim), but they are the sort of non-obvious interactions between components where security issues often crop up, so I want to ensure the possibility has been considered by the WG and an informed decision made either way.

I would be happy if we just made the “aud” and “iss” claims mandatory in this spec (they are optional in RFC 7662), and require that the protected resource is in the audience.

— Neil