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

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Tue, 30 Jul 2013 12:06:08 +0000

This solves a real and common problem with public client implementations. I certainly would like to see it move forward.  Thanks for publishing it Nat.

Cheers,
Morteza

From: Nat Sakimura <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 30, 2013 11:58 AM
To: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt

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

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 28 Aug 2013 17:12:51 +0100

Hi,

can you consider replacing "tcs" and "tcsh" with "temp_client_secret" 
and "temp_client_secret_hash" ? in OAuth2 we have "client_id", 
"client_secret" (ex, in dyn reg), and having a temp variant of 
"client_secret" called as "tcs" seems a bit cryptic to me :-), not a bit 
issue though

Sergey

On 30/07/13 16:36, Nat Sakimura wrote:
> Hi.
>
> I had to fix a few issues with the previous draft text.
> No normative changes, but just removed some extra text.
>
> Nat
>
> From: **<[email-masked] <mailto:[email-masked]>>
> Date: 2013/7/31
> Subject: New Version Notification for draft-sakimura-oauth-tcse-01.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-01.txt
> Revision:        01
> Creation date:   2013-07-30
> URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-01.txt
> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-01
> Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-01
>
> Abstract:
>     The OAuth 2.0 public client utilizing authorization code grant is
>     susceptible to the code interception attack.  This specification
>     describe a mechanism that acts as a control against this threat.
>
>
>
>
>
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org/>.
>
> The IETF Secretariat
>
>
>
>
> --
> Nat Sakimura (=nat)
> 2013/7/30 Nat Sakimura <[email-masked] <mailto:[email-masked]>>
>
>     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] <mailto:[email-masked]>>
>     Date: 2013/7/30
>     To: Nat Sakimura <[email-masked] <mailto:[email-masked]>>,
>     John Bradley <[email-masked]
>     <mailto:[email-masked]>>, Naveen Agarwal <[email-masked]
>     <mailto:[email-masked]>>
>
>
>
>     URL:
>     http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Bradley <[email-masked]>
Date: Wed, 28 Aug 2013 12:51:46 -0400

We probably don't want this secret that is used as confirmation of the code to be confused with a client secret that is bound to a client.  
They are verified by different levels of the stack.   One client_id may have many instances all using different values of the code proof of possession simultaneously.

So I prefer to eliminate the term client secret entirely.

On 2013-08-28, at 12:12 PM, Sergey Beryozkin <[email-masked]> wrote:

> Hi,
> 
> can you consider replacing "tcs" and "tcsh" with "temp_client_secret" and "temp_client_secret_hash" ? in OAuth2 we have "client_id", "client_secret" (ex, in dyn reg), and having a temp variant of "client_secret" called as "tcs" seems a bit cryptic to me :-), not a bit issue though
> 
> Sergey
> 
>>    <http://tools.ietf.org>.

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 28 Aug 2013 18:01:42 +0100

> So I prefer to eliminate the term client secret entirely.
OK

thanks, Sergey