IETF standards can do one of two things: they can set a high level of security or they can clearly point out where they are insecure. If we do not require HTTPS for bearer tokens, we will have to put a big disclaimer that doing so without some other protections is insecure.
The choice is between setting a higher bar and letting those who don't use HTTPS be called 'not in compliance', or set a low bar and put a SHOULD with a strongly worded warning. I strongly believe we have a responsibility to improve internet security. The only tool we are given in this working group is calling an implementation 'not in compliance'. Calling something insecure does not deter developers from doing stupid things (hence the wide use of Basic auth where it clearly must not be used per the spec). Calling something in-compliance when it is not falls under false marketing... At the end, you are free to deploy whatever you want. But if you are going to deploy OAuth in an insecure way (regardless of how insecure your other interfaces are), you don't get say it is compliant. Is anyone here naïve enough to think that the first time such an insecure OAuth token is stolen and abused, people will care that it was ignoring the SHOULD? The company will say that their implementation is in compliance and move the blame on to OAuth. Go implement whatever you want. But the spec should set the highest practical bar it can, and requiring HTTPS is trivial. As a practical note, if the WG reaches consensus to drop the MUST, I would ask the chairs to ask the security area and IESG to provide guidance whether they would approve such document. The IESG did not approve OAuth 1.0a for publication as an RFC until this was changed to a MUST (for PLAINTEXT) among other comments, and that with a strong warning. There is also an on going effort to improve cookie security. Do we really want OAuth to become the next weakest link? EHL On 4/6/10 12:04 PM, "Blaine Cook" <rom...@gmail.com> wrote: > My take on this is that MUSTs MAY be ignored. ;-) > > To echo John's concerns here, the worst-case scenario is that client > libraries implement "no SSL present" as a gentle reminder warning with > a flag (possibly the default) to disable those HTTPS warnings. Clients > that behave in that way should be flagged as non-compliant and > publicly humiliated. If we just write SHOULD for HTTPS/secure channel > support, then those clients are acting "properly." > > If WRAP is aiming to just be a replacement for Cookie auth, then why > don't we just add a redirection profile for issuing cookies? They work > now, refreshing them is built-in, etc, etc. Instead, what we're trying > to do is build something better, more secure, and more aligned with > the sorts of behaviours we see and want to encourage on the web. > > b. > > On 6 April 2010 11:54, John Panzer <jpan...@google.com> wrote: >> My $.02: SHOULD is okay, as long as all clients MUST support HTTPS. E.g., >> SHOULD for service providers, MUST support for clients. >> Otherwise, you will end up with clients that don't support https or don't do >> it properly. (E.g., don't bother to check certificates.) Which hurts >> security for service providers that do want SSL. >> >> On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >>> >>> +1 for the standard should recommand HTTPS or comparable means of >>> transport protection but not require it. >>> >>> This requirement does not result in any benefit for the specification by >>> itself (e.g. simplification). Therefore, the decision to use HTTPS or any >>> other means should be up to the service providers based on its security >>> considerations. >>> >>> One of the biggest differences between OAuth2 and WRAP is that OAuth2 >>> requires that Protected Resources be accessed using HTTPS if no signature is >>> being used. Bullet Point #2 in Section 1.2 says: >>> >>> 4. Don't allow bearer tokens without either SSL and/or signatures. >>> While some providers may offer this ability, they should be out >>> of spec for doing so though technically it won't break the flows. >>> >>> While I personally think that requiring SSL is a fantastic idea, and it¹s >>> very hard for me to argue against it, however.... >>> >>> One of the goals for WRAP was to define a standard AuthZ interface for >>> APIs which matched what we currently have on the Web. WRAP protected APIs >>> are intended to be a replacement for screen scraping. >>> >>> On the web, almost all websites implement Cookie Auth. Specifically, when >>> you log into a website, the browser is issued a bearer token, called a >>> Cookie, and the browser is able to access Protected Resources by using the >>> Cookie as the credential. >>> >>> The WRAP access token is intended to be a direct replacement for the HTTP >>> Cookie. A client should be able to present its bearer token (a WRAP Access >>> Token or an HTTP Cookie) without having to sign the request. >>> >>> While I certainly think that requiring SSL would be a huge improvement in >>> internet security, HTTP does not require SSL, and since WRAP was intended to >>> be a replacement for HTTP Cookie Auth, then OAuth2 should also not require >>> HTTPS. >>> >>> Yes, dropping the SSL requirement isn¹t optimal, but again the intent with >>> WRAP was to replace HTTP Cookie auth, and it should be up to the service >>> provider to require HTTPS when applicable. >>> >>> Allen >>> >>> _______________________________________________ >>> 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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
