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