<div dir="ltr">This is the agreed upon next round edit for tcse. <br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Nat Sakimura</b> <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>></span><br>
Date: 2013/9/9<br>Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt<br>To: Naveen Agarwal <<a href="mailto:nvnagr@gmail.com">nvnagr@gmail.com</a>><br>Cc: John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>><br>
<br><br><div dir="ltr">OK. As a compromise, what about this? <div><br></div><div>1. Default: Just a random number. </div><div>2. Iff the server supports and the client has done a alg negotiation/registration with the server, client may send hash etc. instead. In this case, the alg needs to be adhered. </div>
<div><br></div><div>I do not think the run-time negotiation of alg is a good idea as it would be prone to the downgrade attack. </div><div><br></div><div>What do you think? </div></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><br><div class="gmail_quote">
2013/9/6 Naveen Agarwal <span dir="ltr"><<a href="mailto:nvnagr@gmail.com" target="_blank">nvnagr@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div>Breno and I chatted a bit more. </div><div>Adding any hashing algo makes it more work for the client and also we have to worry about servers supporting the same hashing algos. We need to then define various hashing algorithms, handshake and a way to upgrade in the future otherwise issues will keep coming up.</div>
<div>Given that we don't know of a way requests get compromised (unless the bad guy has full platform control) we feel strongly that it is better to keep it simple and get rid of any hashing. i.e. Don't do crypto unless we need it.</div>
<div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 4:25 PM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It is all about the level of assurance, i suppose. <div>If it is just a random number, then it could be captured on the way and reused. </div>
<div>On the other hand, if it is a hash, it will not be. <br></div>
<div><br></div><div>I made it a hash as a striking ground between a random number and more full brown cypto protection. </div><div>It is easy and short enough for the sender while the attacker would have hard time cracking it on the device within a second or so. </div>
<div>Considering we are fighting against attackers right now, just a little more protection than a random number seemed to be a good idea. <br></div><div>That's what Brian and other people seemed to have thought as well. </div>
<div><br></div><div>What would you think about that? </div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/5 Naveen Agarwal <span dir="ltr"><<a href="mailto:nvnagr@gmail.com" target="_blank">nvnagr@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">- mailing list<div><br></div><div>Hi Nat, John,</div><div><br></div><div>In Google's implementation we are generating a random string and just passing that as is (in the request and in the code exchange). There is no hashing magic etc. I think that may be enough and also takes away the complain people may have about doing the crypto and crypto analysis. Given the code is short lived, I don't know if hashing and other complexities really help. I can see that the current proposal tries helps in the bad guy intercepts the request itself then it won't have the secret either but not sure that is a real concern. Thoughts?</div>
<div><br></div><div><br></div><div><br></div><div>Thanks</div><span><font color="#888888"><div><br></div><div>Naveen</div></font></span></div><div><div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Tue, Sep 3, 2013 at 11:04 PM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">From the security PoV, I prefer HMAC as well. <div>If implementers supports the idea, I would change it to HMAC in the next rev. </div>
<div>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. </div>
<div><br></div><div>I agree with John that we may want to avoid the name that is a variation on client secret as it would confuse people. </div><div><br></div><div><br></div></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">
2013/9/3 John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Yes Phil it is the same sort of idea that you proposed in 2011.<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br>
</div>
<div>I also don't think the problem with native apps custom redirect schemes being hijacked was apparent to people. </div><div><br></div><div>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.</div>
<div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>John B.</div><div><div><div><br></div><div><br></div><div><div><div>On 2013-09-02, at 4:34 PM, Phil Hunt <<a href="mailto:phil.hunt@oracle.com" target="_blank">phil.hunt@oracle.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="word-wrap:break-word">FWIW, this was raised before in 2011.<div><br></div><div><a href="http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html" target="_blank">http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html</a></div>
<div><a href="http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html" target="_blank">http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html</a></div><div><br><div>
<span style="border-collapse:separate;border-spacing:0px"><div style="word-wrap:break-word"><span style="border-collapse:separate;font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word">
<span style="border-collapse:separate;font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word">
<span style="border-collapse:separate;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word">
<div>Phil</div><div><br></div><div>@independentid</div><div><a href="http://www.independentid.com/" target="_blank">www.independentid.com</a></div></div></span><a href="mailto:phil.hunt@oracle.com" target="_blank">phil.hunt@oracle.com</a></div>
<div style="word-wrap:break-word"><br><br></div></span><br></div></span><br></div></span><br><br>
</div>
<br><div><div>On 2013-09-02, at 3:44 PM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">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.<div>
Many AS maintain server state for code as it also has grants, redirect_uri, client_id, subject etc that need to be tracked.<br><div><br></div><div>The point being that the value of "tcsh" not be made available to someone who intercepts code on the return.</div>
<div><br></div><div>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.</div>
<div>
<br></div><div>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.</div>
<div><br></div><div>This is intended as a early draft to document the security problem on iOS and one possible mitigation that people are using.</div><div><br></div><div>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.</div>
<div><br></div><div>John B.</div><div><br></div><div><br><div><div>On 2013-09-02, at 2:14 PM, Prateek Mishra <<a href="mailto:prateek.mishra@oracle.com" target="_blank">prateek.mishra@oracle.com</a>> wrote:</div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
Nat - is there cryptanalysis of the proposed model available
anyplace?<br>
<br>
Extending protocols by throwing in a smidgen of hashing and a
tablespoon of encryption is often a bad idea. One of the strengths
of <span> <em>RFC</em> 6749 is that it avoids stuff
like that.<br>
<br>
What do you mean when you say - <br>
<br>
[quote]<br>
</span>The server MUST NOT include the "tcsh" value in the form that
any entity but itself can extract it.
<div>[\quote]<br>
<br>
Is this even theoretically achievable without a stateful server
that maintains a table of [code x tcsh] pairs? <br>
<br>
If not, how should the server embed tcsh in "code" and what
constructions are recommended?<br>
<br>
- prateek<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:18px">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. </span>
<div style="font-family:arial,sans-serif;font-size:18px">
<br>
</div>
<div style="font-family:arial,sans-serif;font-size:18px">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. </div>
<div style="font-family:arial,sans-serif;font-size:18px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:18px">IMHO,
although it came up as an issue in OpenID Connect, this is a
quite useful extension to OAuth 2.0 in general. </div>
<div style="font-family:arial,sans-serif;font-size:18px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:18px">Best, </div>
<div style="font-family:arial,sans-serif;font-size:18px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:18px">
Nat Sakimura</div>
<br>
<div class="gmail_quote">---------- Forwarded message ----------<br>
From: <span dir="ltr"><<a href="mailto:internet-drafts@ietf.org" target="_blank">internet-drafts@ietf.org</a>></span><br>
Date: 2013/7/30<br>
Subject: New Version Notification for
draft-sakimura-oauth-tcse-00.txt<br>
To: Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>,
John Bradley <<a href="mailto:jbradley@pingidentity.com" target="_blank">jbradley@pingidentity.com</a>>,
Naveen Agarwal <<a href="mailto:naa@google.com" target="_blank">naa@google.com</a>><br>
<br>
<br>
<br>
A new version of I-D, draft-sakimura-oauth-tcse-00.txt<br>
has been successfully submitted by Nat Sakimura and posted to
the<br>
IETF repository.<br>
<br>
Filename: draft-sakimura-oauth-tcse<br>
Revision: 00<br>
Title: OAuth Transient Client Secret Extension for
Public Clients<br>
Creation date: 2013-07-29<br>
Group: Individual Submission<br>
Number of pages: 7<br>
URL: <a href="http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt" target="_blank">http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt</a><br>
Status: <a href="http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse" target="_blank">http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse</a><br>
Htmlized: <a href="http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00" target="_blank">http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00</a><br>
<br>
<br>
Abstract:<br>
The OAuth 2.0 public client utilizing code flow is
susceptible to the<br>
code interception attack. This specification describe a
mechanism<br>
that acts as a control against this threat.<br>
<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time
of submission<br>
until the htmlized version and diff are available at <a href="http://tools.ietf.org/" target="_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<br>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OAuth mailing list
<a href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a>
<a href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>OAuth mailing list<br><a href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
</blockquote></div><br></div></div></div>_______________________________________________<br>OAuth mailing list<br><a href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
</blockquote></div><br></div></div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
OAuth mailing list<br>
<a href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>
</div></div><br>_______________________________________________<br>
OAuth mailing list<br>
<a href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>
</div></div></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>