idnits 2.17.1 draft-mandyam-tokbind-attest-04.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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 11, 2018) is 2143 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 296, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tokbind-https' is defined on line 302, but no explicit reference was found in the text ** 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-12 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-10 == Outdated reference: A later version (-19) exists of draft-ietf-tokbind-protocol-16 -- Possible downref: Non-RFC (?) normative reference: ref. 'Keystore' -- Possible downref: Non-RFC (?) normative reference: ref. 'TPMv2' == 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: December 13, 2018 Qualcomm Technologies Inc. 6 June 11, 2018 8 Attested TLS Token Binding 9 draft-mandyam-tokbind-attest-04 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 December 13, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 2.1. KeyStore Attestation . . . . . . . . . . . . . . . . . . 3 58 2.1.1. Verification Procedures . . . . . . . . . . . . . . . 4 59 2.2. TPMv2 Attestation . . . . . . . . . . . . . . . . . . . . 4 60 2.2.1. Verification Procedures . . . . . . . . . . . . . . . 5 61 3. Extension Support Negotiation . . . . . . . . . . . . . . . . 5 62 3.1. Negotiating Token Binding Protocol Extensions . . . . . . 6 63 4. Example - Platform Attestation for Anomaly Detection . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 6.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 [I-D.ietf-tokbind-protocol] and [I-D.ietf-tokbind-negotiation] 73 describe a framework whereby servers can leverage cryptographically- 74 bound authentication tokens to verify TLS connections. This is 75 useful for prevention of man-in-the-middle attacks on TLS sessions, 76 and provides a mechanism by which identity federation systems can be 77 leveraged by a relying party to verify a client based on proof-of- 78 possession of a private key. 80 Once the use of token binding is negotiated as part of the TLS 81 handshake, an application layer message (the Token Binding message) 82 may be sent from the client to the relying party whose primary 83 purpose is to encapsulate a signature over a value associated with 84 the current TLS session (Exported Key Material, i.e. EKM - see 85 [I-D.ietf-tokbind-protocol]). 87 Proof-of-possession of a private key is useful to a relying party, 88 but the associated signature in the Token Binding message does not 89 provide an indication as to how the private key is stored and in what 90 kind of environment the associated cryptographic operation takes 91 place. This information may be required by a relying party in order 92 to satisfy requirements regarding client platform integrity. 93 Therefore, attestations are sometimes required by relying parties in 94 order for them to accept signatures from clients. As per the 95 definition in [I-D.birkholz-tuda], "remote attestation describes the 96 attempt to determine the integrity and trustworthiness of an endpoint 97 -- the attestee -- over a network to another endpoint -- the verifier 98 -- without direct access." Attestation statements are therefore 99 widely used in any server verification operation that leverages 100 client cryptography. 102 TLS token binding can therefore be enhanced with remote attestation 103 statements. The attestation statement can be used to augment Token 104 Binding message. This could be used by a relying party for several 105 different purpose, including (1) to determine whether to accept token 106 binding messages from the associated client, or (2) require an 107 additional mechanism for binding the TLS connection to an 108 authentication operation by the client. 110 2. Attestation Enhancement to TLS Token Binding Message 112 The attestation statement can be processed 'in-band' as part of the 113 Token Binding Message itself. This document leverages the 114 TokenBinding.extensions field of the Token Binding Message as 115 described in Section 3.4 of [I-D.ietf-tokbind-protocol], where the 116 extension data conforms to the guidelines of Section 6.3 of the same 117 document. The extension data takes the form of a CBOR (compact 118 binary object representation) Data Definition Language construct, 119 i.e. CDDL. 121 extension_data = {attestation} 122 attestation = ( 123 attestation_type: tstr, 124 attestation_data: bstr, 125 ) 127 The attestation data is determined according to the attestation type. 128 In this document, the following types are defined: "KeyStore" (where 129 the corresponding attestation data defined in [Keystore]) and "TPMv2" 130 (where the corresponding attestation data defined in [TPMv2]). 131 Additional attestation types may be accepted by the token binding 132 implementation (for instance, see Section 8 of [webauthn]). 134 2.1. KeyStore Attestation 136 KeyStore attestation is relevant to the Android operating system. 137 The Android Keystore mechanism allows for an application (such as a 138 browser implementing the Token Binding stack) to create a key pair, 139 export the public key, and protect the private key in a hardware- 140 backed keystore. The Android Keystore can then be used to verify a 141 keypair using the Keystore Attestation mechanism, which involves 142 signing a payload according to a public key that chains to a root 143 certificate signed by an attestation root key that is specific to the 144 device manufacturer. 146 KeyStore attestation provides a signature over a payload generated by 147 the application. Since in this case the application is the Token 148 Binding stack resident on the device, the payload is the Exported Key 149 Material (EKM) corresponding to the current TLS connection (see 150 Section 3.3 of [I-D.ietf-tokbind-protocol]). Then the attestation 151 takes the form of a signature accompanies by a chain of DER-encoded 152 x.509 certificates: 154 attestation_data = ( 155 sig: bytes, 156 x5c: [credCert: bytes, *(caCert: bytes)] 157 ) 159 2.1.1. Verification Procedures 161 The steps at the server for verifying a Token Binding KeyStore 162 Attestation are: 164 o Extract EKM for current TLS connection. 166 o Verify that attestation_data is in the expected CBOR format. 168 o Parse the first certificate listed in x5c and extract the public 169 key, algorithm and challenge. If the challenge does not match the 170 EKM then the attestation is invalid. 172 o If the challenge matches the EKM, verify the sig with respect to 173 the extracted public key and algorithm from the previous step. 175 o Verify the rest of the certificate chain up to the root. The root 176 certificate must match the expected root for the device. 178 2.2. TPMv2 Attestation 180 Version 2 of the Trusted Computing Group's Trusted Platform Module 181 (TPM) specification provides for an attestation generated within the 182 context of a TPM. The attestation then is defined as 183 attestation_data = ( 184 tpmt_sig: bytes, 185 tpms_attest: bytes, 186 x5c: [credCert: bytes, *(caCert: bytes)] 187 ) 189 The tpmt_sig is generated over a tpms_attest structure signed with 190 respect to the certificate chain provided in the x5c array. It is 191 derived from the TPMT_SIGNATURE data structure defined in 192 Section 11.3.4 of [TPMv2]. tpms_attest is derived from the 193 TPMS_ATTEST data structure in Section 10.2.8 of [TPMv2], specifically 194 with the extraData field being set to a SHA-256 hash of the EKM. 196 2.2.1. Verification Procedures 198 The steps for verifying a Token Binding TPMv2 Attestation are: 200 o Extract EKM for current TLS connection. 202 o Verify that attestation_data is in the expected CBOR format. 204 o Parse the first certificate listed in x5c and extract the public 205 key. 207 o Verify the tpms_attest structure,which includes 209 * Verify that the type field is set to TPM_ST_ATTEST_CERTIFY. 211 * Verify that extraData is equivalent to the EKM. 213 * Verify that magic is set to the expected TPM_GENERATED_VALUE 214 for the expected command sequence used to generate the 215 attestation. 217 * Verification of additonal TPMS_ATTEST data fields is optional. 219 o Verify tpmt_sig with respect to the public key provided in the 220 first certifcate in x5c, using the algorithm as specified in the 221 sigAlg field (see Sections 11.3.4, 11.2.1.5 and 9.29 of [TPMv2]). 223 3. Extension Support Negotiation 225 Even if the client supports a Token Binding extension, it may not be 226 desirable to send the extension if the server does not support it. 227 The benefits of client-suppression of an extension could include 228 saving of bits "over the wire" or simplified processing of the Token 229 Binding message at the server. Currently, extension support is not 230 communicated as part of the Token Binding extensions to TLS (see 231 [I-D.ietf-tokbind-negotiation]). 233 It is proposed that the Client and Server Hello extensions defined in 234 Sections 3 and 4 of [I-D.ietf-tokbind-negotiation] be extended so 235 that endpoints can communicate their support for specific 236 TokenBinding.extensions. With reference to Section 3, it is 237 recommended that the "token_binding" TLS extension be augmented by 238 the client to include supported TokenBinding.extensions as follows: 240 enum { 241 attestation(0), (255) 242 } TokenBindingExtensions; 244 struct { 245 TB_ProtocolVersion token_binding_version; 246 TokenBindingKeyParameters key_parameters_list<1..2^8-1>; 247 TokenBindingExtensions supported_extensions_list<1..2^8-1> 248 } TokenBindingParameters; 250 The "supported_extensions_list" contains the list of identifiers of 251 all token binding message extensions supported by the client. A 252 server supporting token binding extensions will respond in the server 253 hello with an appropriate "token_binding" extension that includes a 254 "supported_extensions_list". This list must be a subset of the the 255 extensions provided in the client hello. 257 3.1. Negotiating Token Binding Protocol Extensions 259 The negotation described in Section 4 of 260 [I-D.ietf-tokbind-negotiation] still applies. In addition, a client 261 can receive a "supported_extensions_list" from the server as part of 262 the server hello. The client must terminate the handshake if the 263 "supported_extensions_list" received from the server is not a subset 264 of the "supported_extensions_list" sent by the client in the client 265 hello. If the server hello list of supported extensions is a subset 266 of the client supported extensions, then the client must only send 267 those extensions specified in the server hello in the Token Binding 268 protocol. If the server hello does not include a 269 "supported_extensions_list", then the client must not send any 270 extensions along with the Token Binding Message. 272 4. Example - Platform Attestation for Anomaly Detection 274 An example of where a platform-based attestation is useful can be for 275 remote attestation based on client traffic anomaly detection. Many 276 network infrastructure deployments employ network traffic monitors 277 for anomalous pattern detection. Examples of anomalous patterns 278 detectable in the TLS handshake could be unexpected cipher suite 279 negotiation for a given source/destination pairing. In this case, it 280 may be desirable for a client-enhanced attestation reflecting for 281 instance that an expected offered cipher suite in the client hello 282 message is present or the originating browser integrity is intact 283 (e.g. through a hash over the browser application package). If the 284 network traffic monitor can interpret the atttestation included in 285 the token binding message, then it can verify the attestation and 286 potentially emit alerts based on an unexpected attestation. 288 5. IANA Considerations 290 This memo includes no request to IANA. 292 6. References 294 6.1. Normative References 296 [I-D.greevenbosch-appsawg-cbor-cddl] 297 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 298 definition language (CDDL): a notational convention to 299 express CBOR data structures", draft-greevenbosch-appsawg- 300 cbor-cddl-11 (work in progress), July 2017. 302 [I-D.ietf-tokbind-https] 303 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 304 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 305 tokbind-https-12 (work in progress), January 2018. 307 [I-D.ietf-tokbind-negotiation] 308 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 309 "Transport Layer Security (TLS) Extension for Token 310 Binding Protocol Negotiation", draft-ietf-tokbind- 311 negotiation-10 (work in progress), October 2017. 313 [I-D.ietf-tokbind-protocol] 314 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 315 Hodges, "The Token Binding Protocol Version 1.0", draft- 316 ietf-tokbind-protocol-16 (work in progress), October 2017. 318 [Keystore] 319 Google Inc., "Verifying hardware-backed key pairs with Key 320 Attestation", 321 . 324 [TPMv2] The Trusted Computing Group, "Trusted Platform Module 325 Library, Part 2: Structures", September 2016, 326 . 329 [webauthn] 330 The Worldwide Web Consortium, "Web Authentication: An API 331 for accessing Scoped Credentials", 332 . 334 6.2. Informative References 336 [I-D.birkholz-tuda] 337 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 338 "Time-Based Uni-Directional Attestation", draft-birkholz- 339 tuda-02 (work in progress), July 2016. 341 Authors' Addresses 343 Giridhar Mandyam 344 Qualcomm Technologies Inc. 345 5775 Morehouse Drive 346 San Diego, California 92121 347 USA 349 Phone: +1 858 651 7200 350 Email: mandyam@qti.qualcomm.com 352 Laurence Lundblade 353 Qualcomm Technologies Inc. 354 5775 Morehouse Drive 355 San Diego, California 92121 356 USA 358 Phone: +1 858 658 3584 359 Email: llundbla@qti.qualcomm.com 360 Jon Azen 361 Qualcomm Technologies Inc. 362 5775 Morehouse Drive 363 San Diego, California 92121 364 USA 366 Phone: +1 858 651 9476 367 Email: jazen@qti.qualcomm.com