[Unbearable] New version of Attested TLS Token Binding

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

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
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
Precedence: list

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>; Jon Azen <jazen@qti.qualcomm.com>; 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

Abstract:
   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

[Unbearable] New version of Attested TLS Token Bi… Giridhar Mandyam
Re: [Unbearable] New version of Attested TLS Toke… Andrei Popov
Re: [Unbearable] New version of Attested TLS Toke… Giridhar Mandyam