On Fri, Jan 15, 2010 at 10:41 AM, Richard L. Barnes <[email protected]> wrote:
> I would think not; it's a matter of the client's policy what signatures it > will issue, and the server's policy which it will accept. > That doesn't answer the interop question, though, which is the interesting one from the standpoint of the spec. If there is no requirement for a common minimal-subset then there is no guarantee of interop between a random client and a random server that both speak the same data protocol. Most use cases of OAuth have a custom client for every data API so this isn't an issue, but that's not necessarily the case, especially as new protocols start to depend on OAuth for their security needs. > > And in any case, OAuth doesn't have any in-band security negotiation, so > there's no way for the server to ask for a given set of features (e.g., > bearer tokens and no TLS) within the protocol. > > See however https://groups.google.com/group/oauth-key-discovery for a very needed extension that does add key discovery and rotation. Even without that, the question is just punted to the out of band documentation: Is a server allowed to support only bearer tokens and no TLS for some use case? --Richard > > > > > On Jan 15, 2010, at 1:29 PM, John Panzer wrote: > > 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 > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
