If the issue is that the client doesn't *want* to do PLAINTEXT-NOTLS,
then there is no interop issue -- the client and the server have
different requirements, at a policy level. You can have a requirement
for compliant implementations to implement the mode, but you can't
force people to use it. This remains true even if you do have a
algorithm negotiation mechanism.
Two analogies:
1. HTTP: If I enter an HTTPS URI and and the server returns a 301
sending me to an HTTP URI, then I don't follow it to the insecure
site in order to comply with HTTP (even though my browser usually does
so automatically).
2. IPsec: If two IKE peers are trying to set up an IPsec security
association, first one peer advertises the list of algorithms it's
willing to use, then the second peer responds with the subset of those
that it's willing to use. If the second peer doesn't like any of the
advertised algorithms, then it says so, and the negotiation fails.
--Richard
On Jan 15, 2010, at 2:21 PM, John Panzer wrote:
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
