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

Benjamin Kaduk <kaduk@mit.edu> Fri, 10 August 2018 21:26 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF713130FC5; Fri, 10 Aug 2018 14:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaPqgYeiUQ3x; Fri, 10 Aug 2018 14:26:54 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 475BA12F1A5; Fri, 10 Aug 2018 14:26:54 -0700 (PDT)
X-AuditID: 12074425-d6fff70000006a4e-09-5b6e031bf11a
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.83.27214.C130E6B5; Fri, 10 Aug 2018 17:26:52 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w7ALQngM018684; Fri, 10 Aug 2018 17:26:50 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (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 <kaduk@mit.edu>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: hilarie@purplestreak.com, The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-oauth-token-exchange.all@ietf.org
Message-ID: <20180810212645.GU40887@kduck.kaduk.org>
References: <201808080746.w787kd74021069@rumpleteazer.rhmr.com> <CAAX2Qa2GB9srzCarcfZcx8oyB2K7jFS=MK4vdZU9XQFbRgr=OQ@mail.gmail.com> <CA+k3eCT_q6sqSJrLav+LOctkE_ophdsp1Egm2YEzL3Ld3QrVfg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+k3eCT_q6sqSJrLav+LOctkE_ophdsp1Egm2YEzL3Ld3QrVfg@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/secdir/Axj9uFsSDVfCKso97IvgBSP_3kM>
Subject: Re: [secdir] Security review of draft-ietf-oauth-token-exchange-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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
> 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.

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

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