Hi, I think that draft-sakimura-oauth-tcse should reference http://tools.ietf.org/html/rfc6819 and especially reference the sections that this draft addresses.
Regarding Prateek's comment about stateful servers: I think that a stateful server is the price the AS pays to ensure that the requestor of the code (A or section 3.3 in http://tools.ietf.org/html/draft-sakimura-oauth-tcse-01 ) is the same as the requestor of the access token (C or 3.5 in the draft). It is my interpretation of the purpose of this draft to achieve this goal (requestor A== requestor C). Regarding the hashing: I think that the length of tcs should be restricted. The draft assumes that an attacker is not able to create a tcs to be used in step 3.5 that generates the same tcsh that was used in step 3.3. I think that if the length of tcs is unrestricted then it is easier for the attacker to generate a new tcs that matches tcsh. The was the case in an attack against md5. I have no prove for this "feeling" but I think it is harder for an attacker to find a matching tcs for a given tcsh if the length of tcs is fixed or limited. -Axel 1.2<https://tools.ietf.org/html/rfc6749#section-1.2>. Protocol Flow +--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+ Figure 1: Abstract Protocol Flow From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Friday, September 06, 2013 1:44 AM To: Nat Sakimura Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt 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<mailto: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<mailto: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<mailto: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<mailto:sakim...@gmail.com>>, John Bradley <jbrad...@pingidentity.com<mailto:jbrad...@pingidentity.com>>, Naveen Agarwal <n...@google.com<mailto: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<http://tools.ietf.org/>. The IETF Secretariat -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
