I think the question at hand is: If a server says it wants to do bearer tokens and no TLS, is a client obligated to interop in order to claim spec compliance?
-- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer On Fri, Jan 15, 2010 at 10:01 AM, Hurliman, John <[email protected]>wrote: > +1 to this as well. Any implementation is free to deviate from the spec, at > the risk of breaking interoperability. > > John > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > John Panzer > Sent: Friday, January 15, 2010 8:43 AM > To: Eve Maler > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure > Channels > > +1 to MUST implement TLS on both sides. > > I thought we were only discussing whether the server could decide to > skip TLS for a particular use case. No? > > On Friday, January 15, 2010, Eve Maler <[email protected]> wrote: > > The points about matching security to use case are excellent. This is > why I think we're maybe misinterpreting Eran's argument for MUST. It's not > an argument from security alone ("we must always have highest security all > the time"); it's an argument from interoperability of security features at > Internet scale ("in the general/at-scale case, we should not accept deployed > instances that do not support this important security feature"). > > > > On this basis, it's reasonable to argue for MUST for implementing TLS > (with no weasel words about "or equivalent", since this isn't a testable > protocol clause), for the broad ecosystem benefits. > > > > Eve > > > > On 15 Jan 2010, at 8:06 AM, John Kemp wrote: > > > >> On Jan 14, 2010, at 7:39 PM, Richard L. Barnes wrote: > >> > >>>> As such, I can't see how *not* requiring SSL for unsigned requests > >>>> could pass muster at an IETF security review. > >>> > >>> Speaking as someone who does IETF security reviews ... :) > >>> > >>> If I were reviewing a document that defines an optional insecure mode > of operation (in this case, operating without TLS), I would be looking for > basically two things: (1) A discussion of the risks if the insecure mode is > used, and (2) a motivation for why these risks might be acceptable in > certain cases. This is in the spirit of "MUST=SHOULD+exception" -- if it's > a SHOULD, you need to explain the exception. In this case, the risks (1) > are pretty obvious: A passive observer can steal your password and use it to > authenticate as you. The motivations (2) are what this thread is about. > >>> > >>> I would also observe that "MUST use TLS or equivalent" is actually the > same as "SHOULD use TLS", since the "or equivalent" isn't really specified. > >> > >> Right. Which is why I'm currently OK with Eran's text either way as I > think it allows bearer tokens with *any* other security protections, unless > we specify exactly which security properties should be provided by the > channel, vs. via other mechanisms. > >> > >> SAML's "confirmation method" is sort of the equivalent idea to what > we've been talking about here (where the method could be "holder-of-key+a > signature algorithm", "bearer" or something else) but we also haven't > separated out security properties such as integrity or confidentiality for > the purposes of this discussion. > >> > >>> (This is really obvious when you think about it from the perspective of > an implementor: If you're going to cover the "or equivalent" cases, then you > have to have be able to operate in non-TLS mode.) The "or equivalent" cases > are the ones where not using TLS might be acceptable, i.e., the ones that > should be cited as motivations (2) for allowing the non-secure mode. > >>> > >>> Taking the SECDIR hat off, it seems to me that there are some > motivations appearing in this thread: > >>> -- Appropriate key management (frequent key refresh) > >>> -- Private trusted networks > >>> -- John's observation that "URL+token" == "private URL" > >>> So ISTM that "SHOULD use TLS" could be motivated here. > >>> > >>> (Now, all that said, it probably wouldn't hurt to have TLS as a "MUST > implement" so that it's there if people want to use it.) > >> > >> +1 > >> > >> - johnk > > > > > > Eve Maler > > [email protected] > > http://www.xmlgrrl.com/blog > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
