Network Working Group C. Latze Internet-Draft U. Ultes-Nitsche Intended status: Experimental University of Fribourg Expires: April 10, 2010 F. Baumgartner Swisscom Schweiz AG October 7, 2009 Transport Layer Security (TLS) Extensions for the Trusted Platform Module (TPM) draft-latze-tls-tpm-extns-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 10, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Latze, et al. Expires April 10, 2010 [Page 1] Internet-Draft tls-tpm-extn October 2009 Abstract Trusted Platform Modules (TPMs) become more and more widespread in modern desktop and laptop computers and provide secure storage and cryptographic functions. As one nice feature of TPMs is that they can be identified uniquely, they provide a good base for device authentication in protocols like TLS.This document specifies a TLS extension that allows to use TPM certified keys with TLS in order to allow for a secure and comfortable device authentication in TLS. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . . 3 3. Certification Process . . . . . . . . . . . . . . . . . . . . . 3 4. TLS TPM Extension Type . . . . . . . . . . . . . . . . . . . . 4 5. TLS TPM Supplemental Data Handshake Message . . . . . . . . . . 5 6. TLS Handshake Using The TPM Extensions . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Latze, et al. Expires April 10, 2010 [Page 2] Internet-Draft tls-tpm-extn October 2009 1. Introduction This document aims at specifying a new TLS extension that allows to use TPM certified keys directly with TLS [RFC5246]. TPM is short for Trusted Platform Module and describes a trusted module that provides secure storage and some cryptographic function and has been specified in [TPMMainP1]. The TPM comes with the possibility to create so called Attestation Identity Keys (AIKs) that prove that a platform equipped with a TPM is a given platform. Although those AIKs cannot be used in protocols like TLS without further changes to the protocol, [TPMMainP3] introduces so called certified keys. Certified keys are RSA keys that are certified by other keys, for instance by an AIK. Keys that are certified by an AIK are non migratable which means they remain in the same TPM forever. In order to use those keys with TLS, one has to create a self-signed certificate including the SKAE extension [SKAE], which will be used during the TLS handshake. In order to be able to verify that the key is stored inside a given TPM, the AIK will be send in the supplemental data handshake message. 2. Terms and Abbreviations The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Furthermore, the document uses the following terms and abbreviations: AIK - Attestation Identity Key CA - Certificate Authority Entity - One of the communication end points, be it either client or server. PCA - Privacy CA TLS - Transport Layer Security TPM - Trusted Platform Module 3. Certification Process This section describes the process of creating and requesting all the certificates necessary to be used with the TLS TPM extension specified in the next sections. Latze, et al. Expires April 10, 2010 [Page 3] Internet-Draft tls-tpm-extn October 2009 First of all an TPM equipped entity has to request its AIK as specified in [TPMMainP1]. Afterwards, a new non-migratable key has to be created and certified using the AIK. The details about the certification process can be found in [TPMMainP3]. Some details will be repeated here for convenience. The certificate is done using either TPM_CertifyKey or TPM_CertifyKey2 (for details about when to use which function, have a look at [TPMMainP3]). Depending on the key properties, those functions result in either TCPA_CERTIFY_INFO or TCPA_CERTIFY_INFO2 structure, whereas the first is compatible to the TPM 1.1 standard [TCGMainSpec]. Now that the entity has an AIK and a certified key structure, a self- signed certificate around the certified key has to be created. As the TCPA_CERTIFY_INFO (or TCPA_CERTIFY_INFO2) structure is needed to verify the binding between AIK and the certified key, that self- signed certificate has to include the Subject Key Attestation Evidence (SKAE) extension defined in [SKAE]. The SKAE extension is an X.509 extension that has been defined to carry the certify info structure returned by TPM_CertifyKey (or TPM_CertifyKey2). The self-signed certificate will be sent during the TLS handshake in the Certificate message whereas the AIK MUST be announced with the TLS TPM extension type and sent in the supplemental data handshake message. 4. TLS TPM Extension Type The general TLS extension format has been defined in [RFC5246] and will be repeated here for convenience: struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } The new extension types for TPM enabled entities are called client_aik and server_aik: enum { client_aik(TBD), server_aik(TBD), (65535) } ExtensionType This extensions MAY be used in full handshakes as well as in session resumption handshakes. Although the latter does not require a certificate exchange it might happen that the server refuses to accept a resumed session and runs a full handshake instead. In order to be able to do that without interruption, the extensions SHOULD be Latze, et al. Expires April 10, 2010 [Page 4] Internet-Draft tls-tpm-extn October 2009 included also in the session resumption handshake. The extension includes the certify info type the client is able to create and verify: enum { tpm_certify_info(0), tpm_certify_info2(1), (255) } CertifyInfoType The client includes client_aik in order to indicate that he wants to use a self-signed certified key during the handshake and send the AIK in the supplemental data handshake message. If the server receives client_aik, he MUST respond with same client_aik - possibly removing unsupported certify info types or omit the extension in case it is not supported by the server. In case the client wants to authenticate the server also using TPM certified keys, he MUST include server_aik in its extended hello message.The server_aik contains all the certify info types the client is able to verify. If the server receives server_aik and accepts it, he MUST respond with the same server_aik - possibly removing certify info types he cannot create. Otherwise the server omits server_aik. 5. TLS TPM Supplemental Data Handshake Message The TLS supplemental data handshake message as defined in [RFC4680] allows to send additional application data during the TLS handshake if it has been announced in a TLS extension. This document defines a new supplemental data type: enum { aik_data(TBD), (65535) } with struct { SupplementalDataType supplemental_data_type; select(SupplementalDataType) { case aik_data: AikData; } } SupplementalData and opaque ASN.1Cert<2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } AikData; Latze, et al. Expires April 10, 2010 [Page 5] Internet-Draft tls-tpm-extn October 2009 AikData carries the entity's AIK chain. 6. TLS Handshake Using The TPM Extensions Figure Figure 1 shows the full TLS handshake with a TPM equipped client: Client Server ClientHello (w/ extensions)---------> ServerHello (w/ extensions) Certificate ServerKeyExchange CertificateRequest* <--------- ServerHelloDone SupplementalData Certificate* ClientKeyExchange CertificateVerify* ChangeCipherSpec Finished ---------> ChangeCipherSpec Finished * indicates optional or situation dependant messages Figure 1: Full TLS Handshake With a TPM Equipped Client Figure Figure 2 shows the full handshake with a TPM equipped server: Latze, et al. Expires April 10, 2010 [Page 6] Internet-Draft tls-tpm-extn October 2009 Client Server ClientHello (w/ extensions)---------> ServerHello (w/ extensions) SupplementalData Certificate ServerKeyExchange CertificateRequest* <--------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* ChangeCipherSpec Finished ---------> ChangeCipherSpec Finished * indicates optional or situation dependant messages Figure 2: Full TLS Handshake With a TPM Equipped Server Finally, figure Figure 3 shows the TLS handshakes if both sides make use of certified keys: Client Server ClientHello (w/ extensions)---------> ServerHello (w/ extensions) SupplementalData Certificate ServerKeyExchange CertificateRequest* <--------- ServerHelloDone SupplementalData Certificate* ClientKeyExchange CertificateVerify* ChangeCipherSpec Finished ---------> ChangeCipherSpec Finished * indicates optional or situation dependant messages Figure 3: Full TLS Handshake With TPM Equipped Client and Server The authentication of either client or server is done by verifying the self-signed certificate as well as by verifying the binding Latze, et al. Expires April 10, 2010 [Page 7] Internet-Draft tls-tpm-extn October 2009 between the AIK and the certified key in order to ensure that the key used is really protected by a given TPM. In order to verify the binding, the SKAE extension of the self-signed certificate has to be evaluated using the AIK. There is no need for additional TLS alerts since all the existing certificate related alerts cover possible problems during the entity verification. 7. IANA Considerations This document makes the following IANA requests: 1. A new registry for certify info types needs to be maintained by IANA. The first two types include tpm_certify_info(0) and tpm_certify_info2(1). Certify info types with values in the inclusive range of 0 to 63 (decimal) are assigned using RFC 2434 [RFC2434] Standards Action, whereas values from the inclusive range of 64 to 223 (decimal) are using RFC 2434 Specification Required. Values in the inclusive range of 224 to 255 (decimal) are reserved for RFC 2434 Private Use. 2. The values client_aik(TBD) and server_aik(TBD) are assigned from TLS Extension Type Registry [RFC5246]. 3. The value aik_data(TBD) is assigned from TLS Supplemental Data Type registry [RFC4680]. 8. Security Considerations If an entity certified several keys with the same AIK, somebody who has the AIK and all of the certified keys is able to track that identity. Therefore, the AIK might be seen as sensitive information forcing an implementation to use the double handshake technique. The first handshake requires one or both entities to accept the self- signed certificate since the binding can only be verified during the second protected handhake. 9. Acknowledgements The basic idea to use the supplemental data handshake message to supply the AIK was supplied by Sam Hartmann. Latze, et al. Expires April 10, 2010 [Page 8] Internet-Draft tls-tpm-extn October 2009 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental Data", RFC 4680, October 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [SKAE] The Trusted Computing Group, "Subject Key Attestation Evidence Extension", TCG Infrastructure Workinggroup, June 2005. [TCGMainSpec] The Trusted Computing Group, "TCPA Main Specification Version 1.1b", TCG Trusted Platform Module, February 2002. [TPMMainP1] The Trusted Computing Group, "TPM Main Part 1 Design Principles", TCG Trusted Platform Module, July 2007. [TPMMainP3] The Trusted Computing Group, "TPM Main Part 3 Commands", TCG Trusted Platform Module, October 2006. Authors' Addresses Carolin Latze University of Fribourg Boulevard de Perolles 90 Fribourg, FR 1700 Switzerland Email: carolin.latze@unifr.ch Latze, et al. Expires April 10, 2010 [Page 9] Internet-Draft tls-tpm-extn October 2009 Ulrich Ultes-Nitsche University of Fribourg Boulevard de Perolles 90 Fribourg, FR 1700 Switzerland Email: uun@unifr.ch Florian Baumgartner Swisscom Schweiz AG Ostermundigenstrasse 93 Bern, BE 3006 Switzerland Email: florian.baumgartner@swisscom.com Latze, et al. Expires April 10, 2010 [Page 10]