idnits 2.17.1 draft-latze-tls-tpm-extns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 27, 2009) is 5262 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Latze 3 Internet-Draft U. Ultes-Nitsche 4 Intended status: Experimental University of Fribourg 5 Expires: May 31, 2010 F. Baumgartner 6 Swisscom Schweiz AG 7 November 27, 2009 9 Transport Layer Security (TLS) Extensions for the Trusted Platform 10 Module (TPM) 11 draft-latze-tls-tpm-extns-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 31, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Trusted Platform Modules (TPMs) become more and more widespread in 50 modern desktop and laptop computers and provide secure storage and 51 cryptographic functions. As one nice feature of TPMs is that they 52 can be identified uniquely, they provide a good base for device 53 authentication in protocols like TLS. This document specifies a TLS 54 extension that allows to use TPM certified keys with TLS in order to 55 allow for a secure and comfortable device authentication in TLS. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . . 3 61 3. Certification Process . . . . . . . . . . . . . . . . . . . . . 3 62 4. TLS TPM Extension Type . . . . . . . . . . . . . . . . . . . . 4 63 5. TLS TPM Supplemental Data Handshake Message . . . . . . . . . . 5 64 6. TLS Handshake Using The TPM Extensions . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. Normative References . . . . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 This document aims at specifying a new TLS extension that allows to 74 use TPM certified keys directly with TLS [RFC5246]. TPM is short for 75 Trusted Platform Module and describes a trusted module that provides 76 secure storage and some cryptographic function and has been specified 77 in [TPMMainP1]. The TPM comes with the possibility to create so 78 called Attestation Identity Keys (AIKs) that prove that a platform 79 equipped with a TPM is a given platform. Although those AIKs cannot 80 be used in protocols like TLS without further changes to the 81 protocol, [TPMMainP3] introduces so called certified keys. Certified 82 keys are RSA keys that are certified by other keys, for instance by 83 an AIK. Keys that are certified by an AIK are non migratable which 84 means they remain in the same TPM forever. In order to use those 85 keys with TLS, one has to create a self-signed certificate including 86 the SKAE extension [SKAE], which will be used during the TLS 87 handshake. In order to be able to verify that the key is stored 88 inside a given TPM, the AIK will be send in the supplemental data 89 handshake message. 91 2. Terms and Abbreviations 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 Furthermore, the document uses the following terms and abbreviations: 99 AIK - Attestation Identity Key 101 CA - Certificate Authority 103 Entity - One of the communication end points, be it either client or 104 server. 106 PCA - Privacy CA 108 TLS - Transport Layer Security 110 TPM - Trusted Platform Module 112 3. Certification Process 114 This section describes the process of creating and requesting all the 115 certificates necessary to be used with the TLS TPM extension 116 specified in the next sections. 118 First of all an TPM equipped entity has to request its AIK as 119 specified in [TPMMainP1]. Afterwards, a new non-migratable key has 120 to be created and certified using the AIK. The details about the 121 certification process can be found in [TPMMainP3]. Some details will 122 be repeated here for convenience. 124 The certificate is done using either TPM_CertifyKey or 125 TPM_CertifyKey2 (for details about when to use which function, have a 126 look at [TPMMainP3]). Depending on the key properties, those 127 functions result in either TCPA_CERTIFY_INFO or TCPA_CERTIFY_INFO2 128 structure, whereas the first is compatible to the TPM 1.1 standard 129 [TCGMainSpec]. 131 Now that the entity has an AIK and a certified key structure, a self- 132 signed certificate around the certified key has to be created. As 133 the TCPA_CERTIFY_INFO (or TCPA_CERTIFY_INFO2) structure is needed to 134 verify the binding between AIK and the certified key, that self- 135 signed certificate has to include the Subject Key Attestation 136 Evidence (SKAE) extension defined in [SKAE]. The SKAE extension is 137 an X.509 extension that has been defined to carry the certify info 138 structure returned by TPM_CertifyKey (or TPM_CertifyKey2). 140 The self-signed certificate will be sent during the TLS handshake in 141 the Certificate message whereas the AIK MUST be announced with the 142 TLS TPM extension type and sent in the supplemental data handshake 143 message. 145 4. TLS TPM Extension Type 147 The general TLS extension format has been defined in [RFC5246] and 148 will be repeated here for convenience: 149 struct { 150 ExtensionType extension_type; 151 opaque extension_data<0..2^16-1>; 152 } 154 The new extension types for TPM enabled entities are called 155 client_aik and server_aik: 156 enum { 157 client_aik(TBD), server_aik(TBD), (65535) 158 } ExtensionType 160 This extensions MAY be used in full handshakes as well as in session 161 resumption handshakes. Although the latter does not require a 162 certificate exchange it might happen that the server refuses to 163 accept a resumed session and runs a full handshake instead. In order 164 to be able to do that without interruption, the extensions SHOULD be 165 included also in the session resumption handshake. 167 The extension includes the certify info type the client is able to 168 create and verify: 169 enum { 170 tpm_certify_info(0), tpm_certify_info2(1), (255) 171 } CertifyInfoType 173 The client includes client_aik in order to indicate that he wants to 174 use a self-signed certified key during the handshake and send the AIK 175 in the supplemental data handshake message. If the server receives 176 client_aik, he MUST respond with same client_aik - possibly removing 177 unsupported certify info types or omit the extension in case it is 178 not supported by the server. 180 In case the client wants to authenticate the server also using TPM 181 certified keys, he MUST include server_aik in its extended hello 182 message.The server_aik contains all the certify info types the client 183 is able to verify. If the server receives server_aik and accepts it, 184 he MUST respond with the same server_aik - possibly removing certify 185 info types he cannot create. Otherwise the server omits server_aik. 187 5. TLS TPM Supplemental Data Handshake Message 189 The TLS supplemental data handshake message as defined in [RFC4680] 190 allows to send additional application data during the TLS handshake 191 if it has been announced in a TLS extension. 193 This document defines a new supplemental data type: 194 enum { 195 aik_data(TBD), (65535) 196 } 198 with 199 struct { 200 SupplementalDataType supplemental_data_type; 201 select(SupplementalDataType) { 202 case aik_data: AikData; 203 } 204 } SupplementalData 206 and 207 opaque ASN.1Cert<2^24-1>; 209 struct { 210 ASN.1Cert certificate_list<0..2^24-1>; 211 } AikData; 212 AikData carries the entity's AIK chain. 214 6. TLS Handshake Using The TPM Extensions 216 Figure Figure 1 shows the full TLS handshake with a TPM equipped 217 client: 219 Client Server 221 ClientHello (w/ extensions)---------> 222 ServerHello (w/ extensions) 223 Certificate 224 ServerKeyExchange 225 CertificateRequest* 226 <--------- ServerHelloDone 227 SupplementalData 228 Certificate* 229 ClientKeyExchange 230 CertificateVerify* 231 ChangeCipherSpec 232 Finished ---------> 233 ChangeCipherSpec 234 Finished 236 * indicates optional or situation dependant messages 238 Figure 1: Full TLS Handshake With a TPM Equipped Client 240 Figure Figure 2 shows the full handshake with a TPM equipped server: 242 Client Server 244 ClientHello (w/ extensions)---------> 245 ServerHello (w/ extensions) 246 SupplementalData 247 Certificate 248 ServerKeyExchange 249 CertificateRequest* 250 <--------- ServerHelloDone 251 Certificate* 252 ClientKeyExchange 253 CertificateVerify* 254 ChangeCipherSpec 255 Finished ---------> 256 ChangeCipherSpec 257 Finished 259 * indicates optional or situation dependant messages 261 Figure 2: Full TLS Handshake With a TPM Equipped Server 263 Finally, figure Figure 3 shows the TLS handshakes if both sides make 264 use of certified keys: 266 Client Server 268 ClientHello (w/ extensions)---------> 269 ServerHello (w/ extensions) 270 SupplementalData 271 Certificate 272 ServerKeyExchange 273 CertificateRequest* 274 <--------- ServerHelloDone 275 SupplementalData 276 Certificate* 277 ClientKeyExchange 278 CertificateVerify* 279 ChangeCipherSpec 280 Finished ---------> 281 ChangeCipherSpec 282 Finished 284 * indicates optional or situation dependant messages 286 Figure 3: Full TLS Handshake With TPM Equipped Client and Server 288 The authentication of either client or server is done by verifying 289 the self-signed certificate as well as by verifying the binding 290 between the AIK and the certified key in order to ensure that the key 291 used is really protected by a given TPM. In order to verify the 292 binding, the SKAE extension of the self-signed certificate has to be 293 evaluated using the AIK. 295 There is no need for additional TLS alerts since all the existing 296 certificate related alerts cover possible problems during the entity 297 verification. 299 7. IANA Considerations 301 This document makes the following IANA requests: 303 1. A new registry for certify info types needs to be maintained by 304 IANA. The first two types include tpm_certify_info(0) and 305 tpm_certify_info2(1). Certify info types with values in the 306 inclusive range of 0 to 63 (decimal) are assigned using RFC 5226 307 [RFC5226] Standards Action, whereas values from the inclusive 308 range of 64 to 223 (decimal) are using RFC 2434 Specification 309 Required. Values in the inclusive range of 224 to 255 (decimal) 310 are reserved for RFC 2434 Private Use. 312 2. The values client_aik(TBD) and server_aik(TBD) are assigned from 313 TLS Extension Type Registry [RFC5246]. 315 3. The value aik_data(TBD) is assigned from TLS Supplemental Data 316 Type registry [RFC4680]. 318 8. Security Considerations 320 If an entity certified several keys with the same AIK, somebody who 321 has the AIK and all of the certified keys is able to track that 322 identity. Therefore, the AIK might be seen as sensitive information 323 forcing an implementation to use the double handshake technique. The 324 first handshake requires one or both entities to accept the self- 325 signed certificate since the binding can only be verified during the 326 second protected handhake. 328 9. Acknowledgements 330 The basic idea to use the supplemental data handshake message to 331 supply the AIK was supplied by Sam Hartmann. 333 10. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 339 Data", RFC 4680, October 2006. 341 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 342 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 343 May 2008. 345 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 346 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 348 [SKAE] The Trusted Computing Group, "Subject Key Attestation 349 Evidence Extension", TCG Infrastructure Workinggroup, 350 June 2005. 352 [TCGMainSpec] 353 The Trusted Computing Group, "TCPA Main Specification 354 Version 1.1b", TCG Trusted Platform Module, February 2002. 356 [TPMMainP1] 357 The Trusted Computing Group, "TPM Main Part 1 Design 358 Principles", TCG Trusted Platform Module, July 2007. 360 [TPMMainP3] 361 The Trusted Computing Group, "TPM Main Part 3 Commands", 362 TCG Trusted Platform Module, October 2006. 364 Authors' Addresses 366 Carolin Latze 367 University of Fribourg 368 Boulevard de Perolles 90 369 Fribourg, FR 1700 370 Switzerland 372 Email: carolin.latze@unifr.ch 373 Ulrich Ultes-Nitsche 374 University of Fribourg 375 Boulevard de Perolles 90 376 Fribourg, FR 1700 377 Switzerland 379 Email: uun@unifr.ch 381 Florian Baumgartner 382 Swisscom Schweiz AG 383 Ostermundigenstrasse 93 384 Bern, BE 3006 385 Switzerland 387 Email: florian.baumgartner@swisscom.com