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