> -----Original Message----- > From: Luke Shepard [mailto:lshep...@facebook.com] > 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. > > 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. 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? > > 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? 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 > > On 1/28/10 10:33 PM, "David Recordon" <record...@gmail.com> wrote: > On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav > <e...@hueniverse.com> 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.) 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:lshep...@facebook.com] > Sent: Thursday, January 28, 2010 6:36 PM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth > communication > > > 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" <e...@hueniverse.com > <http://e...@hueniverse.com> > wrote: > 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: oauth-boun...@ietf.org <http://oauth- > boun...@ietf.org> [mailto:oauth-boun...@ietf.org] On Behalf Of Luke > Shepard > Sent: Thursday, January 28, 2010 7:30 AM > To: oauth@ietf.org <http://oauth@ietf.org> > 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. > > == 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
