Hypertext Transport Protocol (HTTP) Session Continuation: Problem Statement

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



1.  Introduction

   Today most web applications use "cookies" to associate HTTP requests
   with "sessions".  A "session" is a set of related HTTP requests (and
   responses), where the relation is to some request(s) that created the
   session.  Some sessions are created by the act of authenticating a
   user, in which case the primary goal of "sessions" is to avoid having
   to re-authenticate the user on every request.  Other times a session
   is created when a request is received that is not associated with any
   session, in which case the primary purpose of "sessions" may be to
   provide a pseudonymous identifier for an otherwise anonymous user.
   We call the mechanisms by which requests are strung into sessions
   "session continuation".

   "Cookies" are server-assigned bearer tokens - nothing more, nothing
   less, though some cookies are used just to store things like
   "shopping cart" state.  A bearer token is an octet blob which can be
   presented as-is, possibly repeatedly, to authenticate a user to some
   party; mere possession of the bearer token is sufficient to act on
   the user's behalf to at least one service.  As such they are
   susceptible to theft via passive attacks (eavesdropping) if not
   protected in some other way (e.g., by using TLS), or via active
   attacks such as BEAST and CRIME
   [http://www.xors.me/?attachment_id=3727], as well as to leakage in
   various ways [XXX expand].

   We would like a session continuation mechanism to replace or augment
   cookies that has better security semantics than bearer tokens.  In
   particular we would like a system that is not susceptible to theft
   via active attacks like BEAST and CRIME.  We believe that such a
   scheme should use cryptographic algorithms and cryptographic session
   keys, and should be amenable to being keyed by HTTP- and web-
   authentication mechanisms.  A new session continuation mechanism
   should be suitable for use in web and non-web HTTP applications, and
   should work even for unauthenticated sessions.