Hi Eran! On Jan 14, 2010, at 11:41 PM, Eran Hammer-Lahav wrote:
> (this is not aimed at John Kemp) I think you mean it's not _specifically_ aimed at me, but in any case, I'll take the opportunity to reply anyway ;) > > I understand that some providers will not want to bother with the extra > security for their own reasons. I am willing to assume they are doing this > fully aware of the repercussions of their actions. What I don't understand > is why should the protocol - which is aimed at interoperability - bother > with it? I do agree that is the central question. > > We got people here representing many companies, large and small. Can one of > them please raise their hand and ask for this feature? I am asking for us to not remove the possibility to use a non-channel, non-signature security method to secure OAuth tokens, so I raise my hand. > And if they do, can > they explain how they justify providing poor security to their users? This sounds like a trick question ;) Speaking on behalf of only myself (and not my company), I aim NOT to provide poor security, but to provide just the right amount of security for a given use-case. Where "just the right amount" means the amount which is of the least cost to the overall system to provide an adequate amount of security for a given use-case. Today, OAuth already supports that possibility - a sliding-scale of security, as I noted in earlier email. Even if we require TLS or signing, we still have more than one security method, and each of them has different security properties. We will not (as far as I can tell) ever limit ourselves to a single choice for providing security, and I would argue that we should not. > > I am no longer interested in the argument that somewhere there are valid use > cases. Writing a protocol for scenarios that are not anchored in reality is > bad. OAuth 1.0 does not require using a secure channel for sending token > secrets because people claimed it will be a problem for some providers. So > far, no such providers showed up. I would say that it is more likely that no such providers wished to announce what they want to do in a public forum. But that doesn't mean that what they plan to do is bad for their users. Security requires tradeoffs, and people should be both forced, and allowed to make those tradeoffs - based on their own analysis, not some standard. Public pressure _will_ limit what providers actually offer their users, but that is a market force and shouldn't be enforced in a standard (in my opinion anyway). > > If someone want to argue the need of no-crypto / no-HTTPS, while showing how > that need justifies subjecting the web to more bad protocols and poor > foresight, I am eager to listen. > > If you don't care about security, you are free to implement the protocol > poorly. There is no OAuth Police to enforce servers to check signature and > reject requests with bad ones. At least by forcing such cases to break the > protocol, we are forcing them to make an active decision and we get their > API users to notice. Yes, if the community as a whole decides that my argument is weak, then I certainly would concede. We can decide as a group that we don't want to support the minimal-security use-cases by mandating crypto, and I will bow to the will of the community in that decision. I think there is an advantage to making as many implementations as possible conformant to OAuth, but perhaps not everyone in the community agrees with that? > > There is also a case to be made about pushing the envelope when it comes to > security. The more services use TLS, the cheaper and easier it will get. > That's economics 101. And unlike writing new code for new OAuth signatures, > requiring TLS will simply mean linking another library and making a function > call. > > My vote is to start with an HTTPS requirement for any unsigned request, and > let those who have real reasons to object show up. None of the current users > of OAuth 1.0 will be able to claim this since they all use HTTPS for all > such requests. I am not prepared to name names. But I will say that I have helped design two OAuth-like protocols in my career, and in both cases, we were asked by some customers of those protocols to allow bearer tokens without TLS. When I look at what is possible in the offline world, I would ask - would you require that movie theatre tickets bought in advance were encrypted in transport between the person who bought the ticket and the receptionist at the cinema? What if the person drops her ticket and it's picked up by someone else? The risk of someone dropping his ticket is low, so we don't bother to secure it (of course, I haven't been to a city movie theatre in years so perhaps you need to show ID even to see a movie these days -- I hope not ;) Of course, the person who _does_ drop his ticket will be mad when he gets to the movie theatre, but probably not too mad. The system has worked quite well without any real security. We might add more security, but it would, even today, probably be hard to justify the cost. Yes, those things change over time, but having a sliding scale of security is a good thing, not a bad thing - and that is already allowed by OAuth today, (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue even if you remove PLAINTEXT from the list. - johnk > > EHL > > > On 1/14/10 5:59 AM, "John Kemp" <[email protected]> wrote: > >> Hi Blaine, >> >> On Jan 14, 2010, at 7:10 AM, Blaine Cook wrote: >> >>> OAuth WRAP is very similar to cookies as deployed by major vendors. >> >> How is that relevant to _this_ discussion (I apologize, I don't know much >> about WRAP)? >> >>> >>> Google has just switched to HTTPS-by-default for all GMail >>> sessions[1], >> >> Yes, HTTPS by default, and they are doing it in order to secure the exchange >> of email - allowing emails to remain confidential on insecure networks. I >> think that is a strong use-case for requiring confidentiality. >> >> But not all use-cases for OAuth need that much confidentiality, or any >> confidentiality at all. >> >>> and my understanding (per [2]) is that access to >>> authenticated sessions (i.e., full GMail or Google Docs access versus >>> just displaying "[email protected]" on the page) is always negotiated with >>> a secure cookie. Thus, Google has made decisions internally to secure >>> the equivalent of both the Refresh and the Bearer token, short-lived >>> assurances aside. >>> >>> We're also entering an age where we have enough computing power to >>> *factor* RSA-1024 in non-infinite-time; handheld devices that are >>> realistically expected to use these protocols have sufficient >>> computing power and battery life to encrypt HTTP requests and decrypt >>> the responses (my phone already does this for all Twitter and email >>> requests; yours probably does, too). >> >> I guess my concern about performance is more at the server-side, where many >> requests may be processed more or less simultaneously. Back in the old days >> (1997) we had a special crypto hardware accelerator in our Internet-connected >> proxies, and our non-Internet connected machines wouldn't use SSL at all, >> because of the performance impact. >> >> I'm sure things are better these days, but crypto operations still add >> performance overhead that may not in practice be necessary for every >> use-case. >> >>> >>> As such, I can't see how *not* requiring SSL for unsigned requests >>> could pass muster at an IETF security review. >> >> Well, I don't know what is required to pass IETF security review, and perhaps >> you're right, but the point is really whether there are cases where a >> combination of short-lifespan + replay-prevention and possibly other >> non-transport things could provide enough security to allow people to perform >> real work with OAuth tokens. >> >> And I think there are such cases - rather vaguely I could say that the broad >> category would be anything for which a large volume of authorized requests is >> possible, and where the "value" in an individual request is low. That >> certainly does not include email, which I rather think _is_ deserving of >> confidentiality over insecure networks (of course, Gmail does allow you to >> turn off https if you are in a more secure network environment). >> >> Regards, >> >> - johnk >> >>> >>> [1] >>> http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html >>> [2] >>> http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web-appli >>> cations.html >>> >>> 2010/1/14 John Kemp <[email protected]>: >>>> >>>> On Jan 14, 2010, at 1:05 AM, Eran Hammer-Lahav wrote: >>>> >>>> [...] >>>>> >>>>> QUESTIONS: Are there any valid (such that will pass IETF security review >>>>> scrutiny) reasons for allowing unsigned requests to be sent in the clear >>>>> over an insecure channel? Are there use cases for this (regardless of >>>>> their >>>>> security properties)? >>>> >>>> I am still wavering on this. >>>> >>>> I think that using a bearer token with short lifetime and one-time use >>>> semantics (for example) is probably sufficient security for many use-cases. >>>> And using TLS/SSL (or even just signing and verifying a signed request) in >>>> all cases may provide too much performance overhead for some of those >>>> cases. >>>> >>>> In other words, I think that it's not only channel security we need to >>>> consider, but a combination of other measures that would, in some cases, >>>> obviate the need for TLS. >>>> >>>> Regards, >>>> >>>> - johnk >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
