[secdir] Security review of draft-ietf-oauth-token-exchange-14
"Hilarie Orman" <hilarie@purplestreak.com> Wed, 08 August 2018 07:47 UTC
Return-Path: <hilarie@purplestreak.com>
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 A6BE8126CB6; Wed, 8 Aug 2018 00:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 BwDv42fzl98x; Wed, 8 Aug 2018 00:47:17 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B22130DC9; Wed, 8 Aug 2018 00:47:13 -0700 (PDT)
Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from <hilarie@purplestreak.com>) id 1fnJBZ-0006B7-1d; Wed, 08 Aug 2018 01:47:13 -0600
Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from <hilarie@purplestreak.com>) id 1fnJBX-0007Ly-C4; Wed, 08 Aug 2018 01:47:12 -0600
Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w787kdal021070; Wed, 8 Aug 2018 01:46:39 -0600
Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id w787kd74021069; Wed, 8 Aug 2018 01:46:39 -0600
Date: Wed, 08 Aug 2018 01:46:39 -0600
Message-Id: <201808080746.w787kd74021069@rumpleteazer.rhmr.com>
From: Hilarie Orman <hilarie@purplestreak.com>
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
To: iesg@ietf.org, secdir@ietf.org
Cc: draft-ietf-oauth-token-exchange.all@ietf.org
X-XM-SPF: eid=1fnJBX-0007Ly-C4; ; ; mid=<201808080746.w787kd74021069@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-AID: U2FsdGVkX1+yDEGh9rIDbtCD+LPE3ziU
X-SA-Exim-Connect-IP: 72.250.219.84
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: *;iesg@ietf.org, secdir@ietf.org
X-Spam-Relay-Country:
X-Spam-Timing: total 1348 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.6 (0.3%), b_tie_ro: 2.5 (0.2%), parse: 1.25 (0.1%), extract_message_metadata: 6 (0.5%), get_uri_detail_list: 2.5 (0.2%), tests_pri_-1000: 4.7 (0.3%), tests_pri_-950: 2.1 (0.2%), tests_pri_-900: 1.77 (0.1%), tests_pri_-400: 27 (2.0%), check_bayes: 25 (1.9%), b_tokenize: 9 (0.7%), b_tok_get_all: 7 (0.5%), b_comp_prob: 3.9 (0.3%), b_tok_touch_all: 2.9 (0.2%), b_finish: 0.81 (0.1%), tests_pri_0: 1294 (96.0%), check_dkim_signature: 0.90 (0.1%), check_dkim_adsp: 7 (0.5%), tests_pri_500: 3.4 (0.3%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4Y4OulAJcDrQzaIK3x0LWIVvXSg>
Subject: [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: Wed, 08 Aug 2018 07:47:19 -0000
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
- [secdir] Security review of draft-ietf-oauth-toke… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-oauth-… Brian Campbell
- Re: [secdir] Security review of draft-ietf-oauth-… Benjamin Kaduk
- Re: [secdir] Security review of draft-ietf-oauth-… Brian Campbell
- Re: [secdir] Security review of draft-ietf-oauth-… Brian Campbell