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

[Phil Hunt <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail]>:
>> 
>> 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 <[e-mail]> のメッセージ:
>> 
>>> 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.
>>> 
>>>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt <[e-mail]> wrote:
>>>> 
>>>> Hi John,
>>>> 
>>>> why not make the more secure option the only one?
>>>> 
>>>> regards,
>>>> Torsten.
>>>> 
>>>> 
>>>> 
>>>> John Bradley <[e-mail]> 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.   
>>>>> 
>>>>> 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 <[e-mail]> 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.
>>>>>> 
>>>>>> 
>>>>>> 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: <[e-mail]>
>>>>>>> Date: 2013/10/19
>>>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
>>>>>>> To: Nat Sakimura <[e-mail]>, John Bradley <[e-mail]>, Naveen Agarwal <[e-mail]>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> The IETF Secretariat
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Nat Sakimura (=nat)
>>>>>>> Chairman, OpenID Foundation
>>>>>>> http://nat.sakimura.org/
>>>>>>> @_nat_en
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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