Subject: [OAUTH-WG] TLS is needed for redirecting back to the client

From: Francisco Corella <[email-masked]>
Date: Mon, 3 Jan 2011 22:11:05 -0800 (PST)

Hi all,

The OAuth spec recommends the use of TLS when sending
requests to the end-user authorization endpoint and requires
it when sending requests to the token endpoint.  It says
nothing about using TLS when redirecting the browser back to
the client, which implies that it is not needed for that
purpose.

In fact, TLS is needed just as much when redirecting back to
the client as when sending requests to the token endpoint.
If TLS is not used when redirecting back, the following
attack, which is easy to implement, allows the attacker to
impersonate a resource owner and gain access to protected
resources.

The resource owner goes to an airport or a coffee house with
a laptop.  The attacker is sitting at the airport or coffee
house with a loptop that implements a rogue Wifi access
point.  (Using a laptop as a rogue access point has always
been easy to do, and it may have become easier with the soft
access point feature of Windows 7.)  The resource owner
connects to the Internet through the rogue access point.
The attacker can observe all traffic that is not encrypted
by TLS.

The resource owner tries to use a client application to
access a protected resource.  The client application, which
implements the web server client profile, has registered
with an authorization server, and has been issued a client
identifier and client password credentials by the
authorization server.

The resource owner accesses the client application.  The
client application redirects the resource owner to the
authorization server.  The authorization server
authenticates the resource owner and redirects the resource
owner's browser to the redirection URI of the client
application.  The scheme of the redirection URI is http
rather than https.  The redirected request conveys the
authorization code to the client application.  The client
application uses the authorization code and its client
password credentials to obtain an access token from the
authorization server.

When it obtains the access token, the client application
logs in the resource owner (as applications typically do)
creating a session record where it stores the access token,
so that it can use it later to access protected resources as
requested by the resource owner.  The client application
sets an authentication cookie in the resource owner's
browser (as applications typically do) which refers to the
session record and is used to authenticate subsequent
requests to the client application from the resource owner.

The authentication cookie is set by the http response to the
request that conveyed the authorization code to the client
application.  That request was sent to the redirection URI,
and was not encrypted by TLS.  Therefore the attacker can
observe the authentication cookie.  As soon as the attacker
observes the cookie, it terminates the wireless connection
of the resource owner, and starts using the cookie to
impersonate the resource owner.  The attacker uses the
cookie to make requests to the application for protected
resources, and the application accesses those protected
resources using the access token stored in the browser
record referenced by the cookie.

There is a variation of the attack that uses DNS spoofing.
DNS spoofing is easy to set up on a laptop that implements a
rogue access point.  The attacker spoofs the DNS vis-a-vis
the resource-owner's laptop, mapping the domain name of the
client application to the LAN-side IP address of the rogue
address point.  The attacker's laptop then proxies the
connection from the resource owner's laptop to the client,
which is possible because the connection is not protected by
TLS.  The attacker has thus easy access to the
authentication cookie.

Besides OAuth, the attack works against OpenID, which fails
to recommend the use of TLS for the redirection from the
OpenID Provider back to the Relying party.  The attack also
affected my own little PKAuth protocol (discussed in the
unregistered applications thread), which also uses a double
redirection mechanism.  PKAuth uses TLS throughout, but I
was implicitly making the claim that it provided protection
even if the user ignored an invalid-certificate warning from
the browser.  I've now removed that claim.

Francisco

---

From: [email-masked]
Date: Tue, 4 Jan 2011 07:27:20 +0000

Francisco,

you made a good point. However, the question is if this belongs into the OAuth scope since this a general attack on a web app's session management. 

I will incorporate the threat you described and the advice to use TLS into the OAuth security document.

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Francisco Corella <[email-masked]>
Sender: [email-masked]
Date: Mon, 3 Jan 2011 22:11:05 
To: <[email-masked]>
Reply-To: [email-masked]
Cc: Karen P. Lewison<[email-masked]>
Subject: [OAUTH-WG] TLS is needed for redirecting back to the client

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Francisco Corella <[email-masked]>
Date: Tue, 4 Jan 2011 13:27:22 -0800 (PST)

Torsten,

> you made a good point. However, the question is if this
> belongs into the OAuth scope since this a general attack on
> a web app's session management.

I gave two variants of the attack.  I agree that the first
variant "looks like" an attack against session management,
but the second variant is clearly an attack against the
protocol.

Let me recap the second variant.

The attacker compromises the DNS, mapping the domain name in
the redirection URI to the attacker's machine.  The http
request sent by the resource owner's browser to the
redirection uri, which contains the authorization code, is
received by the attacker's machine.  The attacker forwards
the request with the authorization code to the client
application from the attacker's own machine, thereby
impersonating the resource owner.  The client application
mistakenly authenticates the attacker as the resource owner
after verifying that the authorization code is legitimate by
using it to get an access code from the authorization
server.  After the mistaken authentication, the client
application creates a session and gives an authentication
cookie to the attacker.

Let me philosophize a bit.

OAuth was conceived as an authorization protocol, hence the
vocabulary ("authorization server", "resource owner"), but
it has morphed.  Now it is also used for authentication.
When you click on a button "Login with Twitter" or "Login
with Facebook" you are authenticated with OAuth: Twitter and
Facebook do not currently support OpenID for social login.

When OAuth is used for authentication, the authorization
code takes on a different role: posession of the
authorization code is what authenticates the user.
Therefore transmission of the authorization code must be
protected by TLS.

Let me philosophize some more.  (Busy people should stop
reading here ;-)

We need a protocol that does both authentication and
authorization.  We can take OAuth and adapt it for
authentication, or take OpenID and adapt it for
authorization, or combine OpenID and OAuth (great solution
for people who love complexity) or... take the best ideas
from OpenID and OAuth and incorporate them into a new
protocol that's designed from the start for both
authentication and authorization.  That's one of my
motivations for proposing PKAuth.

Now a political speech.

Social login is going to win.  (I use "social login" as
Janrain uses it, I believe they coined the term, is that
right?)  It will win because it has tremendous advantages
not just for users (that's not enough), but also for social
sites and applications.  Once it wins we may get into a
situation where social login with the social identity
provided by the dominant social site (currently Facebook)
becomes the de fact standard for user authentication on the
Web.  If the dominant social site requires application
registration, then every application on the Web will have to
register with the dominant social site just to be able to
authenticate its users, whether or not they have anything to
do with the social site.

The dominant social site would then have to power to kill
any application by terminating its registration.  This would
be an intolerable situation for everybody, including the
dominant social site.  The dominant social site will not
need or want this kind of power, which would call for
government regulation by every government on the planet.

So we need an authentication and authorization protocol
where application registration is optional.  But
registration has an essential function in OAuth.  The social
site relies on registration to be able to reliably identify
the application to the user.  We need a protocol that can
reliably identify unregistered applications to the user.
That's a second motivation for PKAuth.

Francisco

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 Jan 2011 13:37:28 -0800

> motivations for proposing PKAuth.

Are you aware of OpenIDConnect?

http://openidconnect.com/

Marius

---

From: [email-masked]
Date: Tue, 4 Jan 2011 21:43:15 +0000

What is the status of openid connect and what organisation ist standardizing it?
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 Jan 2011 13:37:28 
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; Karen P. Lewison<[email-masked]>
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client

Marius

---

From: Justin Richer <[email-masked]>
Date: Tue, 4 Jan 2011 16:46:30 -0500

> http://openidconnect.com/

And also the latest drafts of OpenID Artifact Binding:

http://wiki.openid.net/w/page/12995134/Artifact-Binding

(Don't have a link to the latest draft spec that uses OAuth2
terminology-- Nat, do you have something?)

 -- Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 04 Jan 2011 22:54:48 +0100

Francisco,

the attack you described sounds very similar to session fixation 
attacks. TLS (more specifically server authentication) is one way to 
cope with spoofing in general (supposed the client has a reasonably CA 
policy). So it should do in this case, too.

Validation of the redirect_uri associated with a particular 
authorization code on the tokens endpoint is another way to 
detect/prevent such an attack. Supposed the attacker has to inject the 
tapped authorization code into the client application during a second 
authorization flow. If the client uses different redirect_uri's for 
every flow, the attempt to inject the code can be detected.

What do you think?

regards,
Torsten.

---

From: Francisco Corella <[email-masked]>
Date: Tue, 4 Jan 2011 16:55:41 -0800 (PST)

> http://openidconnect.com/

I stumbled upon that page recently while doing a search, but
didn't look at it in any detail because it looked like an
abandoned draft, and another complicated combination of
OpenID and OAuth.

I've looked at it in more detail now, and I've found
something interesting.  The last section discusses
unregistered applications, and it has a paragraph in italics
that addresses the issue of how the server can identify an
unregistered application to a user, which is the main issue
that I'm trying to address with PKAuth:

---- quote ----
Maybe add client discovery here if the server wants to
verify the redirect URL exists and is valid for the
domain. Thinking you fetch
https://domain/.well-known/host-meta and look for
openid:redirect_uri. Also useful to get the client's display
name and logo which the server can display to the user. The
client would also use host-meta to advertise information
needed for web browsers to help manage identity.
---- end of quote ----

In the paper I consider an attacker who owns the domain
example.com and hosts an application at pomcor.example.com
to trick the user into believing that it belongs to Pomcor.
Both OpenID and OAuth will identify the application to the
user as "pomcor.example.com" which I argue is not good
enough.  But OpenID Connect is much worse!  OpenID Connect
will identify the application to the user with a display
name and a logo PROVIDED BY THE ATTACKER.  So the attacker
can just provide "Pomcor" as the display name and the Pomcor
logo and the user is taken in.

Francisco

---

From: Francisco Corella <[email-masked]>
Date: Tue, 4 Jan 2011 17:03:57 -0800 (PST)

> http://wiki.openid.net/w/page/12995134/Artifact-Binding

I'm not familiar with that, and I haven't been able to find
a draft at the site.

Francisco

---

From: Francisco Corella <[email-masked]>
Date: Tue, 4 Jan 2011 17:26:42 -0800 (PST)

--- On Tue, 1/4/11, Torsten Lodderstedt <[email-masked]> wrote:
> the attack you described sounds very similar to session
> fixation attacks. TLS (more specifically server
> authentication) is one way to cope with spoofing in general
> (supposed the client has a reasonably CA policy). So it
> should do in this case, too.

Yes, TLS is the solution for both variants of the attack.

> detect/prevent such an attack. Supposed the attacker has to
> inject the tapped authorization code into the client
> application during a second authorization flow. If the
> client uses different redirect_uri's for every flow, the
> attempt to inject the code can be detected.

This I don't understand.  The redirect_uri is alwasy the
same...

Francisco

---

From: [email-masked]
Date: Wed, 5 Jan 2011 06:17:02 +0000

The client could just add another random string with every authorization request.

Regards,
Torsten.

-----Original Message-----
From: Francisco Corella <[email-masked]>
Date: Tue, 4 Jan 2011 17:26:42 
To: Torsten Lodderstedt<[email-masked]>
Reply-To: [email-masked]
Cc: <[email-masked]>; Karen P. Lewison<[email-masked]>
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client

Francisco

---

From: Mike Jones <[email-masked]>
Date: Wed, 5 Jan 2011 17:18:26 +0000

You can read about the Artifact Binding at https://bitbucket.org/openid/ab/wiki/Home.  The latest draft is at https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_0.html.  Nat Sakimura is actively updating the specification as we speak, incorporating some of the ideas from OpenID Connect.  The merger of the specs that Nat is working on is sometimes referred to as OpenID Artifact Binding/Connect or OpenID ABC for short.  FYI, specification will be using JSON Web Tokens (JWTs).

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Francisco Corella
Sent: Tuesday, January 04, 2011 5:04 PM
To: Marius Scurtescu; Justin Richer
Cc: [email-masked]; Karen P. Lewison
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client

Francisco

---

From: Francisco Corella <[email-masked]>
Date: Wed, 5 Jan 2011 16:16:31 -0800 (PST)

Mike,

Thank you very much for sending the links to the artifact binding home page and spec.  I've had a quick look, and maybe I'm missing something, but it seems that this completely ignores the problem of authenticating the relying party.  In section 7.4.1, the RP registers on the fly just by telling the OP who it claims to be, and the OP takes the RP's word for it without any verification and issues a client_secret.  Same as OpenID Connect.

OpenID 2.0 at least goes to the trouble of asking the user whether he/she trusts the realm, and then verifying the return_url against the realm.  I don't think that's sufficient, but it's better than nothing.

Francisco

--- On Wed, 1/5/11, Mike Jones <[email-masked]> wrote:

From: Mike Jones <[email-masked]>
Subject: RE: [OAUTH-WG] TLS is needed for redirecting back to the client
To: "[email-masked]" <[email-masked]>, "Marius Scurtescu" <[email-masked]>, "Justin Richer" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Karen P. Lewison" <[email-masked]>, "Nat Sakimura ([email-masked])" <[email-masked]>, "John Bradley" <[email-masked]>
Date: Wednesday, January 5, 2011, 5:18 PM

You can read about the Artifact Binding at
https://bitbucket.org/openid/ab/wiki/Home.  The latest draft is at

https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_0.html.  Nat Sakimura is actively updating the specification as we speak, incorporating some of the ideas from OpenID Connect.  The merger of the specs that Nat is working on is
 sometimes referred to as OpenID Artifact Binding/Connect or OpenID ABC for short.  FYI, specification will be using JSON Web Tokens (JWTs). 
   
                                                                -- Mike 
   
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Francisco Corella

> > > authorization, or combine OpenID and OAuth (great

> > > solution

> > > for people who love complexity) or... take the best

> > > ideas

a draft at the site.

Francisco

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 14 Jan 2011 08:24:33 +0900

On Thu, Jan 6, 2011 at 9:16 AM, Francisco Corella <[email-masked]>wrote:

> Mike,
>
> Thank you very much for sending the links to the artifact binding home page
> and spec.  I've had a quick look, and maybe I'm missing something, but it
> seems that this completely ignores the problem of authenticating the relying
> party.  In section 7.4.1, the RP registers on the fly just by telling the OP
> who it claims to be, and the OP takes the RP's word for it without any
> verification and issues a client_secret.  Same as OpenID Connect.
>

7.4.1 was taken from OpenID Connect proposal. Primary mode for Artifact
Binding was the Asymmetric Keys.
Whether allowing dynamic association is entirely at the discretion of the
IdP.
I can imagine that IdP whitelisting or using whitelist from a trust
framework will be the main mode of operation. This is not going to be in the
protocol spec, but should be dealt with the Profiles that are defined by
some sort of Trust Framework.

>
> OpenID 2.0 at least goes to the trouble of asking the user whether he/she
> trusts the realm, and then verifying the return_url against the realm.  I
> don't think that's sufficient, but it's better than nothing.
>

ABC may go much further than this, especially when using the asymmetric
signatures and encryption. Whether the IdP is going to be operating in that
mode is dependent on what kind of Trust Framework it is going to use. We
should not conflate the protocol and the trust framework issues.

FYI, the refactoring that we are doing for ABC spec right now is:

0. Signature, Encryption and Token. (JWT)
1. Core: defines the message format and abstract protocols.
2. Protocol Binding binds the Core into a specific flow/protocols.
3. Profiles (which are to be defined by the Trust Frameworks) further
constrains the bindings.
4. Discovery
5. Dynamic Registration
6. Session Management

=nat

>
> Francisco
>
> --- On *Wed, 1/5/11, Mike Jones <[email-masked]>* wrote:
>
>
> To: "[email-masked]" <[email-masked]>, "Marius Scurtescu" <
> [email-masked]>, "Justin Richer" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "Karen P. Lewison" <
> [email-masked]>, "Nat Sakimura ([email-masked])" <[email-masked]>,
> "John Bradley" <[email-masked]>
> https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_0.html.
> Nat Sakimura is actively updating the specification as we speak,
> incorporating some of the ideas from OpenID Connect.  The merger of the
> specs that Nat is working on is sometimes referred to as OpenID Artifact
> Binding/Connect or OpenID ABC for short.  FYI, specification will be using
> JSON Web Tokens (JWTs).
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Francisco Corella
> *Sent:* Tuesday, January 04, 2011 5:04 PM
> *To:* Marius Scurtescu; Justin Richer
> *Cc:* [email-masked]; Karen P. Lewison
> *Subject:* Re: [OAUTH-WG] TLS is needed for redirecting back to the client
>
>
>
> --- On Tue, 1/4/11, Justin Richer <[email-masked]<http://mc/compose?to=[email-masked]>>
> wrote:

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 14 Jan 2011 08:26:27 +0900

=nat

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en