Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

John Bradley <ve7jtb@ve7jtb.com> Fri, 10 July 2015 15:36 UTC

Return-Path: <ve7jtb@ve7jtb.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 4645A1B29E6 for <oauth@ietfa.amsl.com>; Fri, 10 Jul 2015 08:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 IueUSTjoJmxD for <oauth@ietfa.amsl.com>; Fri, 10 Jul 2015 08:36:28 -0700 (PDT)
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (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 5FEBC1B2850 for <oauth@ietf.org>; Fri, 10 Jul 2015 08:36:28 -0700 (PDT)
Received: by qkhu186 with SMTP id u186so209375577qkh.0 for <oauth@ietf.org>; Fri, 10 Jul 2015 08:36:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0FK3XIcoQbkA/oHFln/gY4Ddv9iFm5wcIYowNYz2uvc=; b=WWU47TlFVxU6OtWCpKhYZXQs583n5phlyYhEFvcDLxOBfAo15kyhyTO7g2fiPou/Qr JZQjBf/2qojWSyFA0WO4B/83s4HitRiNxtzw9An/XuU9Fm6+M3pz+6PHTiU1zhkmZgDs OhcKap++uZf9h7PwHeNGCm7+I+9bRfEPYT5OF5InwORJ3FrXhDQ4VJZJ46GeP/8LpmyM ov8pZt0EaFYOmvpcahoDp/5Cn0pCXo6cYlZwEROc4B1IZS/mAwBWqSqKIwil5iZ+l9Kf zmdI4QCzptEz+x+Adg5IEhCdecFYTYXotF1lacd9zo5uMdy+BnaEGZrJFd7m9zkA1t4R boSA==
X-Gm-Message-State: ALoCoQnWf+JmDbcU//35VGHPmsimpSoSpIz8+5tKbBoKcz7IZSeRU2zs+WnMkvIPGAlJGfQaKXW8
X-Received: by 10.55.17.197 with SMTP id 66mr13884906qkr.90.1436542587548; Fri, 10 Jul 2015 08:36:27 -0700 (PDT)
Received: from [192.168.1.216] (181-163-3-125.baf.movistar.cl. [181.163.3.125]) by smtp.gmail.com with ESMTPSA id h49sm5901767qgd.24.2015.07.10.08.36.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jul 2015 08:36:26 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7FE08EE0-24AE-487C-9A00-75D90C7CDB34"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CAHbuEH6wotjbkb-jWxHMA+xxA-paw6e7Svbqqh6JGj-4giZtbw@mail.gmail.com>
Date: Fri, 10 Jul 2015 12:36:18 -0300
Message-Id: <E495F04D-0DE7-489B-8F8C-443AA20D5E4C@ve7jtb.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> <CA+k3eCSLqwY2hF459oJU2d+tW6J5yKOVzN=3DSvWp+c-UoDNUw@mail.gmail.com> <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> <CAHbuEH6wotjbkb-jWxHMA+xxA-paw6e7Svbqqh6JGj-4giZtbw@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/SLkLXF-Pm39tHOt6wDBdvqc5Zmo>
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: Fri, 10 Jul 2015 15:36:32 -0000

Yes I believe I I addressed these comments as part of Barry’s discuss points.  
They were comments on the changes that Barry introduced that caused a inconsistency.   I resolved that in 15.

I think it is good to go.


> On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> John,
> 
> The updates were included in the version I approved for posting that also addressed Barry's discuss points, correct?
> 
> Are we good with the current version to move forward:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/>
> 
> Thank you,
> Kathleen
> 
> On Thu, Jul 9, 2015 at 2:46 PM, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
> I have made some edits to make it consistent.  They are checked into the butbucket repo nat and I use, but we can’t update the official draft during the freeze before the IETF meeting.
> 
> https://bitbucket.org/Nat/oauth-spop <https://bitbucket.org/Nat/oauth-spop>
> 
>> On Jul 9, 2015, at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
>> 
>> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/ <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 <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 <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 <http://tools.ietf.org/>.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen