Subject: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

From: Luke Shepard <[email-masked]>
Date: Thu, 28 Jan 2010 07:29:38 -0800

In the discussions around the OAuth WRAP spec, one of the questions often asked is, "why use SSL exclusively?" Several of us have done a lot of thinking on it and I wanted to articulate my understanding of the pros and cons of the approach for discussion. The use case I primarily have in mind is that of a web service, like Facebook, Twitter, or Google services. Our service is primarily authenticated via the Web, but we have a use for all of the WRAP profiles (web app, client app, desktop, mobile).

Overall, I think that the simplicity of using SSL outweighs all the associated costs for most developers. However, we should offer plaintext signatures as an optional performance enhancement for advanced developers.

== Advantages of using SSL for API calls

-- It's overwhelmingly simpler for developers.
I've implemented OpenID and OAuth, and I've worked for years with developers trying to handle signatures on the Facebook Platform. In my experience, calculating signatures is one of the most complex and difficult parts of an authentication protocol, and developers often get it wrong. By moving that piece down the stack we can get it out of their way and let developers focus on building their apps.

-- Existing tools ecosystem
It's not that SSL is a simpler encryption protocol than OAuth (it's not) but rather that commonly available tools almost universally support it - every major web browser, as well as most libraries for making HTTP requests (like curl) have built-in support for SSL. For OAuth 1.0, you need to use a client library just to construct your very first request.

-- Smaller client libraries
A good chunk of code in many client libraries is devoted to calculating and verifying signatures. For example, the OpenID PHP library imports several BigMath modules and encryption schemes. Even the relatively simpler Facebook client library requires several functions to sign requests. This makes the client libraries a black box and impedes understanding.

Wouldn't it be great if we could write a protocol that doesn't even require a client library to implement? If I could just make an authenticated API request in my browser, as easily as with Basic Auth?

== Disadvantages of using SSL for API calls

-- Difficulties of debugging

Both signatures and SSL present difficulties in debugging, but they tend to be different. While with signatures you worry about composing the arguments wrong or using the wrong algorithm, with SSL you worry about reading the request over the wire. You can't sniff a request, and to intercept it, you need an HTTP proxy that understands SSL, and you need to worry about invalid certificate errors. To aid in this, providers will probably offer a non-SSL endpoint for debugging, but they may need to set up a sandbox environment to prevent damage from tokens exposed in plaintext.

-- Variable costs for providers

Server CPU costs will increase when handling SSL requests - especially on every API call instead of just at the auth stage. At scale, this can become expensive, although it can be offset by using specialized hardware to terminate the SSL connection. All the big companies I've talked to are comfortable trading these higher costs for increased adoption due to the simplicity.

-- Fixed costs for smaller providers

There is a fixed cost to obtaining and signing an SSL certificates, although that has dropped in recent years such that an operator can have a cert signed for a single domain for pretty cheap.

-- Latency

SSL connections take more time to establish than normal HTTP connections. Servers can use specialized hardware to speed it up, but clients rarely do, which means that for client-to-server API requests, there may be some higher latency in each request. Smaller, mobile devices may be disproportionately affected by this, but as they grow more powerful it's less of a concern. Already today newer phones can handle SSL just fine.

-- Browser limitations for cross domain communication

A more niche disadvantage is that some cross domain communication techniques require the protocol of the parent page to match that of the endpoint being queried. So for example, in some browsers, for some API calls, it would be impossible to make an API call to an HTTPS endpoint from a normal HTTP page. However, as browsers advance and HTML5 methods like postMessage become more common, this will become less of an issue.

-- Verifying information on the relying party

If information is passed from a Service Provider to a Consumer through the user's browser, then that information cannot be verified without an API call, unless a signature is provided. Similar to stateful vs. stateless mode in the OpenID 2.0 spec, the signature can serve as a performance enhancement to avoid an API call.

== Providing a non-SSL option for the short head

Most platforms tend to have a small number of fairly large developers and then a really large number of smaller developers. The former are typically experienced (or at least, they are by the time they get big) and have made a large investment in the platform. The latter range from experienced developers to amateurs to folks that would not typically program. For this spec to be successful, it must meet the needs of both groups.

Facebook is very interested in adopting OAuth WRAP / 2.0 / whatever because we want to help our long tail developers use our platform more easily. For the long tail, the simplicity provided by SSL will be crucial. It means smaller or nonexistent client libaries, it means that developers can just try out the API by typing it into a web browser, and it will help reduce debugging and maintenance costs.

However, for the short head of high volume developers, we probably want an option to use something other than SSL to make secure requests. These developers tend to have already solved the low hanging performance fruit, and for them it may be a significant penalty to pay the SSL connection cost on every request. To that end, I think it's pretty important that OAuth 2.0 support a method other than SSL as an option for advanced developers. But it should be just that - an option, and only for advanced developers, so that beginning programmers and folks learning an API don't need to worry about signatures when they just want to play around.

Please let me know if I'm missing something or if my assumptions sound incorrect.

-Luke Shepard
Software Engineer, Facebook Platform

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Jan 2010 14:41:53 -0700

Thanks Luke. This is a useful analysis.

I believe we have already reached consensus in this regard:

* Support an extensible set of signature algorithms
* Define hmac-sha-1, hmac-sha-256, and rsassa-pkcs1-v1.5-sha-256
* Define a plain method for bearer tokens and either require SSL/TLS or strongly recommend it (open issue)

(if these assumptions are incorrect, raise your hand now)

The specification is going to define the four methods above (and possibly more) as *must implement*. This does not mean vendors have to support all of them, but that any *client* library or application claiming to be 'OAuth 2.0 compliant' must implement all these methods.

If a vendor issues tokens not using all these methods (which is more likely), it does not have to implement all these methods and can still be called 'OAuth 2.0 compliant' because any it can interop with *any* compliant library. However, if such a vendor produces a client library for its developers which only implements the methods deployed by the vendor, that library is 'OAuth 2.0 partially compliant' (because it will not interop with *all* vendors).

In practice, from Facebook's perspective, you will be able to deploy OAuth 2.0 in a compliant way, while only implementing the methods that you find suitable for your developers. It sounds like you will be using the plain method over SSL and either hmac-sha-1 or hmac-sha-256. Since Facebook usually makes things trivial for its developers, I expect Facebook to produce libraries that will implement these two methods, but not others. This will be a 'Facebook API' library that uses OAuth 2.0. It will be partially compliant but this only means it is only guaranteed to work with Facebook, but that it does so in a fully compliant way.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Luke Shepard
Sent: Thursday, January 28, 2010 7:30 AM
To: [email-masked]
Subject: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

-- Latency

-Luke Shepard

---

From: Luke Shepard <[email-masked]>
Date: Thu, 28 Jan 2010 18:35:40 -0800

Thanks for the detailed reply, Eran.

I think that your proposed design has it backwards: servers should bear complexity and one-time costs, not clients. Much of why I think OAuth WRAP / 2.0 is so appealing is that it dramatically simplifies life for developers. If a client can support SSL and doesn't want to deal with signatures, then they never should have to. I want to be able to write a very lightweight SSL-only client library that is still fully OAuth 2.0 compatible.

I think instead, the consensus should be:

 *   Support an extensible set of signature algorithms
 *   Servers required to support plaintext tokens over a secure channel (SSL/TLS)
 *   Servers required to support at least one or a small subset of encryption algorithms. Possible candidates include hmac-sha-1, hmac-sha-256, and rsassa....
 *   Clients must support at least ONE of the required encryption methods

If a client supports at least one of the required methods (SSL or one of the algorithms), then it can be considered fully OAuth 2.0 compliant. If it only supports encryption methods that are not in the required list, then it is partially compliant - that is, it may work with a specific vendor that advertises support for that algorithm, but it won't work with all servers. As algorithms gradually change over time, client libraries can be upgraded while servers need to maintain backwards compatibility. (For example, Facebook will deprecate MD5 as its sig algorithm, but will continue to support it for the clients using it in the wild)

As a concrete example of what can be written when you don't need to worry about encryption, see: http://github.com/lshepard/oauth-wrap-demo/tree/master/src/wrap.js
If I were to modify that JS to accommodate multiple signature algorithms, then I would need to include at least another 1-2k of JavaScript for each method just in case. That would be fairly ridiculous.

On 1/28/10 1:41 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

-- Latency

-Luke Shepard

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Jan 2010 20:10:49 -0700

(For the sake of simplicity, I am going to refer to the Plain bearer token with SSL/TLS as S-Plain)

WRAP appeal is also its limitation and (strictly as written) it sacrifices security for client ease. We still don't know what OAuth 2.0 is (it is *not* WRAP, but likely to include ideas from it).

The problem I have with your approach is that you are mandating server deployment and given that this is a security protocol, we have no business telling servers what they MUST implement (they might consider S-Plain too weak for their needs). There are many reasons why vendors would rather not use the S-Plain option (you listed some of those) for every protected resource request. There are also many reasons why vendors would only support S-Plain and no signature option.

My proposal allows you to do everything you have asked for and your developers will have an easy life with the S-Plain option, or performance / flexibility with one of the HMAC methods. But the advantage is that I do not mandate Facebook to do anything it doesn't want. Any OAuth 2.0 client will work with Facebook.

It is true that writing a fully compliant client will require more work. But the whole point of the S-Plain option is that it requires *no* additional library beyond having SSL/TLS available. So this is a vendor support issue - if you want to enable a library-less client development, offer S-Plain. This again, is a vendor choice.

Also keep in mind that the current proposal moves the algorithm choice to the token request/issue phase. Each token will only work with a single algorithm (which is better cryptographic hygiene). So a vendor can choose to allow the client to pick the algorithm they want to you, or just tell them which one they are going to use.

EHL

From: Luke Shepard [mailto:[email-masked]]
Sent: Thursday, January 28, 2010 6:36 PM
To: Eran Hammer-Lahav; [email-masked]
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

EHL

-- Latency

-Luke Shepard

---

From: David Recordon <[email-masked]>
Date: Thu, 28 Jan 2010 22:33:19 -0800

On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> WRAP appeal is also its limitation and (strictly as written) it sacrifices
> security for client ease. We still don’t know what OAuth 2.0 is (it is **
> not** WRAP, but likely to include ideas from it).
>
How is security sacrificed in the S-Plain method proposed for OAuth 2.0?  I
understand that WRAP makes sacrifices, but am I missing something in terms
of moving a Plain bearer token always over SSL/TLS when making
authentication requests?

The problem I have with your approach is that you are mandating server
> deployment and given that this is a security protocol, we have no business
> telling servers what they MUST implement (they might consider S-Plain too
> weak for their needs). There are many reasons why vendors would rather not
> use the S-Plain option (you listed some of those) for every protected
> resource request. There are also many reasons why vendors would only support
> S-Plain and no signature option.
>
> My proposal allows you to do everything you have asked for and your
> developers will have an easy life with the S-Plain option, or performance /
> flexibility with one of the HMAC methods. But the advantage is that I do not
> mandate Facebook to do anything it doesn’t want. Any OAuth 2.0 client will
> work with Facebook.
>
> It is true that writing a fully compliant client will require more work.
> But the whole point of the S-Plain option is that it requires **no**
> additional library beyond having SSL/TLS available. So this is a vendor
> support issue – if you want to enable a library-less client development,
> offer S-Plain. This again, is a vendor choice.
>
Yes, but the tradeoff here is that a client will have S-Plain plus two or
three other algorithms.  The library size is increased, the complexity is
increased, and it encourages servers (like Facebook) to develop separate
libraries which only support the one or two methods they have chosen to use.
 Luke and I would like to avoid creating Facebook specific client libraries.
 (This is of course based on the assumption that the majority of
implementations will adopt S-Plain.  We then envision an advanced client
library which also implements HMAC SHA-256.)

Also keep in mind that the current proposal moves the algorithm choice to
> the token request/issue phase. Each token will only work with a single
> algorithm (which is better cryptographic hygiene). So a vendor can choose to
> allow the client to pick the algorithm they want to you, or just tell them
> which one they are going to use.
>
>
>
> EHL
>
>
>
>
>
> *From:* Luke Shepard [mailto:[email-masked]]
> *Sent:* Thursday, January 28, 2010 6:36 PM
> *To:* Eran Hammer-Lahav; [email-masked]
> *Subject:* Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth
> communication
>
>
>
> I think that your proposed design has it backwards: servers should bear
> complexity and one-time costs, not clients. Much of why I think OAuth WRAP /
> 2.0 is so appealing is that it dramatically simplifies life for developers.
> If a client can support SSL and doesn’t want to deal with signatures, then
> they never should have to. I want to be able to write a very lightweight
> SSL-only client library that is still fully OAuth 2.0 compatible.
>
>    - Support an extensible set of signature algorithms
>    - Servers required to support plaintext tokens over a secure channel
>    (SSL/TLS)
>    - Servers required to support at least one or a small subset of
>    encryption algorithms. Possible candidates include hmac-sha-1, hmac-sha-256,
>    and rsassa....
>    - Clients must support at least ONE of the required encryption methods
>
>
> If a client supports at least one of the required methods (SSL or one of
> the algorithms), then it can be considered fully OAuth 2.0 compliant. If it
> only supports encryption methods that are not in the required list, then it
> is partially compliant – that is, it may work with a specific vendor that
> advertises support for that algorithm, but it won’t work with all servers.
> As algorithms gradually change over time, client libraries can be upgraded
> while servers need to maintain backwards compatibility. (For example,
> Facebook will deprecate MD5 as its sig algorithm, but will continue to
> support it for the clients using it in the wild)
>
> As a concrete example of what can be written when you don’t need to worry
> about encryption, see:
> http://github.com/lshepard/oauth-wrap-demo/tree/master/src/wrap.js
> If I were to modify that JS to accommodate multiple signature algorithms,
> then I would need to include at least another 1-2k of JavaScript for each
> method just in case. That would be fairly ridiculous.
>
>
> The specification is going to define the four methods above (and possibly
> more) as **must implement**. This does not mean vendors have to support
> all of them, but that any **client** library or application claiming to be
> ‘OAuth 2.0 compliant’ must implement all these methods.
>
> If a vendor issues tokens not using all these methods (which is more
> likely), it does not have to implement all these methods and can still be
> called ‘OAuth 2.0 compliant’ because any it can interop with **any**
> compliant library. However, if such a vendor produces a client library for
> its developers which only implements the methods deployed by the vendor,
> that library is ‘OAuth 2.0 partially compliant’ (because it will not interop
> with **all** vendors).
>
> In practice, from Facebook’s perspective, you will be able to deploy OAuth
> 2.0 in a compliant way, while only implementing the methods that you find
> suitable for your developers. It sounds like you will be using the plain
> method over SSL and either hmac-sha-1 or hmac-sha-256. Since Facebook
> usually makes things trivial for its developers, I expect Facebook to
> produce libraries that will implement these two methods, but not others.
> This will be a ‘Facebook API’ library that uses OAuth 2.0. It will be
> partially compliant but this only means it is only guaranteed to work with
> Facebook, but that it does so in a fully compliant way.
>
> EHL
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Luke Shepard
> *Sent:* Thursday, January 28, 2010 7:30 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] Discussion of SSL as the primary means for OAuth
> communication
>
> In the discussions around the OAuth WRAP spec, one of the questions often
> asked is, “why use SSL exclusively?” Several of us have done a lot of
> thinking on it and I wanted to articulate my understanding of the pros and
> cons of the approach for discussion. The use case I primarily have in mind
> is that of a web service, like Facebook, Twitter, or Google services. Our
> service is primarily authenticated via the Web, but we have a use for all of
> the WRAP profiles (web app, client app, desktop, mobile).
>
> Overall, I think that the simplicity of using SSL outweighs all the
> associated costs for most developers. However, we should offer plaintext
> signatures as an optional performance enhancement for advanced developers.
>
> -- It’s overwhelmingly simpler for developers.
> I’ve implemented OpenID and OAuth, and I’ve worked for years with
> developers trying to handle signatures on the Facebook Platform. In my
> experience, calculating signatures is one of the most complex and difficult
> parts of an authentication protocol, and developers often get it wrong. By
> moving that piece down the stack we can get it out of their way and let
> developers focus on building their apps.
>
> It’s not that SSL is a simpler encryption protocol than OAuth (it’s not)
> but rather that commonly available tools almost universally support it –
> every major web browser, as well as most libraries for making HTTP requests
> (like curl) have built-in support for SSL. For OAuth 1.0, you need to use a
> client library just to construct your very first request.
>
> A good chunk of code in many client libraries is devoted to calculating and
> verifying signatures. For example, the OpenID PHP library imports several
> BigMath modules and encryption schemes. Even the relatively simpler Facebook
> client library requires several functions to sign requests. This makes the
> client libraries a black box and impedes understanding.
>
> Wouldn’t it be great if we could write a protocol that doesn’t even require
> a client library to implement? If I could just make an authenticated API
> request in my browser, as easily as with Basic Auth?
>
> Both signatures and SSL present difficulties in debugging, but they tend to
> be different. While with signatures you worry about composing the arguments
> wrong or using the wrong algorithm, with SSL you worry about reading the
> request over the wire. You can’t sniff a request, and to intercept it, you
> need an HTTP proxy that understands SSL, and you need to worry about invalid
> certificate errors. To aid in this, providers will probably offer a non-SSL
> endpoint for debugging, but they may need to set up a sandbox environment to
> prevent damage from tokens exposed in plaintext.
>
> Server CPU costs will increase when handling SSL requests – especially on
> every API call instead of just at the auth stage. At scale, this can become
> expensive, although it can be offset by using specialized hardware to
> terminate the SSL connection. All the big companies I’ve talked to are
> comfortable trading these higher costs for increased adoption due to the
> simplicity.
>
> There is a fixed cost to obtaining and signing an SSL certificates,
> although that has dropped in recent years such that an operator can have a
> cert signed for a single domain for pretty cheap.
>
> -- Latency
>
> SSL connections take more time to establish than normal HTTP connections.
> Servers can use specialized hardware to speed it up, but clients rarely do,
> which means that for client-to-server API requests, there may be some higher
> latency in each request. Smaller, mobile devices may be disproportionately
> affected by this, but as they grow more powerful it’s less of a concern.
> Already today newer phones can handle SSL just fine.
>
> A more niche disadvantage is that some cross domain communication
> techniques require the protocol of the parent page to match that of the
> endpoint being queried. So for example, in some browsers, for some API
> calls, it would be impossible to make an API call to an HTTPS endpoint from
> a normal HTTP page. However, as browsers advance and HTML5 methods like
> postMessage become more common, this will become less of an issue.
>
> If information is passed from a Service Provider to a Consumer through the
> user’s browser, then that information cannot be verified without an API
> call, unless a signature is provided. Similar to stateful vs. stateless mode
> in the OpenID 2.0 spec, the signature can serve as a performance enhancement
> to avoid an API call.
>
> Most platforms tend to have a small number of fairly large developers and
> then a really large number of smaller developers. The former are typically
> experienced (or at least, they are by the time they get big) and have made a
> large investment in the platform. The latter range from experienced
> developers to amateurs to folks that would not typically program. For this
> spec to be successful, it must meet the needs of both groups.
>
> Facebook is very interested in adopting OAuth WRAP / 2.0 / whatever because
> we want to help our long tail developers use our platform more easily. For
> the long tail, the simplicity provided by SSL will be crucial. It means
> smaller or nonexistent client libaries, it means that developers can just
> try out the API by typing it into a web browser, and it will help reduce
> debugging and maintenance costs.
>
> However, for the short head of high volume developers, we probably want an
> option to use something other than SSL to make secure requests. These
> developers tend to have already solved the low hanging performance fruit,
> and for them it may be a significant penalty to pay the SSL connection cost
> on every request. To that end, I think it’s pretty important that OAuth 2.0
> support a method other than SSL as an option for advanced developers. But it
> should be just that – an option, and only for advanced developers, so that
> beginning programmers and folks learning an API don’t need to worry about
> signatures when they just want to play around.
>
> Please let me know if I’m missing something or if my assumptions sound
> incorrect.
>
> -Luke Shepard
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Luke Shepard <[email-masked]>
Date: Thu, 28 Jan 2010 23:55:04 -0800

Thanks Eran, this is helpful. Few thoughts:

> We have no business telling servers what they MUST implement (they might consider S-Plain too weak for their needs)

Of all the negatives I listed below about SSL, being insecure was not one of them. I'm very interested in hearing real world use cases where you think SSL will be too insecure?

> But the advantage is that I do not mandate Facebook to do anything it doesn't want.

I would rather mandate that the Service Provider support something extra than require it in every client.

> Any OAuth 2.0 client will work with Facebook. It is true that writing a fully compliant client will require more work.

If it's more work to write libraries, then fewer libraries will be written, and they will be less well maintained. My primary goal with this spec is to make adoption as easy as possible and supported on as many platforms as possible. Part of the point of adopting a spec is you get to share code across libraries. If we start by saying "you'll have a different client library for each service" then doesn't that defeat the point?

On 1/28/10 10:33 PM, "David Recordon" <[email-masked]> wrote:

On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav <[email-masked]> wrote:
(For the sake of simplicity, I am going to refer to the Plain bearer token with SSL/TLS as S-Plain)
WRAP appeal is also its limitation and (strictly as written) it sacrifices security for client ease. We still don't know what OAuth 2.0 is (it is *not* WRAP, but likely to include ideas from it).
How is security sacrificed in the S-Plain method proposed for OAuth 2.0?  I understand that WRAP makes sacrifices, but am I missing something in terms of moving a Plain bearer token always over SSL/TLS when making authentication requests?

The problem I have with your approach is that you are mandating server deployment and given that this is a security protocol, we have no business telling servers what they MUST implement (they might consider S-Plain too weak for their needs). There are many reasons why vendors would rather not use the S-Plain option (you listed some of those) for every protected resource request. There are also many reasons why vendors would only support S-Plain and no signature option.
My proposal allows you to do everything you have asked for and your developers will have an easy life with the S-Plain option, or performance / flexibility with one of the HMAC methods. But the advantage is that I do not mandate Facebook to do anything it doesn't want. Any OAuth 2.0 client will work with Facebook.
It is true that writing a fully compliant client will require more work. But the whole point of the S-Plain option is that it requires *no* additional library beyond having SSL/TLS available. So this is a vendor support issue - if you want to enable a library-less client development, offer S-Plain. This again, is a vendor choice.
Yes, but the tradeoff here is that a client will have S-Plain plus two or three other algorithms.  The library size is increased, the complexity is increased, and it encourages servers (like Facebook) to develop separate libraries which only support the one or two methods they have chosen to use.  Luke and I would like to avoid creating Facebook specific client libraries.  (This is of course based on the assumption that the majority of implementations will adopt S-Plain.  We then envision an advanced client library which also implements HMAC SHA-256.)

EHL

On 1/28/10 1:41 PM, "Eran Hammer-Lahav" <[email-masked] <http://[email-masked]> > wrote:
Thanks Luke. This is a useful analysis.

EHL

From: [email-masked] <http://[email-masked]>  [mailto:[email-masked]] On Behalf Of Luke Shepard
Sent: Thursday, January 28, 2010 7:30 AM
To: [email-masked] <http://[email-masked]>
Subject: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

-- Latency

-Luke Shepard

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 29 Jan 2010 01:12:21 -0700

For one, we know never to assume that SSL is implemented correctly (not in terms of the libraries but how certificate exceptions are handled and how its defenses can be compromised). S-Plain also exposes the secret to intermediaries while signatures can pass through without being compromised. I am sure Ben Laurie and others can list more differences (and hope they will).

I disagree with your second comment about client library size. Typically if you have one crypto algorithm, you have many others available. And if you are suggesting that by requiring only S-Plain it will enable crypto-less libraries, I would rather the community avoided producing such limited *libraries*. If we make it ok not to support signatures in generic libraries, it will make it even harder for vendors to offer them.

At the end, the market will decide between signatures and S-Plain, the same way the RSA method in OAuth 1.0 gained very little traction (mostly because it was underspecified IMO). I don't think we should make that decision here.

EHL

From: David Recordon [mailto:[email-masked]]
Sent: Thursday, January 28, 2010 10:33 PM
To: Eran Hammer-Lahav
Cc: Luke Shepard; [email-masked]
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
(For the sake of simplicity, I am going to refer to the Plain bearer token with SSL/TLS as S-Plain)
WRAP appeal is also its limitation and (strictly as written) it sacrifices security for client ease. We still don't know what OAuth 2.0 is (it is *not* WRAP, but likely to include ideas from it).
How is security sacrificed in the S-Plain method proposed for OAuth 2.0?  I understand that WRAP makes sacrifices, but am I missing something in terms of moving a Plain bearer token always over SSL/TLS when making authentication requests?

EHL

From: Luke Shepard [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 28, 2010 6:36 PM
To: Eran Hammer-Lahav; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

On 1/28/10 1:41 PM, "Eran Hammer-Lahav" <[email-masked]<http://[email-masked]>> wrote:
Thanks Luke. This is a useful analysis.

EHL

From: [email-masked]<http://[email-masked]> [mailto:[email-masked]] On Behalf Of Luke Shepard
Sent: Thursday, January 28, 2010 7:30 AM
To: [email-masked]<http://[email-masked]>
Subject: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

-- Latency

-Luke Shepard

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 29 Jan 2010 01:43:11 -0700

> -----Original Message-----
> Sent: Thursday, January 28, 2010 11:55 PM

> > We have no business telling servers what they MUST implement (they
> > might consider S-Plain too weak for their needs)
>
> Of all the negatives I listed below about SSL, being insecure was not one of
> them. I'm very interested in hearing real world use cases where you think
> SSL will be too insecure?

Having to go through intermediaries is one.

You are also limiting your review to symmetric secrets in which there is little difference between sending the secret or using it to sign something (assuming the secret remains secret and you prevent MITM). But using asymmetric secrets to sign requests offers more protections such as preventing the server from being able to imitate the client.

It also doesn't need to be insecure, just not acceptable in the environment it is deployed. For example, it can be wasteful over a VPN connection or illegal in some countries.

> than require it in every client.

But it goes much beyond 'supporting something extra'. Either S-Plain is good enough for everything or it's not. If it is, we should just mandate it and forget about the rest. But as your analysis clearly shows, there are cases where it is not appropriate. What if I have a service with only large API clients?

> If it's more work to write libraries, then fewer libraries will be written, and
> they will be less well maintained. My primary goal with this spec is to make
> adoption as easy as possible and supported on as many platforms as
> possible. Part of the point of adopting a spec is you get to share code across
> libraries. If we start by saying "you'll have a different client library for each
> service" then doesn't that defeat the point?

This reflects your specific needs. Your view is that your users will most likely use S-Plain but that some large (and more sophisticated) clients will use signatures. It sounds to me like you don't really care much about helping the big guys because they should be able to write their own custom libraries. If we create an environment where no one ever bothers to implement the more advanced features because they don't have to, we might as well not bother including them.

A big part of our work is to figure out what is core and what is not. I think signatures are core and consider the use of asymmetric secrets in OAuth as critical for the future of the web. If you consider protocols like Salmon where pre-registration is not likely, being able to establish a client identity simply by publishing a public key using discovery and using that to sign OAuth requests is an important use case.

If Facebook, Yahoo, Google, Microsoft, and others will all support S-Plain, you will have libraries that work across many services, not just one, and I think this is a very likely scenario considering the interest these vendors have in adopting WRAP.

As an aside, I don't buy the argument (when it comes from the likes of the companies behind WRAP) that we should put the amateur developer on a pedestal and design web architecture to meet their needs. It is pathetic that these companies have failed to produce quality open source libraries or make a significant contribution to them over the past two years. That includes my own employer (at least they pay for all the editorial work and documentation I produce).

EHL

> (For the sake of simplicity, I am going to refer to the Plain bearer token with
> SSL/TLS as S-Plain) WRAP appeal is also its limitation and (strictly as written) it
> sacrifices security for client ease. We still don't know what OAuth 2.0 is (it is
> *not* WRAP, but likely to include ideas from it).
> weak for their needs). There are many reasons why vendors would rather
> not use the S-Plain option (you listed some of those) for every protected
> resource request. There are also many reasons why vendors would only
> support S-Plain and no signature option.
> mandate Facebook to do anything it doesn't want. Any OAuth 2.0 client will
> work with Facebook.
> It is true that writing a fully compliant client will require more work. But the
> whole point of the S-Plain option is that it requires *no* additional library
> beyond having SSL/TLS available. So this is a vendor support issue - if you
> want to enable a library-less client development, offer S-Plain. This again, is a
> vendor choice.
> Yes, but the tradeoff here is that a client will have S-Plain plus two or three
> other algorithms.  The library size is increased, the complexity is increased,
> and it encourages servers (like Facebook) to develop separate libraries which
> only support the one or two methods they have chosen to use.  Luke and I
> would like to avoid creating Facebook specific client libraries.  (This is of
> course based on the assumption that the majority of implementations will
> adopt S-Plain.  We then envision an advanced client library which also
> implements HMAC SHA-256.) Also keep in mind that the current proposal
> moves the algorithm choice to the token request/issue phase. Each token
> will only work with a single algorithm (which is better cryptographic hygiene).
> So a vendor can choose to allow the client to pick the algorithm they want to
> you, or just tell them which one they are going to use.
>
> EHL
>
>
>
> complexity and one-time costs, not clients. Much of why I think OAuth WRAP
> / 2.0 is so appealing is that it dramatically simplifies life for developers. If a
> client can support SSL and doesn't want to deal with signatures, then they
> never should have to. I want to be able to write a very lightweight SSL-only
> client library that is still fully OAuth 2.0 compatible.
>
> * Support an extensible set of signature algorithms * Servers required to
> support plaintext tokens over a secure channel (SSL/TLS) * Servers required
> to support at least one or a small subset of encryption algorithms. Possible
> candidates include hmac-sha-1, hmac-sha-256, and rsassa....
> If a client supports at least one of the required methods (SSL or one of the
> algorithms), then it can be considered fully OAuth 2.0 compliant. If it only
> supports encryption methods that are not in the required list, then it is
> partially compliant - that is, it may work with a specific vendor that advertises
> support for that algorithm, but it won't work with all servers. As algorithms
> gradually change over time, client libraries can be upgraded while servers
> need to maintain backwards compatibility. (For example, Facebook will
> deprecate MD5 as its sig algorithm, but will continue to support it for the
> clients using it in the wild)
>
> As a concrete example of what can be written when you don't need to worry
> about encryption, see: http://github.com/lshepard/oauth-wrap-
> demo/tree/master/src/wrap.js
> more) as *must implement*. This does not mean vendors have to support all
> of them, but that any *client* library or application claiming to be 'OAuth 2.0
> compliant' must implement all these methods.
>
> If a vendor issues tokens not using all these methods (which is more likely), it
> does not have to implement all these methods and can still be called 'OAuth
> 2.0 compliant' because any it can interop with *any* compliant library.
> However, if such a vendor produces a client library for its developers which
> only implements the methods deployed by the vendor, that library is 'OAuth
> 2.0 partially compliant' (because it will not interop with *all* vendors).
>
> In practice, from Facebook's perspective, you will be able to deploy OAuth
> suitable for your developers. It sounds like you will be using the plain method
> over SSL and either hmac-sha-1 or hmac-sha-256. Since Facebook usually
> makes things trivial for its developers, I expect Facebook to produce libraries
> that will implement these two methods, but not others. This will be a
> 'Facebook API' library that uses OAuth 2.0. It will be partially compliant but
> this only means it is only guaranteed to work with Facebook, but that it does
> so in a fully compliant way.
>
> EHL
>
>
>
>
>
> From: [email-masked] <http://oauth-
> [email-masked]>  [mailto:[email-masked]] On Behalf Of Luke
> Shepard
> asked is, "why use SSL exclusively?" Several of us have done a lot of thinking
> on it and I wanted to articulate my understanding of the pros and cons of the
> approach for discussion. The use case I primarily have in mind is that of a web
> service, like Facebook, Twitter, or Google services. Our service is primarily
> authenticated via the Web, but we have a use for all of the WRAP profiles
> (web app, client app, desktop, mobile).
>
> Overall, I think that the simplicity of using SSL outweighs all the associated
> costs for most developers. However, we should offer plaintext signatures as
> an optional performance enhancement for advanced developers.
>
> I've implemented OpenID and OAuth, and I've worked for years with
> It's not that SSL is a simpler encryption protocol than OAuth (it's not) but
> rather that commonly available tools almost universally support it - every
> major web browser, as well as most libraries for making HTTP requests (like
> curl) have built-in support for SSL. For OAuth 1.0, you need to use a client
> library just to construct your very first request.
>
> BigMath modules and encryption schemes. Even the relatively simpler
> Facebook client library requires several functions to sign requests. This
> makes the client libraries a black box and impedes understanding.
>
> Wouldn't it be great if we could write a protocol that doesn't even require a
> client library to implement? If I could just make an authenticated API request
> in my browser, as easily as with Basic Auth?
>
> Both signatures and SSL present difficulties in debugging, but they tend to be
> different. While with signatures you worry about composing the arguments
> request over the wire. You can't sniff a request, and to intercept it, you need
> an HTTP proxy that understands SSL, and you need to worry about invalid
> endpoint for debugging, but they may need to set up a sandbox
> environment to prevent damage from tokens exposed in plaintext.
>
> Server CPU costs will increase when handling SSL requests - especially on
> terminate the SSL connection. All the big companies I've talked to are
> There is a fixed cost to obtaining and signing an SSL certificates, although that
> has dropped in recent years such that an operator can have a cert signed for
> a single domain for pretty cheap.
>
> -- Latency
>
> which means that for client-to-server API requests, there may be some
> higher latency in each request. Smaller, mobile devices may be
> disproportionately affected by this, but as they grow more powerful it's less
> of a concern. Already today newer phones can handle SSL just fine.
>
> calls, it would be impossible to make an API call to an HTTPS endpoint from a
> normal HTTP page. However, as browsers advance and HTML5 methods like
> user's browser, then that information cannot be verified without an API call,
> unless a signature is provided. Similar to stateful vs. stateless mode in the
> OpenID 2.0 spec, the signature can serve as a performance enhancement to
> avoid an API call.
>
> Facebook is very interested in adopting OAuth WRAP / 2.0 / whatever
> because we want to help our long tail developers use our platform more
> easily. For the long tail, the simplicity provided by SSL will be crucial. It means
> smaller or nonexistent client libaries, it means that developers can just try
> out the API by typing it into a web browser, and it will help reduce debugging
> and maintenance costs.
>
> However, for the short head of high volume developers, we probably want
> an option to use something other than SSL to make secure requests. These
> and for them it may be a significant penalty to pay the SSL connection cost on
> every request. To that end, I think it's pretty important that OAuth 2.0
> support a method other than SSL as an option for advanced developers. But
> it should be just that - an option, and only for advanced developers, so that
> beginning programmers and folks learning an API don't need to worry about

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 29 Jan 2010 11:13:55 -0700

I'm fine with letting the market decide whether to use SSL or implement their own crypto in libraries (I know our implementations will choose SSL-only), but that means we'll be going from fully compliant with OAuth WRAP to partially compliant with OAuth 2.0 by making the same choices. Some concern was raised that the client library offerings will fragment because of this, but I think it's more likely there will just be two versions of OAuth 2.0 client libraries. The thin SSL-only version of the library used by Facebook, VWRAP, and anyone else that is fine with the SSL mode, and the thick client lib used by vendors that require other modes.

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 29, 2010 12:12 AM
To: David Recordon
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

EHL

EHL

EHL

-- Latency

-Luke Shepard

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 29 Jan 2010 12:25:01 -0700

Your server will be fully compliant. But if you produce a library that only supports you limited needs, it will be partially compliant.

EHL

On Jan 29, 2010, at 10:54, "Hurliman, John" <[email-masked]<mailto:[email-masked]>> wrote:

I’m fine with letting the market decide whether to use SSL or implement their own crypto in libraries (I know our implementations will choose SSL-only), but that means we’ll be going from fully compliant with OAuth WRAP to partially compliant with OAuth 2.0 by making the same choices. Some concern was raised that the client library offerings will fragment because of this, but I think it’s more likely there will just be two versions of OAuth 2.0 client libraries. The thin SSL-only version of the library used by Facebook, VWRAP, and anyone else that is fine with the SSL mode, and the thick client lib used by vendors that require other modes.

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 29, 2010 12:12 AM
To: David Recordon
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

At the end, the market will decide between signatures and S-Plain, the same way the RSA method in OAuth 1.0 gained very little traction (mostly because it was underspecified IMO). I don’t think we should make that decision here.

EHL

From: David Recordon [mailto:[email-masked]]
Sent: Thursday, January 28, 2010 10:33 PM
To: Eran Hammer-Lahav
Cc: Luke Shepard; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
(For the sake of simplicity, I am going to refer to the Plain bearer token with SSL/TLS as S-Plain)
WRAP appeal is also its limitation and (strictly as written) it sacrifices security for client ease. We still don’t know what OAuth 2.0 is (it is *not* WRAP, but likely to include ideas from it).
How is security sacrificed in the S-Plain method proposed for OAuth 2.0?  I understand that WRAP makes sacrifices, but am I missing something in terms of moving a Plain bearer token always over SSL/TLS when making authentication requests?

The problem I have with your approach is that you are mandating server deployment and given that this is a security protocol, we have no business telling servers what they MUST implement (they might consider S-Plain too weak for their needs). There are many reasons why vendors would rather not use the S-Plain option (you listed some of those) for every protected resource request. There are also many reasons why vendors would only support S-Plain and no signature option.
My proposal allows you to do everything you have asked for and your developers will have an easy life with the S-Plain option, or performance / flexibility with one of the HMAC methods. But the advantage is that I do not mandate Facebook to do anything it doesn’t want. Any OAuth 2.0 client will work with Facebook.
It is true that writing a fully compliant client will require more work. But the whole point of the S-Plain option is that it requires *no* additional library beyond having SSL/TLS available. So this is a vendor support issue – if you want to enable a library-less client development, offer S-Plain. This again, is a vendor choice.
Yes, but the tradeoff here is that a client will have S-Plain plus two or three other algorithms.  The library size is increased, the complexity is increased, and it encourages servers (like Facebook) to develop separate libraries which only support the one or two methods they have chosen to use.  Luke and I would like to avoid creating Facebook specific client libraries.  (This is of course based on the assumption that the majority of implementations will adopt S-Plain.  We then envision an advanced client library which also implements HMAC SHA-256.)

EHL

From: Luke Shepard [mailto:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 28, 2010 6:36 PM
To: Eran Hammer-Lahav; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

I think that your proposed design has it backwards: servers should bear complexity and one-time costs, not clients. Much of why I think OAuth WRAP / 2.0 is so appealing is that it dramatically simplifies life for developers. If a client can support SSL and doesn’t want to deal with signatures, then they never should have to. I want to be able to write a very lightweight SSL-only client library that is still fully OAuth 2.0 compatible.

If a client supports at least one of the required methods (SSL or one of the algorithms), then it can be considered fully OAuth 2.0 compliant. If it only supports encryption methods that are not in the required list, then it is partially compliant – that is, it may work with a specific vendor that advertises support for that algorithm, but it won’t work with all servers. As algorithms gradually change over time, client libraries can be upgraded while servers need to maintain backwards compatibility. (For example, Facebook will deprecate MD5 as its sig algorithm, but will continue to support it for the clients using it in the wild)

As a concrete example of what can be written when you don’t need to worry about encryption, see: <http://github.com/lshepard/oauth-wrap-demo/tree/master/src/wrap.js> http://github.com/lshepard/oauth-wrap-demo/tree/master/src/wrap.js
If I were to modify that JS to accommodate multiple signature algorithms, then I would need to include at least another 1-2k of JavaScript for each method just in case. That would be fairly ridiculous.

On 1/28/10 1:41 PM, "Eran Hammer-Lahav" <<http://[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Thanks Luke. This is a useful analysis.

The specification is going to define the four methods above (and possibly more) as *must implement*. This does not mean vendors have to support all of them, but that any *client* library or application claiming to be ‘OAuth 2.0 compliant’ must implement all these methods.

If a vendor issues tokens not using all these methods (which is more likely), it does not have to implement all these methods and can still be called ‘OAuth 2.0 compliant’ because any it can interop with *any* compliant library. However, if such a vendor produces a client library for its developers which only implements the methods deployed by the vendor, that library is ‘OAuth 2.0 partially compliant’ (because it will not interop with *all* vendors).

In practice, from Facebook’s perspective, you will be able to deploy OAuth 2.0 in a compliant way, while only implementing the methods that you find suitable for your developers. It sounds like you will be using the plain method over SSL and either hmac-sha-1 or hmac-sha-256. Since Facebook usually makes things trivial for its developers, I expect Facebook to produce libraries that will implement these two methods, but not others. This will be a ‘Facebook API’ library that uses OAuth 2.0. It will be partially compliant but this only means it is only guaranteed to work with Facebook, but that it does so in a fully compliant way.

EHL

From: <http://[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of Luke Shepard
Sent: Thursday, January 28, 2010 7:30 AM
To: <http://[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

In the discussions around the OAuth WRAP spec, one of the questions often asked is, “why use SSL exclusively?” Several of us have done a lot of thinking on it and I wanted to articulate my understanding of the pros and cons of the approach for discussion. The use case I primarily have in mind is that of a web service, like Facebook, Twitter, or Google services. Our service is primarily authenticated via the Web, but we have a use for all of the WRAP profiles (web app, client app, desktop, mobile).

-- It’s overwhelmingly simpler for developers.
I’ve implemented OpenID and OAuth, and I’ve worked for years with developers trying to handle signatures on the Facebook Platform. In my experience, calculating signatures is one of the most complex and difficult parts of an authentication protocol, and developers often get it wrong. By moving that piece down the stack we can get it out of their way and let developers focus on building their apps.

-- Existing tools ecosystem
It’s not that SSL is a simpler encryption protocol than OAuth (it’s not) but rather that commonly available tools almost universally support it – every major web browser, as well as most libraries for making HTTP requests (like curl) have built-in support for SSL. For OAuth 1.0, you need to use a client library just to construct your very first request.

Wouldn’t it be great if we could write a protocol that doesn’t even require a client library to implement? If I could just make an authenticated API request in my browser, as easily as with Basic Auth?

Both signatures and SSL present difficulties in debugging, but they tend to be different. While with signatures you worry about composing the arguments wrong or using the wrong algorithm, with SSL you worry about reading the request over the wire. You can’t sniff a request, and to intercept it, you need an HTTP proxy that understands SSL, and you need to worry about invalid certificate errors. To aid in this, providers will probably offer a non-SSL endpoint for debugging, but they may need to set up a sandbox environment to prevent damage from tokens exposed in plaintext.

Server CPU costs will increase when handling SSL requests – especially on every API call instead of just at the auth stage. At scale, this can become expensive, although it can be offset by using specialized hardware to terminate the SSL connection. All the big companies I’ve talked to are comfortable trading these higher costs for increased adoption due to the simplicity.

-- Latency

SSL connections take more time to establish than normal HTTP connections. Servers can use specialized hardware to speed it up, but clients rarely do, which means that for client-to-server API requests, there may be some higher latency in each request. Smaller, mobile devices may be disproportionately affected by this, but as they grow more powerful it’s less of a concern. Already today newer phones can handle SSL just fine.

If information is passed from a Service Provider to a Consumer through the user’s browser, then that information cannot be verified without an API call, unless a signature is provided. Similar to stateful vs. stateless mode in the OpenID 2.0 spec, the signature can serve as a performance enhancement to avoid an API call.

However, for the short head of high volume developers, we probably want an option to use something other than SSL to make secure requests. These developers tend to have already solved the low hanging performance fruit, and for them it may be a significant penalty to pay the SSL connection cost on every request. To that end, I think it’s pretty important that OAuth 2.0 support a method other than SSL as an option for advanced developers. But it should be just that – an option, and only for advanced developers, so that beginning programmers and folks learning an API don’t need to worry about signatures when they just want to play around.

Please let me know if I’m missing something or if my assumptions sound incorrect.

-Luke Shepard

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