IETF Logo Mail Archive

Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00

Trevor Perrin <trevp@trevp.net> Fri, 12 July 2013 03:40 UTC

Return-Path: <trevp@trevp.net>
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 0998211E81E0 for <websec@ietfa.amsl.com>; Thu, 11 Jul 2013 20:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 kvylD1RaZ-HU for <websec@ietfa.amsl.com>; Thu, 11 Jul 2013 20:40:33 -0700 (PDT)
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4B811E80F7 for <websec@ietf.org>; Thu, 11 Jul 2013 20:40:32 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id n57so7727305wev.0 for <websec@ietf.org>; Thu, 11 Jul 2013 20:40:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=yrrxYpaGdRBHaEWZOKBVsCoWn6azvJaWW2pnFE20gV8=; b=h9UDSHVktM2yQyDJJsKAoQz8P/RLAyA3IIxg7RXVUk6xJmELFfaE35aUTJk5BoUP/X Vwi4emQiUFU+TiJovJk6aLBpWjlmX943Ivz7HIHN7oeSvYfFFkv7/i4trdiVEFodnky8 WTDoiaszJmP60cb5yCoVvObKbeOtcWJ80RdT9sRtG0tUHB7kL8Pc4kGTicTV1ahFmWJk mSDONYA9/mQXPaAH/GzElTkAJW86hjw+0G93szQ2lqblygzTTOrnv/WpBpsiTzXJfqCj 6BDITOAD2unfzclIoBeR4MYZLKrZjhFOUta8I00dYigeMgVKEMhZPCJ3ZW7d2thVLa4V vGOg==
MIME-Version: 1.0
X-Received: by 10.194.83.195 with SMTP id s3mr23345881wjy.82.1373600431917; Thu, 11 Jul 2013 20:40:31 -0700 (PDT)
Received: by 10.216.212.9 with HTTP; Thu, 11 Jul 2013 20:40:31 -0700 (PDT)
X-Originating-IP: [50.37.26.202]
In-Reply-To: <CAK3OfOhdNQqCHmVkbzgi3N5r2S4dChmQMe_ndEDCjs81_LgXZQ@mail.gmail.com>
References: <20130708052654.13662.45967.idtracker@ietfa.amsl.com> <30F10539-AE45-48C6-A1ED-4914BDFB4156@checkpoint.com> <CAGZ8ZG3pvqMNzTCNxQ49NpBCLXeBr6HA2H1Am7-XacCmqA8u1Q@mail.gmail.com> <D97453ED-2352-4273-B8AF-0DAA00C1E555@checkpoint.com> <CAGZ8ZG11R9X5URK5zq=3cu-umpBRy0QWHV1eutcGakALjBBYSw@mail.gmail.com> <44801B83-214F-47E2-91B2-F3E42DE30249@checkpoint.com> <51DEFE70.6080402@fifthhorseman.net> <BA4C70A6-0C88-446E-914F-9BEF857EF3DB@checkpoint.com> <51DF194A.6040604@fifthhorseman.net> <CAK3OfOhdNQqCHmVkbzgi3N5r2S4dChmQMe_ndEDCjs81_LgXZQ@mail.gmail.com>
Date: Thu, 11 Jul 2013 20:40:31 -0700
Message-ID: <CAGZ8ZG2uNkzUxBKwohCFcfYG_s5xwwEGnAZ1f4pnp9o4nj5hSw@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="047d7bdc7c90cedfd304e14845cf"
X-Gm-Message-State: ALoCoQlZn3WJV25zgR3RlqI5bfdb+oX7z86Xfi0W4JVhQCnh+avyK7Fe1IK17Pqh+WWoolDedgR4
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Call for adoption: draft-ietf-websec-session-continue-prob-00
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: Fri, 12 Jul 2013 03:40:38 -0000

On Thu, Jul 11, 2013 at 1:58 PM, Nico Williams <nico@cryptonector.com>wrote:

>
> 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,
>


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

v2.23.0 | Report a Bug | By Email