FWIW, this was raised before in 2011. http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html
Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-09-02, at 3:44 PM, John Bradley <ve7...@ve7jtb.com> wrote: > AS that don't maintain state would need to encode everything into code. I > have seen a couple of implementations do that. The encoding tends to be > custom for size reasons. > Many AS maintain server state for code as it also has grants, redirect_uri, > client_id, subject etc that need to be tracked. > > The point being that the value of "tcsh" not be made available to someone who > intercepts code on the return. > > This method is being used without hashing, and just sending "tcs" however > that clearly has no resistance if the authorization request can somehow be > intercepted by an attacker as well. > > In order to stick to well understood crypto I argued that "tcsh" be a hmac of > the client_id using tcs as the key. I also think calling it a client > secret is misleading as it is a proof for the code requester not the client. > > This is intended as a early draft to document the security problem on iOS and > one possible mitigation that people are using. > > While interoperable OAuth clients like Connect may be a edge case to some, it > is desirable to have a solution to this that can work with multiple AS rather > than the client requiring custom code to talk to every AS. > > John B. > > > On 2013-09-02, at 2:14 PM, Prateek Mishra <prateek.mis...@oracle.com> wrote: > >> Nat - is there cryptanalysis of the proposed model available anyplace? >> >> Extending protocols by throwing in a smidgen of hashing and a tablespoon of >> encryption is often a bad idea. One of the strengths of RFC 6749 is that it >> avoids stuff like that. >> >> What do you mean when you say - >> >> [quote] >> The server MUST NOT include the "tcsh" value in the form that any entity but >> itself can extract it. >> [\quote] >> >> Is this even theoretically achievable without a stateful server that >> maintains a table of [code x tcsh] pairs? >> >> If not, how should the server embed tcsh in "code" and what constructions >> are recommended? >> >> - prateek >> >>> As some of you know, passing the authorization code securely to a native >>> app on iOS platform is next to impossible. Malicious application may >>> register the same custom scheme as the victim application and hope to >>> obtain the code, whose success rate is rather high. >>> >>> We have discussed about it during the OpenID Conenct Meeting at IETF 87 on >>> Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. >>> I have captured the discussion in the form of I-D. It is pretty short and >>> hopefully easy to read. >>> >>> IMHO, although it came up as an issue in OpenID Connect, this is a quite >>> useful extension to OAuth 2.0 in general. >>> >>> Best, >>> >>> Nat Sakimura >>> >>> ---------- Forwarded message ---------- >>> From: <internet-dra...@ietf.org> >>> Date: 2013/7/30 >>> Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt >>> To: Nat Sakimura <sakim...@gmail.com>, John Bradley >>> <jbrad...@pingidentity.com>, Naveen Agarwal <n...@google.com> >>> >>> >>> >>> A new version of I-D, draft-sakimura-oauth-tcse-00.txt >>> has been successfully submitted by Nat Sakimura and posted to the >>> IETF repository. >>> >>> Filename: draft-sakimura-oauth-tcse >>> Revision: 00 >>> Title: OAuth Transient Client Secret Extension for Public Clients >>> Creation date: 2013-07-29 >>> Group: Individual Submission >>> Number of pages: 7 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 >>> >>> >>> Abstract: >>> The OAuth 2.0 public client utilizing code flow 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
