[websec] Starting work on Session Continuation/Bound State/Management (was: Session Continuation = Session Bound State?)

Yoav Nir <ynir@checkpoint.com> Wed, 20 March 2013 02:44 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5557B21F8F0F for <websec@ietfa.amsl.com>; Tue, 19 Mar 2013 19:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.406
X-Spam-Level:
X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfNXcecO7qM7 for <websec@ietfa.amsl.com>; Tue, 19 Mar 2013 19:44:57 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1621F8455 for <websec@ietf.org>; Tue, 19 Mar 2013 19:44:57 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2K2it4S030928; Wed, 20 Mar 2013 04:44:55 +0200
X-CheckPoint: {5149217A-0-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 04:44:55 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Harry Halpin <hhalpin@w3.org>, websec <websec@ietf.org>
Thread-Topic: Starting work on Session Continuation/Bound State/Management (was: Session Continuation = Session Bound State?)
Thread-Index: AQHOJRTmB6HrN5Hlik+ysGrhUrSkBQ==
Date: Wed, 20 Mar 2013 02:44:54 +0000
Message-ID: <AC9072D1-0E95-4619-88FC-8617256989D8@checkpoint.com>
References: <CAMm+Lwge7VBNWvWG01UN4j9=1nB+b8prusSVxgOpOcNLbZT8Sg@mail.gmail.com> <51487450.2060707@w3.org>
In-Reply-To: <51487450.2060707@w3.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.169]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D274CEF543F3A14293D8F2512F2A2249@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [websec] Starting work on Session Continuation/Bound State/Management (was: Session Continuation = Session Bound State?)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2013 02:44:58 -0000

Hi Harry.

On Mar 19, 2013, at 10:21 AM, Harry Halpin <hhalpin@w3.org> wrote:

> On 03/14/2013 04:49 AM, Phillip Hallam-Baker wrote:
>> 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?
>> 
> 
> 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