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
