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

[Justin Richer <[e-mail]>]

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
>         
>         
>  
> 
> 
>  
> 
>