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

[William Denniss <[e-mail]>]

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 <
[e-mail]> wrote:

> Thanks, Brian!
>
> William? Are you good with this version?
>
> On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell <
> [e-mail]> wrote:
>
>> I think -15 does address the inconsistency.
>>
>> On Fri, Jul 10, 2015 at 9:36 AM, John Bradley <[e-mail]> 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 <
>>> [e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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 <[e-mail]>
>>>> 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 <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>>> 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 <[e-mail]>
>>>>>>> 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, <[e-mail]> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>>
>>>
>>
>
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>