Subject: [secdir] Security review of draft-ietf-oauth-token-exchange-14

From: "Hilarie Orman" <[email-masked]>
Date: Wed, 8 Aug 2018 01:46:39 -0600

Security review of draft-ietf-oauth-token-exchange-14
OAuth 2.0 Token Exchange

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

The abstract states:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.

[This review is late because I mistook the due date, 
dd-mm-yyyy = 06-08-2018 
for 
mm-dd-yyyy = 06-08-2018
and ignored the mm because obviously it is August and just focused on
the day.  Which goes to show that it is important to understand what
a message means.]

I'm not at all sure I understand what the various fields in the new
OAuth 2.0 tokens really mean.  For example, section 4.1 about Actor
Claims says that a web application might receive a token expressing
that subject "admin" is acting for subject "user".  The web
application could "exchange" that token for a new one showing itself
as the actor for "user".  As a "chain of delegation", this is
confusing.  It would seem that the original token could be used to
access resources, and the "exchange" of one token for another is not
necessary.

The complications of delegation and "impersonation" and "may act for"
aside, section 7 (Privacy) seems to open a can of worms.  Tokens may
"reveal details of the target services" and thus may give away
information about what the subject is doing or intends to do.  But the
subject must send the token in order to access the resource.  What is
a rational privacy policy for Oauth tokens?  Will clients find it
expedient to include all their tokens in every request?  How does a
client know which tokens a server can be trusted with?  The document
suggests that the tokens should only be communicated according to the
privacy policies of the "respective organizations".  How do two
organizations communicate their privacy policies to one another?
This section needs some amplification.

The document is well-written, but the subject is complex.  

Hilarie

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Aug 2018 13:36:11 -0600

Hi Hilarie and thank you for the review.

In looking again at the example in section 4.1 about nested Actor Claims I
agree that the scenario depicted by the example is confusing and rather
unrealistic. I'll endeavor to produce a better example in the next revision
of the draft.  I think perhaps showing a chain of delegation where the
actors are different systems rather than mixing users and systems would be
more straightforward.

So to be totally forthright, the Privacy Considerations section was written
in response to a single but persistent mailing list commenter who was
objecting to this (and other drafts for that matter) on the grounds that
details of services being accessed and personal information may be revealed
to the entities involved. But as you've noted, that's kinda fundamental to
how this stuff works - the token is obtained and sent in order to access
the resource. The Privacy Considerations text was basically just a
compromise noting that the concerns had been heard but so the draft could
move forward. Like many compromises, I don't know that anyone was
particularly happy with this one. I don't think the text really adds any
value - would simply removing it close that can of worms? Or would perhaps
incorporating some text similar to what's in
https://tools.ietf.org/html/rfc7523#section-7 be helpful here? I honestly
don't know that much more concrete can be said about it. But I'm certainly
open to suggestions, should you have them.

Thanks,
Brian

---------- Forwarded message ---------
> From: Hilarie Orman <[email-masked]>
> Date: Wed, Aug 8, 2018 at 1:47 AM
> Subject: Security review of draft-ietf-oauth-token-exchange-14
> To: <[email-masked]>, <[email-masked]>
> Cc: <[email-masked]>
>
>

-- 
_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: Fri, 10 Aug 2018 16:26:45 -0500

> open to suggestions, should you have them.

With the disclaimer that I haven't read token-exchange recently and am
mostly going off my memory of the mailing list discussions, it seems like
the key consideration here is that token exchange allows you to convert a
token that may be opaque to you into one that has inspectable fields, and
those fields can be privacy sensitive.  So a JWT response should only be
given to a requestor that trusted to know such information; a lot of the
time, that has large overlap with being trusted to have the token in the
first place, but potentially there is some amount of non-overlap.

The considerations from 7523 of course also apply, and sensitive
information should not be sent over unencrypted channels, but isn't the
above paragraph an aspect inherently new to token exchange?

-Benjamin

---

From: Brian Campbell <[email-masked]>
Date: Mon, 13 Aug 2018 11:36:49 -0600

On Fri, Aug 10, 2018 at 3:26 PM Benjamin Kaduk <[email-masked]> wrote:

> ...

I don't think it's unique to token exchange. RFC 7523, for example, defines
the use of a JWT as an authorization grant used to obtain an access token
from a authorization server. Unless encrypted as a JWE, the JWT in that
scenario has fields that are inspectable to the client. And an OAuth access
token is considered opaque to the client but whether or not information in
the token is actually accessible to a client is an implementation detail of
the authorization server. The latter is true for OAuth in general and not
just these more specialized exchanges.

The idea behind maybe incorporating some text similar to (but adapted to
the context) what's in the privacy considerations of RFC 7523
<https://tools.ietf.org/html/rfc7523#section-7> is that the considerations
are pretty much the same - use TLS in transit, minimize the amount of
information in the token, encrypt the token if disclosure of its
information to the client is a concern.