>From the security PoV, I prefer HMAC as well. If implementers supports the idea, I would change it to HMAC in the next rev. I am also open to changing the param names. As I was writing them, I was reading JWx specs and got influenced by their short names apparently. I have no strong preference.
I agree with John that we may want to avoid the name that is a variation on client secret as it would confuse people. 2013/9/3 John Bradley <ve7...@ve7jtb.com> > Yes Phil it is the same sort of idea that you proposed in 2011. > > In this proposal it is limited to preventing an attacker who intercepts > code from being able to use it even if it knows the client_id and secret of > the requester as is likely in a native app without dynamic registration > case. > > I think of this as a symmetric proof of possession for code rather than a > authentication mechanism for the client. Looking at the old thread I don't > think that was clear to people. > > I also don't think the problem with native apps custom redirect schemes > being hijacked was apparent to people. > > Sending the password itself in the authorization request works assuming > the attacker can't see the request as is the case in native environments > currently. > We changed it to sending a hash of the secret in the request as sending > passwords in the clear just seems like it will eventually bite us in the > ass. > > I personally think making it a hmac is something people are more likely to > have the correct code for than a truncated hash, but this is a first draft. > > John B. > > > On 2013-09-02, at 4:34 PM, Phil Hunt <phil.h...@oracle.com> wrote: > > 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 listOAuth@ietf.orghttps://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 > > -- 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
