Hannes, Thanks for the feedback. I will go over it today.
> On Nov 19, 2014, at 7:44 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
