Subject: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 13 Jan 2010 23:05:33 -0700

Authentication Open Question #3: Should require using TLS/SSL/secure channel
for any request made without a signature?

WRAP got a lot of attention (mostly negative) to how it sends requests
without using signatures or a secure channel. WRAP only uses HTTPS for
obtaining tokens but does not mandate (or even suggests) using HTTPS for
making protected resources requests. Instead, WRAP recommends short lived
tokens that must be refreshed (using HTTPS).

In a recent thread [1] on this list we reach (very small) consensus that the
OAuth 1.0 protocol should mandate HTTPS for the PLAINTEXT method. The
community edition only recommends it.

QUESTIONS: Are there any valid (such that will pass IETF security review
scrutiny) reasons for allowing unsigned requests to be sent in the clear
over an insecure channel? Are there use cases for this (regardless of their
security properties)?

EHL

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00951.html

---

From: John Panzer <[email-masked]>
Date: Wed, 13 Jan 2010 22:30:21 -0800

> community edition only recommends it.

Actually, HTTPS or equivalent channel security was the consensus.

> over an insecure channel? Are there use cases for this (regardless of their

There was also a discussion (initiated by Brian Eaton) regarding the
combination of short lived token plus refresh, which should be dug up.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Kemp <[email-masked]>
Date: Thu, 14 Jan 2010 06:35:08 -0500

On Jan 14, 2010, at 1:05 AM, Eran Hammer-Lahav wrote:

[...]
> over an insecure channel? Are there use cases for this (regardless of their

I am still wavering on this. 

I think that using a bearer token with short lifetime and one-time use semantics (for example) is probably sufficient security for many use-cases. And using TLS/SSL (or even just signing and verifying a signed request) in all cases may provide too much performance overhead for some of those cases. 

In other words, I think that it's not only channel security we need to consider, but a combination of other measures that would, in some cases, obviate the need for TLS.

Regards,

- johnk

---

From: Blaine Cook <[email-masked]>
Date: Thu, 14 Jan 2010 12:10:11 +0000

OAuth WRAP is very similar to cookies as deployed by major vendors.

Google has just switched to HTTPS-by-default for all GMail
sessions[1], and my understanding (per [2]) is that access to
authenticated sessions (i.e., full GMail or Google Docs access versus
just displaying "[email-masked]" on the page) is always negotiated with
a secure cookie. Thus, Google has made decisions internally to secure
the equivalent of both the Refresh and the Bearer token, short-lived
assurances aside.

We're also entering an age where we have enough computing power to
*factor* RSA-1024 in non-infinite-time; handheld devices that are
realistically expected to use these protocols have sufficient
computing power and battery life to encrypt HTTP requests and decrypt
the responses (my phone already does this for all Twitter and email
requests; yours probably does, too).

As such, I can't see how *not* requiring SSL for unsigned requests
could pass muster at an IETF security review.

[1] http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html
[2] http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web-applications.html

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Jan 2010 06:45:47 -0700

Replying everyone all at once...

> Actually, HTTPS or equivalent channel security was the consensus.

It gets exhausting typing that every time. I have to assume people are
following the conversation a bit... :-)

> combination of short lived token plus refresh, which should be dug up.  

This is part of my question - is a fully exposed bearer token with a time
limit of an hour (which is what I have heard most of those advocating this
approach suggest) provide adequate security in line with IETF security
standards. I have a strong feeling it does not...

On 1/14/10 3:35 AM, "John Kemp" <[email-masked]> wrote:

> I think that using a bearer token with short lifetime and one-time use
> semantics (for example) is probably sufficient security for many use-cases.
> And using TLS/SSL (or even just signing and verifying a signed request) in all
> cases may provide too much performance overhead for some of those cases.

How short lived does it need to be to be sufficient? The attack vector is
trivial with the amount of open access points people use in public places.

> In other words, I think that it's not only channel security we need to
> consider, but a combination of other measures that would, in some cases,
> obviate the need for TLS.

Are there other 'combination of other measures' anyone has to offer than
making the bearer token short lived?

> OAuth WRAP is very similar to cookies as deployed by major vendors.

Which has been the argument made by some of the WRAP authors. I don't buy
it. Using this argument keeps web security broken and based on the broken
system we have today. We need to start fixing it somewhere and this is a
goof place.

> could pass muster at an IETF security review.

I completely agree.

EHL

---

From: John Kemp <[email-masked]>
Date: Thu, 14 Jan 2010 08:59:42 -0500

Hi Blaine,

> OAuth WRAP is very similar to cookies as deployed by major vendors.

How is that relevant to _this_ discussion (I apologize, I don't know much about WRAP)?

> sessions[1],

Yes, HTTPS by default, and they are doing it in order to secure the exchange of email - allowing emails to remain confidential on insecure networks. I think that is a strong use-case for requiring confidentiality. 

But not all use-cases for OAuth need that much confidentiality, or any confidentiality at all. 

> and my understanding (per [2]) is that access to

I guess my concern about performance is more at the server-side, where many requests may be processed more or less simultaneously. Back in the old days (1997) we had a special crypto hardware accelerator in our Internet-connected proxies, and our non-Internet connected machines wouldn't use SSL at all, because of the performance impact. 

I'm sure things are better these days, but crypto operations still add performance overhead that may not in practice be necessary for every use-case.  

> could pass muster at an IETF security review.

Well, I don't know what is required to pass IETF security review, and perhaps you're right, but the point is really whether there are cases where a combination of short-lifespan + replay-prevention and possibly other non-transport things could provide enough security to allow people to perform real work with OAuth tokens. 

And I think there are such cases - rather vaguely I could say that the broad category would be anything for which a large volume of authorized requests is possible, and where the "value" in an individual request is low. That certainly does not include email, which I rather think _is_ deserving of confidentiality over insecure networks (of course, Gmail does allow you to turn off https if you are in a more secure network environment).

Regards,

- johnk

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 14 Jan 2010 14:06:15 -0500

I agree that TLS (which, in the IETF, sprobably a better three-letter 
word than SSL) is the simplest solution, and the one that is 
implementable. 

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 14 Jan 2010 14:15:38 -0500

John Kemp wrote:
> ...
> ...
There definitely are such use cases. For instance, if I kept a photo 
album on Flicker and asked Kodak to print it, I personally would not 
care if others got access to this album by replaying (or just learned 
that I was trying to print some pictures). But I envision that OAuth 
will be used in much more serious cases, where the "value" will be high. 
The problem is that allowing individuals users to judge the value, 
understand the risks, and make their own decisions in specific cases is 
not a good idea. The protocol must enforce it.

Igor

---

From: John Panzer <[email-masked]>
Date: Thu, 14 Jan 2010 11:29:01 -0800

On Thu, Jan 14, 2010 at 11:15 AM, Igor Faynberg <[email-masked]
> wrote:

> John Kemp wrote:
>
>> ...
>>
>> And I think there are such cases - rather vaguely I could say that the
>> broad category would be anything for which a large volume of authorized
>> requests is possible, and where the "value" in an individual request is low.
>> That certainly does not include email, which I rather think _is_ deserving
>> of confidentiality over insecure networks (of course, Gmail does allow you
>> to turn off https if you are in a more secure network environment).
>>
>> ...
>>
> There definitely are such use cases. For instance, if I kept a photo album
> on Flicker and asked Kodak to print it, I personally would not care if
> others got access to this album by replaying (or just learned that I was
> trying to print some pictures). But I envision that OAuth will be used in
> much more serious cases, where the "value" will be high. The problem is that
> allowing individuals users to judge the value, understand the risks, and
> make their own decisions in specific cases is not a good idea. The protocol
> must enforce it.
>

Are you saying that the protocol must enforce "strongest auth" in all cases?
 Or that the protocol must understand the security implications of the data
and make appropriate decisions?  (I'm assuming the former.)

---

From: John Kemp <[email-masked]>
Date: Thu, 14 Jan 2010 14:37:27 -0500

On Jan 14, 2010, at 2:15 PM, Igor Faynberg wrote:

> There definitely are such use cases. For instance, if I kept a photo album on Flicker and asked Kodak to print it, I personally would not care if others got access to this album by replaying (or just learned that I was trying to print some pictures). But I envision that OAuth will be used in much more serious cases, where the "value" will be high. The problem is that allowing individuals users to judge the value, understand the risks, and make their own decisions in specific cases is not a good idea. The protocol must enforce it.

What delegated authorization protocol should be used to deal with those "not so serious" use-cases then, if OAuth makes them too expensive?

Cheers,

- johnk

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 14 Jan 2010 14:41:12 -0500

John Panzer wrote:
> ...
>
> Are you saying that the protocol must enforce "strongest auth" in all 
> cases?  Or that the protocol must understand the security implications 
> of the data and make appropriate decisions?  (I'm assuming the former.)
>  
>
>

Yes, exactly.  I am for the "strongest auth." 

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 14 Jan 2010 14:53:12 -0500

> What delegated authorization protocol should be used to deal with those "not so serious" use-cases then, if OAuth makes them too expensive?
I expected this question and dreaded it.  I don't have a good answer, 
and I don't think there is one. (In my defense, the airport security 
cannot find the way around the 
wait-wait-wait/shoes-off/belts-off/watches-off routine for "good" 
people--who are actually the majority.)

One not-so-good answer, but--I think--a workable one is to consider an 
(enumerated type) parameter carrying a required security value, 
something that would have to come from the user initially, and then 
specify TLS or any other cryptographic delicacy based on such value. The 
only problem is that end users might happily settle for the highest 
security, anyway (unless they have to pay for it).

Igor

---

From: Eve Maler <[email-masked]>
Date: Thu, 14 Jan 2010 14:45:41 -0800

What's generally done today (think Google Calendar, Flickr, etc.) is use "private" URLs and mail them around.  It doesn't really meet anyone's standards for controlling access to anything valuable -- but it sure is convenient. :-)

	Eve

On 14 Jan 2010, at 11:53 AM, Igor Faynberg wrote:

> I expected this question and dreaded it.  I don't have a good answer, and I don't think there is one. (In my defense, the airport security cannot find the way around the wait-wait-wait/shoes-off/belts-off/watches-off routine for "good" people--who are actually the majority.)
> 
> One not-so-good answer, but--I think--a workable one is to consider an (enumerated type) parameter carrying a required security value, something that would have to come from the user initially, and then specify TLS or any other cryptographic delicacy based on such value. The only problem is that end users might happily settle for the highest security, anyway (unless they have to pay for it).
> 
> Igor

Eve Maler
[email-masked]
http://www.xmlgrrl.com/blog

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 14 Jan 2010 14:53:07 -0800

> over an insecure channel? Are there use cases for this (regardless of their

Yes, two machines on a network that is internal and presumed secure, and
that doesn't need—or want!—the overhead of using point-to-point
transport layer security.

As has been pointed-out on this thread, the decision to use a secure
channel, and to what extent it is made secure, are dependent on the
threat model: the sensitivity of the data, the extent to which it is
exposed, and the threat of its exposure.

I don't think the OAuth protocol specification should mandate (a la
MUST) transport security. At best, recommendations (a la SHOULD) would
be more appropriate, giving discretion to those designing and deploying.

> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00951.html

Paul

---

From: John Panzer <[email-masked]>
Date: Thu, 14 Jan 2010 15:28:07 -0800

And to build such a secret url, a WRAP token as a query param in the
url would be sufficient.

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 14 Jan 2010 18:43:23 -0500

Actually, this makes a lot of sense. I believe that such URLs can be 
made sufficiently secure by signing with a key bootstrapped from the 
password (something like PAK or EKE). But they ought to remain secret, 
which is  pretty impossible  to ensure, or they must be made unreusable 
by anyone except the intended party.  I guess one way is to build the 
delegation into the URL by providing the recognizable identity string 
(like OpenId) on which the recipient will need to authenticate.

One question: how would that fit into the present OAuth plan? Could we 
standardize the delegation URL?

Igor

P.S.: I just wanted to clarify that I see the promise in OAuth to be 
used in  far more sensitive settings. For instance, I would consider 
delegation (to an insurance agent)  to access medical data or another 
private record.  There is also an interesting proposal from Deutche 
Telecom, related to SIP, already on the table.

This is why I am  a proponent of a general secure solution as a default.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 14 Jan 2010 19:39:30 -0500

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

--Richard

>> I think that using a bearer token with short lifetime and one-time  
>> use semantics (for example) is probably sufficient security for  
>> many use-cases. And using TLS/SSL (or even just signing and  
>> verifying a signed request) in all cases may provide too much  
>> performance overhead for some of those cases.
>>
>> In other words, I think that it's not only channel security we need  
>> to consider, but a combination of other measures that would, in  
>> some cases, obviate the need for TLS.
>>
>> Regards,
>>
>> - johnk
>>

---

From: John Kemp <[email-masked]>
Date: Thu, 14 Jan 2010 19:46:52 -0500

> What's generally done today (think Google Calendar, Flickr, etc.) is use "private" URLs and mail them around.  It doesn't really meet anyone's standards for controlling access to anything valuable…

Right, so the URL itself is a bearer token, perhaps with usage limitations, like a limited timeframe when you get a 200 response from dereferencing the URL ;)

- johnk

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Jan 2010 21:41:21 -0700

(this is not aimed at John Kemp)

I understand that some providers will not want to bother with the extra
security for their own reasons. I am willing to assume they are doing this
fully aware of the repercussions of their actions. What I don't understand
is why should the protocol - which is aimed at interoperability - bother
with it?

We got people here representing many companies, large and small. Can one of
them please raise their hand and ask for this feature? And if they do, can
they explain how they justify providing poor security to their users?

I am no longer interested in the argument that somewhere there are valid use
cases. Writing a protocol for scenarios that are not anchored in reality is
bad. OAuth 1.0 does not require using a secure channel for sending token
secrets because people claimed it will be a problem for some providers. So
far, no such providers showed up.

If someone want to argue the need of no-crypto / no-HTTPS, while showing how
that need justifies subjecting the web to more bad protocols and poor
foresight, I am eager to listen.

If you don't care about security, you are free to implement the protocol
poorly. There is no OAuth Police to enforce servers to check signature and
reject requests with bad ones. At least by forcing such cases to break the
protocol, we are forcing them to make an active decision and we get their
API users to notice.

There is also a case to be made about pushing the envelope when it comes to
security. The more services use TLS, the cheaper and easier it will get.
That's economics 101. And unlike writing new code for new OAuth signatures,
requiring TLS will simply mean linking another library and making a function
call.

My vote is to start with an HTTPS requirement for any unsigned request, and
let those who have real reasons to object show up. None of the current users
of OAuth 1.0 will be able to claim this since they all use HTTPS for all
such requests.

EHL

On 1/14/10 5:59 AM, "John Kemp" <[email-masked]> wrote:

> Yes, HTTPS by default, and they are doing it in order to secure the exchange
> of email - allowing emails to remain confidential on insecure networks. I
> think that is a strong use-case for requiring confidentiality.
> 
> I guess my concern about performance is more at the server-side, where many
> requests may be processed more or less simultaneously. Back in the old days
> (1997) we had a special crypto hardware accelerator in our Internet-connected
> proxies, and our non-Internet connected machines wouldn't use SSL at all,
> because of the performance impact.
> 
> I'm sure things are better these days, but crypto operations still add
> performance overhead that may not in practice be necessary for every use-case.
> 
>> 
> Well, I don't know what is required to pass IETF security review, and perhaps
> you're right, but the point is really whether there are cases where a
> combination of short-lifespan + replay-prevention and possibly other
> non-transport things could provide enough security to allow people to perform
> real work with OAuth tokens.
> 
> And I think there are such cases - rather vaguely I could say that the broad
> category would be anything for which a large volume of authorized requests is
> possible, and where the "value" in an individual request is low. That
> certainly does not include email, which I rather think _is_ deserving of
> confidentiality over insecure networks (of course, Gmail does allow you to
> turn off https if you are in a more secure network environment).
> 
> Regards,
> 
> - johnk
> 
>> 
>> [2] 
>> http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web-appli
>> cations.html
>> 
>>> And using TLS/SSL (or even just signing and verifying a signed request) in
>>> all cases may provide too much performance overhead for some of those cases.
>>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Jan 2010 21:45:47 -0700

+1. Obtaining a certificate is far from an onerous requirement...

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Jan 2010 21:48:05 -0700

Doesn't the fact that this approach has clearly failed for HTTP Basic act as
a warning sign? 2617 clearly states the problems in using Basic over
insecure channels, and yet, given its simplicity, it is one of the most
widely used and abused protocol around.

I think this is a case where security and interoperability must be
considered as a pair. We know what makes a more secure protocol. How does
making it less secure by not making HTTPS required improve interoperability?
If it doesn't, there is no justification other than to make bad security
easier to excuse.

EHL

On 1/14/10 4:39 PM, "Richard Barnes" <[email-masked]> wrote:

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

---

From: David Recordon <[email-masked]>
Date: Thu, 14 Jan 2010 21:07:43 -0800

> for any request made without a signature?

Yes.  Either TLS/SSL should be used or their should be an appropriate
signature.  I'll leave "secure channel" for others to define and argue
about. ;)

> tokens that must be refreshed (using HTTPS).

Speaking as an implementor (Facebook hat) we always saw WRAP as using
HTTPS for making protected resources requests.  Every protocol drawing
we've drawn includes HTTPS on this step.  We can see offering some
APIs which work entirely with public data over HTTP, but in that case
the access token would be a poor choice and really just acts as a
consumer key for logging purposes.

That said, the JavaScript profile has very different security
characteristics than the other profiles when it comes to acquiring an
access token.  Access tokens acquired via this profile will be short
lived and have more restricted scopes than those acquired via other
(more secure) profiles.

---

From: John Kemp <[email-masked]>
Date: Fri, 15 Jan 2010 10:58:22 -0500

Hi Eran!

> (this is not aimed at John Kemp)

I think you mean it's not _specifically_ aimed at me, but in any case, I'll take the opportunity to reply anyway ;)
 
> is why should the protocol - which is aimed at interoperability - bother

I do agree that is the central question.

> them please raise their hand and ask for this feature?

I am asking for us to not remove the possibility to use a non-channel, non-signature security method to secure OAuth tokens, so I raise my hand. 

> And if they do, can

This sounds like a trick question ;) 

Speaking on behalf of only myself (and not my company), I aim NOT to provide poor security, but to provide just the right amount of security for a given use-case. Where "just the right amount" means the amount which is of the least cost to the overall system to provide an adequate amount of security for a given use-case. Today, OAuth already supports that possibility - a sliding-scale of security, as I noted in earlier email. Even if we require TLS or signing, we still have more than one security method, and each of them has different security properties. We will not (as far as I can tell) ever limit ourselves to a single choice for providing security, and I would argue that we should not. 

> far, no such providers showed up.

I would say that it is more likely that no such providers wished to announce what they want to do in a public forum. But that doesn't mean that what they plan to do is bad for their users. Security requires tradeoffs, and people should be both forced, and allowed to make those tradeoffs - based on their own analysis, not some standard. Public pressure _will_ limit what providers actually offer their users, but that is a market force and shouldn't be enforced in a standard (in my opinion anyway).  

> protocol, we are forcing them to make an active decision and we get their

Yes, if the community as a whole decides that my argument is weak, then I certainly would concede. We can decide as a group that we don't want to support the minimal-security use-cases by mandating crypto, and I will bow to the will of the community in that decision. I think there is an advantage to making as many implementations as possible conformant to OAuth, but perhaps not everyone in the community agrees with that? 

> of OAuth 1.0 will be able to claim this since they all use HTTPS for all

I am not prepared to name names. But I will say that I have helped design two OAuth-like protocols in my career, and in both cases, we were asked by some customers of those protocols to allow bearer tokens without TLS. 

When I look at what is possible in the offline world, I would ask - would you require that movie theatre tickets bought in advance were encrypted in transport between the person who bought the ticket and the receptionist at the cinema? What if the person drops her ticket and it's picked up by someone else? The risk of someone dropping his ticket is low, so we don't bother to secure it (of course, I haven't been to a city movie theatre in years so perhaps you need to show ID even to see a movie these days -- I hope not ;) Of course, the person who _does_ drop his ticket will be mad when he gets to the movie theatre, but probably not too mad. The system has worked quite well without any real security. We might add more security, but it would, even today, probably be hard to justify the cost. 

Yes, those things change over time, but having a sliding scale of security is a good thing, not a bad thing - and that is already allowed by OAuth today, (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue even if you remove PLAINTEXT from the list.

- johnk

---

From: John Kemp <[email-masked]>
Date: Fri, 15 Jan 2010 11:06:06 -0500

On Jan 14, 2010, at 7:39 PM, Richard L. Barnes wrote:

> 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:
> (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

---

From: Eve Maler <[email-masked]>
Date: Fri, 15 Jan 2010 08:18:55 -0800

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

Eve Maler
[email-masked]

---

From: John Panzer <[email-masked]>
Date: Fri, 15 Jan 2010 08:42:55 -0800

+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?

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 15 Jan 2010 11:01:23 -0700

+1 to this as well. Any implementation is free to deviate from the spec, at the risk of breaking interoperability.

John

---

From: John Panzer <[email-masked]>
Date: Fri, 15 Jan 2010 10:29:50 -0800

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?

On Fri, Jan 15, 2010 at 10:01 AM, Hurliman, John <[email-masked]>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
> >
> of operation (in this case, operating without TLS), I would be looking for
> 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.
> >>>
> 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.
> >>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jan 2010 13:41:22 -0500

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
> On Fri, Jan 15, 2010 at 10:01 AM, Hurliman, John <[email-masked] 
> > wrote:
> +1 to this as well. Any implementation is free to deviate from the  
> spec, at the risk of breaking interoperability.
>
> John
>
> > 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
> >
> >>> 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  
> >>> 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  
> 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  
> >>> (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-masked]

---

From: John Panzer <[email-masked]>
Date: Fri, 15 Jan 2010 11:21:05 -0800

On Fri, Jan 15, 2010 at 10:41 AM, Richard L. Barnes <[email-masked]> 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
>> +1 to this as well. Any implementation is free to deviate from the spec,
>> at the risk of breaking interoperability.
>>
>> John
>>
>> >>> (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.
>> >>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jan 2010 14:58:26 -0500

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:

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 15 Jan 2010 14:41:52 -0700

On 1/15/10 7:58 AM, "John Kemp" <[email-masked]> wrote:

> When I look at what is possible in the offline world, I would ask - would you
> require that movie theatre tickets bought in advance were encrypted in
> transport between the person who bought the ticket and the receptionist at the
> cinema? What if the person drops her ticket and it's picked up by someone
> else? The risk of someone dropping his ticket is low, so we don't bother to
> secure it (of course, I haven't been to a city movie theatre in years so
> perhaps you need to show ID even to see a movie these days -- I hope not ;) Of
> course, the person who _does_ drop his ticket will be mad when he gets to the
> movie theatre, but probably not too mad. The system has worked quite well
> without any real security. We might add more security, but it would, even
> today, probably be hard to justify the cost.

I don't think this is a fair comparison. Stealing a movie ticket is very
hard, and punishable but fines and prison time (potentially federal is
captured in transit via US Mail). On the other hand, capturing bearer tokens
while sitting at a Starbucks using nothing more than a laptop with a WiFi
card is trivial.
 
> Yes, those things change over time, but having a sliding scale of security is
> a good thing, not a bad thing - and that is already allowed by OAuth today,
> (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue even if
> you remove PLAINTEXT from the list.

We are creating web standards, not just generic technologies. I don't want
to find *any* PLAINTEXT implementation on the web, but don't care if someone
uses it on their own private network. But if that's what they are doing,
they are free to drop TLS/SSL requirement anyway because they control the
environment.

Since we are talking about one word, MUST vs. SHOULD, I think we should
start with MUST and continue having this discussion when we have more pieces
of the puzzle in place.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 15 Jan 2010 14:49:56 -0700

> tokens and no TLS, is a client obligated to interop in order to claim spec

Its a tricky question because HTTPS is not a parameter or extension you
negotiate. It is dictated by the URI of the protected resource you are
trying to access, and clients should never assume that the http:// resource
is the same as the https:// resource, just with more/less security.

EHL

---

From: John Kemp <[email-masked]>
Date: Fri, 15 Jan 2010 17:02:41 -0500

Hello Eran,

On Jan 15, 2010, at 4:41 PM, Eran Hammer-Lahav wrote:

> captured in transit via US Mail).

The point is that the overall system makes the cost of providing any extra security not very worthwhile, as most thieves aren't that interested in stealing movie tickets, and most people don't lose their tickets!

> On the other hand, capturing bearer tokens

Why would someone bother to sit and capture bearer tokens - what is the value of doing that, and what is the actual risk? In some cases, probably not that great... Imagine that we have an online movie bearer token - it's one-time use + replay-protected and gets delivered to the original requester after that entity has been authenticated (and is delivered over SSL). Now your thief has to grab that token as it is sent over the wire and somehow send it himself before the first request (by the lawfully-authorized viewer) is processed by the server! I think this is hard too - not impossible, but hard enough that for low-value cases, I simply wouldn't worry too much about encrypting that initial request (although of course, the movie stream itself would be DRMed!). 

> start with MUST and continue having this discussion when we have more pieces

I think you've raised a valid issue, but I don't yet hear any consensus about this change, or whether the suggested text actually does what we want. I hope you'll consider that (and perhaps wait a bit longer to make such a change).

Cheers,

- johnk

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 15 Jan 2010 15:15:13 -0700

On 1/15/10 2:02 PM, "John Kemp" <[email-masked]> wrote:

> Why would someone bother to sit and capture bearer tokens - what is the value
> of doing that, and what is the actual risk? In some cases, probably not that
> great...

It would be great if the WRAP authors can share with us how their employers
plan to deploy their protocol. We have three major companies involved in
developing WRAP and they created a solution that can create severe security
risks. I am not aware of any APIs from MS, Y!, or Google that I would be
happy to use if they used bearer token without channel security.

> I think you've raised a valid issue, but I don't yet hear any consensus about
> this change, or whether the suggested text actually does what we want. I hope
> you'll consider that (and perhaps wait a bit longer to make such a change).

I agree, which is why I didn't want to paint this as a decided issue, just
that we might need more context to reach consensus and I need to put
something in the spec. My proposal is to be more restrictive and loosen it
later instead of the other way around.

EHL

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 15 Jan 2010 14:49:45 -0800

> they are free to drop TLS/SSL requirement anyway because they control the

I'm in 100% agreement on this point if the MUST is constrained to limit
only non-encrypted PLAINTEXT implementations on the web.

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 15 Jan 2010 17:57:01 -0500

Interestingly enough, when I bought, over the Internet, a ticket to Film 
Forum in New York, the way it worked, it amounted to a number (token), 
which I had to redeem at the movie theater. I was authenticated by 
showing my credit card with which I bought the ticket; I guess I could 
have been asked for a drivers license, too. So even in the movie ticket 
case, there was a (sort of) strong authentication of the token bearer at 
the point of obtaining the resource. Interestingly enough, the same 
method is being used with the airline tickets, where the risks are much 
higher.

This is why I am taking the same position as Eran.

Igor

---

From: John Kemp <[email-masked]>
Date: Fri, 15 Jan 2010 18:01:17 -0500

On Jan 15, 2010, at 5:57 PM, Igor Faynberg wrote:

> Interestingly enough, when I bought, over the Internet, a ticket to Film Forum in New York, the way it worked, it amounted to a number (token), which I had to redeem at the movie theater. I was authenticated by showing my credit card with which I bought the ticket; I guess I could have been asked for a drivers license, too. So even in the movie ticket case, there was a (sort of) strong authentication of the token bearer at the point of obtaining the resource. Interestingly enough, the same method is being used with the airline tickets, where the risks are much higher.

Right, you were authenticated as an authorized bearer of the token, by matching information about the bearer in the token against additional information you provided separately. That's possible without channel security, of course. 

- johnk

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 15 Jan 2010 18:24:46 -0500

> Right, you were authenticated as an authorized bearer of the token, by matching information about the bearer in the token against additional information you provided separately. That's possible wit…
Exactly, and I did not see in OAuth a way to enforce the token bearer 
authentication, which is one reason I was for channel security. The 
other reason is privacy. Even with movie tickets, some people might 
prefer that no one  know what exactly they are buying. The channel 
security sort of takes care of the transaction privacy at the same time 
as doing other useful things. I think this will be a serious point in 
bringing SIP to use OAuth.

Igor