[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: 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-token-exchange/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It looks like allocations in the OAuth URIs registry are merely
"Specification Required", so we should not have the expectation of WG
exclusivity and thus are squatting on unallocated values here.
Process-wise, that's not great and the IESG shouldn't approve a document
that is squatting on codepoints.

why do we allow both client authentication (i.e., using an
actor token) and a distinct actor_token request parameter?  Is it
supposed to be the case that the actor_token parameter is only supplied
for delegation flows?  If so, that needs to be made explicit in the
document.

Are the privacy considerations (e.g., risk of a tailed per-request
error_uri) relating to the use of error_uri discussed in some other
document that we can refer to from this document's security
considerations?  (I say a bit more about this in my COMMENT.)

Section 2.1 has:
   audience
      OPTIONAL.  The logical name of the target service where the client
      intends to use the requested security token.  This serves a
      purpose similar to the "resource" parameter, but with the client
      providing a logical name rather than a location.  Interpretation
      of the name requires that the value be something that both the
      client and the authorization server understand.  An OAuth client
      identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an
      OpenID Connect Issuer Identifier [OpenID.Core], or a URI are
      examples of things that might be used as "audience" parameter
      values.  [...]

How does the STS know what type of identifier it is supposed
to interpret the provided audience value as?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The document could perhaps benefit from greater clarity as to whether
"security token"s refer to inputs, outputs, or both, of the token
endpoint (for the interactions defined in this specification).

Section 1

                                                            The OAuth
   2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens
   [RFC6750] have emerged as popular standards for authorizing third-
   party applications access to HTTP and RESTful resources.  [...]

nit: possessive "applications'"

Section 1.1

This section really jumps in quickly with no lead-in to why we would
care or transition from the introduction.  I suggest:

  One common use case for an STS (as alluded to in the previous section)
  is to allow a resource server A to make calls to a backend service C on
  behalf of the requesting user B.  Depending on the local site policy and
  authorization infrastructure, it may be desireable for A to use its own
  credentials to access C along with an annotation of some form that A is
  acting on behalf of B ("delegation"), or for A to be granted a limited access
  credential to C but that continues to identify B as the authorized
  entity ("imperesonation").  Delegation and impersonation can be useful
  concepts in other scenarios involving multiple participants as well.

Section 2.1

                                                  For example, [RFC7523]
   defines client authentication using JSON Web Tokens (JWTs) [JWT].

Please clarify that these are still bearer tokens.

   The supported methods of client authentication and whether or not to
   allow unauthenticated or unidentified clients are deployment
   decisions that are at the discretion of the authorization server.

It seems appropriate to note that omitting client authentication allows
for a compromised token to be leveraged via an STS into other tokens by
anyone possessing the compromised token, and thus that client
authentication allows for additional authorization checks as to which
entities are permitted to impersonate or receive delegations from other
entities.

   The client makes a token exchange request to the token endpoint with
   an extension grant type by including the following parameters using
   the "application/x-www-form-urlencoded" format with a character
   encoding of UTF-8 in the HTTP request entity-body:

Is there more to say than "just use UTF-8"; any normalization or
canonicalization issues to consider?

   subject_token
      REQUIRED.  A security token that represents the identity of the
      party on behalf of whom the request is being made.  Typically, the
      subject of this token will be the subject of the security token
      issued in response to this request.

nit: I think there's a subtle grammar mismatch here, where we start off
by talking about a/the request and end up with "this request".

   In processing the request, the authorization sever MUST validate the
   subject token as appropriate for the indicated token type and, if the
   actor token is present, also validate it according to its token type.

I misread this the first time around; I'd suggest something like
"perform the appropriate validation procedures for the indicated token
type" (as opposed to just verifying that the presented token is a
syntactically valid instance of the claimed type).

   In the absence of one-time-use or other semantics specific to the
   token type, the act of performing a token exchange has no impact on
   the validity of the subject token or actor token.  Furthermore, the
   validity of the subject token or actor token have no impact on the
   validity of the issued token after the exchange has occurred.

Do we really want this strong of a statement?  I suspect that in many
environments propagating, e.g., expiration time to the exchanged
credential may be desired.

Section 2.2.1

   token_type
[...]
      contents of the token itself.  Note that the meaning of this
      parameter is different from the meaning of the "issued_token_type"
      parameter, which declares the representation of the issued
      security token; the term "token type" is typically used with this
      meaning, as it is in all "*_token_type" parameters in this
      specification. [...]

Please disambiguate what "typically used with this meaning" means.
Perhaps it would be even more clear to change this field's name to
"token_access_token_type" to match the name of the registry?

Section 2.3

   The following example demonstrates a hypothetical token exchange in
   which an OAuth resource server assumes the role of the client during
   token exchange in order to trade an access token that it received in
   a protected resource request for a token that it will use to call to
   a backend service (extra line breaks and indentation in the examples
   are for display purposes only).

We could maybe add some commas or parentheses to help the reader group
the various clauses properly.  E.g., it is "(trade an access token (that
it received in a protected resource request)) for a token...", not
"trace an access token that it received (in a protected resource request
for a token)", where parentheses indicate logical grouping.

    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
    &resource=https%3A%2F%2Fbackend.example.com%2Fapi%20
    &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
    &subject_token_type=
     urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

                     Figure 2: Token Exchange Request
Is there really supposed to be a %20 in the resource query parameter's
value?

The token octets in Figures 3 and 4 do not match up, despite the prose
indicating that they are the same token.

Section 3

Would it be appropriate to note (here or elsewhere) that for non-JWT
token formats that are a binary format, the URI used for conveying them
needs to be associated with the semantics of base64 (or otherwise)
encoding them for usage with OAuth?

                                                Token Exchange can work
   with both tokens issued by other parties and tokens from the given
   authorization server.  [...]

Does "work with" mean "accept as input" or "produce as output" or both?
For input, as both subject_token and actor_token?

   The following token type identifiers are defined by this
   specification.  Other URIs MAY be used to indicate other token types.
I'd also link to the registry here.

Why is the text about "urn:ietf:params:oauth:token-type:jwt" formatted
differently than the other URIs listed?

Section 4.1

Do we want to consider a more self-describing subject identifier scheme,
akin to
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers ?

The example in Figure 5 appears to be using the "implicit issuer"
behavior wherein the "iss" of the actor's "sub" is assumed to be the
same value as in the containing structure.  I'm not a fan of this type
of behavior in general, but if it's going to be used, you need to
document the possibility in some fashion.

I might also consider some language about how "the nested "act" claims
serve as a history trail that connects the initial request and subject
through the various delegation steps undertaken before reaching the
current actor.  In this sense, the current actor is considered to
include the entire authorization/delegation history, leading naturally
to the nested structure described here".  (But see also the other ballot
comment about this potentially leaking information to unauthorized
parties; it seems a more careful adjustment of the text is in order
here.)

Section 4.2

Is this really the first time we're defining "scope" as a JWT claim?  I
would have thought that would be defined long ago...

Section 4.4

Just to double-check: this is "things that can act as me" (where "me" is
the subject of the token containing this field), right?  The
parenthetical "May Act For" doesn't really help me decide whether this
claim represents the source or target of a permitted delegation, so
maybe "Allowed Impersonators" or similar would be more clear.  Even "act
as" or "act on behalf of" instead of "act for" would help me, I think.
[This would have trickle-down effects to later parts of the document as
well, e.g., the IANA Considerations.]
(Not that I claim to be a representative population, of course!)

It would probably also help greatly to note that when a subject_token is
presented to the token endpoint in a token exchange request, the
"may_act" claim in the subject token can be used by the authorization
service to determine whether the client (or party identified in the
actor_token) is authorized to engage in the requested delegation [or
impersonation].

Section 6

Let me say a bit more here about my perception of the potential privacy
considerations involved in the use of an error_uri (so we can figure out
if they are already discussed in a relevant document that we can cite;
JWT itself doesn't seem to cover this topic).  By sending an error_uri
instead of an error string, the server is in effect causing the client
to make an outbound request to a URL of the server's choosing.  If there
is a proxy between the client and server, this could result in the
server (and/or a party controlled by the server) learning additional
information about the client's identity/location.  A malicious server
could also attempt to construct a URI that, when retrieved by the
client, performs some unwanted side effect.  Defenses against this
latter scenario are pretty well known in the web comunity, but we may
want to be sure that the need for them is mentioned in a discoverable
place.

Appendix A.1.1

   In the following token exchange request, a client is requesting a
   token with impersonation semantics. [...]

What part of the request indicates that impersonation semantics are
requested?

Is the use of the "jwt" subject_token_type appropriate, given the
previous discussion about id_token/access_token being generally
preferred (as conveying more meaning)?