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

[Eran Hammer-Lahav <[e-mail]>]

While my approach is slightly different (one of the very few benefits of being the editor), it is what the plan is. The authentication spec is going to offer two methods: Plain (bearer token with optional shared secret), and HMAC (a significantly simplified signature flow based on the HMAC one in 1.0 but with less flexibility for limited platforms). Instead of sacrificing security I have been trying to make the case we should just raise the bar for what an OAuth client should be able to do. Both will accomplish simplicity but at different costs. The Plain method will give the bearer-token+TLS crown everything they need out of that spec.

The delegation spec is where most of the work is needed, and where I would like to see us adopt much of the new and improved ideas from WRAP.

EHL



From: John Panzer [mailto:[e-mail]]
Sent: Friday, November 13, 2009 9:48 AM
To: Eran Hammer-Lahav
Cc: [e-mail]
Subject: Re: [OAUTH-WG] why are we signing?

Replies inline (sorry for async postings):
On Fri, Nov 13, 2009 at 9:21 AM, Eran Hammer-Lahav <[e-mail]<mailto:[e-mail]>> wrote:


> -----Original Message-----
> From: John Panzer [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Friday, November 13, 2009 8:37 AM
> To: Eran Hammer-Lahav
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: [OAUTH-WG] why are we signing?
>
> The 90% is just MHO.
>
> I think we should be sure that using TLS for everything is unviable in
> 2010 before diving into complicated signing and binding.  For my use
> cases, non body signed requests are about equivalent to bearer token
> in terms of security; body signing is an interop pain point; absent a
> deus ex machina with a new, secure, simple, ip-free, interoperable
> algorithm for body signing I would personally use PLAINTEXT over TLS
> for resource access and move on to more important things.
>
> Note that nothing stops someone from defining a data protocol which
> supplies signatures and even binds to the important bits of the
> envelope.  And if you can get XML Dsig to work interoperably for your
> protocol, great!  But OAuth 2 could be defined to leave that to
> protocols and extensions.  In theory this would make things less
> interoperable, but in practice signatures are a huge interop pain
> point anyway (IMHO) so I do not believe there is a practical
> difference in the field.
That's half of what we are explicitly chartered to do. My point is that people should focus on the parts of the protocol they care about. I think such a reduction in functionality and scope would require a more explicit reconsideration of this entire WG.

If the WG needs to consider it, then I move that we do the first, PLAINTEXT, relying-on-TLS-when-necessary half (at least to the point of an I-D that people can go implement) before moving on to the far more complex world of new signature algorithms.

This doesn't mean having two specs, just stabilizing the bits nobody has serious arguments about so people who need the first half can move forward.  Obviously things can change in draft, etc., but we're all playing the odds here and actual running code is important to have.


I for one, see great value in offering some form of crypto-based security for cases where TLS is not suitable.

I am also not buying the argument that we should avoid crypto because it is hard. The same argument can be made about TLS (who really writes their own libraries for that?).

Nobody; we get them from Ben Laurie.  But they're already available everywhere, so nobody has to write them, while the OAuth 2 libraries, whatever they will be, are available nowhere right now.  So whatever OAuth comes up with has to be _significantly_ simpler and easier than using openssl.



EHL

> On Thursday, November 12, 2009, Eran Hammer-Lahav <[e-mail]<mailto:[e-mail]>>
> wrote:
> > 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:[e-mail]<mailto:[e-mail]>]
> >> Sent: Thursday, November 12, 2009 7:46 AM
> >> To: Eran Hammer-Lahav
> >> Cc: [e-mail]<mailto:[e-mail]>
> >> 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
> <[e-mail]<mailto:[e-mail]>>
> >> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On
> >> Behalf
> >> >> Of Brian Eaton
> >> >> Sent: Wednesday, November 11, 2009 5:54 PM
> >> >> To: [e-mail]<mailto:[e-mail]>
> >> >> Cc: [e-mail]<mailto:[e-mail]>
> >> >> 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,  <[e-mail]<mailto:[e-mail]>> wrote:
> >> >> >
> >> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <[e-mail]<mailto:[e-mail]>>
> 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
> >> >> [e-mail]<mailto:[e-mail]>
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> > _______________________________________________
> >> > OAuth mailing list
> >> >
>
> --
> --
> John Panzer / Google
> [e-mail]<mailto:[e-mail]> / abstractioneer.org<http://abstractioneer.org> / @jpanzer