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.
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.
--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
