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

[John Bradley <[e-mail]>]

Hannes,

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


> On Nov 19, 2014, at 7:44 AM, Hannes Tschofenig <[e-mail]> wrote:
> 
> 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
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth