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
