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

From: Prateek Mishra <[email-masked]>
Date: Mon, 02 Sep 2013 17:14:35 -0400

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: <[email-masked] <mailto:[email-masked]>>
> Date: 2013/7/30
> Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
> To: Nat Sakimura <[email-masked] <mailto:[email-masked]>>, 
> John Bradley <[email-masked] 
> <mailto:[email-masked]>>, Naveen Agarwal <[email-masked] 
> <mailto:[email-masked]>>
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Sep 2013 15:44:57 -0700

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 <[email-masked]> wrote:

> 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.
> 
> 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
>> 
>> From: <[email-masked]>
>> Date: 2013/7/30
>> To: Nat Sakimura <[email-masked]>, John Bradley <[email-masked]>, Naveen Agarwal <[email-masked]>
>> 
>> 
>> 
>> Title:           OAuth Transient Client Secret Extension for Public Clients
>> 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)

---

From: Phil Hunt <[email-masked]>
Date: Mon, 2 Sep 2013 16:34:25 -0700

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
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Sep 2013 18:04:05 -0700

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.

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 4 Sep 2013 15:04:15 +0900

>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 <[email-masked]>

> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
>
> of encryption is often a bad idea. One of the strengths of *RFC* 6749 is
>  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
>
> To: Nat Sakimura <[email-masked]>, John Bradley <
> [email-masked]>, Naveen Agarwal <[email-masked]>
>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 4 Sep 2013 07:13:05 -0700

How about request identifier?

Phil

On 2013-09-03, at 23:04, Nat Sakimura <[email-masked]> wrote:

> 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. 
> 
> 
> 
>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 6 Sep 2013 08:34:42 +0900

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 <[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Sep 2013 16:44:26 -0700

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 <[email-masked]> 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. 
> 
>

---

From: <[email-masked]>
Date: Mon, 23 Sep 2013 13:52:11 +0200

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: [email-masked] [mailto:[email-masked]] 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

On 2013-09-05, at 4:34 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

2013/9/3 Prateek Mishra <[email-masked]<mailto:[email-masked]>>
Nat - is there cryptanalysis of the proposed model available anyplace?

[quote]

- prateek

Best,

Nat Sakimura

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <[email-masked]<mailto:[email-masked]>>, John Bradley <[email-masked]<mailto:[email-masked]>>, Naveen Agarwal <[email-masked]<mailto:[email-masked]>>

Abstract:

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

OAuth mailing list

[email-masked]<mailto:[email-masked]>

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 26 Sep 2013 13:40:17 +0100

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.
>
> 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.
>

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

>> could have been a random string. That's how some of the existing but
>> widely deployed implementations are doing.
>>
>> 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.
>>
>>     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.
>>
>>     Is this even theoretically achievable without a stateful server
>>     that maintains a table of [code x tcsh] pairs?
>>
>>>     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
>>>
>>>     To: Nat Sakimura <[email-masked]
>>>     <mailto:[email-masked]>>, John Bradley
>>>     <[email-masked] <mailto:[email-masked]>>,
>>>     Naveen Agarwal <[email-masked] <mailto:[email-masked]>>
>>>
>>>
>>>
>>>     until the htmlized version and diff are available at
>>>     tools.ietf.org <http://tools.ietf.org/>.
>>>
>>>     The IETF Secretariat
>>>
>>>
>>>
>>>
>>>     --
>>>     Nat Sakimura (=nat)
>>>     [email-masked]  <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>