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

[Nat Sakimura <[e-mail]>]

Thanks Hannes!

Nat
On Wed Nov 19 2014 at 21:49:07 John Bradley <[e-mail]> wrote:

> 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
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>