How about request identifier? Phil
On 2013-09-03, at 23:04, Nat Sakimura <sakim...@gmail.com> wrote: > 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 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 > > > > -- > 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
