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

[Torsten Lodderstedt <[e-mail]>]

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 <[e-mail]> schrieb:
>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.
>
>
>
>On Nov 9, 2013, at 12:32 PM, Phil Hunt <[e-mail]> wrote:
>
>> 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
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth