[OAUTH-WG] Protocol Action: 'Proof Key for Code Exchange by OAuth Public Clients' to Proposed Standard (draft-ietf-oauth-spop-15.txt)

[The IESG]

The IESG has approved the following document:
- 'Proof Key for Code Exchange by OAuth Public Clients'
  (draft-ietf-oauth-spop-15.txt) as Proposed Standard

This document is the product of the Web Authorization Protocol Working
Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/





Technical Summary

   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.

Working Group Summary

  The working group last call for this document was started 
  soon after the document was adopted as a WG item. A substantial
  number of comments were received and the subsequent document 
  versions addressed those comments. No difficult decisions
  had to be made by the chairs or the group. 

Document Quality

PingIdentity, Google, and Deutsche Telekom have implementations 
of the plain code challenge method.  Additional information on 
implementations can be found in the shepherd report.

Review from an ABNF expert is requested.  Specific questions are 
included in the shepherd writeup.

Personnel

Hannes Tschofenig is the document shepherd and the responsible area 
director is Kathleen Moriarty. 


IANA Note

This document allocates three new parameters to the existing OAuth 
parameter registry (see Section 6.1) and creates a new registry 
called 'PKCE Code Challenge Method' registry, with expert review required, 
RFC5226. 
This document adds two values to the PKCE Code Challenge Method registry, as 
defined 
in Section 6.2.2.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Review of draft-ietf-oauth-pop-architecture

[Phil Hunt]

Thanks Derek,

I will take a look at this.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

> On Jul 10, 2015, at 1:48 PM, Derek Atkins  wrote:
> 
> Hi,
> 
> In performing my shephard review of draft-ietf-oauth-pop-architecture I
> found one issue that was bugging me: you talk about target naming "too
> late" in the draft.  I.e., as I was reading through section 3.1 about
> token reuse I think it doesn't have enough detail about how you would
> prevent server A asking the client for a token for a resource of server
> B, and then server A acting as the client for server B?  I.e., how do
> you prevent server A acting as a MITM between the client and server B?
> (This is sort of the same question that resulted in TLS channel
> bindings).
> 
> I know this target (scope) protection exists, and it's even discussed a
> bit later in the document but it's not even mentioned as a possible
> threat in 3.1, which seems like a glaring ommission.
> 
> I'll create a more formal shephard review but I'd suggest some
> additional text to at least mention this threat in 3.1; you can provide
> a pointer to the protections then, too.
> 
> -derek
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> ___
> 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] Review of draft-ietf-oauth-pop-architecture

[Derek Atkins]

Hi,

In performing my shephard review of draft-ietf-oauth-pop-architecture I
found one issue that was bugging me: you talk about target naming "too
late" in the draft.  I.e., as I was reading through section 3.1 about
token reuse I think it doesn't have enough detail about how you would
prevent server A asking the client for a token for a resource of server
B, and then server A acting as the client for server B?  I.e., how do
you prevent server A acting as a MITM between the client and server B?
(This is sort of the same question that resulted in TLS channel
bindings).

I know this target (scope) protection exists, and it's even discussed a
bit later in the document but it's not even mentioned as a possible
threat in 3.1, which seems like a glaring ommission.

I'll create a more formal shephard review but I'd suggest some
additional text to at least mention this threat in 3.1; you can provide
a pointer to the protections then, too.

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kathleen Moriarty]

Thank you all for your work on this draft!



On Fri, Jul 10, 2015 at 12:57 PM, William Denniss 
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.i...@gmail.com> wrote:
>
>> Thanks, Brian!
>>
>> William? Are you good with this version?
>>
>> On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> I think -15 does address the inconsistency.
>>>
>>> On Fri, Jul 10, 2015 at 9:36 AM, John Bradley  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.i...@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  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 
> 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 
> 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 > > 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 
>>> 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 
 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`

>>

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

[Kathleen Moriarty]

Thanks, Brian!

William? Are you good with this version?

On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell  wrote:

> I think -15 does address the inconsistency.
>
> On Fri, Jul 10, 2015 at 9:36 AM, John Bradley  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.i...@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  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 
>>> 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 
>>> 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 
 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 
> 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 
>> 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,  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
>>>  

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

[Brian Campbell]

I think -15 does address the inconsistency.

On Fri, Jul 10, 2015 at 9:36 AM, John Bradley  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.i...@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  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 
>> 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 
>> 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 
>>> 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  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 
> 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,  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
>>susce

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

[John Bradley]

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 
>  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  > 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 > > 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 > > 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 > > 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 > > 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 >> > 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, >> > 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
>>>

[OAUTH-WG] I-D ACTION:draft-ietf-oauth-spop-15.txt

[Internet-Drafts]

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
Author(s) : N. Sakimura, et al
Filename  : draft-ietf-oauth-spop
Pages : 21 
Date  : 2015-07-10 

   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").


A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-oauth-spop-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kathleen Moriarty]

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  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 
> 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 
> 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 
>> 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  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 
 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,  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