Re: [OAUTH-WG] why are we signing?

Indeed, in the beginning of OAuth, that was one of the primary drivers that
lead us to the decision to sign everything — because of the non-SSL case...

While it's possibly increasingly common to expect that serious developers
will go and buy an SSL cert, that may not be the case for the wider array of
hobbyist types. Now, that's not to say that they are the only audience that
needs to be addressed, but the idea was to make it harder for them to screw
up if they leaked their API calls... Clearly it turned out that the signing
bit intended to prevent against such attacks itself was too hard to
implement, and so now we're having these conversations again.

At least now we have more data about what the market will bear now.

Anyway, that's my recollection. But it might also not be exactly the
explanation for what you're looking for.

Chris

On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav <eran@hueniverse.com>wrote:

> The problem is, we are not likely to ever reach consensus on 'reasonable
> security'.
>
> For example, I don't find most cookie-based session systems reasonably
> secure without SSL/TLS. Being able to sit at a coffee shop with free wifi
> and a laptop and steal sessions cookies, then access people's email for the
> duration the cookie is valid isn't reasonable or secure.
>
> If you would like to try this approach, I would suggest adding next to each
> option the list of common attacks still possible under those terms. It will
> allow us to evaluate the added security each level of complexity brings.
>
> EHL
>
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Brian Eaton
> > Sent: Sunday, November 08, 2009 9:03 PM
> > To: oauth@ietf.org
> > Subject: [OAUTH-WG] why are we signing?
> >
> > Hey folks -
> >
> > What are the use cases for cryptography in OAuth?  Why are we signing
> > requests?  And how much of each request do we need to sign in order to
> > be useful?
> >
> > As I see it, we have roughly the following menu of choices:
> >
> > 1) No signatures.
> >     Just use bearer tokens.  Use transport layer encryption to keep
> > those bearer tokens from leaking.
> >
> > 2) Signed tokens.
> >     We could just sign a timestamp, rather than entire messages.
> >
> > 3) Partially signed messages.
> >     We could sign just the request URL, or the request URL plus some
> > parameters.
> >
> > 4) Fully signed messages.
> >      Sign as much of the HTTP request as possible, down to the bits of
> > the HTTP entity body.
> >
> > My guess is we need at least two out of those four choices (one with
> > bearer tokens, a la OAuth 1.0 plaintext) and another with
> > cryptography.  But I'm not sure whether we need to sign entire
> > messages, or if we can get away with something simpler and still have
> > reasonable security.
> >
> > Cheers,
> > Brian
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private