Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt
Brian Campbell <bcampbell@pingidentity.com> Thu, 09 July 2015 18:20 UTC
Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB651B2B16 for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2015 11:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 b-2aerIbwGS9 for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2015 11:20:27 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 9CF9B1A1BCD for <oauth@ietf.org>; Thu, 9 Jul 2015 11:20:27 -0700 (PDT)
Received: by igrv9 with SMTP id v9so229782702igr.1 for <oauth@ietf.org>; Thu, 09 Jul 2015 11:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZKXFGUeEjTuEYSfLaLgpoe357E2LYgqNy8xyPw1LXHk=; b=PAtt0p9/8nJNM01fEoKiwTw0t35QlVskhlQzKuE6sZhF/zyH8/GalpTELfUQworb+o kNxT+XIbK2KqOBAmDd7jp5ficThW+9ERixN6p2xLWreBCpCd9bhYpMpzrJddxdi+DrsL C6351Z5ou0J3ausXEn9ad9NoOrldMVb7jQqp4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZKXFGUeEjTuEYSfLaLgpoe357E2LYgqNy8xyPw1LXHk=; b=LUH8SAN0B8qV9MMmdXPXJaeTFkhoY9J7GgFjBbIIQmoQ0hESjISVOsWi//kuR5KsV2 HSXcdedbFSoAQaGQy5lK7SD1T789t+MgfLFF90iD4I87pbWByv1uHWSRIbvTRwMX52rw WUPmwTCvV+G1d0Nf2kUtRPd9NjJvmctThIAn8POmkkpdv4a/nl1iM36DWC4iewPmuZs0 VfN3JPq8dVaO4MMvrKvebdhpVLPVBlX9xXXQBmWcfpdSqSgdAX6JyvnXAtwYCxB/v6s9 owP88vKfkH2hDjVp4eXe5ZLhraaNJt2PMBNdbNWpZ9RCpd5UcQ8u3gW+xoGlGd8+4fku 0C8A==
X-Gm-Message-State: ALoCoQlV3Lrvhj4oMKB6i/wlv5+dBt+onDL6/8oLAnMKe7iayQwRcag9YKqFdaPalzG+hgjecNmt
X-Received: by 10.107.165.206 with SMTP id o197mr29586472ioe.2.1436466027008; Thu, 09 Jul 2015 11:20:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.96.199 with HTTP; Thu, 9 Jul 2015 11:19:57 -0700 (PDT)
In-Reply-To: <CAAP42hA9B4HNURC6wZ+KBLre-VCXSz_BROZ6qcjSQ0ZTX4YC-w@mail.gmail.com>
References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <CAAP42hD=CXnWUgQ5b=cgtqp2TkOgXWQ89yZtyEJe9_19K+72Mw@mail.gmail.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> <CAAP42hDMH9gc97aa3-hjrLuRyFsc3j8tmSwDee-oJvMn4dxsAg@mail.gmail.com> <CAAP42hA9B4HNURC6wZ+KBLre-VCXSz_BROZ6qcjSQ0ZTX4YC-w@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 09 Jul 2015 12:19:57 -0600
Message-ID: <CA+k3eCSLqwY2hF459oJU2d+tW6J5yKOVzN=3DSvWp+c-UoDNUw@mail.gmail.com>
To: William Denniss <wdenniss@google.com>
Content-Type: multipart/alternative; boundary="001a1141507445b5d0051a754fbc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/AlkzR5eS6-G0gyI94O7xYptRuwM>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2015 18:20:31 -0000
I agree with William that it's a little confusing. I get that there's a desire to discourage using "plain" but perhaps the language (especially the MUST NOT in 7.2) should be lightened up just a bit? On Wed, Jul 8, 2015 at 8:22 PM, William Denniss <wdenniss@google.com> wrote: > Following up the discussion on today's NAPPS call, I understand why plain > is not presented as the recommended approach in the spec (though it still > has some value over not doing PKCE at all, in that it mitigates against the > current known attack where a rogue app registers the same custom URI scheme > as another), but I feel that after all the back and forth the picture is a > little confusing. > > In particular, 4.2 and 4.4.1 include some examples where plain is > supported: > > 4.2 >> Clients SHOULD use the S256 transformation. The plain transformation is >> for compatibility with existing deployments and for constrained >> environments that can't use the S256 transformation. >> > > > 4.4.1. >> If the client is capable of using "S256", it MUST use "S256", as "S256" >> is Mandatory To Implement (MTI) on the server. Clients are permitted to use >> "plain" only if they cannot support "S256" for some technical reason and >> knows that the server supports "plain". > > > But then 7.2 is very vocal that it MUST NOT be used for new > implementations: > > 7.2 >> Because of this, "plain" SHOULD NOT be used, and exists only >> for compatibility with deployed implementations where the request path >> is already protected. The "plain" method MUST NOT be used in >> new implementations. > > > What if those new implementations are constrained, as indicated in 4.2 > and 4.4.1? > > > Also, while S256 is clearly indicated as MTI, little is said about > "plain", although it's alluded to that it's not MTI in 4.4.1 ("and knows > that the server supports "plain""). > > Should we be more explicit upfront that "plain" is optional for servers to > support, if that's the intention? > > > On Tue, Jul 7, 2015 at 10:51 PM, William Denniss <wdenniss@google.com> > wrote: > >> t_m works for me, I just think we should have some indication that it's >> the name of the transform. Will you also update where it is referenced in >> the description below Figure 2? >> >> >> >> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <ve7jtb@ve7jtb.com> wrote: >> >>> Thanks, I fixed my finger dyslexia for the next draft. >>> >>> I changed it to t_m rather than “t” I think that is clearer. If I were >>> to do it the other way XML2RFC would have double quotes in the text version. >>> >>> John B. >>> >>> On Jul 7, 2015, at 9:38 PM, William Denniss <wdenniss@google.com> wrote: >>> >>> In version 14, there's a typo on this line ("deso") in Section 7.2: >>> >>> `"plain" method deso not protect` >>> >>> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>> >>> `+ t(code_verifier), t` >>> >>> I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` >>> (note the quotes on the second 't') given that it's a string representation >>> of the method that's being sent? >>> >>> >>> On Mon, Jul 6, 2015 at 4:05 PM, <internet-drafts@ietf.org> wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Web Authorization Protocol Working >>>> Group of the IETF. >>>> >>>> Title : Proof Key for Code Exchange by OAuth Public >>>> Clients >>>> Authors : Nat Sakimura >>>> John Bradley >>>> Naveen Agarwal >>>> Filename : draft-ietf-oauth-spop-14.txt >>>> Pages : 20 >>>> Date : 2015-07-06 >>>> >>>> Abstract: >>>> OAuth 2.0 public clients utilizing the Authorization Code Grant are >>>> susceptible to the authorization code interception attack. This >>>> specification describes the attack as well as a technique to mitigate >>>> against the threat through the use of Proof Key for Code Exchange >>>> (PKCE, pronounced "pixy"). >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
- [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.t… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… William Denniss
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… John Bradley
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… William Denniss
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… William Denniss
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… John Bradley
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… Kathleen Moriarty
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… John Bradley
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… Kathleen Moriarty
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… William Denniss
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-… Kathleen Moriarty