Doesn't the fact that this approach has clearly failed for HTTP Basic act as a warning sign? 2617 clearly states the problems in using Basic over insecure channels, and yet, given its simplicity, it is one of the most widely used and abused protocol around.
I think this is a case where security and interoperability must be considered as a pair. We know what makes a more secure protocol. How does making it less secure by not making HTTPS required improve interoperability? If it doesn't, there is no justification other than to make bad security easier to excuse. EHL On 1/14/10 4:39 PM, "Richard Barnes" <[email protected]> wrote: >> As such, I can't see how *not* requiring SSL for unsigned requests >> could pass muster at an IETF security review. > > Speaking as someone who does IETF security reviews ... :) > > If I were reviewing a document that defines an optional insecure mode of > operation (in this case, operating without TLS), I would be looking for > basically two things: (1) A discussion of the risks if the insecure mode is > used, and (2) a motivation for why these risks might be acceptable in certain > cases. This is in the spirit of "MUST=SHOULD+exception" -- if it's a SHOULD, > you need to explain the exception. In this case, the risks (1) are pretty > obvious: A passive observer can steal your password and use it to authenticate > as you. The motivations (2) are what this thread is about. > > I would also observe that "MUST use TLS or equivalent" is actually the same as > "SHOULD use TLS", since the "or equivalent" isn't really specified. (This is > really obvious when you think about it from the perspective of an implementor: > If you're going to cover the "or equivalent" cases, then you have to have be > able to operate in non-TLS mode.) The "or equivalent" cases are the ones > where not using TLS might be acceptable, i.e., the ones that should be cited > as motivations (2) for allowing the non-secure mode. > > Taking the SECDIR hat off, it seems to me that there are some motivations > appearing in this thread: > -- Appropriate key management (frequent key refresh) > -- Private trusted networks > -- John's observation that "URL+token" == "private URL" > So ISTM that "SHOULD use TLS" could be motivated here. > > (Now, all that said, it probably wouldn't hurt to have TLS as a "MUST > implement" so that it's there if people want to use it.) > > --Richard > > > > >> 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
