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 protected]> 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 <[email protected]>: >> >> 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 protected]> のメッセージ: >> >>> 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 <[email protected]> >>>> wrote: >>>> >>>> Hi John, >>>> >>>> why not make the more secure option the only one? >>>> >>>> regards, >>>> Torsten. >>>> >>>> >>>> >>>> John Bradley <[email protected]> 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 >>>>>> <[email protected]> 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: <[email protected]> >>>>>>> Date: 2013/10/19 >>>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt >>>>>>> To: Nat Sakimura <[email protected]>, John Bradley >>>>>>> <[email protected]>, Naveen Agarwal <[email protected]> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
