I agree that TLS (which, in the IETF, sprobably a better three-letter
word than SSL) is the simplest solution, and the one that is
implementable.
Igor
Blaine Cook wrote:
OAuth WRAP is very similar to cookies as deployed by major vendors.
Google has just switched to HTTPS-by-default for all GMail
sessions[1], and my understanding (per [2]) is that access to
authenticated sessions (i.e., full GMail or Google Docs access versus
just displaying "[email protected]" on the page) is always negotiated with
a secure cookie. Thus, Google has made decisions internally to secure
the equivalent of both the Refresh and the Bearer token, short-lived
assurances aside.
We're also entering an age where we have enough computing power to
*factor* RSA-1024 in non-infinite-time; handheld devices that are
realistically expected to use these protocols have sufficient
computing power and battery life to encrypt HTTP requests and decrypt
the responses (my phone already does this for all Twitter and email
requests; yours probably does, too).
As such, I can't see how *not* requiring SSL for unsigned requests
could pass muster at an IETF security review.
[1] http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html
[2]
http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web-applications.html
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
