Hi Torsten, folks, I reviewed the text of Section 4.1 of draft-lodderstedt-oauth-security, and also the text of Section 9 of oath-draft16.
I think there seems to be a disconnect (may be its just me). (a) Oauth2.0 today is designed for low-assurance environments. So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just assume that the problem of keeping secrets is out of scope for Oauth. Unless we are trying to address high-assurance environments (and start talking about smartcards, HSMs, TPMs, trusted execution, trusted boot, etc), I think the WG should just move on. ps. Section 4.1 is OK, but this WG will not be able to solve many of the problems listed in Section 4.1 (b) The current text of Section 9 says: ]]]] Native applications SHOULD use the authorization code ]]]] grant type flow without client password credentials (due to their ]]]] inability to keep the credentials confidential) to obtain ]]]] short-lived access tokens, and use refresh tokens to maintain access. When it comes to "keeping secrets" I don't know why we are assuming that a native application (software running in user-space managed by an OS) is any worse than a browser (user-agent). Did I misunderstood the definition of a native application? Thanks. /thomas/ _________________________________ > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Torsten Lodderstedt > Sent: Thursday, June 02, 2011 5:00 AM > To: Skylar Woodward > Cc: [email protected] > Subject: Re: [OAUTH-WG] Text for Native Applications > > Dave, Skylar, > > the assumption of the OAuth 2.0 security threat model > (http://tools.ietf.org/html/draft-lodderstedt-oauth-security- > 01#section-4.1) > is that client secrets, which are distributed with applications, cannot > reliably kept confidential. Therefore the advice is given to use other > means to validate the client identity (e.g. user consent, platform > security measures). > > I would highly appreciate if you would review this document and give us > feedback. > > thanks in advance, > Torsten. > > Am 01.06.2011 22:07, schrieb Skylar Woodward: > > On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote: > > > >> for mounting the attack. I firmly believe that secrets can be > >> sufficiently obfuscated in code delivered in binary format without > >> the benefit of a symbol table, so as to be sufficiently resistant to > >> discovery via disassembly by attackers you'd expect to encounter in > a > >> typical commercial environment. I'm not talking about printable > > I have empirical evidence to support this. At Yahoo! we devised one > of the most complex systems I've ever seen in a publicly distributed > program (Messenger). It was disassembled in 3 days. Scott Renfro (now > over with David at Facebook) and likely Bill Mills can also vouch for > the difficulty of this having also studied the case well. > > > > Moreover if a hardware-enforced system like that of Playstation 3 can > be broken, then so can most systems. The PS3 protection mechanisms > are/were very sophisticated. > > > > Even if a system is not yet cracked or is very hard, you have to > assume it can be cracked. History has shown this to be true nearly > without exception - at least to the point it is not worth considering > for the OAuth use cases. > > > > skylar > > > > _______________________________________________ > > 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
