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

I am not sure what the practical impact will be, but for what it's worth I
support the concept of recommending TLS (SHOULD, not MUST) in general, and
also the concept of moving forward.

Side note:  In prior IETF standards efforts I've been involved with, having
very specific spec language proposals to get consensus around was helpful.
 In this case that'd be premature but I think that getting to the point
where we can start doing that would help bring these discussions to closure
earlier, and make it stick.   (To change a prior consensus, new specific
language would need to be drafted that replaces the old language, and that
would need a new consensus; this is a much higher bar than just passively
opposing something).

Side note 2:  RFC 5023 (AtomPub) has a pair of paragraphs that are
pertinent, though you may need a standards wonk to interpret them properly.
 In many ways they're a cry for help :) :

> The type of authentication deployed is a local decision made by the server
> operator. Clients are likely to face authentication schemes that vary across
> server deployments. At a minimum, client and server implementations *must* be
> capable of being configured to use HTTP Basic Authentication [RFC2617]<#RFC2617> in
> conjunction with a connection made with TLS 1.0[RFC2246] <#RFC2246> or a
> subsequent standards-track version of TLS (such as [RFC4346] <#RFC4346>),
> supporting the conventions for using HTTP over TLS described in [RFC2818]<#RFC2818>
> .
>
> The choice of authentication mechanism will impact interoperability. The
> minimum level of security referenced above (Basic Authentication with TLS)
> is considered good practice for Internet applications at the time of
> publication of this specification and sufficient for establishing a baseline
> for interoperability. Implementers are encouraged to investigate and use
> alternative mechanisms regarded as equivalently good or better at the time
> of deployment. It is *recommended* that clients be implemented in such a
> way that new authentication schemes can be deployed.
>

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer

On Tue, Dec 1, 2009 at 10:04 PM, Eran Hammer-Lahav <eran@hueniverse.com>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:Dick.Hardt@microsoft.com]
> > Sent: Tuesday, December 01, 2009 9:51 PM
> > To: Brian Eaton
> > Cc: Eran Hammer-Lahav; Peter Saint-Andre; <ext@core3.amsl.com>;
> > Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org
> > 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
> > <eran@hueniverse.com> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>