Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt

Hi
On 06/09/13 00:44, John Bradley wrote:
> 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.
>

Given that Resource owner credentials grant did get IETF acceptance 
without any problems (due to HTTPS being recommended I guess) and due to 
the comment below that if we have a case where the device is compromised 
then passing a transient sensitive value in clear does not really makes 
the device client any more insecure than it already is, would it make 
sense to keep the current approach in place ? I did a quick try at 
implementing it few weeks ago and it was easy to do...

Sergey

> On 2013-09-05, at 4:34 PM, Nat Sakimura <sakimura@gmail.com
> <mailto:sakimura@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.mishra@oracle.com
>> <mailto:prateek.mishra@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-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>>>     Date: 2013/7/30
>>>     Subject: New Version Notification for
>>>     draft-sakimura-oauth-tcse-00.txt
>>>     To: Nat Sakimura <sakimura@gmail.com
>>>     <mailto:sakimura@gmail.com>>, John Bradley
>>>     <jbradley@pingidentity.com <mailto:jbradley@pingidentity.com>>,
>>>     Naveen Agarwal <naa@google.com <mailto:naa@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
>