Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 04 Sep 2019 14:13:10 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection

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-resource-indicators/

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

Thank you for this easy-to-read-document -- reducing the risk of using
bearer tokens seems worthwhile, since they are not going away very
quickly.

Abstract

This seems to be a sentence fragment (maybe preface with "This document
specifies"?).

Section 1

                                                           When the
   authorization server is informed of the resource that will process
   the access token, it can restrict the intended audience of that token
   to the given resource such that the token cannot be used successfully
   at other resources.

(This mechanism is only effective if the other resources are
checking in some fashion, whether by direct inspection of a structured
token or by a backchannel to the AS or otherwise, but I hope that
checking 'aud' is standard practice by now!)

Section 2.1

   For authorization requests sent as a JWTs, such as when using JWT
   Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single
   "resource" parameter value is represented as a JSON string while
   multiple values are represented as an array of strings.

jwsreq includes an example with "aud" in the request, yet this new
"resource" request parameter is also intended to influence the audience
of the resulting token.  I'm not sure whether we need to say anything
specifically about this in the document, but I'd like to have a better
understanding of how "aud" and "resource" would interact when both
present in the reqeust.
(This is presumably related to why the request parameter is called
"resource" and not "aud" or "audience", but unfortunately I seem to have
zoned out for that part of the WG discussion.)

   If the client omits the "resource" parameter when requesting
   authorization, the authorization server MAY process the request with
   no specific resource or by using a pre-defined default resource
   value.  [...]

Would/could this default value be global or on a per-scope basis or some
other finer granularity than global?

                                                                     The
   authorization server might use this data to inform the user about the
   resources the client is going to access on her behalf, to meet policy
   decision (e.g. refuse the request due to unknown resources), and
   determine the set of resources that can be used in subsequent access
   token requests.

nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/
(or similar), and "to" before "determine" for parallelism.

In Figure 1 we URL-encode the '.'s in "client.example.org" but not in
"api.example.com" in the request URL; should we be consistent?  (This
seems to be recurring throughout the examples.)

Section 2.2

   needs to know.  This further improves privacy as scope values give an
   indication of what services the resource owner uses and downscoping a
   token to only that which is needed for a particular service can limit
   the extent to which such information is revealed across different
   services.  As specified in Section 5.1 of [RFC6749], the

(nit?) I suggest to s/scope values give an indication of what services
the resource owner uses and/a list of scope values is an indication that the
resource owner uses the multiple various services listed;/ since I
misparsed it the first time as-is.

Section 3

   An access token that is audience restricted to a protected resource
   that obtains that token legitimately cannot be used to access
   resources on behalf of the resource owner at other protected
   resources.  The "resource" parameter enables a client to indicate the

nit: This sentence has a pretty strange construction.  I think the
intent is to say that that a token, legitimately presented to a
resource, cannot then be taken by that resource server and
illegitimately present it somewhere else for access to other resources.
But with the current wording we seem to be missing part of the part
where some entity obtains the token with intent for illegitimate access.

   Some servers may host user content or be multi-tenant.  In order to
   avoid attacks that might confuse a client into sending an access
   token to a resource that is user controlled or is owned by a
   different tenant, it is important to use a specific resource URI
   including a path component.  This will cause any access token issued
   for accessing the user controlled resource to have an invalid
   audience if replayed against the legitimate resource API.

I'm not entirely sure what this is trying to say.  What is the
"legitimate resource API"?  Why would a token be issued for accessing a
user-controlled resource if that's something we're trying to avoid
having confused clients access?

   Although multiple occurrences of the "resource" parameter may be
   included in a request, using only a single "resource" parameter is
   encouraged.  A bearer token that has multiple intended recipients
   (audiences) indicating that the token is valid at more than one
   protected resource can be used by any one of those protected
   resources to access any of the other protected resources.  Thus, a
   high degree of trust between the involved parties is needed when
   using access tokens with multiple audiences.  Furthermore an
   authorization server may be unwilling or unable to fulfill a token
   request with multiple resources.

Do we want to contrast this with an authorization code/refresh token,
which may be more likely to be issued with a multiple-resource/audience
property?

---

From: Brian Campbell <[email-masked]>
Date: Wed, 4 Sep 2019 17:19:27 -0600

Thanks Ben, for the review and non-objectional ballot.

> COMMENT:

Hrm. Yeah, I suppose so. I guess I was trying to be efficient with the
words but to the point of not having a complete sentence. I'll add that
preface.

> zoned out for that part of the WG discussion.)

In the context of a jwsreq request the "aud" indicates the intended
recipient/audience of the singed authorization request itself, which will
be the authorization server to whom the request is being made. This
prevents a singed request meant for AS1 from being used successfully at
AS2, for example. That "aud" does not do anything to influence the audience
of the resulting token - it's really just metadata of the signed request
that will be discarded once the singed request is validated. The "resource"
parameter of this document indicates where the client intends to use the
token its requesting, which can and will influence the audience of the
resulting token. So "aud" and "resource" do not interact when both present
in a signed authorization request.

And yes, this is related to why the request parameter is called "resource"
and not "aud" and also I think related to the outstanding discuss you have
on jwsreq. If this parameter were to have been called "aud" then there
would be a name collision when used in conjunction with jwsreq where "aud"
would have had two distinct and irreconcilable meanings at the same time.
There are a few other reasons the WG landed on "resource" as the name but
what you've alluded to up here was a big part of it.

> other finer granularity than global?

Yes, it could be any of those. Though I think most likely it'd be global or
influenced by scope. Really, it'd be whatever that AS was doing in the
absence of such a parameter before this document came along.

> (or similar), and "to" before "determine" for parallelism.

Okay, will do.

> seems to be recurring throughout the examples.)

Shoot. I really do aim to be tighter with that kind of thing well before
getting to the IESG evaluation phase. I suspect some copy/paste/change work
along with not looking closely enough got the better of me here. I'll fix
to use not-encoded '.'s throughout.

> misparsed it the first time as-is.

Sure. Striving to avoid the ol' misparse is always good.

> where some entity obtains the token with intent for illegitimate access.

Yes, despite the pretty strange construction, you have the correct intent.
I'll work on improving that sentence (borrowing heavily from your words
there).

> having confused clients access?

Um... so on rereading that I might say that it's also "pretty strange".

What it was trying to somehow say is similar to the previous nit about
audience-restricted not being usable at the resource for whom the weren't
intended. But saying so in the context of a multi-tenant environment.
Basically it's trying to say that, in a multi-tenant environment, the
resource URI and subsequent token audience need to have something that
identifies the tenant so as to prevent the token from being used by one
tenant to illegitimately access resources at a different tenant. I'll work
on trying to improve that text to better explain all that.

> which may be more likely to be issued with a multiple-resource/audience

Yeah, it's perhaps worth making the distinction. Though I don't know that
it needs to be explicitly contrasted per se. I think just qualifying the
text above to more specifically say "... parameter may be included in a
token request" (as apposed to authorization request) would be enough to
indicate that the suggestion is only applicable to the access token and not
authorization code/refresh token.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Sep 2019 18:55:32 -0500

> in a signed authorization request.

Ah, of course; thanks for the refresher, and that makes perfect sense.

> what you've alluded to up here was a big part of it.

Agreed.

> absence of such a parameter before this document came along.

Very true :)

> on trying to improve that text to better explain all that.

Ah, yes, that's a very good point to make.  I'm happy to look at some draft
text if you want.

> authorization code/refresh token.

Sure; we don't need to overemphasize it.

Thanks,

Ben

---

From: Brian Campbell <[email-masked]>
Date: Wed, 4 Sep 2019 18:17:32 -0600

> Ah, yes, that's a very good point to make.  I'm happy to look at some draft

Thanks, here's what I've got now for this and the previous item in sec 3.
Suggestions welcome.

3.  Security Considerations

   An audience-restricted access token, legitimately presented to a
   resource, cannot then be taken by that resource to present it
   elsewhere for illegitimate access to other resources.  The "resource"
   parameter enables a client to indicate the protected resources where
   the requested access token will be used, which in turn enables the
   authorization server to apply the appropriate audience restrictions
   to the token.

   Some servers may host user content or be multi-tenant.  In order to
   avoid attacks where one tenant uses an access token to illegitimately
   access resources owned by a different tenant, it is important to use
   a specific resource URI including any portion of the URI that
   identifies the tenant, such as a path component.  This will allow
   access tokens to be audience-restricted in a way that identifies the
   tenant and prevent their use, due to an invalid audience, at
   resources owned by a different tenant.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Sep 2019 12:53:20 -0500

>    elsewhere for illegitimate access to other resources.  The "resource"

I think "by that resource and presented elsewhere" probbaly has a more
parallel flow.

>    resources owned by a different tenant.

But other than the above nit, this all looks really good; thank you!

-Ben

---

From: Brian Campbell <[email-masked]>
Date: Thu, 5 Sep 2019 12:43:19 -0600

thanks and done

On Thu, Sep 5, 2019 at 11:53 AM Benjamin Kaduk <[email-masked]> wrote:

> > > > >    resources.  The "resource" parameter enables a client to
> indicate
> > > the
> > > > >