Subject: [websec] I-D Action: draft-ietf-websec-session-continue-prob-00.txt

From: [email-masked]
Date: Sun, 07 Jul 2013 22:26:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Security Working Group of the IETF.

	Title           : Hypertext Transport Protocol (HTTP) Session Continuation: Problem Statement
	Author(s)       : Nicolas Williams
	Filename        : draft-ietf-websec-session-continue-prob-00.txt
	Pages           : 13
	Date            : 2013-07-07

Abstract:
   One of the most often talked about problems in web security is
   "cookies".  Web cookies are a method of associating requests with
   "sessions" that may have been authenticated somehow.  Cookies are a
   form of bearer token that leave much to be desired.  This document
   describes the session "continuation" problem for the HyperText
   Transport Protocol (HTTP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-websec-session-continue-prob

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-websec-session-continue-prob-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Yoav Nir <[email-masked]>
Date: Mon, 8 Jul 2013 05:37:52 +0000

Hi all

This has been submitted with a websec filename, but note that this is not (yet) on our charter.

At the Orlando meeting, we discussed some of the security issues with keeping HTTP sessions using cookies. There was consensus in the room that this is a problem that needs solving. Nicolas Williams, Phillip Hallam-Baker, and Yaron Sheffer volunteered to write a problem statement, and this is it. The message we got from our AD is that first we should show that the working group has the time and energy to work on solving this problem, and then we can add this to our charter.

So please have a look and this document, and answer the following:
 - Is this a good starting point for the problem statement?
 - Will you be willing to review the problem statement?
 - Will you be willing to read multiple solution proposals to help the working group choose?
 - Will you be willing to review the solution document?

We will have a chance to discuss this in Berlin, but it would be great if we have a rough measure of how much energy we have.

Thanks

Tobias and Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 8 Jul 2013 05:40:37 +0000

And I'll start the ball rolling, buy answering yes (with no hats) to all questions.

On Jul 8, 2013, at 8:37 AM, Yoav Nir <[email-masked]>
 wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
> 
> Email secured by Check Point

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 10 Jul 2013 14:32:41 -0700

On Sun, Jul 7, 2013 at 10:37 PM, Yoav Nir <[email-masked]> wrote:

> At the Orlando meeting, we discussed some of the security issues with
> keeping HTTP sessions using cookies. There was consensus in the room that
> this is a problem that needs solving. Nicolas Williams, Phillip
> Hallam-Baker, and Yaron Sheffer volunteered to write a problem statement,
> and this is it. The message we got from our AD is that first we should show
> that the working group has the time and energy to work on solving this
> problem, and then we can add this to our charter.
>

Hmm, it's surprising there's no discussion of cookie scoping problems like:
 - "cookie stealing" via MITM-created subdomains [1], or
 - "cookie forcing" via attacker-controlled sibling or cousin domains [2]

These attacks seems particularly relevant to this WG, since they can
subvert hostname-specified security like HSTS or HPKP.

Also:  despite mentioning a few proposals, there's no mention of ChannelID
/ Channel-bound cookies [3].

ChannelID seems to solve these problems, seems more polished than other
proposals, and apparently is being experimentally deployed (see Chrome |
Preferences | Cookies and site data | "google.com" or "gmail.com").

>  - Will you be willing to review the solution document?

I'd be more interested in websec taking this on if someone could argue why
ChannelID is *not* the right solution, and had some ideas how to do better.

Trevor

[1]
http://tools.ietf.org/html/rfc6265  Section 4.1.2.3 WARNING
https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies
Scope
http://tools.ietf.org/html/rfc6797  Section 14.4

[2]
http://tools.ietf.org/html/rfc6265  Sections 4.1.2.5 and 8.6
http://scarybeastsecurity.blogspot.com/2008/11/cookie-forcing.html
https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies
Overwriting cookies

[3] http://tools.ietf.org/html/draft-balfanz-tls-channelid-01

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Jul 2013 16:39:40 -0500

>  - "cookie forcing" via attacker-controlled sibling or cousin domains [2]

There's minimal discussion of the concept of "origin"; it clearly
needs more text.  I'd love to receive some suggestions for such text
:)

> Also:  despite mentioning a few proposals, there's no mention of ChannelID /
> Channel-bound cookies [3].
>

There's definitely mention of channel binding.  Channel bound cookies
used over HTTPS would meet the requirements of this spec, except for
the CRIME/BEAST resistance part.

I'm not sure that we should mandate CRIME/BEAST resistance -- TLS
should arguably be able to resist such attacks.  But it will take a
long time to deploy TLS that does, and that's what makes it appealing
to have CRIME/BEAST resistance in the session continuation protocol.

> ChannelID is *not* the right solution, and had some ideas how to do better.

See above.

Nico
--

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 10 Jul 2013 14:54:24 -0700

> needs more text.  I'd love to receive some suggestions for such text

I'm not volunteering!  It's complicated...

> the CRIME/BEAST resistance part.

Are you sure about that?  I meant "channel-bound cookies" as defined in the
ChannelID draft.  Even if an attacker stole such cookies via BEAST / CRIME
/ whatever, the cookies would be unusable without the browser's ChannelID
private key for that site.

> to have CRIME/BEAST resistance in the session continuation protocol.

Hmm, haven't browsers already deployed BEAST / CRIME / etc countermeasures?

I actually think that TLS-layer fixes to TLS problems are going to be
faster, easier, and more comprehensive than trying to get thousands of
websites to change how they manage sessions.

But the cookie-scoping problems will still exist, so cookies definitely
need improvement.  For that, ChannelID still seems like the best proposal
out there.

Trevor

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Jul 2013 17:01:01 -0500

> I'm not volunteering!  It's complicated...

Bummer.  It's complicated.

> ChannelID draft.  Even if an attacker stole such cookies via BEAST / CRIME /
> whatever, the cookies would be unusable without the browser's ChannelID

Ah, right, excuse me.  I'd responded without swapping in enough of the
channel bound cookie context.

Yes, I see that we need to adjust this spec to cover that.  The
intention is not to exlcude channel bound cookies.  I'll fix it.

> But the cookie-scoping problems will still exist, so cookies definitely need
> improvement.  For that, ChannelID still seems like the best proposal out
> there.

That context I still don't have swapped in, or maybe I've never had it.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 Jul 2013 12:50:40 +0000

On Jul 11, 2013, at 12:32 AM, Trevor Perrin <[email-masked]<mailto:[email-masked]>> wrote:

ChannelID seems to solve these problems, seems more polished than other proposals, and apparently is being experimentally deployed (see Chrome | Preferences | Cookies and site data | "google.com<http://google.com/>" or "gmail.com<http://gmail.com/>").

I'd be more interested in websec taking this on if someone could argue why ChannelID is *not* the right solution, and had some ideas how to do better.

Hi Trevor

[wearing no hats]

ChannelID is a TLS-layer extension. As such, it does nothing for HTTP. OTOH a proposal that hashes some header fields with a secret value works with or without TLS.

But even if we restrict our solution to HTTPS, I don't see how ChannelID helps a problem like the BEAST and CRIME attacks. In both cases, the issue is the scoping of cookie use. An attacker's web page or script can cause the UA to send requests of the attacker's choosing to a server. This has nothing to do with TLS - this in an HTTP behavior.

As it is, if I visit a website that has <img src="https://mail.google.com/gaaaaaaaaaah"> my UA is going to send a request to mail.google.com<http://mail.google.com> for "gaaaaaaaaaah", and that request is going to have my cookie. I don't see what ChannelID adds here. With channel-bound cookies (section 7.1) my UA will send the same request to mail.google.com<http://mail.google.com>, but with a channel-bound cookie. But since it's my valid channel, the server will accept it just the same.

What we need, IMO, is a new cookie with new rules, such as that cookies will be indexed by origin and refer(r)er so that my UA would use different cookies for requests stemming from pages from google and requests initiated by pages and scripts from other origins. This kind of rule change is more important than either the crypto binding or the request hashing.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 11 Jul 2013 09:51:34 -0700

On Thu, Jul 11, 2013 at 5:50 AM, Yoav Nir <[email-masked]> wrote:

>
>  On Jul 11, 2013, at 12:32 AM, Trevor Perrin <[email-masked]> wrote:
>
>
>  I'd be more interested in websec taking this on if someone could argue
> why ChannelID is *not* the right solution, and had some ideas how to do
> better.
>
>
>  Hi Trevor
>
>  [wearing no hats]
>
>  ChannelID is a TLS-layer extension. As such, it does nothing for HTTP.
>

That's true, but is it important?

If a site can't be bothered to deploy TLS, is it going to deploy a new
session management mechanism?

The security gain of improving cookies without deploying TLS seems small -
it might protect cookies at "http://example.com" from someone who hacks "
http://test.example.com", but that's about it.

But even if we restrict our solution to HTTPS, I don't see how ChannelID
> helps a problem like the BEAST and CRIME attacks. In both cases, the issue
> is the scoping of cookie use. An attacker's web page or script can cause
> the UA to send requests of the attacker's choosing to a server. This has
> nothing to do with TLS - this in an HTTP behavior.
>

ChannelID solves this problem.

The goal of BEAST, CRIME, or other forms of cookie theft is to steal a
*usable* cookie.  With ChannelID, the channel-bound cookie that an attacker
might steal is unusable.

What we need, IMO, is a new cookie with new rules, such as that cookies
> will be indexed by origin and refer(r)er so that my UA would use different
> cookies for requests stemming from pages from google and requests initiated
> by pages and scripts from other origins. This kind of rule change is more
> important than either the crypto binding or the request hashing.
>

Deriving new cookie values based on where the cookie originated and where
it is being sent is one approach.

But making cookies sent to a particular client untransferable to other
clients seems equally valid, and is simpler if you can rely on something
(eg "ChannelID") to securely differentiate clients.

Trevor

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 12:44:26 -0500

> That's true, but is it important?

Sort of.  I think we should have a protocol that doesn't require
channel bound cookies.  Or even TLS at all.  But we should support the
use of channel bound cookies as a session continuation protocol for
two reasons: one is that there is/will be deployment, and the other is
that it works.

> session management mechanism?

It's not that.  There's several problems with using TLS and extensions
to it properly.  For example, if you have concentrators then you have
problems -- not unresolvable, but one i then at the mercy of their
concentrator vendor.  Another example is that even without
concentrators there's layering that complicates a portable service
implementation (portable, that is, relative to a variety of HTTP and
TLS server stacks).

> it might protect cookies at "http://example.com" from someone who hacks
> "http://test.example.com", but that's about it.

We want to improve on cookies.  IMO we should aim for a solution that
works: with and without TLS, with and without extensive support in the
TLS and HTTP stacks.

Channel bound cookies fit in, but only in a subset of cases.  It's a
great solution, but I think at least today it's not sufficient for all
the cases we should care about.

HOWEVER, that's a fair question: which cases should we care about?

It's entirely possible that we'd reach consensus on only caring about
the cases where channel bound cookies are sufficient, and then reach
consensus that it's the only solution we want.

I personally want a solution that doesn't require changing *any* part
of any TLS or HTTP client or server stack.  The reason is that I've
had the unpleasant experience of looking at the innards of several
widely used HTTP stacks to scope HTTP authentication and proxy
improvements, this in an environment where quite a few stacks are used
(Java, Apache, nginx, curl -- that's just to start, and just on the
HTTP side, and there are many more in use than just those).  It's a
never-ending saga to improve anything in all of them.

A purely application-layer solution has enormous benefits.  Almost
every server stack, for example, supports FCGI filters, so that's one
way to write a universal implementation for servers.  With
tls-server-end-point channel binding we only need the Host header and
a lookup table of host->EE certificate (with a bit more help from the
concentrators/servers it's possible to always and efficiently deal
with servers for which there are many equivalent certs).  On the
client-side there's still a large number of stacks for which to
implement (e.g., all the browsers), but at least for scripts using XHR
a universal implementation is feasible.

Channel bound cookies requires fixing all client and server stacks, so
it's definitely more difficult to deploy universally.  (Or did I
misunderstand?)  But of course, even an application-layer solution has
a massive client-side dev workload to deal with, comparable with
channel bound cookies' client-side dev workload.  Perhaps the
server-side dev workload is less severe than I've thought?

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 Jul 2013 18:41:20 +0000

On Jul 11, 2013, at 7:51 PM, Trevor Perrin <[email-masked]<mailto:[email-masked]>> wrote:

The goal of BEAST, CRIME, or other forms of cookie theft is to steal a *usable* cookie.  With ChannelID, the channel-bound cookie that an attacker might steal is unusable.

True, but I believe that the fact that attackers are able to get the UA to send arbitrary requests to a server and have them bless this request with their cookie is bad enough. I can demonstrate this with a real world example. This is from a real firewall appliance. I won't mention names, except to say that it is not from my company (otherwise I would be too embarrassed to post this to a public mailing list.

This firewall had a web-based management interface protected with HTTPS. The pages would have all kinds of buttons, each button had a name pretty similar to the text on the button, and clicking the buttons would cause a GET request like this:

GET /mainpage.html?button=something,field1="", field2="".

So I recorded some traffic (it was HTTPS, so I had to use a browser add-on to record it), and got this:

  *   GET /maingage.html?button=shutdown   caused the firewall to power-off.
  *   GET /mainpage.html?button=unload       caused the firewall to unload policy, so that it didn't enforce policy or do IPsec or anything a router wouldn't do.

So I tried opening another browser tab, and loading an HTML document that said <img src="https://myfw/mainpage.html?button=shutdown">

Yes, the firewall powered down, and if I had used "unload" instead of "shutdown" that would be the end of enforcing a security policy.

Now, granted, this is epic levels of cluelessness. But Channel-bound cookies don't save the administrator of this firewall. Only changing the rules around "blessing" requests with cookies can help.

I'm all in favor of binding to TLS or MAC-ing the requests, but I think we need those in addition to making cookie behavior secure, not instead of.

Having re-read draft-balfanz, that draft only has a TLS extension. Section 7.1 is only an example of how that extension can be used. If we really wanted a channel-bound cookie, we'd need a different document that specified channel-bound cookies. So we'd need someone two write such a draft.

Yoav

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 Jul 2013 14:50:24 -0400

On 07/11/2013 02:41 PM, Yoav Nir wrote:
> Now, granted, this is epic levels of cluelessness.

these are indeed epic levels of cluelessness.  at the very least the
authors of such an appliance need to learn the distinction between POST
and GET, which would prevent your "attack".  If the authors aren't
capable of making this distinction (which has been around for nearly 20
years), and they don't use widely-known measures for CSRF protection
(itself coming up on 10 years old, i think) when they have users who
enable javascript, i strongly doubt they'll deploy any sort of fancy
session continuation even if we specify it perfectly.

I'm not sure this sort of example is a reasonable argument for
developing any new standard technical measures, since by definition the
culprits here are not making use of standard technical measures.

Regards,

	--dkg

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 14:31:53 -0500

> session continuation even if we specify it perfectly.

Would any session continuation protocol alone we've discussed address
such epic mistakes?  I don't think so.  I think we could address these
problems by having session IDs that correspond to "requests made by
pages from the same or trusted origins" and ones that correspond to
"requests made by untrusted third parties", *then* we only have to
make sure that the service is HTTPS-only or that if it has any
resources not protected with HTTPS then that it can authenticate HTTP
requests and responses or otherwise treat the HTTP origin as
untrusted.  Of course, this all ties into the notion of origins and
whether mixed HTTP/HTTPS services are a good idea (and why) -- a bit
off-topic for session continuation, but tangential enough.

> culprits here are not making use of standard technical measures.

Actually, several alternatives to channel bound cookies that use MACs
have in fact been implemented and deployed.  We're not necessarily
developing new protocols.  New standards, possibly.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 Jul 2013 19:37:35 +0000

On Jul 11, 2013, at 9:50 PM, Daniel Kahn Gillmor <[email-masked]> wrote:

> and GET, which would prevent your "attack".  

I would still be able to make a form that would cause a POST. It's just a matter of getting the user to click a button, no?  I think I could also do it in Javascript.

> If the authors aren't

They don't have to. I don't think they wrote the web server from scratch. They have probably some web server and/or framework that does the cookie and authentication handling for them. CSRF counter-measures are hard. Writing the application with POST rather than GET is not hard, but it's something you have to think about. New-fangled cookies can be baked into the framework.

> culprits here are not making use of standard technical measures.

I think anything that takes the requirement for security clue away from the web developer and into the hands of the framework developer is a good thing. That does not mean they won't find other ways to mess up, but this is one case we can fix.

Yoav

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 Jul 2013 16:44:58 -0400

> I would still be able to make a form that would cause a POST. It's just a matter of getting the user to click a button, no?  I think I could also do it in Javascript.

Which is why you need CSRF protection, as i mentioned.
> They don't have to. I don't think they wrote the web server from scratch. They have probably some web server and/or framework that does the cookie and authentication handling for them. CSRF counter…

Any sane modern webapp framework has CSRF protection built in already.
Some not-so-sane and not-so-modern webapp frameworks have it too :P  The
point is, the devs on this silly appliance you describe weren't using
such a framework.

> I think anything that takes the requirement for security clue away from the web developer and into the hands of the framework developer is a good thing. That does not mean they won't find other way…

Sure, they could also have fixed it using standard tools that we already
have available, though, without any new standards.

I'm not saying that there are no good arguments for working on the
session continuation problem as stated; i'm just saying that this
example does not seem like a clear argument for it.

	--dkg

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 15:58:43 -0500

> point is, the devs on this silly appliance you describe weren't using

Not that it's on-topic but, it's hard for a framework to ensure that
GETs have no harmful side-effects because GET is allowed to have them,
as long as it's idempotent.

> example does not seem like a clear argument for it.

I think that's correct in this case, unless I misunderstood how
session continuation per-se can help in Yoav's example.  But this is
WEBSEC WG, and other things besides session continuation protocols are
on-topic that could, together with session continuation protocols,
address the problem.

At any rate, I don't think we should do anything to exclude channel
bound cookies (at least not yet, not without much more discussion as
to why) as a candidate session continuation protocol.  I have given
reasons why I think it shouldn't be the only candidate at this time,
or why we might need to have more than one session continuation
protocol (since, in fact, we already do as deployed).

Nico
--

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 11 Jul 2013 20:40:31 -0700

> reasons why I think it shouldn't be the only candidate at this time,

That's fair, but I do think ChannelID sets a high standard.  It's clear,
simple and can strongly protect cookies.  The proposals from this WG seem
much more complicated [1,2], and it's hard to tell whether they resist
attacks such as:

- Session forcing, where a MITM attacker transfer a session to the victim
client, thus logging the victim into the attacker's account.

 - Session stealing, where an attacker observes or receives a victim
client's request, and then makes the same request himself (perhaps just
replaying it, perhaps modifying it).

Trevor

[1]
http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00
[2] http://tools.ietf.org/html/draft-hallambaker-httpsession-01

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Jul 2013 09:20:46 -0400

> to have CRIME/BEAST resistance in the session continuation protocol.

We should not be mandating resistance to particular attacks already solved.
But we should be mandating a change in the authentication design.

The point is that the security of the authentication tokens should not be
compromised even if the confidentiality scheme fails. Confidentiality
should be built on authentication, not the other way round as using bearer
tokens forces us to do.

CRIME/BEAST would be a serious problem in any case and I find it amazing
that we still have people pushing header compression schemes even now. And
thats not the end of the problems either. The 'make it unsafe, we want
speed' crowd is currently looking at using HTTP over UDP for bulk transport
(not CoAP, web browsing) so expect DoS problems to get much worse.

The lesson we should be drawing from CRIME/BEAST is that the web browser
developers don't actually give a damn about security. There are security
people working for them but don't be fooled, the people who manage those
products don't consider security a priority or else we would have
revocation checking in SSL clients that is meaningful and many other things.

The KGB and the NSA both have doctrines that say that a system must be
robust in the case of failure of a cryptographic protocol. We have to adopt
the same sort of approach because modern Web browsers are ridiculously
complex and getting more so. There is nobody who can claim to understand
and be able to vouch for the security of the interactions between all the
components. CRIME is a consequence of two design decisions taken without
care for security: header compression and active code. Those two decisions
are not going to be the last.

Since we can't understand the consequences of those interactions our only
viable design approach is to design the session continuation scheme so that
the security of the authentication secrets ONLY depends on things we can
count on.

> why

-- 
Website: http://hallambaker.com/

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 15 Jul 2013 16:02:25 +0900

<no hats>
Yes to all.

Any other volunteers?

Best regards, Tobias

---

From: Yoav Nir <[email-masked]>
Date: Mon, 15 Jul 2013 09:46:28 +0000

<no hats either>

There are some people talking about similar things at httpbis, but for some reason they're not willing to move the discussion here.