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

Benjamin Kaduk <> Fri, 10 August 2018 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF713130FC5; Fri, 10 Aug 2018 14:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jaPqgYeiUQ3x; Fri, 10 Aug 2018 14:26:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 475BA12F1A5; Fri, 10 Aug 2018 14:26:54 -0700 (PDT)
X-AuditID: 12074425-d6fff70000006a4e-09-5b6e031bf11a
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 8B.83.27214.C130E6B5; Fri, 10 Aug 2018 17:26:52 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w7ALQngM018684; Fri, 10 Aug 2018 17:26:50 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w7ALQjUr005599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2018 17:26:47 -0400
Date: Fri, 10 Aug 2018 16:26:45 -0500
From: Benjamin Kaduk <>
To: Brian Campbell <>
Cc:, The IESG <>,,
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixCmqrCvDnBdtsHmXosXq/zcZLc5NfcZq sfXvJEaLGX8mMlt8WPiQxYHVY8mSn0wed49eZPF4+Uo8gDmKyyYlNSezLLVI3y6BK2P3neWM BbN0Kw52zGNuYOxV6WLk4JAQMJE4e76mi5GLQ0hgMZPEhaYeZghnI6PE+R/HmboYOYGcq0wS TW3xIDaLgKpE//cLjCA2m4CKREP3ZWYQW0RAX+L20znsIDazQJ3Ego/vWUEWCAs4SSz9kAkS 5gXa9bpvJiPE/LOMErcfPGGHSAhKnJz5hAWiV0di59Y7bCC9zALSEsv/cUCE5SWat84GW8Up ECjx4dERsHJRAWWJvX2H2CcwCs5CMmkWkkmzECbNQjJpASPLKkbZlNwq3dzEzJzi1GTd4uTE vLzUIl0LvdzMEr3UlNJNjKDAZ3dR3cE456/XIUYBDkYlHt4LG3OjhVgTy4orcw8xSnIwKYny Wt4BCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhzTQFyvGmJFZWpRblw6SkOViUxHnv14RHCwmk J5akZqemFqQWwWRlODiUJHizmfKihQSLUtNTK9Iyc0oQ0kwcnCDDeYCGO4DU8BYXJOYWZ6ZD 5E8xWnLMOzp1EjPHn/cgcl/3tEnMQix5+XmpUuK8HCANAiANGaV5cDNBiUwie3/NK0ZxoBeF efNBqniASRBu6iughUxAC7M1Qb4pLklESEk1MGaodMqLsZxWLpr7kOGSW/6cL7MPnntfIdy0 Tvu4qVndynNdHhVn8z9MPR3Xd87yR4vZdi1W8e/52vHHjOyyQmLYV9ZMzTuXUhhjeedH37bw L9LF/rJbJqqu8f0Yo77z9TdhnpNCv5nbdFojdvz/FDT99j72Y2UxDhPapa0vsQqK1124paDl o8RSnJFoqMVcVJwIAAnjypE/AwAA
Archived-At: <>
Subject: Re: [secdir] Security review of draft-ietf-oauth-token-exchange-14
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Aug 2018 21:26:57 -0000

On Fri, Aug 10, 2018 at 01:36:11PM -0600, Brian Campbell wrote:
> 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
> 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.

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?


> Thanks,
> Brian
> ---------- Forwarded message ---------
> > From: Hilarie Orman <>
> > Date: Wed, Aug 8, 2018 at 1:47 AM
> > Subject: Security review of draft-ietf-oauth-token-exchange-14
> > To: <>rg>, <>
> > Cc: <>
> >
> >
> > 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
> >
> >
> -- 
> _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._