Subject: [OAUTH-WG] Security considerations in draft-sakimura-oauth-tcse-03

From: Josh Mandel <[email-masked]>
Date: Wed, 14 May 2014 16:43:03 -0700

Forgive me if this is well-trodden territory, but I would have expected the
security considerations in this proposal to include a note to the effect of:

"In a scenario where a mobile client is contending with malicious apps on
the same device that listen on the same custom URL scheme, it's important
to keep in mind that a malicious app can initiate its own authorization
request. Such a request  would appear the same as a legitimate request from
the end-user's perspective. So in this case, a malicious app could request
its own verifier code and successfully obtain authorization using the tcse
protocol."

Obviously this does not negate the value of the proposal, but it's
something I'd expect readers to keep in mind.

In particular, it has very strong implications for whitelisted
authorizations, where no end user interaction is required. In such a case,
a malicious app could initiate a request at any time and the user would not
be in the loop to raise a question about its legitimacy.

On May 9, 2014 4:51 PM, "Brian Campbell" <[email-masked]> wrote:
>
> I notice that code_verifier is defined as "high entropy cryptographic
random string of length less than 128 bytes"  [1], which brought a few
questions and comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always
potentially confusing. Maybe characters would be an easier unit for people
like me to wrap their little brains around?
>
> Why are we putting a length restriction on the code_verifier anyway? It
seems like it'd be more appropriate to restrict the length of the
code_challenge because that's the thing the AS will have to maintain
somehow (store in a DB or memory or encrypt into the code). Am I missing
something here?
>
> Let me also say that I hadn't looked at this document since its early
days in draft -00 or -01 last summer but I like the changes and how it's
been kept pretty simple for the common use-case while still allowing for
crypto agility/extension. Nice work!
>
> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 15 May 2014 09:23:23 -0400

True... but isn't this then just a standard "phishing" attack? Even 
today, any app can attempt to start an authorization if it knows the 
client_id (which isn't protected) and the registered callback URL. The 
user has to determine if they think the particular app asking for 
authorization should be granted that authorization.

Am I missing something?

Thanks,
George

On 5/14/14, 7:43 PM, Josh Mandel wrote:
>
> Forgive me if this is well-trodden territory, but I would have 
> expected the security considerations in this proposal to include a 
> note to the effect of:
>
> "In a scenario where a mobile client is contending with malicious apps 
> on the same device that listen on the same custom URL scheme, it's 
> important to keep in mind that a malicious app can initiate its own 
> authorization request. Such a request  would appear the same as a 
> legitimate request from the end-user's perspective. So in this case, a 
> malicious app could request its own verifier code and successfully 
> obtain authorization using the tcse protocol."
>
> authorizations, where no end user interaction is required. In such a 
> case, a malicious app could initiate a request at any time and the 
> user would not be in the loop to raise a question about its legitimacy.
>
> On May 9, 2014 4:51 PM, "Brian Campbell" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> > I notice that code_verifier is defined as "high entropy 
> cryptographic random string of length less than 128 bytes"  [1], which 
> brought a few questions and comments to mind. So here goes:
> >
> potentially confusing. Maybe characters would be an easier unit for 
> people like me to wrap their little brains around?
> >
> > Why are we putting a length restriction on the code_verifier anyway? 
> It seems like it'd be more appropriate to restrict the length of the 
> somehow (store in a DB or memory or encrypt into the code). Am I 
> missing something here?
> >
> > Let me also say that I hadn't looked at this document since its 
> early days in draft -00 or -01 last summer but I like the changes and 
> how it's been kept pretty simple for the common use-case while still 
> allowing for crypto agility/extension. Nice work!
> >
> > [email-masked] <mailto:[email-masked]>

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Josh Mandel <[email-masked]>
Date: Thu, 15 May 2014 09:59:19 -0400

Hi George,

You of course characterize "today's" scenario correctly: any app can start
an authorization and successfully complete it if the user approves. But
that's not "just" phishing, at least in the typical sense, because the
approval screen itself is in fact the approval screen for the genuine app.
When a user is looking at that screen, there's nothing in the content, URL
bar or SSL settings to indicate anything's wrong. The only possible clue is
the temporal context about how she got to that screen (and even that can be
counterfeited -- e.g. by a malicious app that waits for the genuine app to
launch and then immediately executes a permission request).

So there are really two problems:

1. A malicious app can start its own authorization request and successfully
complete it if approval is granted
2. A malicious app can intercept the genuine app's authorization process
and steal a token-equivalent

It's unfair to call #1 a "user-error" because there may be literally no way
for the user to tell the difference. If anything, the user-error was to
install the malicious app in the first place. But this is a distraction for
two reasons: first, because even a knowledgeable end-user can't actually
tell what custom URI schemes an app is going to listen on, and second
because the presence of a malicious app on-device is a precondition for
TSCE anyway. It's already part of the threat model that TSCE mitigates
against.

So to summarize: TSCE explicitly addresses #2 but is silent about #1. I
think it should explicitly explain that it can't solve #1. I claim this is
important because concerns #1 and #2 both apply in the same context: a
mobile environment where the end-user has *already* installed a malicious
app on her device, and that malicious app has registered for the same
custom URI scheme as the genuine app.

I think this point is especially important given one implication: that TCSE
cannot safely be used in conjunction with server-determined permission
whitelists. This implication should also be made explicit.

  -J

On Thu, May 15, 2014 at 9:23 AM, George Fletcher <[email-masked]> wrote:

> client_id (which isn't protected) and the registered callback URL. The user
> has to determine if they think the particular app asking for authorization
> should be granted that authorization.
>
> Am I missing something?
>
> Thanks,
> George
>
> Forgive me if this is well-trodden territory, but I would have expected
> the security considerations in this proposal to include a note to the
> effect of:
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
>  <http://connect.me/gffletch>
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 22 May 2014 10:13:54 +0900

Thanks. I will push it to the next rev.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en