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

Are you suggesting using TLS for every protected resource or just for obtaining the token and refreshing it?

OAuth today already supports this via the PLAINTEXT method (though not very cleanly with all the other parameters still required even if useless).

Also What use cases? And where is this 90% comes from?

I for one have always rejected the argument that since cookies are already so broken, there was little point in trying to make API security better. When we originally worked on OAuth we explicitly looked to prevent replay attacks as well as intercepting and changing an authenticated request. We limited our scope to protecting the request URI and (some) parameters. That provided sufficient protection to the APIs people had in mind at the time which were mostly GET/POST requests with just a few parameters. The body hash extension then extended the usefulness of the protocol to other payloads.

The delegation half of the protocol deals with exchanging passwords with tokens. Those who find bearer token sufficient without any additional crypto can simply focus their attention on that. On the authentication side, I would like to offer something other than "use TLS for everything" or risk attacks for ("only") 10 minutes.

EHL

> -----Original Message-----
> From: John Panzer [mailto:jpanzer@google.com]
> Sent: Thursday, November 12, 2009 7:46 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] why are we signing?
> 
> I think that https plus bearer token is sufficient for 90% of use
> cases.  I haven't heard a first principles argument otherwise.  If for
> no other reason than the record, could the proponents of signing
> explain why bearer token over TLS will not meet their needs?
> 
> On Thursday, November 12, 2009, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > As a matter of process, I would suggest looking at what the 1.0 HMAC-
> SHA1 method signs, and discuss if it is where we should be. We are
> working with an existing draft and should structure our discussions as
> feedback to that point of reference. This doesn't limit the conclusion
> in any way, and is how this WG has been chartered.
> >
> > EHL
> >
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf
> >> Of Brian Eaton
> >> Sent: Wednesday, November 11, 2009 5:54 PM
> >> To: BeckW@telekom.de
> >> Cc: oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] why are we signing?
> >>
> >> So we've got at least five different use cases for signing requests
> >> with the oauth access token and token secret.
> >>
> >> Sweet.
> >>
> >> The downside to the use cases is that they all have incompatible
> >> signature base strings.  I'd like to see us come up with something
> so
> >> that we don't have to reinvent the base string again for every
> single
> >> use case.
> >>
> >> Cheers,
> >> Brian
> >>
> >> On Wed, Nov 11, 2009 at 5:49 PM,  <BeckW@telekom.de> wrote:
> >> >
> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <john@jkemp.net> wrote:
> >> >> If we are only interested in i) [authenticating the entity] then
> >> > signing any piece of the message might
> >> >> be sufficient. If we are interested in ii) [binding the signature
> to
> >> > the message] (or some other security property)
> >> >> then we will need to identify which pieces of the message we want
> to
> >> > provide
> >> >> that, or other, security properties for.
> >> >
> >> >> Brian Eaton wrote:
> >> >> OK, let me try to summarize what I've heard on this thread about
> the
> >> >> different use-cases for message signing:
> >> >>
> >> >> - sign the HTTP request
> >> >>   Used to prevent MITM from replaying token to a different URL.
> >>  Also
> >> >> limits the replay attack window to minutes instead of hours.
> >> >>
> >> >> - sign various other parts of the message
> >> >>   DKIM: signs various message headers
> >> >>   SIP: unspecified, just says "relevant parts of SIP request"
> >> > Hannes Tschofenig suggested handle SIP messages the way described
> in
> >> RfC
> >> > 4474 (SIP identity). It lists the parts of a SIP messsage that
> need
> >> to
> >> > be protected.
> >> >
> >> > Wolfgang
> >> >
> >> _______________________________________________
> >> 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
> >
> 
> --
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer