Re: [http-state] Cookie login security inconsistency

"Paul E. Jones" <paulej@packetizer.com> Sat, 28 August 2010 19:06 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6DA3A693E for <http-state@core3.amsl.com>; Sat, 28 Aug 2010 12:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Level:
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JfiZB19Cm1Z for <http-state@core3.amsl.com>; Sat, 28 Aug 2010 12:06:38 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 713983A693B for <http-state@ietf.org>; Sat, 28 Aug 2010 12:06:38 -0700 (PDT)
Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o7SJ721K021029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Aug 2010 15:07:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1283022429; bh=WFQY7oU0yGkvX02hujW7bO3uEd4KpntEPm/c+Q+P1yc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=MNX7cEaigkrZnxC/q7Z2RBHbrmsRDUL/N+6uBd6JIuAIqGwARytw0tXq/OEZKW2V1 zHfnhT+dLfytbgF3cVGqbjuo1Xc5vXTjAhk2Nf0DQdBbQozHnj0l7gFv9rrF32mD4A loCzJO0em8evWmNzORNnhxSJozM/RKOTJk3+wADI=
From: "Paul E. Jones" <paulej@packetizer.com>
To: <shelby@coolpage.com>, <http-state@ietf.org>
References: <23e5b79de37d3b7ccfa8f85f6a5de360.squirrel@sm.webmail.pair.com>
In-Reply-To: <23e5b79de37d3b7ccfa8f85f6a5de360.squirrel@sm.webmail.pair.com>
Date: Sat, 28 Aug 2010 15:05:46 -0400
Message-ID: <011201cb46e4$09527dc0$1bf77940$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHtb4pPehUiwusRCYI4DCVwRHCy+ZKy5rbA
Content-Language: en-us
Cc: 'Rich Bowen' <rbowen@rcbowen.com>, 'Ben Laurie' <ben@links.org>
Subject: Re: [http-state] Cookie login security inconsistency
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Aug 2010 19:06:40 -0000

Shelby,

Sorry for jumping into this so late.  I've been rather busy with other
things.

I read through the material posted.  In general, I do agree that cookies, as
they are defined today, are horrible as a means for managing session state.
Not only can they be snatched off the wire, they *have been* snatched off
the wire and our of proxy caches and elsewhere.  While some issues with
cookies are due to programming bugs, some are wide open security holes.

A colleague and I produced this initial draft as an alternative to the
traditional cookie approach to try to secure session state:
http://tools.ietf.org/html/draft-salgueiro-secure-state-management

This was just our "straw man" proposal, but we think it is one worth
considering.  Ideally, the server would assign an encryption key via HTTPS.
This would be combined with a nonce produced at the client when the session
information is encrypted.  This would result in changing encrypted data and
the nonce value is monotonically increasing so the server can avoid replay
attacks.

It might not be a perfect solution to the problem, but it's a start at
something. 

In any case, we don't really care *how* we solve the problem, but we do
believe it needs to be solved.  Also important, we need a solution that can
be used with HTTP, not just HTTPS.

Paul

> -----Original Message-----
> From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org] On
> Behalf Of Shelby Moore
> Sent: Wednesday, August 25, 2010 1:04 PM
> To: http-state@ietf.org
> Subject: [http-state] Cookie login security inconsistency
> 
> Some of you know me already from the Hybi WG (WebSockets), so no need to
> introduce myself.
> 
> Please introduce to the record here, one specific inconsistency from prior
> cookies standard for best practices:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c26
> 
> Also I would like to introduce the entire linked page above to the record
> of input to this WG. I notice that Mozilla appears to agree with me on the
> solution or way to proceed:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c47
> 
> I am happy to see some people are working on the problem of http-state and
> I hope with an intent of closing the security holes.
> 
> Good luck with this.  I wish you all the best.
> 
> 
> ============
> Please note I am not joining this WG and will be unsubscribed after this
> post. Please remove my email address from any replies to this mailing
> list. If I have something else important to contribute, I will come back
> in the future.
> _______________________________________________
> http-state mailing list
> http-state@ietf.org
> https://www.ietf.org/mailman/listinfo/http-state