idnits 2.17.1 draft-mandyam-tokbind-attest-05.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 (July 17, 2018) is 2107 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 370, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tokbind-https' is defined on line 376, 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: January 18, 2019 Qualcomm Technologies Inc. 6 July 17, 2018 8 Attested TLS Token Binding 9 draft-mandyam-tokbind-attest-05 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 January 18, 2019. 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. Token Binding Attestation Registry . . . . . . . . . . . 4 58 2.2. KeyStore Attestation . . . . . . . . . . . . . . . . . . 4 59 2.2.1. Verification Procedures . . . . . . . . . . . . . . . 5 60 2.3. TPMv2 Attestation . . . . . . . . . . . . . . . . . . . . 5 61 2.3.1. Verification Procedures . . . . . . . . . . . . . . . 5 62 3. Extension Support Negotiation . . . . . . . . . . . . . . . . 6 63 3.1. Negotiating Token Binding Protocol Extensions . . . . . . 7 64 4. Example - Platform Attestation for Anomaly Detection . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. TLS Extensions Registry . . . . . . . . . . . . . . . . . 8 67 5.2. Token Binding Extension for Attestation . . . . . . . . . 8 68 5.3. Token Binding Attestation Type Registry . . . . . . . . . 8 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 [I-D.ietf-tokbind-protocol] and [I-D.ietf-tokbind-negotiation] 78 describe a framework whereby servers can leverage cryptographically- 79 bound authentication tokens to verify TLS connections. This is 80 useful for prevention of man-in-the-middle attacks on TLS sessions, 81 and provides a mechanism by which identity federation systems can be 82 leveraged by a relying party to verify a client based on proof-of- 83 possession of a private key. 85 Once the use of token binding is negotiated as part of the TLS 86 handshake, an application layer message (the Token Binding message) 87 may be sent from the client to the relying party whose primary 88 purpose is to encapsulate a signature over a value associated with 89 the current TLS session (Exported Key Material, i.e. EKM - see 90 [I-D.ietf-tokbind-protocol]). 92 Proof-of-possession of a private key is useful to a relying party, 93 but the associated signature in the Token Binding message does not 94 provide an indication as to how the private key is stored and in what 95 kind of environment the associated cryptographic operation takes 96 place. This information may be required by a relying party in order 97 to satisfy requirements regarding client platform integrity. 98 Therefore, attestations are sometimes required by relying parties in 99 order for them to accept signatures from clients. As per the 100 definition in [I-D.birkholz-tuda], "remote attestation describes the 101 attempt to determine the integrity and trustworthiness of an endpoint 102 -- the attestee -- over a network to another endpoint -- the verifier 103 -- without direct access." Attestation statements are therefore 104 widely used in any server verification operation that leverages 105 client cryptography. 107 TLS token binding can therefore be enhanced with remote attestation 108 statements. The attestation statement can be used to augment Token 109 Binding message. This could be used by a relying party for several 110 different purpose, including (1) to determine whether to accept token 111 binding messages from the associated client, or (2) require an 112 additional mechanism for binding the TLS connection to an 113 authentication operation by the client. 115 2. Attestation Enhancement to TLS Token Binding Message 117 The attestation statement can be processed 'in-band' as part of the 118 Token Binding Message itself. This document leverages the 119 TokenBinding.extensions field of the Token Binding Message as 120 described in Section 3.4 of [I-D.ietf-tokbind-protocol], where the 121 extension data conforms to the guidelines of Section 6.3 of the same 122 document. The value of the extension, as required by this same 123 section, is TBD. The extension data takes the form of a CBOR 124 (compact binary object representation) Data Definition Language 125 construct, i.e. CDDL. 127 extension_data = {attestation} 128 attestation = ( 129 attestation_type: tstr, 130 attestation_data: bstr, 131 ) 133 The attestation data is determined according to the attestation type. 134 In this document, the following types are defined: "KeyStore" (where 135 the corresponding attestation data defined in [Keystore]) and "TPMv2" 136 (where the corresponding attestation data defined in [TPMv2]). 137 Additional attestation types may be accepted by the token binding 138 implementation (for instance, see Section 8 of [webauthn]). 140 2.1. Token Binding Attestation Registry 142 It is recommended that a registry be created for additional 143 attestation types, with corresponding specifications required to 144 define the attestation data. 146 Entries in this registry must include the following fields: 148 o Value: The text string that uniquely identifies the attestation 149 type, e.g. "TPMv2" 151 o Description: A human-readable description of the attestation, e.g. 152 "TCG TPM Version 2 compliant attestation" 154 o Specification: A reference to a specification that defines the 155 attestation data. 157 2.2. KeyStore Attestation 159 KeyStore attestation is relevant to the Android operating system. 160 The Android Keystore mechanism allows for an application (such as a 161 browser implementing the Token Binding stack) to create a key pair, 162 export the public key, and protect the private key in a hardware- 163 backed keystore. The Android Keystore can then be used to verify a 164 keypair using the Keystore Attestation mechanism, which involves 165 signing a payload according to a public key that chains to a root 166 certificate signed by an attestation root key that is specific to the 167 device manufacturer. 169 KeyStore attestation provides a signature over a payload generated by 170 the application. Since in this case the application is the Token 171 Binding stack resident on the device, the payload is the Exported Key 172 Material (EKM) corresponding to the current TLS connection (see 173 Section 3.3 of [I-D.ietf-tokbind-protocol]). Then the attestation 174 takes the form of a signature accompanies by a chain of DER-encoded 175 x.509 certificates: 177 attestation_data = ( 178 sig: bytes, 179 x5c: [credCert: bytes, *(caCert: bytes)] 180 ) 182 2.2.1. Verification Procedures 184 The steps at the server for verifying a Token Binding KeyStore 185 Attestation are: 187 o Extract EKM for current TLS connection. 189 o Verify that attestation_data is in the expected CBOR format. 191 o Parse the first certificate listed in x5c and extract the public 192 key, algorithm and challenge. If the challenge does not match the 193 EKM then the attestation is invalid. 195 o If the challenge matches the EKM, verify the sig with respect to 196 the extracted public key and algorithm from the previous step. 198 o Verify the rest of the certificate chain up to the root. The root 199 certificate must match the expected root for the device. 201 2.3. TPMv2 Attestation 203 Version 2 of the Trusted Computing Group's Trusted Platform Module 204 (TPM) specification provides for an attestation generated within the 205 context of a TPM. The attestation then is defined as 207 attestation_data = ( 208 tpmt_sig: bytes, 209 tpms_attest: bytes, 210 x5c: [credCert: bytes, *(caCert: bytes)] 211 ) 213 The tpmt_sig is generated over a tpms_attest structure signed with 214 respect to the certificate chain provided in the x5c array. It is 215 derived from the TPMT_SIGNATURE data structure defined in 216 Section 11.3.4 of [TPMv2]. tpms_attest is derived from the 217 TPMS_ATTEST data structure in Section 10.2.8 of [TPMv2], specifically 218 with the extraData field being set to a SHA-256 hash of the EKM. 220 2.3.1. Verification Procedures 222 The steps for verifying a Token Binding TPMv2 Attestation are: 224 o Extract EKM for current TLS connection. 226 o Verify that attestation_data is in the expected CBOR format. 228 o Parse the first certificate listed in x5c and extract the public 229 key. 231 o Verify the tpms_attest structure,which includes 233 * Verify that the type field is set to TPM_ST_ATTEST_CERTIFY. 235 * Verify that extraData is equivalent to the EKM. 237 * Verify that magic is set to the expected TPM_GENERATED_VALUE 238 for the expected command sequence used to generate the 239 attestation. 241 * Verification of additonal TPMS_ATTEST data fields is optional. 243 o Verify tpmt_sig with respect to the public key provided in the 244 first certifcate in x5c, using the algorithm as specified in the 245 sigAlg field (see Sections 11.3.4, 11.2.1.5 and 9.29 of [TPMv2]). 247 3. Extension Support Negotiation 249 Even if the client supports a Token Binding extension, it may not be 250 desirable to send the extension if the server does not support it. 251 The benefits of client-suppression of an extension could include 252 saving of bits "over the wire" or simplified processing of the Token 253 Binding message at the server. Currently, extension support is not 254 communicated as part of the Token Binding extensions to TLS (see 255 [I-D.ietf-tokbind-negotiation]). 257 It is proposed that the Client and Server Hello extensions defined in 258 Sections 3 and 4 of [I-D.ietf-tokbind-negotiation] be extended so 259 that endpoints can communicate their support for specific 260 TokenBinding.extensions. With reference to Section 3, it is 261 recommended that the "token_binding" TLS extension be augmented by 262 the client to include supported TokenBinding.extensions as follows: 264 enum { 265 attestation(0), (255) 266 } TokenBindingExtensions; 268 struct { 269 TB_ProtocolVersion token_binding_version; 270 TokenBindingKeyParameters key_parameters_list<1..2^8-1>; 271 TokenBindingExtensions supported_extensions_list<1..2^8-1> 272 } TokenBindingParameters; 274 The "supported_extensions_list" contains the list of identifiers of 275 all token binding message extensions supported by the client. A 276 server supporting token binding extensions will respond in the server 277 hello with an appropriate "token_binding" extension that includes a 278 "supported_extensions_list". This list must be a subset of the the 279 extensions provided in the client hello. 281 Since a TLS extension cannot itself be extended, the "token_binding" 282 TLS extension cannot be reused. Therefore it is proposed that a new 283 TLS extension be defined - "token_binding_with_extensions". This TLS 284 extension codepoint is identical to the existing "token_binding" 285 extension except for the additional data structures defined above. 287 3.1. Negotiating Token Binding Protocol Extensions 289 The negotation described in Section 4 of 290 [I-D.ietf-tokbind-negotiation] still applies, except now the 291 "token_binding_with_extensions" codepoint would be used if the client 292 supports any token binding extension. In addition, a client can 293 receive a "supported_extensions_list" from the server as part of the 294 server hello. The client must terminate the handshake if the 295 "supported_extensions_list" received from the server is not a subset 296 of the "supported_extensions_list" sent by the client in the client 297 hello. If the server hello list of supported extensions is a subset 298 of the client supported extensions, then the client must only send 299 those extensions specified in the server hello in the Token Binding 300 protocol. If the server hello does not include a 301 "supported_extensions_list", then the client must not send any 302 extensions along with the Token Binding Message. 304 4. Example - Platform Attestation for Anomaly Detection 306 An example of where a platform-based attestation is useful can be for 307 remote attestation based on client traffic anomaly detection. Many 308 network infrastructure deployments employ network traffic monitors 309 for anomalous pattern detection. Examples of anomalous patterns 310 detectable in the TLS handshake could be unexpected cipher suite 311 negotiation for a given source/destination pairing. In this case, it 312 may be desirable for a client-enhanced attestation reflecting for 313 instance that an expected offered cipher suite in the client hello 314 message is present or the originating browser integrity is intact 315 (e.g. through a hash over the browser application package). If the 316 network traffic monitor can interpret the atttestation included in 317 the token binding message, then it can verify the attestation and 318 potentially emit alerts based on an unexpected attestation. 320 5. IANA Considerations 322 This memo includes the following requests to IANA. 324 5.1. TLS Extensions Registry 326 This document proposes an update of the TLS "ExtensionType Values" 327 registry. The following addition to the registry is requested: 329 Value: TBD 331 Extension name: token_binding_with_extensions 333 Reference: this document 335 Recommended: Yes 337 5.2. Token Binding Extension for Attestation 339 This document proposes an extension conformant with Section 6.3 of 340 [I-D.ietf-tokbind-protocol], with the following specifics: 342 o Value: TBD, an octet value between 0 and 255 344 o Description: Token binding attestation extension 346 o Specification: This document 348 5.3. Token Binding Attestation Type Registry 350 This document proposes the establishment of an attestation registry 351 for a Token Binding extension focused on attestation. Entries in 352 this registry must include the following fields: 354 o Value: The text string that uniquely identifies the attestation 355 type 357 o Description: A human-readable description of the attestation 359 o Specification: A reference to a specification that defines the 360 attestation data. 362 6. Acknowledgments 364 Thanks to Andrei Popov for his detailed review and recommendations. 366 7. References 368 7.1. Normative References 370 [I-D.greevenbosch-appsawg-cbor-cddl] 371 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 372 definition language (CDDL): a notational convention to 373 express CBOR data structures", draft-greevenbosch-appsawg- 374 cbor-cddl-11 (work in progress), July 2017. 376 [I-D.ietf-tokbind-https] 377 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 378 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 379 tokbind-https-12 (work in progress), January 2018. 381 [I-D.ietf-tokbind-negotiation] 382 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 383 "Transport Layer Security (TLS) Extension for Token 384 Binding Protocol Negotiation", draft-ietf-tokbind- 385 negotiation-10 (work in progress), October 2017. 387 [I-D.ietf-tokbind-protocol] 388 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 389 Hodges, "The Token Binding Protocol Version 1.0", draft- 390 ietf-tokbind-protocol-16 (work in progress), October 2017. 392 [Keystore] 393 Google Inc., "Verifying hardware-backed key pairs with Key 394 Attestation", 395 . 398 [TPMv2] The Trusted Computing Group, "Trusted Platform Module 399 Library, Part 2: Structures", September 2016, 400 . 403 [webauthn] 404 The Worldwide Web Consortium, "Web Authentication: An API 405 for accessing Scoped Credentials", 406 . 408 7.2. Informative References 410 [I-D.birkholz-tuda] 411 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 412 "Time-Based Uni-Directional Attestation", draft-birkholz- 413 tuda-02 (work in progress), July 2016. 415 Authors' Addresses 417 Giridhar Mandyam 418 Qualcomm Technologies Inc. 419 5775 Morehouse Drive 420 San Diego, California 92121 421 USA 423 Phone: +1 858 651 7200 424 Email: mandyam@qti.qualcomm.com 426 Laurence Lundblade 427 Qualcomm Technologies Inc. 428 5775 Morehouse Drive 429 San Diego, California 92121 430 USA 432 Phone: +1 858 658 3584 433 Email: llundbla@qti.qualcomm.com 435 Jon Azen 436 Qualcomm Technologies Inc. 437 5775 Morehouse Drive 438 San Diego, California 92121 439 USA 441 Phone: +1 858 651 9476 442 Email: jazen@qti.qualcomm.com