[TLS] OBC and logout (Re: TLS-OBC proposal)

Nico Williams <nico@cryptonector.com> Thu, 08 September 2011 21:56 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D821F8B23 for <tls@ietfa.amsl.com>; Thu, 8 Sep 2011 14:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.672
X-Spam-Level:
X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 kO44rA5+wAC8 for <tls@ietfa.amsl.com>; Thu, 8 Sep 2011 14:56:48 -0700 (PDT)
Received: from homiemail-a70.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4621F8B1B for <tls@ietf.org>; Thu, 8 Sep 2011 14:56:48 -0700 (PDT)
Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 253A4768057 for <tls@ietf.org>; Thu, 8 Sep 2011 14:58:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; q=dns; s= cryptonector.com; b=l9OazGLfeaJBxJKxpMjXeY5WEHEDo1sfIhgYSiTU+l9f ottAwilGaPDSHEbRVxGfIAxBwhw0K4dVVEUIZxur961SftlLi9SRqzy7wqttHqnH OkomZJzXG6zAsi6aL3HQ2EZvCJ4cFBWeu2Rd9vQqieNXsKYVsA2YpFNRRsK4BFM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=HYpRus5138vJybredRVFsfrzGPA=; b=W7r/7aaVkVV RM+ahioYb3CQrfwAfTQicNKZ8+rW5u5FFIeXTITf5wwzi0voSVXMEeHVXmU0ADEz 2Kf+8h+TVcZB9JqCbtkkGAcHzsiUF+IBS/WBh0sKku0MENPnMgGeHLjYKh9OjF4M aXvnc/0qYrZo7RKYkyqnkWTuhvEpfKNM=
Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id F05A7768056 for <tls@ietf.org>; Thu, 8 Sep 2011 14:58:41 -0700 (PDT)
Received: by gxk9 with SMTP id 9so455315gxk.40 for <tls@ietf.org>; Thu, 08 Sep 2011 14:58:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.33.164 with SMTP id s4mr1630818pbi.265.1315519121031; Thu, 08 Sep 2011 14:58:41 -0700 (PDT)
Received: by 10.68.66.163 with HTTP; Thu, 8 Sep 2011 14:58:41 -0700 (PDT)
Date: Thu, 08 Sep 2011 16:58:41 -0500
Message-ID: <CAK3OfOh06yO9uFFmOCbfN48O88f3jsEjLmZBgR0SNWNe5v55Ew@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Dirk Balfanz <balfanz@google.com>
Content-Type: text/plain; charset="UTF-8"
Cc: tls@ietf.org
Subject: [TLS] OBC and logout (Re: TLS-OBC proposal)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2011 21:56:49 -0000

Also note that here the client can make logout work better: the server
can't accept the old cookies if the client destroys the corresponding
OBC's private key.  Sure, the server could loosen its rules and accept
such cookies anyways, but it'd be opening itself to a big
vulnerability unless it greatly limited what it will allow clients
presenting such cookies to do (i.e., the server could allow such
cookies only for post-logout tracking.

If we know which cookies are channel bound to OBCs then the client can
destroy those cookies when the corresponding OBCs' private keys are
destroyed.  So then the only way channel bound cookies can be used for
tracking would be if they leaked.

This would be almost as strong a logout semantic as you'd get with,
say, REST-GSS.  Strong enough for me.

Nico
--