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

Brian Campbell <> Fri, 10 August 2018 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE346130F69 for <>; Fri, 10 Aug 2018 12:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gU6Y_E4-tkrw for <>; Fri, 10 Aug 2018 12:36:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E7E2130F6D for <>; Fri, 10 Aug 2018 12:36:39 -0700 (PDT)
Received: by with SMTP id 139-v6so4213543itf.0 for <>; Fri, 10 Aug 2018 12:36:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=osB3l8oZTJKQ5xDLyX55a6/LgGySCPzIVv1kLKW9EoY=; b=hVNf2ITQosp9ZXVxei0UUaTiX+5yjXbd0HLABhstT2aiDG8pnDF7gjcB7KclIu46qV ZNw5xI4o+PaIsC8l/BB1Qirt1SK+JY4jYqagmD6/ds1/b83NKITE/y2D/nd612NoCN0s 3DbvCkF6OW98dgmGWNm3PPlk76fJ7iaZPw2ug=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=osB3l8oZTJKQ5xDLyX55a6/LgGySCPzIVv1kLKW9EoY=; b=WRQCG0DN/W1vUxwYRsopPDGP2EIYx8BK82wrMAdCilCZ4B+YZ2nA6yUj2wtFeig4oY Z8j8npZ7ubLOLENfC4O+Z5rkLNLeES9946jn5rtcQM8Kl5mKEkelP7seV38Htb3ziLfx D7yEr8xRimPVaZWoYwlGzIRu/s1Z79c0glqXppAfm2gldXDXHs7bnrj0E7EFD+j03U7N 7e6sdipk3Knrg7Az+VKON4LOqBkV9SLqDbrv7IWlvZrk9ZD1nVWYhzllUlRGzY+N77X3 WSGhiKy9KFqNgMJx/O+5Tmtnh0xghxWcTQ8BFqrN4O8cXYR+lHAjo8eDuFMVzLf3Dfs7 xRuA==
X-Gm-Message-State: AOUpUlGcwyNlAN4UViGFXdimP171jrn6xSgu29hUjs8YvxNY0wkOENPq 1Hx1Dc/ng9cmpQ47fdvAvmeri0d5oA5DNfM3OXYPn6y5LhXovFftXZnVgD3NZkpvqTphZX9gtxV N7FlJpKq3FORNno4=
X-Google-Smtp-Source: AA+uWPxIbCtl7S1HTJ7ezASxbeUG//FHDoKnK+xPloRtW3A+w+OLAHqwT4Zn62xwjMmcXPN6PMJJHMOd9GU+v5IRnp4=
X-Received: by 2002:a24:ed0c:: with SMTP id r12-v6mr3400980ith.37.1533929798081; Fri, 10 Aug 2018 12:36:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Fri, 10 Aug 2018 13:36:11 -0600
Message-ID: <>
Cc: The IESG <>,,
Content-Type: multipart/alternative; boundary="000000000000b9c229057319dc5b"
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 19:36:42 -0000

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.


---------- 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._