+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 <e...@xmlgrrl.com> 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
> e...@xmlgrrl.com
> http://www.xmlgrrl.com/blog
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
