Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 09 Nov 2013 14:23:56 +0100

Hi Nat,

what's the rationale for having different algorithms to produce a code 
challenges? As this may cause interop issues there should be good 
reasons to introduce variants.

regards,
Torsten.

Am 19.10.2013 12:15, schrieb Nat Sakimura:
> Incorporated the discussion at Berlin meeting and after in the ML.
>
> Best,
>
> Nat
>
> ---------- Forwarded message ----------
> From: <[email-masked] <mailto:[email-masked]>>
> Date: 2013/10/19
> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
> To: Nat Sakimura <[email-masked] <mailto:[email-masked]>>, 
> John Bradley <[email-masked] 
> <mailto:[email-masked]>>, Naveen Agarwal <[email-masked] 
> <mailto:[email-masked]>>
>
>
>
> A new version of I-D, draft-sakimura-oauth-tcse-02.txt
> has been successfully submitted by Nat Sakimura and posted to the
> IETF repository.
>
> Filename:        draft-sakimura-oauth-tcse
> Revision:        02
> Title:           OAuth Symmetric Proof of Posession for Code Extension
> Creation date:   2013-10-19
> Group:           Individual Submission
> Number of pages: 8
> URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt
> Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
> Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02
>
> Abstract:
>    The OAuth 2.0 public client utilizing authorization code grant is
>    susceptible to the code interception attack.  This specification
>    describe a mechanism that acts as a control against this threat.
>
>
>
>
>
> 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>.
>
> The IETF Secretariat
>
>
>
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Sat, 9 Nov 2013 07:51:27 -0800

With a native app using a captive browser with no malware, only the response is susceptible to interception, making encrypting the request redundant.
In other environments and with some user groups the request's challenge needs to be protected from interception.  This may be more the case in a desktop environment where there is less control over the browser.

I expect that we will come to two options one unprotected requests and one for protected requests.

To Phil's point this is not about identifying the class of software this is about matching a response to an instance of software.   
A software statement gives you a hint about the class of software but not the instance without per client registration.

This method gives you the ability to securely return the token to only the instance of the client that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a real problem people are having today, and versions of this are in production now.   

Nat and I are trying to document it so that there can be interoperability rather than every AS doing something different.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <[email-masked]> wrote:

> Hi Nat,
> 
> what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.
> 
> regards,
> Torsten.
> 
> 
>> From: <[email-masked]>
>> Date: 2013/10/19
>> To: Nat Sakimura <[email-masked]>, John Bradley <[email-masked]>, Naveen Agarwal <[email-masked]>
>> 
>> 
>> 
>> 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.
>> 
>> The IETF Secretariat
>> 
>> 
>> 
>> 
>> -- 
>> Nat Sakimura (=nat)

---

From: John Bradley <[email-masked]>
Date: Sat, 9 Nov 2013 07:55:09 -0800

PS I did resist the temptation of doing DH key agreement in the Authorization request /response then using the agreed key as the code proof.
That would also be secure but not popular with developers.

John B.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 09 Nov 2013 17:15:26 +0100

Hi John,

why not make the more secure option the only one?

regards,
Torsten.

John Bradley <[email-masked]> schrieb:
>With a native app using a captive browser with no malware, only the
>response is susceptible to interception, making encrypting the request
>redundant.
>In other environments and with some user groups the request's challenge
>needs to be protected from interception.  This may be more the case in
>a desktop environment where there is less control over the browser.
>
>To Phil's point this is not about identifying the class of software
>this is about matching a response to an instance of software.   
>A software statement gives you a hint about the class of software but
>not the instance without per client registration.
>
>This method gives you the ability to securely return the token to only
>the instance of the client that requested it without the overhead of
>per instance dynamic registration.
>
>This is a practical solution to a real problem people are having today,
>and versions of this are in production now.   
>
>Nat and I are trying to document it so that there can be
>interoperability rather than every AS doing something different.
>
>John B.
>
>> what's the rationale for having different algorithms to produce a
>code challenges? As this may cause interop issues there should be good
>>> To: Nat Sakimura <[email-masked]>, John Bradley
><[email-masked]>, Naveen Agarwal <[email-masked]>
>>> 
>>> 
>>> 
>>> URL:            
>http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt
>>> Status:         
>http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
>>> Htmlized:       
>http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
>>> Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02
>>> 
>>> Abstract:

---

From: John Bradley <[email-masked]>
Date: Sat, 9 Nov 2013 08:42:41 -0800

Simplicity for clients that don't need the extra security.   I happen to agree with you but it is Google that needs the convincing, as they have deployed the non crypto version.
As with many things getting people to adopt it is the trick.

John B.

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 10 Nov 2013 03:04:03 +0900

And adding to it, it is Google's application team that needs to be persuaded. As usual, persuading application people to use crypto is hard. We have to strike a point that is acceptable to them as well as being somewhat sensible security-wise. Having option to bump up the security is important as a future migration path as well, hence the current design. 

=nat via iPhone

---

From: Phil Hunt <[email-masked]>
Date: Sat, 9 Nov 2013 12:21:22 -0800

We may speculatively satisfy google and upset even more developers by creating more options. I think google eng should be more directly involved in this discussion and make the case. 

That said, i do agree with John's analysis that some clients don't benefit. Just worry that the downgraded google option will always tend to be used. I would prefer to go with a single more secure alg as the common solution. 

Phil

> On Nov 9, 2013, at 10:04, Nat Sakimura <[email-masked]> wrote:
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 9 Nov 2013 21:27:42 +0100

Hi,

thanks for the explanation. Seems there is the simpler option sufficient to solve the original problem but it's not secure enough to be a general solution. 

Regarding implementation: The simpler option requires the developer to create a value of reasonable randomness and the second additionally requires to calculate the SHA correctly. I'm afraid client developers will have trouble implementing it correctly. That's why the idea of OAuth always was to push complexity to the server implementation.

While thinking about your proposal, I remembered a potential alternative. We initially discussed usage of dynamically issued client id/secrets (dyn. client registration) in order to mitigate the threat. This has two advantages:
- it utilizes general OAuth functionality
- usage of client credentials is easy from a client developers perspective

This idea was originally rejected due to the potential implications on scalability. The assumption was, potentially billions of client instances could not be managed by the AS in a reasonable way. Based on the outcome of the latest discussions around dynamic registration, we now know how to implement registration in a stateless way using client secrets as self-contained tokens. So this should not be a scalability issue any longer.

Should we reconsider this alternative?

regards,
Torsten.

> Am 09.11.2013 um 19:04 schrieb Nat Sakimura <[email-masked]>:
>

---

From: Phil Hunt <[email-masked]>
Date: Sat, 9 Nov 2013 12:32:09 -0800

Sounds interesting. 

I wonder about why one might choose a public model with tcse vs stateless client reg?  

Eg. Tcse might be more important for transient clients. 

Phil

> On Nov 9, 2013, at 12:27, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi,
>

---

From: John Bradley <[email-masked]>
Date: Sat, 9 Nov 2013 15:11:55 -0800

Yes  tcse is a way to use the code flow without per instance registration, and better security than a plain public client.  
Not every instance needs to needs registered as long as the redirect_uri is constant. 

There is however a difference in how grants are treated then you have multiple instances with the same client_id.
If you want all copies of a app that the user has installed across devices to have the same grants then use one client_id and tcse.

If you want the grants to be separate so that one instance has RW and the other RO scopes for example then you need dynamic client registration or to re-confirm all scopes each time and not prompt only for new scopes for the client.   So there are legitimate reasons for doing both.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Sat, 9 Nov 2013 15:45:58 -0800

+1

How would clients find out? Discovery, docs?

Phil

> On Nov 9, 2013, at 15:11, John Bradley <[email-masked]> wrote:
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 10 Nov 2013 09:57:57 +0100

One can relate all instances of the same app using an initial access token. So doing per client instance registration does not preclude to manage grants per app.

John Bradley <[email-masked]> schrieb:
>Yes  tcse is a way to use the code flow without per instance
>registration, and better security than a plain public client.  
>There is however a difference in how grants are treated then you have
>multiple instances with the same client_id.
>If you want all copies of a app that the user has installed across
>devices to have the same grants then use one client_id and tcse.
>
>If you want the grants to be separate so that one instance has RW and
>the other RO scopes for example then you need dynamic client
>registration or to re-confirm all scopes each time and not prompt only
>for new scopes for the client.   So there are legitimate reasons for
>doing both.
>
>John B.
>
>
>
>>> thanks for the explanation. Seems there is the simpler option
>sufficient to solve the original problem but it's not secure enough to
>be a general solution. 
>>> 
>>> Regarding implementation: The simpler option requires the developer
>to create a value of reasonable randomness and the second additionally
>requires to calculate the SHA correctly. I'm afraid client developers
>will have trouble implementing it correctly. That's why the idea of
>OAuth always was to push complexity to the server implementation.
>>> 
>>> While thinking about your proposal, I remembered a potential
>alternative. We initially discussed usage of dynamically issued client
>id/secrets (dyn. client registration) in order to mitigate the threat.
>This has two advantages:
>>> This idea was originally rejected due to the potential implications
>on scalability. The assumption was, potentially billions of client
>instances could not be managed by the AS in a reasonable way. Based on
>the outcome of the latest discussions around dynamic registration, we
>now know how to implement registration in a stateless way using client
>secrets as self-contained tokens. So this should not be a scalability
>issue any longer.
>>> 
>>>> And adding to it, it is Google's application team that needs to be
>persuaded. As usual, persuading application people to use crypto is
>hard. We have to strike a point that is acceptable to them as well as
>being somewhat sensible security-wise. Having option to bump up the
>security is important as a future migration path as well, hence the
>current design. 
>>>> 
>>>> =nat via iPhone
>>>> 
>>>>> Simplicity for clients that don't need the extra security.   I
>happen to agree with you but it is Google that needs the convincing, as
>they have deployed the non crypto version.
>>>>>> With a native app using a captive browser with no malware, only
>the response is susceptible to interception, making encrypting the
>request redundant.
>>>>>> In other environments and with some user groups the request's
>challenge needs to be protected from interception.  This may be more
>the case in a desktop environment where there is less control over the
>browser.
>>>>>> 
>>>>>> To Phil's point this is not about identifying the class of
>software this is about matching a response to an instance of software. 
> 
>>>>>> A software statement gives you a hint about the class of software
>but not the instance without per client registration.
>>>>>> 
>>>>>> This method gives you the ability to securely return the token to
>only the instance of the client that requested it without the overhead
>of per instance dynamic registration.
>>>>>> 
>>>>>> This is a practical solution to a real problem people are having
>today, and versions of this are in production now.   
>>>>>> 
>>>>>>> what's the rationale for having different algorithms to produce
>a code challenges? As this may cause interop issues there should be
>good reasons to introduce variants.
>>>>>>> 
>>>>>>> regards,
>>>>>>> Torsten.
>>>>>>> 
>>>>>>>

---

From: John Bradley <[email-masked]>
Date: Sun, 10 Nov 2013 08:15:10 -0800

No certainly you can still manage grants per app class if you are doing per instance registration.   It is however more of a UI challenge if you don't do per instance registration and you want to manage grants per instance.

I mostly wanted to point out that there are two models that AS use Twitter as an example give all instances of an application the same grans and I think even the same access token. (OAuth 1 don't blame me:)   Facebook also treats instances as having consented to the same grants.  That has been used for privilege escalation attacks if you can impersonate a client.

Others try and treat different instances of a app as having separate grants.   

There are likely reasons to do both, that is for the AS to decide.

Discovery and out of band API documentation around how scopes and grants are treated would likely be how a developer would find out what the thing to do is. 

If the AS supports tcse the client could discover it dynamically and use it as there is no real downside, though if it is already a confidential client client it would not add much.

The stateless client registration is another way to get similar protection without adding tcse as an extension, however that is still more work for the server to implement than tcse.

Dynamic client registration + stateless is probably the broader solution that also covers use-cases if I had to pick just one.

John B.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 10 Nov 2013 19:32:47 +0100

>
> Dynamic client registration + stateless is probably the broader 
> solution that also covers use-cases if I had to pick just one.

That's my point. I have to decide what to implement in my service since 
we need a solution for our (partner) apps. And right now I'm tending 
more towards dynamic client registration + stateless. In my opinion, 
it's not only broader but easier to use from a client developer's 
perspective (that's what I care more about than server-side complexity).

regards,
Torsten.
>
> John B.
>
> On Nov 10, 2013, at 12:57 AM, Torsten Lodderstedt 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> One can relate all instances of the same app using an initial access 
>> token. So doing per client instance registration does not preclude to 
>> manage grants per app.
>>
>>
>>
>> John Bradley <[email-masked] <mailto:[email-masked]>> schrieb:
>>
>>     There is however a difference in how grants are treated then you
>>     have multiple instances with the same client_id.
>>     If you want all copies of a app that the user has installed
>>     across devices to have the same grants then use one client_id and
>>     tcse.
>>
>>     If you want the grants to be separate so that one instance has RW
>>     and the other RO scopes for example then you need dynamic client
>>     registration or to re-confirm all scopes each time and not prompt
>>     only for new scopes for the client.   So there are legitimate
>>     reasons for doing both.
>>
>>     John B.
>>
>>
>>
>>     On Nov 9, 2013, at 12:32 PM, Phil Hunt <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>>     Sounds interesting.
>>>
>>>     On Nov 9, 2013, at 12:27, Torsten Lodderstedt
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>>     Hi,
>>>>
>>>>     sufficient to solve the original problem but it's not secure
>>>>     enough to be a general solution.
>>>>
>>>>     Regarding implementation: The simpler option requires the
>>>>     developer to create a value of reasonable randomness and the
>>>>     second additionally requires to calculate the SHA correctly.
>>>>     I'm afraid client developers will have trouble implementing it
>>>>     correctly. That's why the idea of OAuth always was to push
>>>>     complexity to the server implementation.
>>>>
>>>>     alternative. We initially discussed usage of dynamically issued
>>>>     client id/secrets (dyn. client registration) in order to
>>>>     mitigate the threat. This has two advantages:
>>>>     This idea was originally rejected due to the potential
>>>>     implications on scalability. The assumption was, potentially
>>>>     billions of client instances could not be managed by the AS in
>>>>     a reasonable way. Based on the outcome of the latest
>>>>     discussions around dynamic registration, we now know how to
>>>>     implement registration in a stateless way using client secrets
>>>>     as self-contained tokens. So this should not be a scalability
>>>>     issue any longer.
>>>>
>>>>     Am 09.11.2013 um 19:04 schrieb Nat Sakimura <[email-masked]
>>>>     <mailto:[email-masked]>>:
>>>>
>>>>>     And adding to it, it is Google's application team that needs
>>>>>     to be persuaded. As usual, persuading application people to
>>>>>     use crypto is hard. We have to strike a point that is
>>>>>     acceptable to them as well as being somewhat sensible
>>>>>     security-wise. Having option to bump up the security is
>>>>>     important as a future migration path as well, hence the
>>>>>     current design.
>>>>>
>>>>>     =nat via iPhone
>>>>>
>>>>>     Nov 10, 2013 1:42、John Bradley <[email-masked]
>>>>>     <mailto:[email-masked]>> のメッセージ:
>>>>>
>>>>>>     Simplicity for clients that don't need the extra security.  
>>>>>>     I happen to agree with you but it is Google that needs the
>>>>>>     convincing, as they have deployed the non crypto version.
>>>>>>     On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt
>>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>>     Hi John,
>>>>>>>
>>>>>>>     John Bradley <[email-masked] <mailto:[email-masked]>>
>>>>>>>     schrieb:
>>>>>>>
>>>>>>>         With a native app using a captive browser with no
>>>>>>>         malware, only the response is susceptible to
>>>>>>>         interception, making encrypting the request redundant.
>>>>>>>         In other environments and with some user groups the
>>>>>>>         request's challenge needs to be protected from
>>>>>>>         interception.  This may be more the case in a desktop
>>>>>>>         environment where there is less control over the browser.
>>>>>>>
>>>>>>>         I expect that we will come to two options one
>>>>>>>         unprotected requests and one for protected requests.
>>>>>>>
>>>>>>>         To Phil's point this is not about identifying the class
>>>>>>>         of software this is about matching a response to an
>>>>>>>         instance of software.
>>>>>>>         A software statement gives you a hint about the class of
>>>>>>>         software but not the instance without per client
>>>>>>>         registration.
>>>>>>>
>>>>>>>         This method gives you the ability to securely return the
>>>>>>>         token to only the instance of the client that requested
>>>>>>>         it without the overhead of per instance dynamic
>>>>>>>         registration.
>>>>>>>
>>>>>>>         This is a practical solution to a real problem people
>>>>>>>         are having today, and versions of this are in production
>>>>>>>         now.
>>>>>>>
>>>>>>>         On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt
>>>>>>>         <[email-masked]
>>>>>>>         <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>>>         Hi Nat,
>>>>>>>>
>>>>>>>>         what's the rationale for having different algorithms to
>>>>>>>>         produce a code challenges? As this may cause interop
>>>>>>>>         issues there should be good reasons to introduce variants.
>>>>>>>>
>>>>>>>>         regards,
>>>>>>>>         Torsten.
>>>>>>>>
>>>>>>>>
>>>>>>>>>         To: Nat Sakimura <[email-masked]
>>>>>>>>>         <mailto:[email-masked]>>, John Bradley
>>>>>>>>>         <[email-masked]
>>>>>>>>>         <mailto:[email-masked]>>, Naveen Agarwal
>>>>>>>>>         <[email-masked] <mailto:[email-masked]>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         until the htmlized version and diff are available at
>>>>>>>>>         tools.ietf.org <http://tools.ietf.org/>.
>>>>>>>>>
>>>>>>>>>         The IETF Secretariat
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         -- 
>>>>>>>>>         Nat Sakimura (=nat)
>>>>>>>>         [email-masked] <mailto:[email-masked]>
>>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>