[Unbearable] New version of Attested TLS Token Binding

Giridhar Mandyam <mandyam@qti.qualcomm.com> Tue, 17 July 2018 21:02 UTC

Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9539C130DEB for <unbearable@ietfa.amsl.com>; Tue, 17 Jul 2018 14:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oI90rrGbHFuq for <unbearable@ietfa.amsl.com>; Tue, 17 Jul 2018 14:02:32 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com []) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0251213104D for <unbearable@ietf.org>; Tue, 17 Jul 2018 14:02:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1531861351; x=1563397351; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1OVXQMI/JPyxkYySxdM1bmTTR1MbDu70qNfP3tjVVEI=; b=n90R/D8Ws4Nvl0v2aEcgQuvFHo8P+AG4ltsrKBxdWsUB0d8uV26H7rkf c7P7mwKtiCwYAuomj7Ufd+a9BD3nJhWXDzDj6qpBImf9iU3FcLwWzx0kb i7ios8vh/FPZWg9Kgb6QgOVFYWFCsoVx7udcd88pZEC3TAyK6dgJ/0UeS g=;
X-IronPort-AV: E=Sophos;i="5.51,367,1526367600"; d="scan'208";a="350151116"
Received: from unknown (HELO ironmsg02-sd.qualcomm.com) ([]) by wolverine01.qualcomm.com with ESMTP; 17 Jul 2018 14:02:31 -0700
Received: from nasanexm01h.na.qualcomm.com ([]) by ironmsg02-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 17 Jul 2018 14:02:22 -0700
Received: from NASANEXM01C.na.qualcomm.com ( by NASANEXM01H.na.qualcomm.com ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Jul 2018 14:02:01 -0700
Received: from NASANEXM01C.na.qualcomm.com ([]) by NASANEXM01C.na.qualcomm.com ([]) with mapi id 15.00.1365.000; Tue, 17 Jul 2018 14:02:01 -0700
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: New version of Attested TLS Token Binding
Thread-Index: AdQeCA4vaugyxA+3Q+uESV6F+H/I7A==
Date: Tue, 17 Jul 2018 21:02:00 +0000
Message-ID: <7d26fe5e053944e48f5c35c2ba57f8f3@NASANEXM01C.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/6zagh4ySUofRet718myStpQtR9U>
Subject: [Unbearable] New version of Attested TLS Token Binding
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.27
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 17 Jul 2018 21:02:38 -0000

Hello All,

I hope to discuss this during Friday's meeting.  Some of the major changes since ver. 0.4 and ver. 0.3:

a) Proposal of new TLS extensions codepoint for tokbind sessions that will involve tokbind.extensions
b) Proposal for negotiating use of extensions  as part of TLS handshake
c) Addition of two base attestation types:  Android Keystore and TPMv2, along with verification procedures (heavily leveraged from Webauthn).
d) Proposal of establishment of tokbind attestation registry.

There are some other issues that I would like to get guidance from the group on the topic of tokbind.extensions, including:

a) Should clients advertise supported extensions? 
b) Should servers select extensions that they are interested in, and have the client suppress other extensions?  
c) Should clients just send all extensions that they support?  If so, can servers just ignore extensions in which they have no interest?

And specific to the attestation extension,

d) Should clients advertise the attestation types they support (which may expose some fingerprinting surface)?  Should servers communicate the attestation roots that they support?

-Giri Mandyam

-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org> 
Sent: Tuesday, July 17, 2018 12:52 PM
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>om>; Jon Azen <jazen@qti.qualcomm.com>om>; Laurence Lundblade <llundbla@qti.qualcomm.com>
Subject: New Version Notification for draft-mandyam-tokbind-attest-05.txt

A new version of I-D, draft-mandyam-tokbind-attest-05.txt
has been successfully submitted by Giridhar Mandyam and posted to the IETF repository.

Name:		draft-mandyam-tokbind-attest
Revision:	05
Title:		Attested TLS Token Binding
Document date:	2018-07-17
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-mandyam-tokbind-attest-05.txt
Status:         https://datatracker.ietf.org/doc/draft-mandyam-tokbind-attest/
Htmlized:       https://tools.ietf.org/html/draft-mandyam-tokbind-attest-05
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mandyam-tokbind-attest
Diff:           https://www.ietf.org/rfcdiff?url2=draft-mandyam-tokbind-attest-05

   Token binding allows HTTP servers to bind bearer tokens to TLS
   connections.  In order to do this, clients or user agents must prove
   possession of a private key.  However, proof-of-possession of a
   private key becomes truly meaningful to a server when accompanied by
   an attestation statement.  This specification describes extensions to
   the existing token binding protocol to allow for attestation
   statements to be sent along with the related token binding messages.


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat