Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)

From: Mark Mcgloin <[email-masked]>
Date: Fri, 1 Apr 2011 10:11:11 +0100

So we have 2 different communities of Oauth developers that will never
agree.

SHOULD: Typically the social networking sites that need to cater for tail
end developers by not enforcing TLS on redirect_uri. It is a risk to think
that using strong language in the spec will help them appreciate the issues
MUST: Typically enterprise organisations (I am in this camp). They can
enforce indirectly by only supporting registered callback urls and ensure
those use TLS

Is there any way the spec can be altered to cater for both camps. How about
an additional grant type = 'secure_code' which mandates the use of TLS.
This won't break anyone using the current grant type = 'code' and providers
can choose which to support.

Mark

[email-masked] wrote on 01/04/2011 01:09:46:

> Eran Hammer-Lahav <[email-masked]>
> Sent by: [email-masked]
>
> 01/04/2011 01:09
>
> To
>
> OAuth WG <[email-masked]>
>
> cc
>
> Subject
>
> [OAUTH-WG] Authorization code security issue (reframed)
>
> (The previous thread is became completely inaccessible to anyone not
> following it carefully for the past week or so. For the sake of
> reaching a conclusion, I am going to sum up the issue and try to
> start over with a more narrow focus.)
>
> * The security issue is very simple:
>
> The authorization code is the only artifact binding the resource
> owner granting access at the authorization endpoint to the resource
> owner being redirected back to the client. OAuth 1.0a added the
> verification code for this sole purpose. If the authorization code
> is intercepted by a MITM (e.g. fake airport wifi), the attacker can
> take over the session and pretend to be the real resource owner.
> Since the client has no way to detect this, it will grant the
> attacker access to the client application which usually includes
> data obtain via the access token (received using the compromise
> authorization code).
>
> The attack does not give the attacker any direct access to the
> access token, the client credentials, or anything other than the
> client application itself. However, the client application is
> typically considered an extension of the resource server.
>
> Another variation of this attack is related to the implicit grant
> (user-agent flow). If a MITM can intercept the response in figure 4
> step E, it can manipulate the script to obtain the access token (and
> any secret or other properties is included).
>
> In other words, the client redirection URI must use a secure channel
> to completely prevent these issues.
>
> However, it is important to note that this is not OAuth specific. It
> is a general security concern regarding all other aspects of the
> client if it is not fully secure. For example, if the client uses
> insecure cookies or provides authentication via other means not
> using TLS. If the client is insecure, well, it’s insecure including
> its OAuth redirection endpoint.
>
> * The two solutions
>
> The debate is which of the following two language alternative we
> want to include in the specification:
>
> 1. Include a normative MUST use TLS for the client redirection URI
endpoint.
> 2. Include a normative SHOULD use TLS for the client redirection URI
> endpoint with strong language explaining the various attacks
> possible if the endpoint is not made secure.
>
> Both options reflect the same security issue, but *communicate* the *same
> * solution differently. Since this is just a specification (no
> standard police), this is just a manual, not an actual defense.
>
> --- You can stop reading here if you are short on time. This should
> give you all the information you need to know ---
>
>
> * The difficulty
>
> There is no debate that this is a valid security concern, and that
> the only solution is to apply a MITM protection (i.e. TLS).
>
> However, given the current web landscape and OAuth history (or any
> other web API), requiring TLS is an unexpected change to the *ecosystem
> *. From unofficial discussions I had with Yahoo!, Facebook, and
> Google today, all three indicated they have no plans to enforce such
> a restriction. None of the major OAuth 1.0 providers today enforce
> such a requirement, even though the exact same issue is present in OAuth
1.0a.
>
> The challenge is to find the right *language* balance between
> reflecting reality and reflecting the ideal security configuration.
> This is not a question of what is appropriate in certain situation,
> or the unique attack vectors of individual deployments. It is about
> how we talk about security, and how to best push the web towards
> better security without pushing too hard too fast.
>
> To me, the challenge is how to effectively communicate the issue,
> without forcing companies to knowingly violate the specification.
> The problem with that is that experience shows it’s a slippery
> slope. Once you are no longer fully compliant, it is easier to let
> other MUSTs slide.
>
> In the consumer web space – which originated and is still the
> primary audience for this work (no matter how much the enterprise
> folks here protest) – enforcing such a requirement on client
> developers is impractical. Very few providers can afford to alienate
> their developers by making such a requirement today. It will also
> completely undo all the other work done to make this specification
> more accessible and easier to deploy. Hands down, deploying server-
> side TLS is much harder for client developers than figuring OAuth 1.
> 0 signatures.
>
> EHL
>
>
>
>
>
>
>
>
>
>
>
>
>
>  _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 1 Apr 2011 08:13:12 -0700

I'm withdrawing my vote. When others decide what they want to do I'll apply it.

EHL

On Mar 31, 2011, at 17:10, "Eran Hammer-Lahav" <[email-masked]<mailto:[email-masked]>> wrote:

(The previous thread is became completely inaccessible to anyone not following it carefully for the past week or so. For the sake of reaching a conclusion, I am going to sum up the issue and try to start over with a more narrow focus.)

The authorization code is the only artifact binding the resource owner granting access at the authorization endpoint to the resource owner being redirected back to the client. OAuth 1.0a added the verification code for this sole purpose. If the authorization code is intercepted by a MITM (e.g. fake airport wifi), the attacker can take over the session and pretend to be the real resource owner. Since the client has no way to detect this, it will grant the attacker access to the client application which usually includes data obtain via the access token (received using the compromise authorization code).

The attack does not give the attacker any direct access to the access token, the client credentials, or anything other than the client application itself. However, the client application is typically considered an extension of the resource server.

Another variation of this attack is related to the implicit grant (user-agent flow). If a MITM can intercept the response in figure 4 step E, it can manipulate the script to obtain the access token (and any secret or other properties is included).

In other words, the client redirection URI must use a secure channel to completely prevent these issues.

However, it is important to note that this is not OAuth specific. It is a general security concern regarding all other aspects of the client if it is not fully secure. For example, if the client uses insecure cookies or provides authentication via other means not using TLS. If the client is insecure, well, it’s insecure including its OAuth redirection endpoint.

* The two solutions

The debate is which of the following two language alternative we want to include in the specification:

1. Include a normative MUST use TLS for the client redirection URI endpoint.
2. Include a normative SHOULD use TLS for the client redirection URI endpoint with strong language explaining the various attacks possible if the endpoint is not made secure.

Both options reflect the same security issue, but *communicate* the *same* solution differently. Since this is just a specification (no standard police), this is just a manual, not an actual defense.

--- You can stop reading here if you are short on time. This should give you all the information you need to know ---

* The difficulty

There is no debate that this is a valid security concern, and that the only solution is to apply a MITM protection (i.e. TLS).

However, given the current web landscape and OAuth history (or any other web API), requiring TLS is an unexpected change to the *ecosystem*. From unofficial discussions I had with Yahoo!, Facebook, and Google today, all three indicated they have no plans to enforce such a restriction. None of the major OAuth 1.0 providers today enforce such a requirement, even though the exact same issue is present in OAuth 1.0a.

The challenge is to find the right *language* balance between reflecting reality and reflecting the ideal security configuration. This is not a question of what is appropriate in certain situation, or the unique attack vectors of individual deployments. It is about how we talk about security, and how to best push the web towards better security without pushing too hard too fast.

To me, the challenge is how to effectively communicate the issue, without forcing companies to knowingly violate the specification. The problem with that is that experience shows it’s a slippery slope. Once you are no longer fully compliant, it is easier to let other MUSTs slide.

In the consumer web space – which originated and is still the primary audience for this work (no matter how much the enterprise folks here protest) – enforcing such a requirement on client developers is impractical. Very few providers can afford to alienate their developers by making such a requirement today. It will also completely undo all the other work done to make this specification more accessible and easier to deploy. Hands down, deploying server-side TLS is much harder for client developers than figuring OAuth 1.0 signatures.

EHL

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

---

From: Francisco Corella <[email-masked]>
Date: Fri, 1 Apr 2011 09:22:32 -0700 (PDT)

> So we have 2 different communities of Oauth developers that
> will never agree.
> 
> SHOULD: Typically the social networking sites that need to
> cater for tail end developers by not enforcing TLS on
> redirect_uri. It is a risk to think that using strong
> language in the spec will help them appreciate the issues
> MUST: Typically enterprise organisations (I am in this
> camp). They can enforce indirectly by only supporting
> registered callback urls and ensure those use TLS

Security is at least as necessary to social networking sites
as to enterprise sites.  Think about what this means for
Facebook.  If you are using Wifi in a cafe and use the
Facebook login button to log in to any application, a hacker
can easily impersonate you.

By the way, is somebody from Facebook reading this?  If so,
this is a vulnerability that Facebook has right now, and you
should do something about it.  At the very least you should
change the examples of redirect URIs in the developer
documentation so that they use https rather than http.

Francisco

---

From: Oleg Gryb <[email-masked]>
Date: Fri, 1 Apr 2011 10:51:19 -0700 (PDT)

It's a very interesting discussion and I think, I understand both parties well 
because consider myself belonging to both communities (enterprise and 
networking). Still, I would vote in favor of MUST.

Considering the big size of this mailing list and the big level of engagement of 
its members, why don't we vote?

The results of the vote should be taken into consideration by those who writes 
the final version.

>
>From: Francisco Corella <[email-masked]>
>To: Eran Hammer-Lahav <[email-masked]>; Mark Mcgloin 
><[email-masked]>
>Cc: OAuth WG <[email-masked]>; [email-masked]
>Sent: Fri, April 1, 2011 9:22:32 AM
>Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
>
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Apr 2011 11:12:53 -0700

Unfortunately neither solution suggested so far is acceptable. So a vote from my perspective is premature.

I'd like to keep working for a new solution.

Phil
[email-masked]

On 2011-04-01, at 10:51 AM, Oleg Gryb wrote:

> It's a very interesting discussion and I think, I understand both parties well because consider myself belonging to both communities (enterprise and networking). Still, I would vote in favor of MUST.
> 
> Considering the big size of this mailing list and the big level of engagement of its members, why don't we vote?
> 
> The results of the vote should be taken into consideration by those who writes the final version.
> 
> To: Eran Hammer-Lahav <[email-masked]>; Mark Mcgloin <[email-masked]>

---

From: Skylar Woodward <[email-masked]>
Date: Sat, 2 Apr 2011 00:52:28 -0400

Am I the only one still supporting SHOULD on this case? If someone else supports this language, please speak up. Otherwise, it seems the group SHOULD move forward with MUST.

As a provider, we (Kiva) must deal with the possibility of an ecosystem of developer apps which can't feasibly serve HTTPS endpoints.  However, we're perfectly capable of securing credential exchange and our ecosystem with our own API/Network additions without holding up the working group on this point.  Alternatively, if others are interested in supporting developers who can't or won't establish HTTPS endpoints, I'm happy to continue the discussion to work toward a solution (in this working group or side thread).

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 1 Apr 2011 23:57:15 -0700

By not feasible, what is the technical use case/issue? 

Phil

Sent from my phone.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 2 Apr 2011 09:33:13 -0700

Google, Facebook, and Yahoo! already indicated they will not enforce such a MUST. I could not get a clear answer from Twitter.

However, no one representing this companies has bothered to express this view on the list, and to express how they would like the specification to handle this case. This is why I stopped advocating for it (personally, my own product is already end-to-end TLS, and when we open it up for developers, will not enforce it for personal installations).

It is important to remember that this is ultimately within the discretion of the authorization server, and the only ramification (other than the security issue) is not being able to claim full conformance. But such a claim just has no real meaning of value in the consumer space, only in enterprise/government/finance - so I doubt anyone will care if Kiva and the above vendors allow some clients to be less secure than ideal.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Skylar Woodward
> Sent: Friday, April 01, 2011 9:52 PM
> To: Phil Hunt
> Cc: Oleg Gryb; OAuth WG
> Am I the only one still supporting SHOULD on this case? If someone else
> supports this language, please speak up. Otherwise, it seems the group
> SHOULD move forward with MUST.
> 
> As a provider, we (Kiva) must deal with the possibility of an ecosystem of
> developer apps which can't feasibly serve HTTPS endpoints.  However, we're
> perfectly capable of securing credential exchange and our ecosystem with
> our own API/Network additions without holding up the working group on
> this point.  Alternatively, if others are interested in supporting developers
> who can't or won't establish HTTPS endpoints, I'm happy to continue the
> discussion to work toward a solution (in this working group or side thread).
> 
> 
> 
> >> > So we have 2 different communities of Oauth developers that will
> >> > never agree.
> >> >
> >> > SHOULD: Typically the social networking sites that need to cater
> >> > for tail end developers by not enforcing TLS on redirect_uri. It is
> >> > a risk to think that using strong language in the spec will help
> >> > them appreciate the issues
> >> > MUST: Typically enterprise organisations (I am in this camp). They
> >> > can enforce indirectly by only supporting registered callback urls
> >> > and ensure those use TLS
> >>
> >> Security is at least as necessary to social networking sites as to
> >> enterprise sites.  Think about what this means for Facebook.  If you
> >> are using Wifi in a cafe and use the Facebook login button to log in
> >> to any application, a hacker can easily impersonate you.
> >>
> >> By the way, is somebody from Facebook reading this?  If so, this is a
> >> vulnerability that Facebook has right now, and you should do
> >> something about it.  At the very least you should change the examples
> >> of redirect URIs in the developer documentation so that they use
> >> https rather than http.
> >>
> >> Francisco
> >>

---

From: Francisco Corella <[email-masked]>
Date: Sat, 2 Apr 2011 10:48:41 -0700 (PDT)

Eran,

> Google, Facebook, and Yahoo! already indicated they will not enforce
> such a MUST. I could not get a clear answer from Twitter.
> 
> However, no one representing this companies has bothered to express
> this view on the list, and to express how they would like the
> specification to handle this case. This is why I stopped advocating
> for it (personally, my own product is already end-to-end TLS, and when
> we open it up for developers, will not enforce it for personal
> installations).

Good.  The IETF is not a consortium of companies.  What the WG should
debate is whether the IETF should endorse lack of security.

Francisco

---

From: David Recordon <[email-masked]>
Date: Sat, 2 Apr 2011 11:36:57 -0700

If this is changed to a MUST, Facebook will be in violation of the
specification moving forward. It is untenable to require all of our
*client* developers to implement TLS endpoints though we certainly
support developers who wish to do so. This is very different than
offerring our entire API (and now site as opt-in) over TLS as the
server.

I feel like we need to write the appropriate security considerations
even with a MUST because many deployers will ignore the requirement.
It's far more valuable to document the risk and explain ways to help
mitigate it than just changing a SHOULD to an ignored MUST.

--David

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 2 Apr 2011 11:46:33 -0700

I don't think your statement that 'the IETF should endorse lack of security' is accurate or helpful.

I completely rejects the notion that a SHOULD with strong language explaining the risk is any less "secure" than a MUST.

The only impact of using a MUST vs. a SHOULD is that companies deploying it without requiring TLS on the redirection endpoint will not be able to claim full compliance if we use a MUST, but will be able to if we use a SHOULD.

RFC 2616 defines compliance as follows:

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST or REQUIRED level requirements for the protocols it
   implements. An implementation that satisfies all the MUST or REQUIRED
   level and all the SHOULD level requirements for its protocols is said
   to be "unconditionally compliant"; one that satisfies all the MUST
   level requirements but not all the SHOULD level requirements for its
   protocols is said to be "conditionally compliant."

If we used a SHOULD for TLS, and added such a language, it will enable the definition of three classes of implementations: non-compliant, unconditionally compliant (your definition of secure), and conditionally compliant (what Facebook, Yahoo, Google, and Kiva are likely to deploy).

But my point is that trying to paint the SHOULD option with strong security guidance as 'the IETF endorsing an insecure protocol' or 'destroy the credibility of OAuth outside the silly social networking circle' (I'm paraphrasing but the spirit of the comments is accurate) is just an overblown reaction and scare tactic.

Both options are legitimate and produce the same deployment reality. They only differ in how the spec talks about security and how implementers can talk about their conformance.

EHL

From: Francisco Corella [mailto:[email-masked]]
Sent: Saturday, April 02, 2011 10:49 AM
To: Skylar Woodward; Phil Hunt; Eran Hammer-Lahav
Cc: Oleg Gryb; OAuth WG; Karen P. Lewison
Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)

Eran,

Francisco

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 2 Apr 2011 12:19:37 -0700

For the record, I can except SHOULD. But my very strong feeling is this leads to much more lengthy and complicated language.

I believe we have already crossed the line where it is no longer easy for deployers to figure out if deployments are secure. It is now a spec challenging to even subject matter experts. 

If we take the current implementers as evidence it shows we have little or no security either due to misunderstandings or business decisions to accept risk for flexibility. 

It is not time to be idealistic but rather realistic. 

It looks to me that it is time to either redo authorization to avoid TLS (somehow) or consider splitting into secure/non-secure profiles to satisfy everyone's needs. (not my preference)

Any other ideas?

Phil

Sent from my phone. 

On 2011-04-02, at 11:46, Eran Hammer-Lahav <[email-masked]> wrote:

> I don’t think your statement that ‘the IETF should endorse lack of security’ is accurate or helpful.
> 
>  
> 
> I completely rejects the notion that a SHOULD with strong language explaining the risk is any less “secure” than a MUST.
> 
>  
> 
> But my point is that trying to paint the SHOULD option with strong security guidance as ‘the IETF endorsing an insecure protocol’ or ‘destroy the credibility of OAuth outside the silly social networking circle’ (I’m paraphrasing but the spirit of the comments is accurate) is just an overblown reaction and scare tactic.
> 
>  
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 2 Apr 2011 12:47:02 -0700

I don’t think a SHOULD leads to more than 2-3 lines clearly warning against a MITM attack on the authorization code or the returned script (implicit grant). The attack is simple and the warning is equally simple.

Different components of the protocol have different security issues and complexity. This is just the nature of the work where many different parties with vastly different needs are trying to create a single framework. The best example of this diversity are the two ways people are asking the protocol to support client authentication: password and an assertion method. It is trivial to write about the security considerations of a password, it is not to write a complete security consideration about client assertion authentication, unless the list of supported assertions is well defined (which would defeat the goals of those requesting this).

This work leaves much unspecified and therefore will need to be profiled or extended. It is the nature of building a framework, not a finite protocol (which is what 1.0 is). By definition, a framework is just the foundation and has limited well-defined properties.

<rant>
Personally, I find most of the enterprise requirements for OAuth to be an abomination. The non-consumer web world has hijacked a successful community protocol and added so much crap to it so that they can whitewash their own proprietary protocols and appear more open and trendy. Since this is an IETF working group, there is nothing I can do about it here, other than try to keep stuff out of the v2 specification through consensus.

But the enterprise world can’t complain about this protocol not measuring up to their security requirements when it was never meant to be an enterprise protocol. It was a *web* application protocol. The recent move from the application area to the security area is the most recent demonstration of how far this work has moved from its original use cases (when this WG was created).
</rant>

EHL

From: Phillip Hunt [mailto:[email-masked]]
Sent: Saturday, April 02, 2011 12:20 PM
To: Eran Hammer-Lahav
Cc: [email-masked]; Skylar Woodward; Oleg Gryb; OAuth WG; Karen P. Lewison
Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)

Any other ideas?

Phil

Sent from my phone.

On 2011-04-02, at 11:46, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
I don’t think your statement that ‘the IETF should endorse lack of security’ is accurate or helpful.

EHL

Eran,

Francisco

---

From: Skylar Woodward <[email-masked]>
Date: Sat, 2 Apr 2011 15:50:08 -0400

> If we take the current implementers as evidence it shows we have little or no security either due to misunderstandings or business decisions to accept risk for flexibility. 

This type of language is also not helpful for moving us forward. I'd like to see the discussion focused on the development of a useful specification that also meets the challenge of being open (working with many different use cases and contributors) as opposed to subjectively evaluating the polices or relative qualities of individual companies. This is the reason we are working together in an open community to collaborate, rather than each company developing their own proprietary solution.

I'm actually quite proud that nearly since our inception Kiva has always protected every bit of consumer-private data via HTTPS, including pages with private data and connections bearing secure session cookies. However, the default security we've put in place for every user may be more security than they care about. Opening this data via API allows new uses of the data outside the current constraints of the core product. As an example, every user's lending profile is currently private and secured over HTTPS.  If a third party app wants to allow users to share their complete lending profiles to the public internet (or to one's friends on a social network running over HTTP only), such an API can allow that. If OAuth can't serve as the permissions mechanism to enable such sharing or flexibility of data it would be a shame. It's really outside the scope of this spec to police the policies of developer programs or their effectiveness in communicating to their users the risks or nature of the apps in their ecosystems.

I hope we can return to a productive discussion in striking a balance between a flexible and effective specification. I think most of us understand the risks of the MITM attacks being described, yet sensational language and judgements are being tossed about - and for what purpose I don't understand.

---

From: Francisco Corella <[email-masked]>
Date: Mon, 4 Apr 2011 17:35:22 -0700 (PDT)

David,

> offerring our entire API (and now site as opt-in) over TLS as the

Why is it untenable?  Is it because of the cost of a
certificate?  Many CAs offer certifcates for less $100, and
there are free certificates.  See
http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers.
Is it because of the cost of hosting an SSL site?  You can
have your own virtual server at Amazon for $14 a month.  Is
it because of the inconvenience of having to spend a few
hours getting a certificate and adding SSL to your site?

And how about putting your users and your data at risk?  Is
that tenable?

Francisco

---

From: Francisco Corella <[email-masked]>
Date: Mon, 4 Apr 2011 17:46:11 -0700 (PDT)

Eran,

> I don’t think your statement that ‘the IETF should endorse
> lack of security’ is accurate or helpful.

If the IETF endorsed a protocol such that a compliant
implementation allows user impersonation and unauthorized
access to protected resource, then the IETF would be
endorsing lack of security.  How is that inaccurate?

The statement is helpful from the point of view of the users
who would be the victims of the attacks.  You seem to be
concerned about companies and developers but not about
users.

> I completely rejects the notion that a SHOULD with strong
> language explaining the risk is any less “secure” than a
> MUST.
>
> The only impact of using a MUST vs. a SHOULD is that
> companies deploying it without requiring TLS on the
> redirection endpoint will not be able to claim full
> compliance if we use a MUST, but will be able to if we use a
> SHOULD.
>
> If we used a SHOULD for TLS, and added such a language, it
> will enable the definition of three classes of
> implementations: non-compliant, unconditionally compliant
> (your definition of secure), and conditionally compliant
> (what Facebook, Yahoo, Google, and Kiva are likely to
> deploy).

Therefore we should use MUST, otherwise there can be
"conditionally compliant" implementations that put users at
risk.

> But my point is that trying to paint the SHOULD option with
> strong security guidance as ‘the IETF endorsing an insecure
> protocol’ or ‘destroy the credibility of OAuth outside the
> silly social networking circle’ (I’m paraphrasing but the
> spirit of the comments is accurate) is just an overblown
> reaction and scare tactic.

What are you paraphrasing?  I think social networking is
very important.  Furthermore, I think social login may very
well become the default user authentication method of the
Web.  So the security of social login is essential for the
security of the Web at large.

> Both options are legitimate and produce the same deployment
> reality. They only differ in how the spec talks about
> security and how implementers can talk about their
> conformance.

If they differ about how implementers can talk about their
conformance then they do not produce the same deployment
reality.

Francisco

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Apr 2011 19:24:44 -0700

<one long rant adding no value to this conversation>

Speaking from current, on-going, firsthand experience building an OAuth 2.0 server and client.

Your questions about deploying TLS are the least significant when it comes to deploying a TLS-based client. I know these are the standard argument people make when defending a requirement to use TLS, but in practice they are almost meaningless.

The problem is that no modern web application is built and deployed using a single provider or served from a single server (or servers controlled by a single entity). Take every popular blog for example, and you'll find at least 5 add-ons hosted by other services and loaded by the client: an analytics tool, one or more ad networks, some site navigation components, hosted comments, and on and on.

If *any* of these scripts loaded by the client at any time during an authenticated session are not using TLS, not only will the browser show some scary UX warning about incomplete HTTPS state, but also , a MITM will be able, with the exact same ease, to hijack the session just like the attack raised here. If the client is a JS-based OAuth client, add to that stealing the in-memory access token.

TLS performance sucks!

No, I'm not talking about the technology - I'm talking about the kind deployed widely on the web. There are no widely available CDNs for TLS at the same price and performance as are for HTTP. It is still hard-to-impossible to find high-performance free TLS hosts for most popular JS toolkits like JQuery and YUI. Loading these (big) script packages from the TLS servers available is simply too slow to be used in any practical web application. Ads are another major issue.

I've spent the past three months building an OAuth 2.0 client. I've gone through the same analysis and realized that I had to use TLS end-to-end in order to protect the MAC secret issued to the client with its access token. This has caused significant pains as we had to figure out solutions for every third party service or script we use. We had to give up on using the analytics package we wanted because they didn't have a fast enough solution for TLS-based pages (it works great for content sites where there isn't a lot of fast interaction or reliance on 'onload' activity).

I can go on for hours. This has been an awful experience, and not for a minute because of paying $100 for a cert or installing it in nginx. That took less than an hour.

I'm tired of having argument with people quoting theories. I work in the real world, and the real world is just not ready for end-to-end TLS deployment. Maybe it's sad, but that's life. No one wants to put user's at risk, but the only way to prevent it is to shut the web down.

This debate is just like talking about highway safety. We know how to make driving 100% safe. Everyone will drive tanks at no faster than 10mph, or alternatively, no one will drive and we'll all climb on converter belts to get anywhere (each bubble wrapped and put into a medically induced coma to make sure we don't move around). But in the real world, practical considerations trump 100% guarantees.

By just offering services online you put users at some risk. If you want 100% safe online banking, just don't offer any.

We must do better, and we should push security as hard as we can. But if you push beyond what is currently reasonable, you will get nowhere and maybe even do more harm. Facebook, Google, Yahoo, Kiva, etc. can easily force our developers to use TLS for the redirection endpoint. And the developers who really want to use our services will figure out how to deploy TLS and get it working. But as soon as these developers try to use other services not ready for end-to-end TLS, they result will be poor user experience.

In other words, no one will use those clients - they will suck.

It will be the safest web no one ever uses.

Awesome!

EHL

From: Francisco Corella [mailto:[email-masked]]
Sent: Monday, April 04, 2011 5:35 PM
To: Eran Hammer-Lahav; Skylar Woodward; Phil Hunt; Oleg Gryb; David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)

David,

Francisco

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Apr 2011 22:59:30 -0700

Blaine, Hannes,

This thread has gone as far as it can. We need to shut it down and move this item to the chairs (and potentially the AD) to resolve, given that this is not a technical issue, but a political/procedural one. I'm asking the chairs to make a decision about this, given that the working group is unable to reach a conclusion.

Rant inline below...

EHL

> Sent: Monday, April 04, 2011 5:46 PM

> If the IETF endorsed a protocol such that a compliant implementation allows
> user impersonation and unauthorized access to protected resource, then the
> IETF would be endorsing lack of security.  How is that inaccurate?

Because there is no such thing as an IETF endorsement, and a publication of an RFC only means that the community has reviewed a document and it represent as full picture as possible (at that time). There is nothing about an IETF standard that requires it to always pick security over usability, *as long as* the security issues are well documented, explained, and given the proper context and warnings.

Documenting a security issue and recommending a solution is well within IETF practice. The point of the security consideration section is to make sure those implementing the standard understand the security issues involved. No IETF RFC claims to be 100% secure and that any implementation of it can be 'trusted'. The IETF should *promote* best security practices, as long as they are practical.

> The statement is helpful from the point of view of the users who would be
> the victims of the attacks.  You seem to be concerned about companies and
> developers but not about users.

That's crap. The user has no way of gaging anything with regard to the client or server implementation. It cannot tell if the server has implemented anything correctly. The user will never even know OAuth exists. Since when does a standard protect users? There is no enforcement. No IETF police. I am not even sure the IETF organization can say anything publically about any particular implementation without opening itself to litigation.

Users vote with their feet. How many people stopped using webmail services once they learned about the danger of FireSheep? Practically none. Our job is to produce technical documents that improve interoperability and abide by the best security practices possible. Our only audience are the people implementing the standard. The only question is, will an average developer reading the document understand the issue and do as much as possible to address it?

I'm in the business of building consumer web products. Who do you think are my customers? We are all here to serve the needs of the end user. But we also live in the real world where the web is insecure and we have to work with what we've got. Your position is that it is better to make a stand and force almost every consumer web company to violate the specification (since you can't force them to abide by it). My position is that more people will pay attention to the issue if we explain it and not give them an excuse to ignore other security related MUSTs (once you ignore the first, the 2nd, 3rd, 10th come easy).
 
If we make this a MUST, we know Facebook is going to ignore it because they have no other options at this point in time. They are not going to write 'Almost OAuth 2.0 compliant' on their site. They are not going to even mention OAuth to their users. But on their developer site they will say they support OAuth 2.0. Then you will come and write a long blog post about how they are not really OAuth 2.0 compliant. Great. Now what? 600 million people will stop using Facebook?

You've been told clearly that the three largest consumer web companies (by audience): Yahoo!, Facebook, and Google, are all going to ignore a MUST if this is what we are going to specify. Either you just don't care producing a document that the three biggest players on the web ignore, or you kidding yourself that they will all commit business suicide and enforce it - forcing their developers to produce unusable client applications (and that client developers will go along with it, wasting time on unusable products).

The world doesn't get any safer with this language, but the spec gets further away from reality and we all know what a slippery slope that is when implementation and standards start drifting apart.

Our job is to fully document any security shortcoming we are aware of. A SHOULD does just that and is perfectly reasonable.

EHL

---

From: Blaine Cook <[email-masked]>
Date: Tue, 5 Apr 2011 08:28:39 +0100

<chair>

DO NOT REPLY TO THIS EMAIL.

To Eran's point, before reaching the end of this thread after limited
access to email over the weekend, I was going to shut this thread down
anyways.

I'm not going to issue a call for consensus on this issue, because I
don't believe anyone on the list (except for a small handful of active
participants) have read even a fraction of the thread. Furthermore,
I'm sure that we understand this threat, and we will ensure that it is
properly documented in the Security Considerations.

If you are reading this, have not had your voice heard on this matter,
and think that this issue is unrepresented in the Security
Considerations, please email the chairs directly.

b.

nb: The OAuth working group's job is to ship OAuth 2.0; while this is
includes ensuring a secure protocol, "secure" does not equal
"impenetrable". If you believe that cookies and security in HTTP is
flawed, please go talk to the HTTP working group and lobby for a MUST
of TLS over all HTTP connections. I also urge you to consider the
implications of Comodogate – $100 certs ain't what they used to be.

</chair>

---

From: "William J. Mills" <[email-masked]>
Date: Tue, 5 Apr 2011 17:44:49 -0700 (PDT)

In working on the SASL mechanism spec for OAuth we have to deal with Channel Binding.  Sparing you the gory details there I believe that the right thing to do is to add the channel binding information into the tunneled HTTP/OAuth  authentication.  For those OAuth profiles like MAC and SAML that have shared secrets and signatures the channel binding information should be added into the signed payload.  Should the deinition of this be in the SASL mechanism spec (updating the OAuth profile behavior) or is the right place for this to have each OAuth profile define how channel binding is carried individually?

Using MAC as a strawman, the only convenient placess to add this payload are the body and as an additional query parameter.  Both of these have drawbacks, of the two I nominally prefer defining a new query parameter for this case.  The usage in SASL is pretty limited at this time, so query parameter will work just fine.

Given OAuth is primarily defined in an HTTP context I don't think I'm stepping on anything because I doubt anyone else is dealing with Channel Binding.   Mechanisms that have a shared secret and signing could actually use CB to guarantee no MITM in an SSL context, which some would argue has significant value.

If anyone has strong opinions on this topic please let me know.

Thanks,

-bill

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 5 Apr 2011 17:49:14 -0700

My only uneducated view is that I do not want to deal with this in the MAC draft (which is being transform into a completely generic HTTP authentication scheme and will move out of this WG with the next draft). Other than that, I don't have an opinion.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of William J. Mills
Sent: Tuesday, April 05, 2011 5:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Channel binding and OAuth profiles

Thanks,

-bill