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

We are not likely to provide less security than currently offered by the 1.0a specification (on the authentication side). While I welcome this discussion, my focus is to enable the two edge cases: "full" security (as currently offered by the OAuth HMAC method) and "transport layer" security (as currently offered by the PLAINTEXT method). I am confident that we can significantly simplify the HMAC-based solution. It is already much simpler in my working draft (which I will focus on next, right after my batch of discovery specs is out this week).

EHL

From: Chris Messina [mailto:chris.messina@gmail.com]
Sent: Monday, November 09, 2009 12:00 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; oauth@ietf.org
Subject: 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<mailto: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> [mailto: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<mailto: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<mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto: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