On Jan 14, 2010, at 7:39 PM, Richard L. Barnes 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.
Right. Which is why I'm currently OK with Eran's text either way as I think it allows bearer tokens with *any* other security protections, unless we specify exactly which security properties should be provided by the channel, vs. via other mechanisms. SAML's "confirmation method" is sort of the equivalent idea to what we've been talking about here (where the method could be "holder-of-key+a signature algorithm", "bearer" or something else) but we also haven't separated out security properties such as integrity or confidentiality for the purposes of this discussion. > (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.) +1 - johnk _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
