idnits 2.17.1 draft-mandyam-tokbind-attest-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 5, 2017) is 2417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.greevenbosch-appsawg-cbor-cddl' is defined on line 152, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tokbind-https' is defined on line 158, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-09 ** Downref: Normative reference to an Informational draft: draft-greevenbosch-appsawg-cbor-cddl (ref. 'I-D.greevenbosch-appsawg-cbor-cddl') == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-05 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-03 == Outdated reference: A later version (-19) exists of draft-ietf-tokbind-protocol-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'TPM' -- Possible downref: Non-RFC (?) normative reference: ref. 'Webauthn' == Outdated reference: A later version (-04) exists of draft-birkholz-tuda-02 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Token Binding Working Group G. Mandyam 3 Internet-Draft L. Lundblade 4 Intended status: Standards Track J. Azen 5 Expires: March 9, 2018 Qualcomm Technologies Inc. 6 September 5, 2017 8 Attested TLS Token Binding 9 draft-mandyam-tokbind-attest-02 11 Abstract 13 Token binding allows HTTP servers to bind bearer tokens to TLS 14 connections. In order to do this, clients or user agents must prove 15 possession of a private key. However, proof-of-possession of a 16 private key becomes truly meaningful to a server when accompanied by 17 an attestation statement. This specification describes extensions to 18 the existing token binding protocol to allow for attestation 19 statements to be sent along with the related token binding messages. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 9, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Attestation Enhancement to TLS Token Binding Message . . . . 3 57 3. Example - Platform Attestation for Anomaly Detection . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 5.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 [I-D.ietf-tokbind-protocol] and [I-D.ietf-tokbind-negotiation] 67 describe a framework whereby servers can leverage cryptographically- 68 bound authentication tokens to verify TLS connections. This is 69 useful for prevention of man-in-the-middle attacks on TLS sessions, 70 and provides a mechanism by which identity federation systems can be 71 leveraged by a relying party to verify a client based on proof-of- 72 possession of a private key. 74 Once the use of token binding is negotiated as part of the TLS 75 handshake, an application layer message (the Token Binding message) 76 may be sent from the client to the relying party whose primary 77 purpose is to encapsulate a signature over a value associated with 78 the current TLS session (Exported Key Material, i.e. EKM - see 79 [I-D.ietf-tokbind-protocol]). 81 Proof-of-possession of a private key is useful to a relying party, 82 but the associated signature in the Token Binding message does not 83 provide an indication as to how the private key is stored and in what 84 kind of environment the associated cryptographic operation takes 85 place. This information may be required by a relying party in order 86 to satisfy requirements regarding client platform integrity. 87 Therefore, attestations are sometimes required by relying parties in 88 order for them to accept signatures from clients. As per the 89 definition in [I-D.birkholz-tuda], "remote attestation describes the 90 attempt to determine the integrity and trustworthiness of an endpoint 91 -- the attestee -- over a network to another endpoint -- the verifier 92 -- without direct access." Attestation statements are therefore 93 widely used in any server verification operation that leverages 94 client cryptography. 96 TLS token binding can therefore be enhanced with remote attestation 97 statements. The attestation statement can be used to augment Token 98 Binding message. This could be used by a relying party for several 99 different purpose, including (1) to determine whether to accept token 100 binding messages from the associated client, or (2) require an 101 additional mechanism for binding the TLS connection to an 102 authentication operation by the client. 104 2. Attestation Enhancement to TLS Token Binding Message 106 The attestation statement can be processed 'in-band' as part of the 107 Token Binding Message itself. This document leverages the 108 TokenBinding.extensions field of the Token Binding Message as 109 described in Section 3.4 of [I-D.ietf-tokbind-protocol], where the 110 extension data conforms to the guidelines of Section 6.3 of the same 111 document. The extension data takes the form of a CBOR (compact 112 binary object representation) Data Definition Language construct, 113 i.e. CDDL. 115 extension_data = {attestation} 116 attestation = ( 117 attestation_type: tstr, 118 attestation_data: bstr, 119 ) 121 The attestation data is determined according to the attestation type. 122 In this document, the following types are defined: "packed" (where 123 the corresponding attestation data defined in [Webauthn]) and "TPM" 124 (where the corresponding attestation data defined in [TPM]). 125 Additional attestation types may be accepted by the token binding 126 implementation. 128 3. Example - Platform Attestation for Anomaly Detection 130 An example of where a platform-based attestation is useful can be for 131 remote attestation based on client traffic anomaly detection. Many 132 network infrastructure deployments employ network traffic monitors 133 for anomalous pattern detection. Examples of anomalous patterns 134 detectable in the TLS handshake could be unexpected cipher suite 135 negotiation for a given source/destination pairing. In this case, it 136 may be desirable for a client-enhanced attestation reflecting for 137 instance that an expected offered cipher suite in the client hello 138 message is present or the originating browser integrity is intact 139 (e.g. through a hash over the browser application package). If the 140 network traffic monitor can interpret the atttestation included in 141 the token binding message, then it can verify the attestation and 142 potentially emit alerts based on an unexpected attestation. 144 4. IANA Considerations 146 This memo includes no request to IANA. 148 5. References 150 5.1. Normative References 152 [I-D.greevenbosch-appsawg-cbor-cddl] 153 Vigano, C. and H. Birkholz, "CBOR data definition language 154 (CDDL): a notational convention to express CBOR data 155 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 156 in progress), September 2016. 158 [I-D.ietf-tokbind-https] 159 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 160 Hodges, "Token Binding over HTTP", draft-ietf-tokbind- 161 https-05 (work in progress), July 2016. 163 [I-D.ietf-tokbind-negotiation] 164 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 165 "Transport Layer Security (TLS) Extension for Token 166 Binding Protocol Negotiation", draft-ietf-tokbind- 167 negotiation-03 (work in progress), July 2016. 169 [I-D.ietf-tokbind-protocol] 170 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 171 Hodges, "The Token Binding Protocol Version 1.0", draft- 172 ietf-tokbind-protocol-08 (work in progress), July 2016. 174 [TPM] The Trusted Computing Group, "Trusted Platform Module 175 Library, Part 1: Architecture", October 2014. 177 [Webauthn] 178 The Worldwide Web Consortium, "Web Authentication: An API 179 for accessing Scoped Credentials", 180 . 182 5.2. Informative References 184 [I-D.birkholz-tuda] 185 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 186 "Time-Based Uni-Directional Attestation", draft-birkholz- 187 tuda-02 (work in progress), July 2016. 189 Authors' Addresses 191 Giridhar Mandyam 192 Qualcomm Technologies Inc. 193 5775 Morehouse Drive 194 San Diego, California 92121 195 USA 197 Phone: +1 858 651 7200 198 Email: mandyam@qti.qualcomm.com 200 Laurence Lundblade 201 Qualcomm Technologies Inc. 202 5775 Morehouse Drive 203 San Diego, California 92121 204 USA 206 Phone: +1 858 658 3584 207 Email: llundbla@qti.qualcomm.com 209 Jon Azen 210 Qualcomm Technologies Inc. 211 5775 Morehouse Drive 212 San Diego, California 92121 213 USA 215 Phone: +1 858 651 9476 216 Email: jazen@qti.qualcomm.com