John, Yes, I overstepped in the first section. I'll retract all the stuff about bearer-tokens over an insecure channel not having a use-case. Clearly they're used all over the place. Whether or not this is a good idea is another question entirely and you've outlined a good way to approach it.
My point is only that bearer-tokens over an insecure channel seem to be always *less* secure or *as* secure (but never *more* secure) than using a signature approach over an insecure channel. As such, I'm uncomfortable taking away an existing, widely implemented, and usually more secure approach for authentication over an insecure channel (OAuth 1.0a signing) and replacing it with a less secure approach (bearer tokens w/o SSL/TLS). Ethan On Sun, Mar 7, 2010 at 1:40 PM, John Kemp <[email protected]> wrote: > On Mar 7, 2010, at 12:24 PM, Ethan Jewett wrote: > > [...] > >> In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in >> nearly all use cases. > > Just to point out that there are many use-cases which are today solved *only* > with "bearer tokens" - namely any authentication method which uses regular > Web cookies. > > Cookies are often sent over an insecure channel. They are usually not signed. > And any request which comes with a valid "session cookie" is assumed to be > from a legitimate requester, even though with cross-site attacks through > browsers, this is often a devastatingly wrong assumption (hence the need for > a browser same-origin policy). > > But the world has not collapsed. > >> Any use case where spam is a threat, for >> example, is not an acceptable use case because of this attack because >> any MITM can send an arbitrary number of spam messages that the >> provider application will show as coming directly from the user. If >> you think Twitter direct-message spam is bad now... > > You are talking about the /impact/ of an attack, and the impact of an attack > on a system secured only with bearer tokens is often high. There is usually > at least one other factor in security threat analysis, however - the /risk/ > of a threat. > > The risk of an attack on bearer tokens seems to be empirically low, despite > the relative ease of such an attack. > > The risk can also be mitigated by making bearer tokens expire quickly, or > have one-time use semantics. > > In short, bearer tokens work for quite a large set of use-cases. > >> >> Because of this and other possible attacks (successfully impersonating >> a provider gets you the bearer-token, for example), I think that >> bearer-tokens without SSL/TLS are not worth considering further for >> the vast majority of use cases. > > I disagree, but I'm not sure it matters anyway for the purposes of deciding > what features OAuth should support. > > OAuth will support bearer (ie. unsigned) tokens sent over SSL. So it will > support bearer tokens. It's just a question of whether the spec. should allow > implementations to send bearer tokens over any other channel than an SSL/TLS > channel. > > If someone wishes to do the risk analysis and decides that a particular > security feature is sufficient for what they want to do, why shouldn't they > be allowed to do it? Someone who gets it wrong, shoots him- or her-self (and > no-one else, as the whole community, or that company's partners don't have to > play along) in the foot, right? > > Make bearer+SSL/TLS mandatory to implement, but don't rule out bearer tokens > being sent over insecure channels, and we should all be able to implement > what we need to implement in peace. > > Cheers, > > - johnk > > > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
