On Tue, Apr 6, 2010 at 12:39 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote:
> Hi Blaine, > > 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 >> >> > I don't understand your objections. If a resource provider decides to > support HTTPS only, no client w/o HTTPS support can connect thus > circumventing this policy. It is possible to 'support' HTTPS but not check certificates. Would that be acceptable to servers supporting HTTPS only? (No.) > > that behave in that way should be flagged as non-compliant and >> publicly humiliated. >> > agreed :-) > > If we just write SHOULD for HTTPS/secure channel >> support, then those clients are acting "properly." >> >> > Why not explicitly state in the spec that HTTPS support is a MUST HAVE for > libraries? This would also mirror the existing de facto situation for web browsers, all of which support HTTPS on demand. > > 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. >> >> > There are a variety of deployment scenarios for OAuth2 (e.g. internet > small/large, intranet) as well as replay countermeasures (encryption, > short-living tokens, restricted permissions, ...). Can we really > anticipate/consider all of them and select HTTPS as the only solution? Even > the spec for BASIC-Authentication (http://www.ietf.org/rfc/rfc2617.txt) > does not force a certain mean of transport protection. It just recommends to > consider security enhancements: > > ---- from http://www.ietf.org/rfc/rfc2617.txt > > The Basic authentication scheme is not a secure method of user > authentication, nor does it in any way protect the entity, which is > transmitted in cleartext across the physical network used as the > carrier. HTTP does not prevent additional authentication schemes and > encryption mechanisms from being employed to increase security or the > addition of enhancements (such as schemes to use one-time passwords) > to Basic authentication. > > The most serious flaw in Basic authentication is that it results in > the essentially cleartext transmission of the user's password over > the physical network. It is this problem which Digest Authentication > attempts to address. > > Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used (without enhancements) to protect > sensitive or valuable information. > > ---- > HTTPS is state of the art and should from in my opinion be the > _recommended_ option. This leaves implementors enough freedom to use other > security measures where neccessary/sufficient/applicable. > > regards, > Torsten. > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
