[Unbearable] New Version Notification for draft-mandyam-tokbind-attest (ver -06)

Giridhar Mandyam <mandyam@qti.qualcomm.com> Tue, 24 July 2018 23:04 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 D494C131218 for <unbearable@ietfa.amsl.com>; Tue, 24 Jul 2018 16:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 GNA6t7MrU_lH for <unbearable@ietfa.amsl.com>; Tue, 24 Jul 2018 16:04:49 -0700 (PDT)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com []) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C431292F1 for <unbearable@ietf.org>; Tue, 24 Jul 2018 16:04:49 -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=1532473489; x=1564009489; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9Amc+B3WqFQoDnKPnQbiNW4pV7E++tQcqnpKUkMRXgI=; b=IB7+h+MY6CsIoOMqLXBpuYy6xvK+cc+MCMNqoEnITh26/fCWUbUr6OSV 0BEPvEnXKfqXkpaBZvh3T9ukZfSnwDxCTy0NVA4MdK+pP9Ryp3IFs2F3N 9nOii0544GNrbpb5xZdCCNGCb6oGrcfnoLRxstRaI1ZdM9JPTr1o5su8U 0=;
X-IronPort-AV: E=Sophos;i="5.51,399,1526367600"; d="scan'208";a="7191676"
Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([]) by alexa-out-sd-02.qualcomm.com with ESMTP; 24 Jul 2018 16:04:49 -0700
X-IronPort-AV: E=McAfee;i="5900,7806,8964"; a="122340435"
Received: from nasanexm01h.na.qualcomm.com ([]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 24 Jul 2018 16:04:49 -0700
Received: from NASANEXM01C.na.qualcomm.com ( by NASANEXM01H.na.qualcomm.com ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 24 Jul 2018 16:02:15 -0700
Received: from NASANEXM01C.na.qualcomm.com ([]) by NASANEXM01C.na.qualcomm.com ([]) with mapi id 15.00.1365.000; Tue, 24 Jul 2018 16:02:15 -0700
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: New Version Notification for draft-mandyam-tokbind-attest (ver -06)
Thread-Index: AdQjmi2dpy5I3GwiQhCzjQgVPBwEzA==
Date: Tue, 24 Jul 2018 23:02:14 +0000
Message-ID: <2874af6cb12d4608b92663f534124954@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/HTbWK0YR65fn4VEXpQaHO_xsjkU>
Subject: [Unbearable] New Version Notification for draft-mandyam-tokbind-attest (ver -06)
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, 24 Jul 2018 23:04:52 -0000

As per recommendation of the chairs at last week's meeting in Montreal, a new version of this doc has been uploaded.  Summary of changes:

a) Each attestation type now has its own tokbind.extension value.  This allowed for a simpler advertisement of supported attestation types during the TLS handshake, as each endpoint can just send a list of supported extensions.  This also avoids having to create an additional registry for attestation types.
	That being said, I realize that there is only an octet for identifying tokbind extensions.   It may be something for the group to consider whether this is sufficient.
b) There are three IANA registrations proposed:  one for the new TLS extension codepoint, and two for the proposed attestation types as separate tokbind extensions.
c) The attestation signature for both types (Android Keystore and TPM) are now created over a hash of the tokbind public key (as suggested in Montreal).  In the previous version, it was over EKM.  Moreover, the tokbind client only has to send the attestation once during the lifetime of the tokbind keypair.  

-Giri MAndyam

-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org> 
Sent: Tuesday, July 24, 2018 3:02 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-06.txt

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

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

   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