Subject: [websec] Session Continuation = Session Bound State?

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Mar 2013 23:49:53 -0400

The main substantive query that seemed to be raised in the meeting was
what we are going to call this session continuation thing. I am not
that worried about confusion with HTTP-Auth. Folk who know, know.

But one of the objectives here is to replace cookies. So choosing a
name that positions the spec as a successor to authentication cookies
is actually quite important.

How about Session Bound State as the term of art?

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 Mar 2013 12:14:50 +0000

I'm kind of partial to "session management"

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 19 Mar 2013 16:58:29 +0800

Session Management sounds good to me.
(And we could change the name anytime over the evolution of the draft.)

Best regards, Tobias

On 18/03/13 20:14, Yoav Nir wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Harry Halpin <[email-masked]>
Date: Tue, 19 Mar 2013 15:21:04 +0100

> How about Session Bound State as the term of art?

For those of who weren't at the meeting, can we get a summary or a pointer?

   cheers,
     harry

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Mar 2013 10:21:14 -0500

> I'm kind of partial to "session management"

I am too, but am afraid that that can lead to confusion, since we're
only dealing with establishment, use, and synchronous destruction of
sessions, not any other aspect of session management (e.g., listing
active sessions, administrative session destruction, setting of
session parameter negotiation parameters, ...).

>> How about Session Bound State as the term of art?

I'd also be happy with:  Session Layer.  (And: Cookie Slayer, and any
other punny names we might think of :)

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Mar 2013 02:44:54 +0000

Hi Harry.

> For those of who weren't at the meeting, can we get a summary or a pointer?

You can get both.

There's the presentation that Phillip gave at the meeting: http://www.ietf.org/proceedings/86/slides/slides-86-websec-3.pdf
Also, there's Nico's draft: http://tools.ietf.org/html/draft-williams-websec-session-continue-prob

To summarize, the problem we are trying to solve, is that the current method of keeping sessions in HTTP through the use of session cookies has a lot of drawbacks:
 1. Cookies are not cryptographically bound to authentication, so there are many opportunities for an attacker to insert itself in the middle.
 2. Cookies are bearer tokens, which makes them attractive targets. Just in the last 18 months we've seen three attacks that recover the cookies even with TLS (BEAST, CRIME, Lucky-13)
 3. The rules for cookie usage are such that static and active content on one page can make requests on the user's behalf to another site, and have those requests authenticated by the user's cookie.
 4. Depending on cookie format, either the client or the server, but never both, can destroy the state, effectively terminating the session. It's the "not both" that is the issue.

So Nico and a design team wrote the above-mentioned draft that should have a problem statement and requirements. This is an initial draft and still requires much work. We are asking the working group to review this and post opinions to the list. If the review is as positive as the sentiment in the room was, we will adopt this and make this a working group document. For now, we're requesting reviews and textual suggestions.

Yoav

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Mar 2013 10:24:13 -0400

Adam Barth proposed "cake" a little while back.
<http://tools.ietf.org/html/draft-abarth-cake-01>