Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 20 Feb 2011 20:05:21 +0100

Hi all,

on behalf of Mark, Phil and myself I just submitted the OAuth 2.0 
security document. This document gives security considerations based on 
a comprehensive
threat model for the OAuth 2.0 Protocol. It is intended for multiple 
purposes:

1) It shall be the foundation of the core draft's security 
considerations section.
2) It shall foster discussion about OAuth 2.0 security inside and 
outside the WG
3) It might become the foundation of security threat models and 
considerations for protocols built on top of OAuth 2.0

We highly appreciate any constructive feedback.

regards,
Torsten.

-------- Original-Nachricht --------
Betreff: 	New Version Notification for draft-lodderstedt-oauth-security-00
Datum: 	Sun, 20 Feb 2011 10:52:50 -0800 (PST)
Von: 	IETF I-D Submission Tool <[email-masked]>
An: 	[email-masked]
CC: 	[email-masked],[email-masked]

A new version of I-D, draft-lodderstedt-oauth-security-00.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Filename:	 draft-lodderstedt-oauth-security
Revision:	 00
Title:		 OAuth 2.0 Threat Model and Security Considerations
Creation_date:	 2011-02-20
WG ID:		 Independent Submission
Number_of_pages: 51

Abstract:
This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol.

The IETF Secretariat.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 20 Feb 2011 16:47:45 -0700

Thanks for submitting this draft.

How do you envision this being incorporated into v2? Just section 5 or the entire document?

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Sunday, February 20, 2011 11:05 AM
To: OAuth WG
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00

Hi all,

on behalf of Mark, Phil and myself I just submitted the OAuth 2.0 security document. This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol. It is intended for multiple purposes:

1) It shall be the foundation of the core draft's security considerations section.
2) It shall foster discussion about OAuth 2.0 security inside and outside the WG
3) It might become the foundation of security threat models and considerations for protocols built on top of OAuth 2.0

regards,
Torsten.

-------- Original-Nachricht --------
Betreff:

New Version Notification for draft-lodderstedt-oauth-security-00

Datum:

Sun, 20 Feb 2011 10:52:50 -0800 (PST)

Von:

IETF I-D Submission Tool <[email-masked]><mailto:[email-masked]>

An:

[email-masked]<mailto:[email-masked]>

CC:

[email-masked],[email-masked]<mailto:[email-masked],[email-masked]>

Revision:      00

Number_of_pages: 51

Abstract:

The IETF Secretariat.

---

From: Brian Eaton <[email-masked]>
Date: Mon, 21 Feb 2011 21:36:11 -0800

> How do you envision this being incorporated into v2? Just section 5 or the

My two cents: rather than dedicating a single section of the core doc to
security considerations, smaller sections should be added to individual
profiles.  I think the following sections would be useful:

User-agent and web-server flow: mostly the same security considerations for
these two flows.  I think there are subsections here.
   1) Authorization server implementation
   2) Client implementation

Token design: Design and implementation recommendations for refresh tokens
and access tokens.

Client id, client secret, and assertions: when and how to use client
secrets, when and how to use assertions, how to store, etc...

Other flows: each of the other flows has separate security considerations.
 In some cases they are brief, but they pretty much always need to be there.

Cheers,
Brian

---

From: Francisco Corella <[email-masked]>
Date: Mon, 21 Feb 2011 21:57:19 -0800 (PST)

Hi Torsten,

> 4.4.1.2.  Threat: Eavesdropping authorization codes
> 
> The OAuth specification does not describe any mechanism for
> protecting authorization codes from eavesdroppers when they are
> transmitted from the Service Provider to the Client and where the
> Service Provider Grants an Access Token.
> 
> Note: A description of a similar attack on the SAML protocol can be
> found at http://www.oasis-open.org/committees/download.php/3405/
> oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1).
> 
> Countermeasures:
> 
> o  The authorization server SHOULD enforce a one time usage
>    restriction (see Section 5.1.5.4).  Authorization server as well
>    as Resource server MUST ensure that these transmissions are
>    protected using transport-layer mechanisms such as TLS or SSL
>    (see Section 5.1.1).

You are talking here about eavesdropping to obtain the authorization
code.  The authorization code is not sent to the resource servers.  I
agree that the authorization code must be protected by TLS when it is
sent by the client to the authorization server.  But it must ALSO be
protected when it is sent by the browser to the client.  (The
connection from the browser to the client is easier to eavesdrop on
than the connection from the client to the authorization server!)  (It
must also be protected when sent from the authorization server to the
browser in the redirection response, which is probably the case
anyway, since that's the response portion of the HTTP request that
authenticates the user.)

> ...
>
> 4.4.1.6.  Threat: Authorization code phishing
> 
> A hostile party could act as the client web server and get access to
> the authorization code.  This could be achieved using DNS or ARP
> spoofing.  

Yes.

> Impact: This affects web applications and may lead to a
> disclosure of authorization codes and, potentially, the corresponding
> access and refresh tokens.

The attacker will not get the access and refresh tokens without the
client_id, but doesn't need to.  The attacker can impersonate the
user, log in to the client if the protocol is used for social login
as in "log in with Facebook", and use the client to obtain protected
resources of the legitimate user and deliver them to the attacker.
The attacker never sees an access token, but the client gets the
access token and uses it for the benefit of the attacker.

> Countermeasures:
> 
> o  The client shall authenticate the server using server
>    authentication - Section 5.1.2

Really?????????  The browser is sending the authorization code to the
client, and the attacker is using DNS or ARP spoofing to receive it
instead of the client.  To prevent this, what's needed is obviously
authentication of the client by the browser, not authentication of the
server by the client!

> o  The authorization server shall require the client to authenticate
>    with a secret, so the binding of the authorization code to a
>    certain client can be validated in a reliable way (see
>    Section 5.2.4.4).

Client authentication to the server does not prevent the attack.

The authorization code is a credential that provides access to the
user's protected resources (via the client) and allows the user to log in
to the client (in a social-login scenario).  Sending it without TLS
protection, as OAuth 2.0 does, is tantamount to sending a user
password without TLS protection.  

If you are not convinced please read the message I sent you a few
weeks ago, available at
http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, and
section 3.5.3 of the security analysis paper I announced earlier,
available at http://www.pomcor.com/techreports/DoubleRedirection.pdf.
(Section 3.5.3 refers to section 2; if you don't want to read the
whole section 2, the relevant portion is the last three paragraphs of
page 4.)

Francisco

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Feb 2011 11:40:12 -0700

IETF rules require a security considerations section. That doesn't mean we can't also incorporate additional security text into each grant section. But having one comprehensive security section makes the other parts easier to read.

EHL

From: Brian Eaton [mailto:[email-masked]]
Sent: Monday, February 21, 2011 9:36 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00

On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
How do you envision this being incorporated into v2? Just section 5 or the entire document?

My two cents: rather than dedicating a single section of the core doc to security considerations, smaller sections should be added to individual profiles.  I think the following sections would be useful:

User-agent and web-server flow: mostly the same security considerations for these two flows.  I think there are subsections here.
   1) Authorization server implementation
   2) Client implementation

Token design: Design and implementation recommendations for refresh tokens and access tokens.

Client id, client secret, and assertions: when and how to use client secrets, when and how to use assertions, how to store, etc...

Other flows: each of the other flows has separate security considerations.  In some cases they are brief, but they pretty much always need to be there.

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 23 Feb 2011 20:13:56 +0100

I would tend to add section 5 as security considerations section to the 
core draft expanded by descriptions of relevant (generic) threats.

We could also add parts of the flow-specific threat model descriptions 
into to flow-specific sections of the core draft and link them to the 
security considerations sections.

@Brian: where would you place the discussion of the design alternatives? 
Our document has them before the threat model.

regards,
Torsten.

Am 22.02.2011 19:40, schrieb Eran Hammer-Lahav:
>
> IETF rules require a security considerations section. That doesn't 
> mean we can't also incorporate additional security text into each 
> grant section. But having one comprehensive security section makes the 
> other parts easier to read
>
> EHL
>
> *From:*Brian Eaton [mailto:[email-masked]]
> *Sent:* Monday, February 21, 2011 9:36 PM
> *To:* Eran Hammer-Lahav
> *Cc:* Torsten Lodderstedt; OAuth WG
> *Subject:* Re: [OAUTH-WG] Fwd: New Version Notification for 
> draft-lodderstedt-oauth-security-00
>
> On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> My two cents: rather than dedicating a single section of the core doc 
> to security considerations, smaller sections should be added to 
> individual profiles.  I think the following sections would be useful:
>
> User-agent and web-server flow: mostly the same security 
> considerations for these two flows.  I think there are subsections here.
>
> Other flows: each of the other flows has separate security 
> considerations.  In some cases they are brief, but they pretty much 
> always need to be there.
>
> Cheers,
>
> Brian
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 23 Feb 2011 20:44:37 +0100

Hi Francisco,

> code.  The authorization code is not sent to the resource servers.  I

true, this was a mistake.

> anyway, since that's the response portion of the HTTP request that

That's correct. I changed resource server to client.

> client_id, but doesn't need to.
>

whether this is an obstacle mainly depends on whether a client secret is 
associated with this client_id.

> The attacker can impersonate the

You describe the potential impact of a spoofing attack on the client web 
site, correct? Is this specific to OAuth? I ask because the focus of the 
document is on OAuth specific threats.

> authentication of the client by the browser, not authentication of the

You are right. Things are getting less obvious after 6 month of work on 
a document :-) I corrected that.

> password without TLS protection.

Hmmh, OAuth 2.0 is just a protocol. Implementations decide to 
send/receive authorization codes with or without TLS protection. Having 
the security threat model now, the OAuth 2.0 spec could declare TLS 
protection a MUST for the redirect back to the clients. I think that's 
what you would like to see?

regards,
Torsten.

---

From: Francisco Corella <[email-masked]>
Date: Wed, 23 Feb 2011 14:45:21 -0800 (PST)

Hi Torsten,

> > The attacker will not get the access and refresh tokens
> > without the client_id, but doesn't need to.
> 
> whether this is an obstacle mainly depends on whether a
> client secret is associated with this client_id.

You're right, I meant to say client_secret, not client_id.

> ...
>
> > The attacker can impersonate the user, log in to the
> > client if the protocol is used for social login as in
> > "log in with Facebook", and use the client to obtain
> > protected resources of the legitimate user and deliver
> > them to the attacker.  The attacker never sees an access
> > token, but the client gets the access token and uses it
> > for the benefit of the attacker.
> 
> You describe the potential impact of a spoofing attack on
> the client web site, correct? Is this specific to OAuth? I
> ask because the focus of the document is on OAuth specific
> threats.

I was talking about your scenario where an attacker uses DNS
spoofing or ARP spoofing to get the authorization code, and
more generally about an attacker obtaining the authorization
code by any means.  It's definitely specific to OAuth.

> ...
>
> > The authorization code is a credential that provides
> > access to the user's protected resources (via the
> > client) and allows the user to log in to the client (in
> > a social-login scenario).  Sending it without TLS
> > protection, as OAuth 2.0 does, is tantamount to sending
> > a user password without TLS protection.
> 
> Hmmh, OAuth 2.0 is just a protocol. Implementations decide
> to send/receive authorization codes with or without TLS
> protection. Having the security threat model now, the
> OAuth 2.0 spec could declare TLS protection a MUST for the
> redirect back to the clients. I think that's what you
> would like to see?

Yes, I'm saying that transmission of the authorization code
to the client must be protected by TLS, just like you say
that transmission of the authorization code to the
authorization server must be protected by TLS (section
4.4.1.2) and all transmissions of the access token must be
protected by TLS (section 4.1.3), and just like the bearer
token specification says that transmission of the token to a
resource server must be protected by TLS (section 3.2).

The thing to keep in mind is that the authorization code
deserves as much protection as the access token because an
attacker can use the authorization code to cause the client
to obtain the access token and use it for the attacker's
benefit.  Plus, the attacker can use the authorization code
to log in to the client in a social login scenario, so the
authorization code is arguably more valuable than the access
token to the attacker.

Francisco