Network Working Group A. Pastor Internet-Draft D. Lopez Intended status: Experimental Telefonica I+D Expires: September 21, 2016 A. Shaw Hewlett Packard Labs March 20, 2016 Remote Attestation Procedures for virtualized NSFs (vNSFs) through the I2NSF Security Controller draft-pastor-i2nsf-vnsf-attestation-02 Abstract This document describes the procedures a user can follow to assess the trust on a virtualized NSF and its user-defined configuration through the I2NSF Security Controller. The procedure to assess trustworthiness is based on a remote attestation of the virtualization platform and the vNSFs running on it performed through a Trusted Platform Module (TPM) invoked by the Security Controller. 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 September 21, 2016. Copyright Notice Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect Pastor, et al. Expires September 21, 2016 [Page 1] Internet-Draft Remote Attestation for vNFs March 2016 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Establishing User Trust . . . . . . . . . . . . . . . . . . . 4 3.1. First Step: User-Agnostic Attestation . . . . . . . . . . 5 3.2. Second Step: User-Specific Attestation . . . . . . . . . . 5 3.3. Trusted Computing . . . . . . . . . . . . . . . . . . . . 6 4. vNSF Attestation Principles . . . . . . . . . . . . . . . . . 8 4.1. Requirements for a Trusted vNSF Platform . . . . . . . . . 9 4.1.1. Trusted Boot . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Remote Attestation Service . . . . . . . . . . . . . . 10 4.1.3. Secure Boot . . . . . . . . . . . . . . . . . . . . . 11 5. Remote Attestation Procedures . . . . . . . . . . . . . . . . 12 5.1. Trusted Channel with the Security Controller . . . . . . . 13 5.2. Security Controller Attestation . . . . . . . . . . . . . 14 5.3. Virtual Platform Attestation . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Pastor, et al. Expires September 21, 2016 [Page 2] Internet-Draft Remote Attestation for vNFs March 2016 1. Introduction As described in [I-D.pastor-i2nsf-merged-use-cases], when virtualization is applied to the NSF environment (vNSF) it implies several additional concerns in security. The most relevant threats associated with a security virtual platform are: o An unknown/unauthorized user can try to impersonate another user that can legitimately access virtualized NSF services. This attack may lead to accessing the policies and applications of the attacked user or to generate network traffic outside a the security functions with a falsified identity. o An authorized user may misuse assigned privileges to alter the network traffic processing of other users in the virtualization platform. This can become especially serious when such a user has administration privileges granted by the virtualization provider, the ISP or the local network operator. o A user may try to install malformed elements (policy or application), trying to directly take the control of a NSF or virtualization platform, for example by exploiting a vulnerability on one of the functions or may try to intercept or modify the traffic of other users in the same platform. o A malicious virtualization provider can modify the software running on it (the operating system or a concrete vNSF) to alter the behaviour of the latter. This event has a high impact on all users accessing vNSFs as the virtualization provider has the highest level of privilege on the software in execution. o A user with physical access to the virtualization platform can modify the behavior of hardware components, or the components themselves. Furthermore, it can access a serial console (most devices offer this interface for maintenance reasons) to access the NSF software with the same level of privilege of the virtualization provider. Mutual authentication between the user and the vNSF environment and, what is more important, the attestation of the elements in the vNSF environment by users could address these threats to an acceptable level of risk. In particular: o User impersonation will be minimized by mutual authentication, and since appropriate records of such authentications will be made available, events will be suitable for auditing in the case of an incident. Pastor, et al. Expires September 21, 2016 [Page 3] Internet-Draft Remote Attestation for vNFs March 2016 o Attestation of the vNSF environment, especially when performed periodically, will allow users to detect the alteration of the processing elements, or the installation of malformed elements, and mutual authentication will provide again an audit trail. o Attestation relying on independent Trusted Third Parties will alleviate the impact of malicious activity on the side of the virtualization provider by issuing the appropriate alarms in the event of vNSF environment manipulation. o While it is true that any virtual environment is vulnerable to malicious activity with full physical access (and this is obviously beyond the scope of this document), the application of attestation mechanisms raises the degree of physical control necessary to perform an untraceable malicious modification of the environment. The user can have a proof that their vNSFs and policies are correctly (from the user point of view) enforced by the Security Controller. Taking into account the threats identified above, this document first identifies the user expectations regarding remote trust establishment, briefly analyzes Trusted Computing techniques, and finally describes the proposed mechanisms for remote establishment of trust through the Security Controller. 2. Requirements Language 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 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Establishing User Trust From a high-level standpoint, in a virtualized I2NSF platform, the user connects and authenticates to the Security Controller, which then initialises the user's vNSFs and policies. Afterwards, the user traffic reaches the Internet via the virtualized platform which hosts the user's vNSFs. The user's expectations of the platform behavior are thus twofold: o The user traffic will be treated according to the user-specified vNSFs and policies, and no other processing will be performed by Pastor, et al. Expires September 21, 2016 [Page 4] Internet-Draft Remote Attestation for vNFs March 2016 the Security Controller or the platform itself (e.g. traffic eavesdropping). o Each vNSF (and its corresponding policies) behaves as configured by the user. We will refer to the attestation of these two expectations as the "user-agnostic attestation" and the "user-specific attestation". Trusted Computing techniques play a key role in addressing this expectations. 3.1. First Step: User-Agnostic Attestation This is the first interaction between a user and a Security Controller: the user wants to attest that he is connected to a genuine Security Controller before he continues with the authentication. In this context, two properties characterise the genuineness of the Security Controller: 1. That the identity of the Security Controller is correct 2. That it will process the user's credentials and set up the user vNSFs and policies properly. Once these two properties are proven to the user, the user knows that their credentials will only be used by the Security Controller to set up the execution platform for their vNSFs. 3.2. Second Step: User-Specific Attestation From the security enforcement point of view, the user agnostic attestation focuses on the initialization of the execution platform for the vNSFs. This second step aims to prove to the user that their security is enforced accordingly with their choices (i.e. vNSFs and policies). The attestation can be performed at the initialization of the vNSFs, before the user traffic is processed by the vNSFs, or during the execution of the vNSFs. Support of static vNSF attestation is REQUIRED for a Security Controller managing vNSFs, and MUST be performed before the user traffic is redirected through any set of vNSFs. The Security Controller MUST provide a proof to the user that the instantiated vNSFs and policies are the ones chosen. Additionally to the vNSFs instantiation attestation, a continuous attestation of the vNSFs execution MAY be required by a user to ensure their security. Pastor, et al. Expires September 21, 2016 [Page 5] Internet-Draft Remote Attestation for vNFs March 2016 3.3. Trusted Computing In a nutshell, Trusted Computing (TC) aims at answering the following question: "As a user or administrator, how can I have some assurance that a computing system is behaving as it should?". The major enterprise level TC initiative is the Trusted Computing Group [TCG], which has been established for more than a decade, that primarily focuses on developing TC for commodity computers (servers, desktops, laptops, etc.). The overall scheme proposed by TCG for using Trusted Computing is based on a step-by-step extension of trust, called a Chain of Trust. It uses a transitive mechanism: if a user can trust the first execution step and each step correctly attests the next executable software for trustworthiness, then a user can trust the system. Pastor, et al. Expires September 21, 2016 [Page 6] Internet-Draft Remote Attestation for vNFs March 2016 +-----------+ | | extends PCR | Platform +------------------------+ | | | +-----^-----+ | | | |measures | +-----------+ | | Security | extends PCR | | +---------------------+ | | Controller| | | +-----^-----+ | | | | | |measures +-v--v----------+ +-----------+ | | | | extends PCR | | | Bootloader+-------------------> Root of Trust | | | | | +-----^-----+ | | | +-^--^----------+ |measures | | +-----------+ | | | | extends PCR | | | BIOS +---------------------+ | | | | +-----^-----+ | | | |measures | +-----------+ | | Bootblock | extends PCR | | (CRTM) +------------------------+ | | +-----------+ Figure 1: Applying Trusted Computing Effectively, during the loading of each piece of software, the integrity of each piece of software is measured and stored inside a log that reflects the different boot stages, as illustrated in the figure above. Later, at the request of a user, the platform can present this log (signed with the unique identity of the platform), which can be checked to prove the platform identity and attest the state of the system. The base element for the extension of the Chain of Trust is called the Core Root of Trust. The TCG has created a standard for the the design and usage of a secure cryptoprocessor to address the storage of keys, general Pastor, et al. Expires September 21, 2016 [Page 7] Internet-Draft Remote Attestation for vNFs March 2016 secrets, identities and platform integrity measurements: the Trusted Platform Module (TPM). When using a TPM as a root of trust, measurements of the software stack are stored in special on-board Platform Configuration Registers (PCRs) on a discrete TPM. There are normally a small number of PCRs that can be used for storing measurements, however it is not possible to directly write to a PCR; instead measurements must be stored using a process called Extending PCRs. The extend operation can update a PCR by producing a global hash of the concatenated values of the previous PCR value with the new measurement value. The Extend operation allows for an unlimited number of measurements to be captured in a single PCR, since the size of the value is always the same and it retains a verifiable ordered chain of all the previous measurements. Attestation of the virtualization platform will thus rely on a process of measuring the booted software and storing a chained log of measurements, typically referred to as Trusted Boot. The user will either validate the signed set of measurements with a trusted third party verifier who will assess whether the software configuration is trusted, or the user can check for themselves against their own set of reference digest values (measurements) that they have obtained a priori, and having already known the public endorsement key of the remote Root of Trust. Trusted Boot should not be confused with a different mechanism known as "Secure Boot", as they both are designed to solve different problems. Secure Boot is a mechanism for a platform owner to lock a platform to only execute particular software. Software components that do not match the configuration digests will not be loaded or executed. This mechanism is particularly useful in preventing bootkits from successfully infecting a platform on reboot. A common standard for implementing Secure Boot is described in [UEFI]. Secure Boot only enforces a particular configuration of software, it does not allow a user to attest or quote for a series of measurements. 4. vNSF Attestation Principles As a general principle, in the I2NSF environment users directly interact with the Security Controller, which will become the essential element to implement the measurements described above, relaying on a TPM for the Root of Trust. Given the role of the Security Controller, a mutual authentication of users and the Security Controller MUST be performed, establishing the desired level of assurance. This level of assurance will determine Pastor, et al. Expires September 21, 2016 [Page 8] Internet-Draft Remote Attestation for vNFs March 2016 how stringent are the requirements for authentication (in both directions), and how detailed the collected measurements and their verification will be. Furthermore, the virtualization platform MUST run a TPM, able to collect measurements of the platform itself, the Security Controller, and the vNSFs being executed. The Security Controller MUST make the attestation measurements available to the user, directly or by means of a Trusted Third Party. NOTE: The reference to results from WGs such as NEA and SACM is currently under consideration and will be included here. Upon successful authentication, a trusted connection with the Security Controller (or an endpoint designated by it) SHALL be established. All traffic to and from the virtualized NSF environment will flow through this connection. The connection is intended not only to be secure, but trusted in the sense that it SHOULD be bound to the mutual authentication between user and Security Controller, with the only exception of the application of the lowest levels of assurance, in which case the user MUST be made aware of this circumstance. 4.1. Requirements for a Trusted vNSF Platform Although a discrete hardware TPM is RECOMMENDED, relaxed alternatives (such as embedded CPU TPMs, or memory and execution isolation mechanisms) MAY also be applied when the required level of assurance is lower. This reduced level of assurance MUST be communicated to the user by the Security Controller during the initial mutual authentication phase. 4.1.1. Trusted Boot All users who interact with a Security Controller MUST be able to: a. Identify the Security Controller based on the public key of a Root of Trust. b. Retrieve a set of measurements of all the base software the Security Controller has booted (i.e. the vNSF platform). This requires that firmware and software MUST be measured before loading, with the resulting value being used to extend the appropriate PCR register. The general usage of PCRs by each software component SHOULD conform to open standards, in order to make verifying attestation reports interoperable, as it is the case of TCG Generic Server Specification [TCGGSS]. The following list describes which PCR registers SHOULD be used Pastor, et al. Expires September 21, 2016 [Page 9] Internet-Draft Remote Attestation for vNFs March 2016 during a Trusted Boot process: o PCRs 00-03: for use by the CRTM (Initial EEPROM or PC BIOS) o PCRs 04-07: for use by the bootloader stages o PCRs 08-15: for use by the booted base system As well as for providing a signed audit log of boot measurements, the PCR values can also be used as an identity for dynamically decrypting encrypted blobs on the platform (such as encryption keys or configurations that belong to operating system components). Software can choose to submit pieces of data to be encrypted by the Root of Trust (which has its own private asymmetric key and PCR registers) and only have it decrypted based on a criteria. This criteria can be that the platform booted into a particular state (e.g. a set of PCR values). Once the desired criteria is described and the sensitive data is encrypted by the root of trust, the data has been sealed to that platform state. The sealed data will only be decrypted when the platform measurements held in the root of trust match the particular state. Trusted Boot requires the use of a root of trust for safely storing measurements and secrets. Since the Root of Trust is self-contained and isolated from all the software that is measured, it is able to produce a signed set of platform measurements to a local or remote user. Trusted Boot however does not provide enforcement of a configuration, since the root of trust is a passive component not in the execution path, and is solely used for safe independent storage of secrets and platform measurements. It will respond to attestation requests with the exact measurements that were made during the software boot process. Sealing and unsealing of sensitive data is also a strong advantage of Trusted Boot, since it prevents leakage of secrets in the event of an untrusted software configuration. 4.1.2. Remote Attestation Service A service MUST be present for providing signed attestation report (e.g. the measurements) from the Root of Trust (RoT) to the end user. In case of failure to communicate with the service, the end user MUST assume the service cannot be trusted and seek an alternative Security Controller. Since some forms of RoT require serialised access (i.e. due to slow access to hardware), latency of getting an attestation report could increase with simultaneous requests. Simultaneous requests could occur if multiple Trusted Third Parties (TTP) request for attestation reports at the same time. This MAY be improved through batching of Pastor, et al. Expires September 21, 2016 [Page 10] Internet-Draft Remote Attestation for vNFs March 2016 requests, in a special manner. In a typical remote attestation protocol, the user sends a random number ("nonce") to the RoT in order to detect any replay attacks. Therefore, cacheing of an attestation report does not work, since there is the possibility that it may not be a fresh report. The solution is to batch the nonce for each requestor until the RoT is ready for creating the attestation report. The report will be signed by the embedded identity of the RoT to provide data integrity and authenticity, and the report will include all the nonces of the requestors. Regardless of the number of the number of nonces included, the requestor verifying the attestation report MUST check to see if the requestor's nonce was included in order to detect replay attacks. In addition to the attestation report containing PCRs, an additional report known as an SML (Secure Measurement Log) can be returned to the requestor to provide more information on how to verify the report (e.g. how to reproduce the PCR values). The integrity of the SML is protected by a PCR measurement in the RoT. An example of an open standard for responses is [TCGIRSS]. Further details are discussed in Section 5.2. As part of initial contact, the Security Controller MAY present a list of external TTPs that the requestor can use to verify it. However, the user MUST assess whether these external verifiers can be trusted. The user can also choose to ignore or discard the presented verifiers. Finally, to prevent malicious relaying of attestation reports from a different host, the authentication material of the secure channel (e.g. TLS, IPSec, etc.) SHOULD be bound to the RoT and verified by the connected user, unless the lowest levels of assurance have been chosen and an explicit warning made to the user. This is also addressed in Section 5.1. 4.1.3. Secure Boot Using a mechanism such as Secure Boot helps provide strong prevention of software attacks. Furthermore, in combination with a hardware- based TPM, Secure Boot can provide some resilience to physical attacks (e.g. preventing a class of offline attacks and unauthorised system replacement). For vNSF platform providers, it is RECOMMENDED that Secure Boot is employed wherever possible with an appropriate firmware update mechanism, due to the possible threat of software/ firmware modifications in either public places or privately with inside attackers. Pastor, et al. Expires September 21, 2016 [Page 11] Internet-Draft Remote Attestation for vNFs March 2016 5. Remote Attestation Procedures The establishment of trust with the Security Controller and the vNSF platform consists of three main phases, which need to be coordinated by the user through a trusted application executed by a trusted network-attached device: 1. Trusted channel with the Security Controller. During this phase, the user securely connects to the Security Controller to avoid that user data can be tampered with or modified by an attacker if the network cannot be considered trusted. The establishment of the trusted channel is completed after the next step. 2. Security Controller attestation. During this phase, the user verifies that the Security Controller components responsible for handling the user's credentials and for the isolation with respect to other potential users are behaving correctly. Furthermore, it is verified that the identity of the platform attested is the same of the one presented by the Security Controller during the establishment of the secure connection. 3. Virtual platform attestation. During this step, that can be repeated periodically until the user connection is terminated, the Security Controller verifies the integrity of the elements composing the user vNSF platform. The components responsible for this task have been already attested during the previous phase. +----------+ 3. Attestation | Trusted | 3. Attestation +--------------------> Third <----------+ | | Party | | | +----------+ +--------+-------+ +----------v-------+ | +-----v-----+ | | User Application | | | Security | | | | 1. Trusted channel | | Controller| | | 2. Get Cert +------+ handshake +---------> | | | 3. Attestation | | +-----------+ | | 4. Cont.handshake| | | | | | | | | | +---------+ | | | | | vNSF | | | | | +---------+ | +------------------+ +----------------+ Pastor, et al. Expires September 21, 2016 [Page 12] Internet-Draft Remote Attestation for vNFs March 2016 Figure 2: Steps for remote attestation In the following each step, as depicted in the above figure, is discussed in more detail. 5.1. Trusted Channel with the Security Controller A trusted channel is an enhanced version of the secured channel that, differently from the latter, requires the integrity verification of the contacted endpoint by the other peer during the initial handshake. However, simply transmitting the integrity measurements over the channel does not guarantee that the platform verified is the channel endpoint. The public key or the certificate for the secure communication MUST be included as part of the measurements presented by the contacted endpoint during the remote attestation. This way, a malicious platform cannot relay the attestation to another platform as its certificate will not be present in the measurements list of the genuine platform. In addition, the problem of a potential loss of control of the private key must be addressed (a malicious endpoint could prove the identity of the genuine endpoint). This is done by defining a long- lived Platform Property Certificate. Since this certificate connects the platform identity to the AIK public key, an attacker cannot use a stolen private key without revealing his identity, as it may use the certificate of the genuine endpoint but cannot create a quote with the AIK of the other platform. Finally, since the platform identity can be verified from the Platform Property Certificate, the information in the certificate to be presented during the establishment of a secure communication are redundant. This allows for the use of self-signed certificates, what would simplify operational procedures in virtualized environments, especially when they are multi-tenant. Thus, in place of certificates signed by trusted CAs, the use of self-signed certificates (which still need to be included in the measurements list) is RECOMMENDED. The steps required for the establishment of a trusted channel with the Security Controller are as follows: 1. The user application begins the trusted channel handshake with the selected Security Controller. 2. The certificate of the Security Controller is collected and used for verifying the binding of the attestation result to the contacted endpoint. Pastor, et al. Expires September 21, 2016 [Page 13] Internet-Draft Remote Attestation for vNFs March 2016 3. The user application performs the remote attestation protocol with the Security Controller, either directly or with the help of a Trusted Third Party. The Trusted Third Party MAY perform the verification of attestation quotes on behalf of multiple user applications. 4. If the result of the attestation is positive, the application continues the handshake and establishes the trusted channel. Otherwise, it closes the connection. 5.2. Security Controller Attestation During the establishment of the trusted channel, the user attests the Security Controller by verifying the identity of the contacted endpoint and its integrity. Initially the Security Controller measures all the hardware and software components involved in the boot process of the vNSF platform, in order to build the chain of trust. Since a user terminal may not have enough capabilities to perform the integrity verification of a Security Controller the user application MAY request the status of a Security Controller to a Trusted Third Party (TTP), which is in charge of communicating with it. This choice has the additional advantage of preventing an attacker from easily determining the software running at the Security Controller. If the user application directly performs the remote attestation it performs the following steps: 1. Ask the Security Controller to generate an integrity report with the format defined in [TCGIRSS]. 2. The Security Controller retrieves the measurements and asks the TPM to sign the PCRs with an Attestation Identity Key (AIK). This signature provides the user with the evidence that the measurements received belong to the Security Controller being attested. 3. Once the integrity report has been generated it is sent back to the user application. 4. The user application first checks if the integrity report is valid by verifying the quote and the certificate associated to the AIK, and then determines if the Security Controller is behaving as expected, i.e. its software has not been compromised and isolation among the users connected to it is enforced. As part of the verification, the application also checks that the digest of the certificate, received during the trusted channel Pastor, et al. Expires September 21, 2016 [Page 14] Internet-Draft Remote Attestation for vNFs March 2016 handshake, is present among measurements. If the user application is running on a terminal with low computation resources, it may contact a TTP which, in turn, attests the Security Controller and returns the result of the integrity evaluation to the user, following the same steps depicted above. 5.3. Virtual Platform Attestation The main outcome of the Security Controller attestation is to detect whether or not it is correctly configuring the virtualization container for the vNSFs belonging to the connecting user (the virtualization platform, or vNSF platform) in a way that the user's traffic is processed only by the NSFs within the container. The virtual platform attestation, instead, evaluates the integrity of the NSFs running within the platform. The virtual platform attestation does not imply a validation of the mechanisms the Security Controller can apply to select the appropriate NSFs (virtual or physical) to enforce the Service Policies applicable to a user. The selection of these NSFs is supposed to happen independently of the attestation procedures, and trust on the selection process and the translation of policies into function capabilities has to be based on the trust the user has on the Security Controller being attested as the one it was intended to be used. An attestation of the selection and policy mapping procedures constitute an interesting research matter, but it is out of the scope of this document. The procedures are essentially similar to the ones described in the previous section. This step MAY be applied periodically if the level of assurance selected by the user requires it. Attesting vNSFs typically running as virtual machines can become a rather costly operation, especially if periodic monitoring is required by the requested level of assurance, and there are several proposals to make them feasible, from the proposal of virtual TPMs in [VTPM] to the application of Virtual Machine Introspection through an integrity monitor described by [VMIA]. 6. Security Considerations This document is specifically oriented to security and it is considered along the whole text. Pastor, et al. Expires September 21, 2016 [Page 15] Internet-Draft Remote Attestation for vNFs March 2016 7. IANA Considerations This document requires no IANA actions. 8. References 8.1. Normative References [I-D.pastor-i2nsf-merged-use-cases] Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M., Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M. Georgiades, "Use Cases and Requirements for an Interface to Network Security Functions", draft-pastor-i2nsf-merged-use-cases-00 (work in progress), June 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [TCG] "Trusted Computing Group (TCG)", . [TCGGSS] "TCG Generic Server Specification, Version 1.0", . [TCGIRSS] "Infrastructure Work Group Integrity Report Schema Specification, Version 1.0", . 8.2. Informative References [UEFI] "UEFI Specification Version 2.2 (Errata D), Tech. Rep.". [VMIA] Schiffman, J., Vijayakumar, H., and T. Jaeger, "Verifying System Integrity by Proxy", . [VTPM] "vTPM:Virtualizing the Trusted Platform Module", . Pastor, et al. Expires September 21, 2016 [Page 16] Internet-Draft Remote Attestation for vNFs March 2016 Authors' Addresses Antonio Pastor Telefonica I+D Zurbaran, 12 Madrid, 28010 Spain Phone: +34 913 128 778 Email: antonio.pastorperales@telefonica.com Diego R. Lopez Telefonica I+D Zurbaran, 12 Madrid, 28010 Spain Phone: +34 913 129 041 Email: diego.r.lopez@telefonica.com Adrian L. Shaw Hewlett Packard Labs Long Down Avenue Bristol, BS34 8QZ UK Phone: +44 117 316 2877 Email: als@hpe.com Pastor, et al. Expires September 21, 2016 [Page 17]