idnits 2.17.1 draft-mandyam-tokbind-attest-07.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 (January 24, 2019) is 1918 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 402, but no explicit reference was found in the text == Unused Reference: 'RFC8473' is defined on line 424, 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') -- 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 (~~), 5 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 Qualcomm Technologies Inc. 4 Intended status: Standards Track L. Lundblade 5 Expires: July 28, 2019 Security Theory LLC 6 J. Azen 7 Qualcomm Technologies Inc. 8 January 24, 2019 10 Attested TLS Token Binding 11 draft-mandyam-tokbind-attest-07 13 Abstract 15 Token binding allows HTTP servers to bind bearer tokens to TLS 16 connections. In order to do this, clients or user agents must prove 17 possession of a private key. However, proof-of-possession of a 18 private key becomes truly meaningful to a server when accompanied by 19 an attestation statement. This specification describes extensions to 20 the existing token binding protocol to allow for attestation 21 statements to be sent along with the related token binding messages. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 28, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Attestation Enhancement to TLS Token Binding Message . . . . 3 59 2.1. KeyStore Attestation . . . . . . . . . . . . . . . . . . 4 60 2.1.1. Verification Procedures . . . . . . . . . . . . . . . 4 61 2.2. TPMv2 Attestation . . . . . . . . . . . . . . . . . . . . 5 62 2.2.1. Verification Procedures . . . . . . . . . . . . . . . 6 63 3. Extension Support Negotiation . . . . . . . . . . . . . . . . 6 64 3.1. Negotiating Token Binding Protocol Extensions . . . . . . 7 65 4. Example - Platform Attestation for Anomaly Detection . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. TLS Extensions Registry . . . . . . . . . . . . . . . . . 8 68 5.2. Token Binding Extensions for Attestation . . . . . . . . 8 69 6. Security and Privacy Considerations . . . . . . . . . . . . . 9 70 6.1. Attestation Privacy Considerations . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 [RFC8471] and [RFC8472] describe a framework whereby servers can 80 leverage cryptographically-bound authentication tokens in part to 81 create uniquely-identifiable TLS bindings that can span multiple 82 connections between a client and a server. Once the use of token 83 binding is negotiated as part of the TLS handshake, an application 84 layer message (the Token Binding message) may be sent from the client 85 to the relying party whose primary purpose is to encapsulate a 86 signature over a value associated with the current TLS session. The 87 payload used for the signature is the token binding public key (see 88 [RFC8471]). Use of the token binding public key allows for 89 generation of the attestation signature once over the lifetime of the 90 public key. 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 [RFC8471], where the extension data 121 conforms to the guidelines of Section 6.3 of the same document. The 122 value of the extension, as required by this same section, is assigned 123 per attestation type. 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 The attestation data will likely include a signature over a challenge 141 (depenting on the attestation type). The challenge can be used to 142 prevent replay of the attestation. However since the attestation is 143 itself part of the token binding message (which has its own anti- 144 replay protection mechanism), the attestation signature need only be 145 generated over a known payload associated with the TLS token binding 146 session - the token binding public key. As a result, the token 147 binding client only needs to send the attestation once during the 148 lifetime of the token binding public key. In other words, if an 149 attestation is included in the token binding message, it should only 150 be sent in the initial token binding message following the creation 151 of the token binding key pair. 153 2.1. KeyStore Attestation 155 KeyStore attestation is relevant to the Android operating system. 156 The Android Keystore mechanism allows for an application (such as a 157 browser implementing the Token Binding stack) to create a key pair, 158 export the public key, and protect the private key in a hardware- 159 backed keystore. The Android Keystore can then be used to verify a 160 keypair using the Keystore Attestation mechanism, which involves 161 signing a payload according to a public key that chains to a root 162 certificate signed by an attestation root key that is specific to the 163 device manufacturer. 165 The octet value of the token binding extension that serves as 166 identifiaction for the Keystore attestation type is requested to be 167 0. 169 KeyStore attestation provides a signature over a payload generated by 170 the application. The payload is a SHA-256 hash of the token binding 171 public key corresponding to the current TLS connection (see 172 Section 3.3 of [RFC8471]). Then the attestation takes the form of a 173 signature, a signature-generation algorithmic identifier 174 corresponding to the COSE algorithm registry ([cose_iana]), and a 175 chain of DER-encoded x.509 certificates: 177 attestation_data = ( 178 alg: int, 179 sig: bytes, 180 x5c: [credCert: bytes, *(caCert: bytes)] 181 ) 183 2.1.1. Verification Procedures 185 The steps at the server for verifying a Token Binding KeyStore 186 Attestation are: 188 o Retrieve token binding public key for the current TLS connection, 189 and compute is SHA-256 hash. 191 o Verify that attestation_data is in the expected CBOR format. 193 o Parse the first certificate listed in x5c and extract the public 194 key and challenge. If the challenge does not match the SHA-256 195 hash of the token binding public key then the attestation is 196 invalid. 198 o If the challenge matches the expected hash of the token binding 199 public key, verify the sig with respect to the extracted public 200 key and algorithm from the previous step. 202 o Verify the rest of the certificate chain up to the root. The root 203 certificate must match the expected root for the device. 205 2.2. TPMv2 Attestation 207 Version 2 of the Trusted Computing Group's Trusted Platform Module 208 (TPM) specification provides for an attestation generated within the 209 context of a TPM. The attestation then is defined as 211 attestation_data = ( 212 alg: int, 213 tpmt_sig: bytes, 214 tpms_attest: bytes, 215 x5c: [credCert: bytes, *(caCert: bytes)] 216 ) 218 The tpmt_sig is generated over a tpms_attest structure signed with 219 respect to the certificate chain provided in the x5c array, and the 220 algorithmic identifier corresponding to the COSE algorithm registry 221 ([cose_iana]). It is derived from the TPMT_SIGNATURE data structure 222 defined in Section 11.3.4 of [TPMv2]. tpms_attest is derived from the 223 TPMS_ATTEST data structure in Section 10.2.8 of [TPMv2], specifically 224 with the extraData field being set to a SHA-256 hash of the token 225 binding public key. 227 The octet value of the token binding extension that serves as 228 identifiaction for the TPMv2 attestation type is requested to be 1. 230 2.2.1. Verification Procedures 232 The steps for verifying a Token Binding TPMv2 Attestation are: 234 o Extract the token binding public key for the current TLS 235 connection. 237 o Verify that attestation_data is in the expected CBOR format. 239 o Parse the first certificate listed in x5c and extract the public 240 key. 242 o Verify the tpms_attest structure,which includes 244 * Verify that the type field is set to TPM_ST_ATTEST_CERTIFY. 246 * Verify that extraData is equivalent to the SHA-256 hash of the 247 token binding public key for the current TLS connection. 249 * Verify that magic is set to the expected TPM_GENERATED_VALUE 250 for the expected command sequence used to generate the 251 attestation. 253 * Verification of additonal TPMS_ATTEST data fields is optional. 255 o Verify tpmt_sig with respect to the public key provided in the 256 first certifcate in x5c, using the algorithm as specified in the 257 sigAlg field (see Sections 11.3.4, 11.2.1.5 and 9.29 of [TPMv2]). 259 3. Extension Support Negotiation 261 Even if the client supports a Token Binding extension, it may not be 262 desirable to send the extension if the server does not support it. 263 The benefits of client-suppression of an extension could include 264 saving of bits "over the wire" or simplified processing of the Token 265 Binding message at the server. Currently, extension support is not 266 communicated as part of the Token Binding extensions to TLS (see 267 [RFC8472]). 269 It is proposed that the Client and Server Hello extensions defined in 270 Sections 3 and 4 of [RFC8472] be extended so that endpoints can 271 communicate their support for specific TokenBinding.extensions. With 272 reference to Section 3, it is recommended that the "token_binding" 273 TLS extension be augmented by the client to include supported 274 TokenBinding.extensions as follows: 276 enum { 277 attestation(0), (255) 278 } TokenBindingExtensions; 280 struct { 281 TB_ProtocolVersion token_binding_version; 282 TokenBindingKeyParameters key_parameters_list<1..2^8-1>; 283 TokenBindingExtensions supported_extensions_list<1..2^8-1> 284 } TokenBindingParameters; 286 The "supported_extensions_list" contains the list of identifiers of 287 all token binding message extensions supported by the client. A 288 server supporting token binding extensions will respond in the server 289 hello with an appropriate "token_binding" extension that includes a 290 "supported_extensions_list". This list must be a subset of the the 291 extensions provided in the client hello. 293 Since a TLS extension cannot itself be extended, the "token_binding" 294 TLS extension cannot be reused. Therefore it is proposed that a new 295 TLS extension be defined - "token_binding_with_extensions". This TLS 296 extension codepoint is identical to the existing "token_binding" 297 extension except for the additional data structures defined above. 299 3.1. Negotiating Token Binding Protocol Extensions 301 The negotation described in Section 4 of [RFC8472] still applies, 302 except now the "token_binding_with_extensions" codepoint would be 303 used if the client supports any token binding extension. In 304 addition, a client can receive a "supported_extensions_list" from the 305 server as part of the server hello. The client must terminate the 306 handshake if the "supported_extensions_list" received from the server 307 is not a subset of the "supported_extensions_list" sent by the client 308 in the client hello. If the server hello list of supported 309 extensions is a subset of the client supported extensions, then the 310 client must only send those extensions specified in the server hello 311 in the Token Binding protocol. If the server hello does not include 312 a "supported_extensions_list", then the client must not send any 313 extensions along with the Token Binding Message. 315 4. Example - Platform Attestation for Anomaly Detection 317 An example of where a platform-based attestation is useful can be for 318 remote attestation based on client traffic anomaly detection. Many 319 network infrastructure deployments employ network traffic monitors 320 for anomalous pattern detection. Examples of anomalous patterns 321 detectable in the TLS handshake could be unexpected cipher suite 322 negotiation for a given source/destination pairing. In this case, it 323 may be desirable for a client-enhanced attestation reflecting for 324 instance that an expected offered cipher suite in the client hello 325 message is present or the originating browser integrity is intact 326 (e.g. through a hash over the browser application package). If the 327 network traffic monitor can interpret the atttestation included in 328 the token binding message, then it can verify the attestation and 329 potentially emit alerts based on an unexpected attestation. 331 5. IANA Considerations 333 This memo includes the following requests to IANA. 335 5.1. TLS Extensions Registry 337 This document proposes an update of the TLS "ExtensionType Values" 338 registry. The following addition to the registry is requested: 340 Value: TBD 342 Extension name: token_binding_with_extensions 344 Reference: this document 346 Recommended: Yes 348 5.2. Token Binding Extensions for Attestation 350 This document proposes two extensions conformant with Section 6.3 of 351 [RFC8471], with the following specifics: 353 Androoid Keystore Attestation: 355 o Value: 0 357 o Description: Android Keystore Attestation 359 o Specification: This document 361 TPM v2 Attestation: 363 o Value: 1 365 o Description: TPMv2 Attestation 367 o Specification: This document 369 6. Security and Privacy Considerations 371 The security and privacy considerations provided in Section 7 of 372 [RFC8471] are applicable to the attestation extensions proposed in 373 this document. Additional considerations are provided in this 374 section. 376 6.1. Attestation Privacy Considerations 378 The root signing key for the certificate chain used in verifying an 379 attestation can be unique to the device. As a result, this can be 380 used to track a device and/or end user. This potential privacy issue 381 can be mitigated by the use of batch keys as an alternative to unique 382 keys, or by generation of origin-specific attestation keys. 384 The attestation data may also contain device-specific identifiers, or 385 information that can be used to fingerprint a device. Sensitive 386 information can be excluded from the attestation data when this is a 387 concern. 389 7. Acknowledgments 391 Thanks to Andrei Popov for his detailed review and recommendations. 393 8. References 395 8.1. Normative References 397 [cose_iana] 398 Internet Assigned Numbers Authority, "COSE Algorithms", 399 . 402 [I-D.greevenbosch-appsawg-cbor-cddl] 403 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 404 definition language (CDDL): a notational convention to 405 express CBOR data structures", draft-greevenbosch-appsawg- 406 cbor-cddl-11 (work in progress), July 2017. 408 [Keystore] 409 Google Inc., "Verifying hardware-backed key pairs with Key 410 Attestation", 411 . 414 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 415 "The Token Binding Protocol Version 1.0", RFC 8471, 416 DOI 10.17487/RFC8471, October 2018, 417 . 419 [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport 420 Layer Security (TLS) Extension for Token Binding Protocol 421 Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 422 2018, . 424 [RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and 425 J. Hodges, "Token Binding over HTTP", RFC 8473, 426 DOI 10.17487/RFC8473, October 2018, 427 . 429 [TPMv2] The Trusted Computing Group, "Trusted Platform Module 430 Library, Part 2: Structures", September 2016, 431 . 434 [webauthn] 435 The Worldwide Web Consortium, "Web Authentication: An API 436 for accessing Scoped Credentials", 437 . 439 8.2. Informative References 441 [I-D.birkholz-tuda] 442 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 443 "Time-Based Uni-Directional Attestation", draft-birkholz- 444 tuda-02 (work in progress), July 2016. 446 Authors' Addresses 448 Giridhar Mandyam 449 Qualcomm Technologies Inc. 450 5775 Morehouse Drive 451 San Diego, California 92121 452 USA 454 Phone: +1 858 651 7200 455 Email: mandyam@qti.qualcomm.com 457 Laurence Lundblade 458 Security Theory LLC 460 Email: lgl@island-resort.com 461 Jon Azen 462 Qualcomm Technologies Inc. 463 5775 Morehouse Drive 464 San Diego, California 92121 465 USA 467 Phone: +1 858 651 9476 468 Email: jazen@qti.qualcomm.com