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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 10 July 2015 16:59 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 5C7881B2A5B for <oauth@ietfa.amsl.com>; Fri, 10 Jul 2015 09:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 KMOyp_ibneN4 for <oauth@ietfa.amsl.com>; Fri, 10 Jul 2015 09:59:09 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (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 A077E1B2A4B for <oauth@ietf.org>; Fri, 10 Jul 2015 09:59:07 -0700 (PDT)
Received: by wgjx7 with SMTP id x7so253993706wgj.2 for <oauth@ietf.org>; Fri, 10 Jul 2015 09:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C+PKIuefV3Q5ZmQDlSzpY7eP61VXFBa9eAvcb6+aBX0=; b=gIRIr7r78KEZdhUECcFC7r1RwYSCk+JNUQdfZUotalMTWkHtG2d5J0GjMtI1mNhReO IDZL0uVS2FFc4uIn7CuZTlGlwm9myjZNSQlJ9fEEvLZQv/QA5EEAjs+LQF02oVkEGX+h 5KPBxEVL/g4uOMuWS5u8Ofv0K5Ilf+vmx741L6oyj2CiBblN1ZhGz4w4Q0UxL0ID8ImH jj2E7oGr55XifsZDuUDekE4lSQ5FSDIS4yj74RboF06EF3RoVCHho8+VbwIkp1Nhggur 88ghnFfR4Q2yK8KoIH+cAFJh1p4Ks8CXtOW9Bc9h3sah/M71ZDBBEIobBc2PYL9lcjnM AOZg==
MIME-Version: 1.0
X-Received: by 10.180.86.168 with SMTP id q8mr7577172wiz.80.1436547546437; Fri, 10 Jul 2015 09:59:06 -0700 (PDT)
Received: by 10.28.31.194 with HTTP; Fri, 10 Jul 2015 09:59:06 -0700 (PDT)
In-Reply-To: <CAAP42hALxzoTCz2vTe+_U_QQhbnMP__mn17qGBMyQQ4-9Vftrg@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> <CA+k3eCSLqwY2hF459oJU2d+tW6J5yKOVzN=3DSvWp+c-UoDNUw@mail.gmail.com> <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> <CAHbuEH6wotjbkb-jWxHMA+xxA-paw6e7Svbqqh6JGj-4giZtbw@mail.gmail.com> <E495F04D-0DE7-489B-8F8C-443AA20D5E4C@ve7jtb.com> <CA+k3eCRfmEHQzVSaUQHDfTaSqrWjPgp+xSsDjONF=HaFp=iiPw@mail.gmail.com> <CAHbuEH4fC2QaCUxOjAUWJ-6mJZDcc29pG3FxLkjJrpRZRzDdsg@mail.gmail.com> <CAAP42hALxzoTCz2vTe+_U_QQhbnMP__mn17qGBMyQQ4-9Vftrg@mail.gmail.com>
Date: Fri, 10 Jul 2015 12:59:06 -0400
Message-ID: <CAHbuEH5xhkw120TkX3sdqSJfoofeP1_GwCiDYVvgk8-AUyFYpA@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: William Denniss <wdenniss@google.com>
Content-Type: multipart/alternative; boundary="bcaec5555030355e05051a884a2c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/fTrWzx3fOLvi0i5dSh_IM4f6Uic>
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 16:59:13 -0000

Thank you all for your work on this draft!



On Fri, Jul 10, 2015 at 12:57 PM, William Denniss <wdenniss@google.com>
wrote:

> Looks good to me. I think it's a lot clearer now, thanks for the update
> John.
>
> Unrelated, I noticed a typo in "7.5.  TLS security considerations", the
> word 'Curent'.
>
> On Fri, Jul 10, 2015 at 9:33 AM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
>> Thanks, Brian!
>>
>> William? Are you good with this version?
>>
>> On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell <
>> bcampbell@pingidentity.com> wrote:
>>
>>> I think -15 does address the inconsistency.
>>>
>>> On Fri, Jul 10, 2015 at 9:36 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>
>>>> 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/
>>>>
>>>> Thank you,
>>>> Kathleen
>>>>
>>>> On Thu, Jul 9, 2015 at 2:46 PM, John Bradley <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
>>>>>
>>>>> On Jul 9, 2015, at 3:19 PM, Brian Campbell <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>
>>>>> 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 mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Kathleen
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>


-- 

Best regards,
Kathleen