Re: [OAUTH-WG] Basic signature support in the core specification

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

Are you going to write it? Still waiting for the best practices guide for 1.0 people suggested over three years ago.

EHL

> -----Original Message-----
> From: Justin Richer [mailto:[e-mail]]
> Sent: Monday, September 27, 2010 12:04 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG
> Subject: Re: [OAUTH-WG] Basic signature support in the core specification
> 
> Arguments like this are why I have been advocating for separating the
> "developers guide" from the "protocol spec" for a while now. I believe that
> they support two different audiences.
> 
> A developers' guide then has the option of combining multiple specs,
> selecting profiles of those specs, and laying out exactly what's happening at
> each step for people to follow.
> 
>  -- Justin
> 
> On Mon, 2010-09-27 at 11:35 -0400, Eran Hammer-Lahav wrote:
> > This is a stupid discussion. We have been talking past each other (the
> > working group) for over a year. We are not likely to convince either
> > side that bearer tokens are bad or good idea.
> >
> >
> >
> > All these experts reviewed WRAP in the strict context of their own
> > environment, with existing protocols and other weaknesses. Other and I
> > are reviewing it in the wider context of what is good for the web, and
> > am much less concerned about complexity. IOW, I don’t believe that in
> > this case WRAP made the right choice between developer ease and
> > security.
> >
> >
> >
> > This is also exactly the problem with the current specification. New
> > readers are more likely to assume that what is good for these big
> > companies is also good for them, without making their own threat model
> > analysis. How would they reach any other conclusion when the
> > specification doesn’t offer a complete alternative?
> >
> >
> >
> > We should focus on finding a compromise everyone can live with, since
> > clearly debating the two sides has produced nothing. I think
> > positioning bearer tokens as the primary mechanism, but including a
> > signature alternative in the same specification is a reasonable
> > compromise. Bearer token fans get the spotlight, while those looking
> > for a signature (providing the same protections as 1.0a HMAC-SHA-1)
> > get some algorithm included.
> >
> >
> >
> > We need to find a way to give each side something to live with.
> >
> >
> >
> > EHL
> >
> >
> >
> >
> >
> > From: Dick Hardt [mailto:[e-mail]]
> > Sent: Monday, September 27, 2010 6:31 AM
> > To: John Panzer; Eran Hammer-Lahav
> > Cc: OAuth WG; Ben Laurie
> > Subject: Re: [OAUTH-WG] Basic signature support in the core
> > specification
> >
> >
> >
> >
> > I'll echo John's comments and remind you that Micrsoft, Yahoo! and
> > Google security experts with plenty of real world experience worked on
> > WRAP which is OAuth bearer tokens.
> >
> >
> >
> >
> > Microsoft, Google, Salesforce, Facebook and others have deployed
> > bearer token OAuth in production after internal security reviews. I
> > don't think that is a personal opinion, that is fact.
> >
> >
> >
> >
> > wrt. another comment you had about security considerations, Brian
> > Eaton did write up a bunch of security considerations for WRAP.
> >
> >
> >
> >
> > On 2010-09-27, at 12:01 AM, John Panzer wrote:
> >
> >
> >
> >
> > On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav
> > <[e-mail]> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Dick Hardt [mailto:[e-mail]]
> > > Sent: Sunday, September 26, 2010 11:21 PM
> >
> > > >  What I absolutely object to is presenting a specification that to
> > a new
> > > reader will read as if bearer tokens are the default way to go.
> > OAuth 2.0 core
> > > today reads like a complete protocol and that's my problem.
> > >
> > > It is a complete protocol for many existing use cases.
> >
> >
> > That's clearly a matter of personal opinion :-) and why we have been
> > arguing about this for over a year.
> >
> >
> > > For those use cases
> > > where it is not, you can call require signatures and point people to
> > the
> > > signature spec, just like the use of bearer tokens points people to
> > the TLS
> > > specs.
> >
> >
> > According to Ben Laurie [1] and Ben Adida [2], a simple reference to
> > TLS is a recipe for disaster.
> >
> >
> >
> >
> > Actually in [1], Ben Laurie does not say that a simple reference to
> > TLS is a recipe for disaster.  (Go read it.)  In fact his first point
> > is that you need a well-define threat model before you can talk
> > sensibly about any of this; I would really like us to do that in this
> > case too.
> >
> >
> >
> >
> >
> >         People tend to implement TLS incorrectly on the client side
> >         which voids many of the important protections it is meant to
> >         provide.
> >
> >
> >
> >
> > The bits they tend to implement incorrectly (specifically, things like
> > checking for certificate revocations) seem to me to be very general
> > and exactly the kinds of things one needs in order to implement _any_
> > protection against the endpoint impersonation you are worried about.
> >  Why would they be more likely to get it right for a new protocol than
> > for an existing one?
> >
> >
> >
> >
> >
> >
> >         As the editor, I am having a hard time consolidating your view
> >         which treats readers as security experts, capable of making
> >         educated decisions about the protocol, and the demands from
> >         others that the specification should be completely accessible
> >         to any developer (especially those with no security
> >         background) and read like a tutorial on OAuth.
> >
> >         If we want to keep the full range, we need to clearly express
> >         it, including highlighting the significant shortcomings of
> >         bearer tokens, the known TLS deployment issues, and the value
> >         in whatever signature proposals we have ready to reference or
> >         include.
> >
> >         Standards are meant to improve interoperability, but also
> >         security. This is why any IETF charter dealing with an
> >         existing technology states that the working group may break
> >         compatibility if it has interop or security reasons to do so.
> >         We are doing fine on interop, but doing pretty badly on
> >         security.
> >
> >         EHL
> >
> >         [1] http://www.links.org/?p=846
> >         [2] http://benlog.com/articles/2009/12/22/its-a-wrap/
> >
> >
> >
> >
> >         _______________________________________________
> >         OAuth mailing list
> >         [e-mail]
> >         https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> >
> >
> >
> >
> >
>