At this point we don't know of any attack against the request, however that is not guaranteed to remain the case.
If we send the secret in plain text through the browser it likely will never get IETF acceptance. We use HMAC a fair bit already I don't think that would be a significant hurdle for clients. The quoted text is trying to prevent the AS from leaking the value back to the attacker, that would be fatal flaw if it is plaintext, and not optimal if it is a HMAC. AS could do something like include it in code unencrypted etc, just trying to prevent that. On 2013-09-05, at 4:34 PM, Nat Sakimura <sakim...@gmail.com> wrote: > Depending on the level of assurance that you might want to achieve, it could > have been a random string. That's how some of the existing but widely > deployed implementations are doing. > > I have taken a step forward to do the hashing to give a little more > protection that even if a malware on the device captures the request, it > would not be able to use it in time. That's a kind of man-in-the-middle and > by that time happens, your device is fairly badly compromised so there are > opinion that it would not matter much by that time that just a random string > would suffice. If the WG feels that way, I am happy to change it to a random > string as well. > > The current "hash" design was a middle ground between a random string and > HMAC etc. > > > 2013/9/3 Prateek Mishra <prateek.mis...@oracle.com> > 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 > > > > > -- > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
