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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
