Subject: [OAUTH-WG] Text Proposal for draft-ietf-oauth-spop-04

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Nov 2014 13:44:46 +0100

Hi Nat,

I have a few text suggestions for the abstract and the intro.

FROM:

Abstract

   The OAuth 2.0 public client utilizing Authorization Code Grant (RFC
   6749 - 4.1) is susceptible to the code interception attack.  This
   specification describes a mechanism that acts as a control against
   this threat.

TO:

Abstract

   OAuth 2.0 public clients utilizing the Authorization Code Grant are
   susceptible to the authorization code interception attack.  This
specification
   describes the attack as well as a technique to mitigate against the
   threat.

New text for the into:

1.  Introduction

   OAuth 2.0 [RFC6749] public clients are susceptible to the
   authorization code interception attack.

   The attacker thereby intercepts the authorization code returned
   from the authorization endpoint within communication path not
   protected by TLS, such as inter-app communication within the
   operating system of the client.

   Once the attacker has gained access to the authorization code it
   can use it to obtain the access token.

   Figure 1 shows the attack graphically. In step (1) the native
   app running on the end device, such as a smart phone, issues
   an authorization request via the browser/operating system, which
   then gets forwarded to the OAuth 2.0 authorization server in
   step (2). The authorization server returns the authorization code
   in step (3). The malicious app is able to observe the
   authorization code in step (4) since it is registered to the
   custom URI scheme used by the legitimate app. This allows the
   attacker to reguest and obtain an access token in step (5)
   and step (6), respectively.

 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
 | End Device (e.g., Smart Phone) |
 |                                |
 | +-------------+   +----------+ | (6) Access Token  +----------+
 | |Legitimate   |   | Malicious|<--------------------|          |
 | |OAuth 2.0 App|   | App      |-------------------->|          |
 | +-------------+   +----------+ | (5) Authorization |          |
 |        |    ^          ^       |        Grant      |          |
 |        |     \         |       |                   |          |
 |        |      \   (4)  |       |                   |          |
 |    (1) |       \  Authz|       |                   |          |
 |   Authz|        \ Code |       |                   |  Authz   |
 | Request|         \     |       |                   |  Server  |
 |        |          \    |       |                   |          |
 |        |           \   |       |                   |          |
 |        v            \  |       |                   |          |
 | +----------------------------+ |                   |          |
 | |                            | | (3) Authz Code    |          |
 | |     Operating System/      |<--------------------|          |
 | |         Browser            |-------------------->|          |
 | |                            | | (2) Authz Request |          |
 | +----------------------------+ |                   +----------+
 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

   Figure 1: Authorization Code Interception Attack.

   A number of pre-conditions need to hold in order for this attack
   to work:

   1) The attacker manages to register a malicious application on
      the client device and registers a custom URI scheme that is
      also used by another application.

      The operating systems must allow a custom URI schemes to
      be registered by multiple applications.

   2) The OAuth 2.0 authorization code grant is used.

   3) The attacker has access to the client id. All native app
      client-instances use the same client id. No client secret is
      used (since public clients cannot keep their secrets
      confidential.)

   4) The attacker (via the installed app) is able to observe
      responses from the authorization endpoint. As a more
      sophisticated attack scenario the attacker is also able
      to observe requests (in addition to responses) to the
      authorization endpoint. The attacker is, however, not
      able to act as a man-in-the-middle.

   While this is a long list of pre-conditions the described attack
   has been observed in the wild and has to be considered in
   OAuth 2.0 deployments. While Section 4.4.1 of [RFC6819] describes
   mitigation techniques they are, unfortunately, not applicable
   since they rely on a per-client instance secret or aper client
   instance redirect URI.

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Nov 2014 07:48:49 -0500

Hannes,

Thanks for the feedback.   I will go over it today.

> On Nov 19, 2014, at 7:44 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Nat,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 20 Nov 2014 10:53:40 +0000

Thanks Hannes!

Nat