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

[Richard Barnes <[e-mail]>]

Right.  Generally the expectation is that the Security Considerations  
section will discuss what the threats are against the protocol in  
question, how security features mitigate those threats, and what the  
risks are of not using those features.  At least that's what I look  
for when I do a SECDIR review :)

The authoritative guide is RFC 3552:
<http://tools.ietf.org/html/rfc3552>

--Richard



On Dec 2, 2009, at 7:49 AM, John Panzer wrote:

> It requires a security considerations section :).
> --
> John Panzer / Google
> [e-mail] / abstractioneer.org / @jpanzer
>
>
>
> On Wed, Dec 2, 2009 at 7:18 AM, Prateek Mishra <[e-mail] 
> > wrote:
> Stephen,
>
> +1 from our side.
>
> Here is a newbie question: does the IETF process require a  
> discussion of threats and countermeasures
> as part of the specification? - explaining the specific situations  
> that rely on SSL or signing and what the consequences
> of "turning it off" might be...
>
> - prateek
>
> I think we'll need an analysis of where we end up wanting TLS
> for the protocols we produce. I wouldn't expect any big
> surprises, but right now I don't think we can be sure since
> things seems to be in flux to some extent.
>
> Then, I'd be for saying that TLS MUST be used for those operations.
> However, I can well believe that there may be some niches where
> using TLS isn't easy, so I could live with something like: it MUST
> be possible to use TLS, and that deployments SHOULD use it, with
> guidance as to the type of scenario where we think TLS really
> has to be turned on, and maybe text about why sometimes people
> can't do that.
>
> So I don't think we can finish this discussion at this stage.
>
> S.
>
> Eran Hammer-Lahav wrote:
>
> <smiling but not joking>
>
> I would like to make an official request to the chair for a  
> consensus call on recommending SSL but keeping it optional in the  
> various OAuth components. We can figure out how strong to make the  
> language (or how scary), and we may make it mandatory in some flows/ 
> profiles, but I would like to be done with this discussion (for the  
> n time).
>
> If someone will want to raise new arguments, well, this is the IETF  
> so who can stop them? :-)
>
> EHL
>
>
> -----Original Message-----
> From: Dick Hardt [mailto:[e-mail]]
> Sent: Tuesday, December 01, 2009 9:51 PM
> To: Brian Eaton
> Cc: Eran Hammer-Lahav; Peter Saint-Andre; <[e-mail]>;
> Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
> Subject: Re: [OAUTH-WG] why are we signing?
>
>
> On 2009-12-01, at 5:46 PM, Brian Eaton wrote:
>
>
> On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav
>
> <[e-mail]> wrote:
>
> Getting a Class 1 cert from the likes of StartSSL is easy as pie
> these days. IMHO there is no excuse for not deploying SSL if you
> care one whit about security. The problem is that too many
> small-scale developers (and big companies!) simply don't care.
>
> Don't care, don't need that much security, don't understand it, etc.
>
> Bottom line is that requiring SSL is certain to fork this work if  
> not done right.
>
> Note, however, that someone who can't get SSL working and still
> deploys OAuth has basically no security against eavesdroppers or MITM
> attacks, and certainly can't expect OAuth to provide it.  The issues
> are in the token issuance phase: these organizations are sending user
> passwords and session cookies in clear text!  OAuth is the least of
> their security concerns,
>
> If the cost of SSL outweighs the risk of a security breach, then why  
> would a
> developer deploying OAuth choose to sign their messages rather then  
> use
> the simpler bearer token?
>
> Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I  
> think
> that is a good question. Perhaps it should be RECOMMENDED, and
> deployments can make their own benefit analysis.
>
> -- Dick
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth