Network Working Group C. Latze Internet-Draft U. Ultes-Nitsche Intended status: Experimental University of Fribourg Expires: February 7, 2011 F. Baumgartner 89grad GmbH August 6, 2010 Transport Layer Security (TLS) Extensions for the Trusted Platform Module (TPM) draft-latze-tls-tpm-extns-02 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 7, 2011. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Latze, et al. Expires February 7, 2011 [Page 1] Internet-Draft tls-tpm-extn August 2010 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 3. Certification Process . . . . . . . . . . . . . . . . . . . . 5 4. TLS TPM Extension Type . . . . . . . . . . . . . . . . . . . . 5 5. TLS TPM Supplemental Data Handshake Message . . . . . . . . . 6 6. TLS Handshake Using The TPM Extensions . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Latze, et al. Expires February 7, 2011 [Page 2] Internet-Draft tls-tpm-extn August 2010 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 functions and has been specified in [TPMMainP1]. TPMs come with the possibility to create so called attestation identity keys (AIKs) that will be signed by a certain certificate authority called Privacy CA resulting in an AIK certificate. The process of signing by the Privacy CA includes verifying that those keys have been generated by a genuine TPM. The private part of the AIK never leaves the TPM, which means that the AIK certificates prove that they belong to a genuine, given TPM. The AIK certificate is a valid X.509 certificate, which can be verified using the standard X.509 verification functions. So if those certificates are used in authentication protocols one can authenticate devices (using their TPM). But, unfortunatly, those keys have some restrictions which makes it impossible to use them in TLS directly: 1. They are restricted to SHA-1 signing, which is a problem to TLS prior to 1.2 2. They only sign data that originates in the TPM, which means that in order to use them with TLS, every data that has to be signed has to originate in the TPM, which would require a lot of changes to the TLS handshake. In order to be able to use something like the AIKs in authentication, the TPM standard propose to define new keys (with the property that the private part never leaves the TPM) and sign them using the AIK. That signing process is defined in [TPMMainP3] and results in a special structure called TCPA_CERTIFY_INFO. That structure proves that a certified key has been signed by a valid AIK, which itself can be verified using standard X.509 verification techniques. Unfortunatly, TCPA_CERTIFY_INFO does not have the same format like X.509. The certified key could be used in TLS directly, but verifying that this key belongs to a given TPM remains an open question. There are several solutions that all rely on the fact, that the AIK certificate proves that this certificate key belongs to a genuine, given TPM: 1. Make it an X.509 certificate signed by the AIK, which would result in a complete X.509 chain, that is easy to verify. This is not possible since the AIK certificate carries the CA:false constraint. Latze, et al. Expires February 7, 2011 [Page 3] Internet-Draft tls-tpm-extn August 2010 2. Make it an X.509 proxy certificate of the AIK. However that is not possible since the subject of the AIK is NULL. Those would be the easy possibilities, but since they do not work, the TCG defined a new X.509 extension to carry the TCPA_CERTIFY_INFO structure called SKAE [SKAE]. Again two possibilities arise to make use of that extension: 1. Generate a new X.509 certificate request around the certified key, include the SKAE extension, and send the request to a CA to sign it. This results in a standard X.509 certificate that can be used for TLS. But if the server wants to ensure that this certificate is bound (which means the private key never leaves the TPM) to a certain genuine TPM, he has to verify the SKAE extension too. That means he has to get the AIK certificate too, which is not part of the chain. The SKAE extension carries a hint where to find that certificate. There has to be some kind of storage for the AIK certificates, that either sends the AIK certificates to all the servers or receives SKAE extensions from servers to validate them. That approach will result in scalability issues. 2. Generate an X.509 self-signed certificate around the certified key including the SKAE extension, use it in the handshake and send the AIK certificate that verifies the SKAE extension within the supplemental data handshake message. This is the approach specified in this document. This document will first explain how the AIK certificates are retrieved in order to allow the reader to fully understand the idea behind AIK certificates. Afterwards the TLS TPM extension as well as the required supplemental data handshake message type will be described. 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 Latze, et al. Expires February 7, 2011 [Page 4] Internet-Draft tls-tpm-extn August 2010 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. 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: Latze, et al. Expires February 7, 2011 [Page 5] Internet-Draft tls-tpm-extn August 2010 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 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: Latze, et al. Expires February 7, 2011 [Page 6] Internet-Draft tls-tpm-extn August 2010 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; 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 Latze, et al. Expires February 7, 2011 [Page 7] Internet-Draft tls-tpm-extn August 2010 Figure Figure 2 shows the full handshake with a TPM equipped server: 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 Latze, et al. Expires February 7, 2011 [Page 8] Internet-Draft tls-tpm-extn August 2010 The authentication of either client or server is done by verifying the self-signed certificate as well as by verifying the binding 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 5226 [RFC5226] 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 February 7, 2011 [Page 9] Internet-Draft tls-tpm-extn August 2010 Furthermore the authors want to thank Bernie Hoeneisen, Kyle Hamilton, Joe Salowey, and Nikos Mavrogiannopoulos for their valuable input, review, and discussions. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental Data", RFC 4680, October 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [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 February 7, 2011 [Page 10] Internet-Draft tls-tpm-extn August 2010 Ulrich Ultes-Nitsche University of Fribourg Boulevard de Perolles 90 Fribourg, FR 1700 Switzerland Email: uun@unifr.ch Florian Baumgartner 89grad GmbH Holligenstrasse 101 Bern, BE 3008 Switzerland Email: florian.baumgartner@89grad.ch Latze, et al. Expires February 7, 2011 [Page 11]