IETF Logo Mail Archive

[Unbearable] one proposal for a charter - please dicsuss

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 08 December 2014 23:19 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE70C1A0073 for <unbearable@ietfa.amsl.com>; Mon, 8 Dec 2014 15:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2q7G8VVzoOp for <unbearable@ietfa.amsl.com>; Mon, 8 Dec 2014 15:19:33 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7181A011F for <unbearable@ietf.org>; Mon, 8 Dec 2014 15:19:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D8CABEE5 for <unbearable@ietf.org>; Mon, 8 Dec 2014 23:19:32 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po0-m6dxTDcw for <unbearable@ietf.org>; Mon, 8 Dec 2014 23:19:30 +0000 (GMT)
Received: from [10.87.48.11] (unknown [86.41.57.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D055ABED5 for <unbearable@ietf.org>; Mon, 8 Dec 2014 23:19:30 +0000 (GMT)
Message-ID: <54863200.4030600@cs.tcd.ie>
Date: Mon, 08 Dec 2014 23:19:28 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: unbearable@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/hewquTFQnbni-8o-ZJ7KgKTuMk8
Subject: [Unbearable] one proposal for a charter - please dicsuss
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Dec 2014 23:19:37 -0000

Hi all,

There's about 70+ people on the list now so let's kick off.

Andrei sent Kathleen and I the charter proposal below a while
ago. For myself I don't think its quite right yet but I'd
rather hear what you all think. So please discuss...

Cheers,
S.


Token Binding (TB)

Charter for Working Group

Web services generate various security tokens (e.g.  HTTP cookies, OAuth
tokens, etc.) for web applications to access protected resources.
Currently these are bearer tokens, i.e. any party in possession of such
token gains access to the protected resource. Attackers export bearer
tokens from client machines or from compromised network connections,
present these bearer tokens to Web services, and impersonate
authenticated users. The idea of Token Binding is to prevent such
attacks by cryptographically binding security tokens to the TLS layer.

The tasks of this working group are as follows:
1.            Specify the Token Binding protocol v1.0.
2.            Specify the use of the Token Binding protocol in
combination with HTTPS.

It is a goal of this working group to prevent security token export and
replay attacks, but other issues associated with the use of security
tokens are out of scope. It is a goal of this working group to design
the Token Binding protocol such that it would be also useable with
application protocols other than HTTPS, however specifying such uses is
not a primary goal.

Some of the main design goals for the Token Binding protocol, in no
particular order:
1.            Prevent export and replay of security tokens.
2.            Allow strong key protection, e.g. using hardware-bound keys.
3.            Support both first-party and federation scenarios.
4.            Preserve user privacy.
5.            Make the Token Binding protocol useable in combination
with a variety of application protocols.
6.            Allow the negotiation of the Token Binding protocol
without additional round-trips.
7.            Allow the use of multiple cryptographic algorithms, so
that a variety of secure hardware modules with different cryptographic
capabilities could be used with Token Binding.

The working group will use the following documents as a starting point
for its work:
-              draft-popov-token-binding-00;
-              draft-balfanz-https-token-binding-00.

This WG will collaborate with other IETF WGs, in particular with the
TLS, HTTPbis and Oauth WGs.

Milestones:

March 2015: WG document for the Token Binding Protocol v1.0.
March 2015: WG document for HTTPS Token Binding.
November 2015: Token Binding Protocol v1.0 to IESG.
November 2015: HTTPS Token Binding to IESG.

v2.23.0 | Report a Bug | By Email