Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT)
Justin Richer <jricher@mit.edu> Wed, 04 September 2019 20:00 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 40A16120CA6; Wed, 4 Sep 2019 13:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 KBbg-TtHkkV7; Wed, 4 Sep 2019 12:59:56 -0700 (PDT)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 DA491120B56; Wed, 4 Sep 2019 12:59:55 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x84JxZpX021128; Wed, 4 Sep 2019 15:59:42 -0400
Received: from oc11expo8.exchange.mit.edu (18.9.4.13) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 4 Sep 2019 15:58:38 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo8.exchange.mit.edu (18.9.4.13) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 4 Sep 2019 15:59:32 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 4 Sep 2019 15:59:32 -0400
From: Justin Richer <jricher@mit.edu>
To: Benjamin J Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, "draft-ietf-oauth-jwt-introspection-response@ietf.org" <draft-ietf-oauth-jwt-introspection-response@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>
Thread-Topic: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT)
Thread-Index: AQHVYd/+guOgpm1lFkSXlmUoiSGPGqccNdcA
Date: Wed, 04 Sep 2019 19:59:32 +0000
Message-ID: <47A41441-F1A9-4401-BBF3-74CA1F178A0B@mit.edu>
References: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com>
In-Reply-To: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_47A41441F1A94401BBF374CA1F178A0Bmitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ToWwl8V2kj-PWFelmHNZg0iJYVk>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (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: Wed, 04 Sep 2019 20:00:01 -0000
One of the issues I have with the current structure aligns with Ben’s comments below — we have two things that feel token-ish, the input token and the resulting JWT response. However, the JWT in the response is not actually a :token: in the OAuth sense. Instead, it’s an assertion that carries payload information :about: a token. The response itself isn’t a token and shouldn’t be treated as a token unto itself. — Justin On Sep 2, 2019, at 6:44 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Per the ongoing discussion on the WG list, it's unclear that we can retain the behaviors we describe and still comply with the requirements of RFC 7519 requirements for being a JWT (e.g., regarding "jti", "iat", etc.). That is, in the present formulation, there are two "token"s involved -- the input that is being introspected, and the "token" that is the introspection response. We are claiming that certain fields are describing the input token, when they are defined to be statements about the current (response) token. Relaxing our statements to say that we merely use JWS as opposed to JWT may be a workaround, though I have thought about it hard enough to have an opinion on whether it is the best workaround. I also think we need more clarity about the use of dynamic client registration by a resource server as outlined in Section 4 (where it's mentioned as "with a resource server posing as the client", without reference to RFC 7591. As far as I can tell this document/section is introducing this use of dynamic client registration by an RS for the first time, so we cannot easily just refer to some other document. Specifically, are there any fields that MUST NOT be supplied? Is a human-readable client_name useful? How does the supplied client_uri need to relate to any existing AS representation of a resource in audience, scope, etc. (e.g., for the "resource" request parameter from draft-ietf-oauth-resource-indicators)? Is this usage considered to be a "new use of JWTs"? If so, it seems that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and use explicit typing. I think there are some missing links in the document between a RS registring client policy and the resulting AS enforcement of encryption of introspection reponses. I think the intent is roughly that the policy will be applied based on the audience of the token being presented for introspection (as opposed to the identity of the RS-as-client making the introspection request), but we don't seem to explicitly say that. Also, we'd need to say something about the interaction of multiple RSs' policy when a given token has multiple valid audiences. There is a very brief discussion in Section 6.5, but it seems to be more of a description of what is possible than mandating particular forms of enforcement. I think we should discuss whether we want some statement from the OpenID Foundation or related bodies before we register claims that point to their documents with the IESG listed as change controller. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- idnits notes that RFC 5646 is mentioned but not present in the references section. Section 1 We probably need to move the 7519 reference up here to where JWT is first used. OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token. This allows deployments to implement identifier-based access tokens in an interoperable way. Does "identifier-based access tokens" mean "tokens that are opaque keys to a (central) database lookup" or "access tokens that convey user identity information" (or something else)? We may want to tweak the wording. Section 3 Can we double-check the base64 form of the response in this example? I am seeing output that backslash-escapes the '/' characters in URLs, which I did not think was needed in this context. I also see an "extension_field" claim in the base64 but not the decoded form of the example, and "given_name"/"family_name"/"birthdate" in the decoded example vs. "username" in the base64 version. Note: If the resource server policy requires a signed and encrypted response and the authorization server receives an unauthenticated request containing an Accept header with content type other than "application/jwt", it MUST refuse to serve the request and return an HTTP status code 400. This is done to prevent downgrading attacks to obtain token data intended for release to legitimate recipients only (see Section 6.2). I'd suggest a forward-reference to section 4 for how the AS will know the RS's policy. Although, given that "unauthenticated request" is included in the preconditions, perhaps we do not need the conditional on "resource server policy" at all? Section 4 The authorization server determines what algorithm to employ to secure the JWT for a particular introspection response. This decision can be based on registered metadata parameters for the resource server, supplied via dynamic client registration with the resource server posing as the client, as defined by this draft. nit: I suggest s/posing as the/acting as a/, and s/by this draft/below/, since it's right here in this section. introspection_encrypted_response_alg OPTIONAL. JWE [RFC7516] algorithm ("alg" value) as defined in JWA [RFC7518] for encrypting introspection responses. If this is specified, the response will be encrypted using JWE and the configured algorithm. The default, if omitted, is that no encryption is This text is slightly confusing with respect to the interaction between the introspection_encrypted_response_alg "alg" value and the introspection_encrypted_response_enc "enc" value. My understanding is that the "enc" is a symmetric bulk encryption scheme that directly protects the payload, whereas the "alg" is a key-wrap or key-agreement mechanism used to establish the key used as input for the "enc" method. So, while "algorithm ("alg value") for encrypting introspection responses" and "the response will be encrypted using the confugred ["algo"] algorithm" are technically true, they're also a bit misleading, since this is not what encrypts the "bulk" of the response. Using the term from RFC 7158, "key management algorithm", would probably alleviate this confusion. Resource servers may register their public encryption keys using the "jwks_uri" or "jwks" metadata parameters. Should we cite 7591 for these (or, really, the whole section)? We don't currently mention it until the IANA considerations. Section 5 Is it worth a note that resource servers will fetch these metadata and use them as input to their dynamic registrations in the previous section (i.e., picking from the list of supported algorithms)? introspection_encryption_alg_values_supported OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms ("alg" values) as defined in JWA [RFC7518] supported by the introspection endpoint to encrypt the response. Similarly to the above, some refined text about "key management algorithm" used to encrypt the response, would probably be helpful. Section 6 There seem to be notable privacy considerations about quite a few of the claims registered in Section 8.3. Section 6.1 I'm surprised to not see discussion of explicit typing (and, IIUC, how it's not a reliable mitigation) here. JWT introspection responses and OpenID Connect ID Tokens are syntactically similar. An attacker could therefore attempt to impersonate an end-user at a OpenID Connect relying party by passing the JWT as an ID token. nit: "response JWT" or "JWT response" Such an attack can be prevented like any other token substitution attack. The authorization server MUST include the claims "iss" and "aud" in each JWT introspection response, with the "iss" value set to the authorization server's issuer URL and the "aud" value set to the resource server's identifier. [...] Related to the Discuss point, how does this relate to the dynamic client registration parameters? [OpenID.Core]. Relying parties SHOULD also use and check the "nonce" parameter and claim to prevent token and code replay. Is this SHOULD just referring to the behavior already described in OpenID.Core (and only applicable to OIDC implementations as opposed to JWT-instrospection consumers)? If so, maybe descriptive language is more appropriate, like "Relying parties are also expected to use and check [...]". Resource servers utilizing JWTs to represent self-contained access tokens could be susceptible to replay attacks. Resource servers should therefore apply proper counter measures against replay as described in [I-D.ietf-oauth-security-topics], section 2.2. I'm not sure what part of this is specific to the introspection case. Is it supposed to be tied to the risk that JWT-instrospection produces a new route for the generation of JWT objects that could be confused for self-contained access tokens? nit: "countermeasures" is valid as a single word. nit: it looks like it's section 3.2, now. Section 6.2 Please cite RFC 7525 as BCP 195 as well as RFC 7525 (e.g., "per BCP 195 [RFC7525]"). To prevent introspection of leaked tokens and to present an additional security layer against token guessing attacks the authorization server may require all requests to the token introspection endpoint to be authenticated. As an alternative or as an addition to the authentication, the intended recipients may be set up for encrypted responses. Do we want to make either of these "may"s into normative recommendations (or make a recommendation for prevention of introspection data leakage even in the face of token leakage, which can be satisfied by either mechanism)? Also, we could say more about how configuring encryption for intended recipients protects against unencrypted replies to unintended recipients... In the latter case, confidentiality is ensured by the fact that only the legitimate recipient is able to decrypt the response. An attacker could try to circumvent this measure by requesting a plain JSON response, using an Accept header with the content type set to, for example, "application/json" instead of "application/jwt". To prevent this attack the authorization server MUST NOT serve requests with content type other than "application/jwt" if the resource server is set up to receive encrypted responses (see also Section 3). ....such as by saying that the introspection response will only be made available to RSes that are intended recipients of (in the audience of?) the access token being introspected. Section 6.3 Authorization servers with a policy that requires token data to be kept confidential from OAuth clients must require all requests to the token introspection endpoint to be authenticated. As an alternative or as an addition to the authentication, the intended recipients may be set up for encrypted responses. [this also seems to be assuming a link not stated between RS policy and AS enforcement, but it seems unlikely that a fix would need to touch this text] Section 8.1.1 nit: using nested lists might make this more readable. o Client Metadata Description: String value specifying the desired introspection response encryption algorithm (alg value). [same bit about "key management algorithm"] Section 8.2.1 o Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response encryption (alg value). [and here] Section 8.3 I think we should make some mention earlier in the document (Introduction?) that we also register some common claim values that are in use in the wild (or whatever text you feel is appropriate to describe the claims in question). The nested lists would be great here as well. Is there any expectation that some combination of "given_name", "middle_name", and "family_name" will produce identical content to the full "name" claim? o Name: "preferred_username" o Description: Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. It seems like there may be some security considerations about sanitziing this field before using it in an application's logic. o Name: "profile" o Description:URL of the End-User's profile page. The contents of this Web page SHOULD be about the End-User. It's slightly surpising to see this claimed for the end-user's profile when it might equally apply to a protocol profile or variant in use. But I assume this is already deployed, so there's no real point in objecting to its registration... o Name: "birthdate" o Description:Time the End-User's information was last updated. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. This seems potentially confusable with the user's day/year of birth. (Also, are leap seconds excluded?) o Name: "zoneinfo" o Description: String from zoneinfo [zoneinfo] time zone database representing the End-User's time zone. For example, Europe/Paris or America/Los_Angeles. We seem to be missing the actual reference entry for [zoneinfo]. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Justin Richer
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Torsten Lodderstedt