idnits 2.17.1 draft-pastor-i2nsf-vnsf-attestation-03.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 : ---------------------------------------------------------------------------- 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 (July 4, 2016) is 2845 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Pastor 3 Internet-Draft D. Lopez 4 Intended status: Experimental Telefonica I+D 5 Expires: January 5, 2017 A. Shaw 6 Hewlett Packard Labs 7 July 4, 2016 9 Remote Attestation Procedures for Network Security Functions (NSFs) 10 through the I2NSF Security Controller 11 draft-pastor-i2nsf-vnsf-attestation-03 13 Abstract 15 This document describes the procedures a client can follow to assess 16 the trust on an external NSF platform and its client-defined 17 configuration through the I2NSF Security Controller. The procedure 18 to assess trustworthiness is based on a remote attestation of the 19 platform and the NSFs running on it performed through a Trusted 20 Platform Module (TPM) invoked by the Security Controller. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 5, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Establishing Client Trust . . . . . . . . . . . . . . . . . . 4 59 3.1. First Step: Client-Agnostic Attestation . . . . . . . . . 4 60 3.2. Second Step: Client-Specific Attestation . . . . . . . . . 4 61 3.3. Trusted Computing . . . . . . . . . . . . . . . . . . . . 5 62 4. NSF Attestation Principles . . . . . . . . . . . . . . . . . . 7 63 4.1. Requirements for a Trusted NSF Platform . . . . . . . . . 8 64 4.1.1. Trusted Boot . . . . . . . . . . . . . . . . . . . . . 8 65 4.1.2. Remote Attestation Service . . . . . . . . . . . . . . 9 66 4.1.3. Secure Boot . . . . . . . . . . . . . . . . . . . . . 10 67 5. Remote Attestation Procedures . . . . . . . . . . . . . . . . 10 68 5.1. Trusted Channel with the Security Controller . . . . . . . 11 69 5.2. Security Controller Attestation . . . . . . . . . . . . . 13 70 5.3. Platform Attestation . . . . . . . . . . . . . . . . . . . 14 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 As described in [I-D.pastor-i2nsf-merged-use-cases], the use of 81 externally provided NSF implies several additional concerns in 82 security. The most relevant threats associated with a externalized 83 virtual platform are detailed in [I-D.ietf-i2nsf-framework]. As 84 stated there, mutual authentication between the user and the NSF 85 environment and, what is more important, the attestation of the 86 elements in this environment by clients could address these threats 87 to an acceptable level of risk. In particular: 89 o Any impersonation attempt (of the client or the NSF environment) 90 will be minimized by mutual authentication, and since appropriate 91 records of such authentications will be made available, events 92 will be suitable for auditing in the case of an incident. 94 o Attestation of the NSF environment, especially when performed 95 periodically, will allow clients to detect the alteration of the 96 processing elements, or the installation of malformed elements, 97 and mutual authentication will provide again an audit trail. 99 o Attestation relying on independent Trusted Third Parties will 100 alleviate the impact of malicious activity on the side of the 101 provider by issuing the appropriate alarms in the event of any NSF 102 environment manipulation. 104 o While it is true that any environment is vulnerable to malicious 105 activity with full physical access (and this is obviously beyond 106 the scope of this document), the application of attestation 107 mechanisms raises the degree of physical control necessary to 108 perform an untraceable malicious modification of the environment. 110 The client can have a proof that their NSFs and policies are 111 correctly (from the client point of view) enforced by the Security 112 Controller. Taking into account the threats identified in 113 [I-D.ietf-i2nsf-framework], this document first identifies the user 114 expectations regarding remote trust establishment, briefly analyzes 115 Trusted Computing techniques, and finally describes the proposed 116 mechanisms for remote establishment of trust through the Security 117 Controller. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 In this document, these words will appear with that interpretation 126 only when in ALL CAPS. Lower case uses of these words are not to be 127 interpreted as carrying RFC-2119 significance. 129 3. Establishing Client Trust 131 From a high-level standpoint, in any I2NSF platform, the client 132 connects and authenticates to the Security Controller, which then 133 initialises the client's NSFs and policies. Afterwards, user traffic 134 from the client domain goes through the NSF platform which hosts the 135 corresponding NSFs. The user's expectations of the platform behavior 136 are thus twofold: 138 o The user traffic will be treated according to the client-specified 139 NSFs and policies, and no other processing will be performed by 140 the Security Controller or the platform itself (e.g. traffic 141 eavesdropping). 143 o Each NSF (and its corresponding policies) behaves as configured by 144 the client. 146 We will refer to the attestation of these two expectations as the 147 "client-agnostic attestation" and the "client-specific attestation". 148 Trusted Computing techniques play a key role in addressing this 149 expectations. 151 3.1. First Step: Client-Agnostic Attestation 153 This is the first interaction between a client and a Security 154 Controller: the client wants an attestation that proves it is 155 connected to a genuine Security Controller before continuing with the 156 authentication. In this context, two properties characterise the 157 genuineness of the Security Controller: 159 1. That the identity of the Security Controller is correct 161 2. That it will process the client credentials and set up the client 162 NSFs and policies properly. 164 Once these two properties are proven to the client, the client knows 165 that their credentials will only be used by the Security Controller 166 to set up the execution of their NSFs. 168 3.2. Second Step: Client-Specific Attestation 170 From the security enforcement point of view, the client agnostic 171 attestation focuses on the initialization of the execution platform 172 for the vNSFs. This second step aims to prove to clients that their 173 security is enforced accordingly with their choices (i.e. NSFs and 174 policies). The attestation can be performed at the initialization of 175 the NSFs, before any user traffic is processed by the NSFs, or during 176 the execution of the NSFs. 178 Support of static NSF attestation is REQUIRED for a Security 179 Controller managing NSFs, and MUST be performed before any user 180 traffic is redirected through any set of NSFs. The Security 181 Controller MUST provide a proof to the client that the instantiated 182 NSFs and policies are the ones chosen. 184 Additionally to the NSF attestation at the moment of their 185 instantiation, a continuous attestation of the NSF execution (based 186 on the generation of periodic TPM integrity measurements) MAY be 187 required by a client to ensure their security. 189 3.3. Trusted Computing 191 In a nutshell, Trusted Computing (TC) aims at answering the following 192 question: "As a user or administrator, how can I have some assurance 193 that a computing system is behaving as it should?". The major 194 enterprise level TC initiative is the Trusted Computing Group [TCG], 195 which has been established for more than a decade, that primarily 196 focuses on developing TC for commodity computers (servers, desktops, 197 laptops, etc.). 199 The overall scheme proposed by TCG for using Trusted Computing is 200 based on a step-by-step extension of trust, called a Chain of Trust. 201 It uses a transitive mechanism: if a user can trust the first 202 execution step and each step correctly attests the next executable 203 software for trustworthiness, then a user can trust the system. 205 +-----------+ 206 | | extends PCR 207 | NSF +------------------------+ 208 | | | 209 +-----^-----+ | 210 | | 211 |measures | 212 +-----------+ | 213 | Security | extends PCR | 214 | +---------------------+ | 215 | Controller| | | 216 +-----^-----+ | | 217 | | | 218 |measures +-v--v----------+ 219 +-----------+ | | 220 | | extends PCR | | 221 | Bootloader+-------------------> Root of Trust | 222 | | | | 223 +-----^-----+ | | 224 | +-^--^----------+ 225 |measures | | 226 +-----------+ | | 227 | | extends PCR | | 228 | BIOS +---------------------+ | 229 | | | 230 +-----^-----+ | 231 | | 232 |measures | 233 +-----------+ | 234 | Bootblock | extends PCR | 235 | (CRTM) +------------------------+ 236 | | 237 +-----------+ 239 Figure 1: Applying Trusted Computing 241 Effectively, during the loading of each piece of software, the 242 integrity of each piece of software is measured and stored inside a 243 log that reflects the different boot stages, as illustrated in the 244 figure above. Later, at the request of a user, the platform can 245 present this log (signed with the unique identity of the platform), 246 which can be checked to prove the platform identity and attest the 247 state of the system. The base element for the extension of the Chain 248 of Trust is called the Core Root of Trust. 250 The TCG has created a standard for the the design and usage of a 251 secure cryptoprocessor to address the storage of keys, general 252 secrets, identities and platform integrity measurements: the Trusted 253 Platform Module (TPM). When using a TPM as a root of trust, 254 measurements of the software stack are stored in special on-board 255 Platform Configuration Registers (PCRs) on a discrete TPM. There are 256 normally a small number of PCRs that can be used for storing 257 measurements, however it is not possible to directly write to a PCR; 258 instead measurements must be stored using a process called Extending 259 PCRs. 261 The extend operation can update a PCR by producing a global hash of 262 the concatenated values of the previous PCR value with the new 263 measurement value. The Extend operation allows for an unlimited 264 number of measurements to be captured in a single PCR, since the size 265 of the value is always the same and it retains a verifiable ordered 266 chain of all the previous measurements. 268 Attestation of the virtualization platform will thus rely on a 269 process of measuring the booted software and storing a chained log of 270 measurements, typically referred to as Trusted Boot. The user will 271 either validate the signed set of measurements with a trusted third 272 party verifier who will assess whether the software configuration is 273 trusted, or the user can check for themselves against their own set 274 of reference digest values (measurements) that they have obtained a 275 priori, and having already known the public endorsement key of the 276 remote Root of Trust. 278 Trusted Boot should not be confused with a different mechanism known 279 as "Secure Boot", as they both are designed to solve different 280 problems. Secure Boot is a mechanism for a platform owner to lock a 281 platform to only execute particular software. Software components 282 that do not match the configuration digests will not be loaded or 283 executed. This mechanism is particularly useful in preventing 284 bootkits from successfully infecting a platform on reboot. A common 285 standard for implementing Secure Boot is described in [UEFI]. Secure 286 Boot only enforces a particular configuration of software, it does 287 not allow a user to attest or quote for a series of measurements. 289 4. NSF Attestation Principles 291 Following the general requirements described in 292 [I-D.ietf-i2nsf-framework] the Security Controller will become the 293 essential element to implement the measurements described above, 294 relaying on a TPM for the Root of Trust. 296 A mutual authentication of clients and the Security Controller MUST 297 be performed, establishing the desired level of assurance. This 298 level of assurance will determine how stringent are the requirements 299 for authentication (in both directions), and how detailed the 300 collected measurements and their verification will be. Furthermore, 301 the NSF platform MUST run a TPM, able to collect measurements of the 302 platform itself, the Security Controller, and the NSFs being 303 executed. The Security Controller MUST make the attestation 304 measurements available to the client, directly or by means of a 305 Trusted Third Party. 307 As described in [I-D.ietf-i2nsf-framework], a trusted connection 308 between the client and the Security Controller MUST be established 309 and all traffic to and from the NSF environment MUST flow through 310 this connection 312 NOTE: The reference to results from WGs such as NEA and SACM is 313 currently under consideration and will be included here. 315 4.1. Requirements for a Trusted NSF Platform 317 Although a discrete hardware TPM is RECOMMENDED, relaxed alternatives 318 (such as embedded CPU TPMs, or memory and execution isolation 319 mechanisms) MAY also be applied when the required level of assurance 320 is lower. This reduced level of assurance MUST be communicated to 321 the user by the Security Controller during the initial mutual 322 authentication phase. 324 4.1.1. Trusted Boot 326 NOTE: This section is derived from the original version of the 327 document, focused on virtual NSFs. Although it seems to be 328 applicable to any modern physical appliance, we must be sure all 329 these considerations are 100% applicable to physical NSFs as well, 330 and provide exceptions when that is not the case. Support from 331 expert in physical node attestation is required here. 333 All clients who interact with a Security Controller MUST be able to: 335 a. Identify the Security Controller based on the public key of a 336 Root of Trust. 338 b. Retrieve a set of measurements of all the base software the 339 Security Controller has booted (i.e. the NSF platform). 341 This requires that firmware and software MUST be measured before 342 loading, with the resulting value being used to extend the 343 appropriate PCR register. The general usage of PCRs by each software 344 component SHOULD conform to open standards, in order to make 345 verifying attestation reports interoperable, as it is the case of TCG 346 Generic Server Specification [TCGGSS]. 348 As well as for providing a signed audit log of boot measurements, the 349 PCR values can also be used as an identity for dynamically decrypting 350 encrypted blobs on the platform (such as encryption keys or 351 configurations that belong to operating system components). Software 352 can choose to submit pieces of data to be encrypted by the Root of 353 Trust (which has its own private asymmetric key and PCR registers) 354 and only have it decrypted based on a criteria. This criteria can be 355 that the platform booted into a particular state (e.g. a set of PCR 356 values). Once the desired criteria is described and the sensitive 357 data is encrypted by the root of trust, the data has been sealed to 358 that platform state. The sealed data will only be decrypted when the 359 platform measurements held in the root of trust match the particular 360 state. 362 Trusted Boot requires the use of a root of trust for safely storing 363 measurements and secrets. Since the Root of Trust is self-contained 364 and isolated from all the software that is measured, it is able to 365 produce a signed set of platform measurements to a local or remote 366 user. Trusted Boot however does not provide enforcement of a 367 configuration, since the root of trust is a passive component not in 368 the execution path, and is solely used for safe independent storage 369 of secrets and platform measurements. It will respond to attestation 370 requests with the exact measurements that were made during the 371 software boot process. Sealing and unsealing of sensitive data is 372 also a strong advantage of Trusted Boot, since it prevents leakage of 373 secrets in the event of an untrusted software configuration. 375 4.1.2. Remote Attestation Service 377 A service MUST be present for providing signed attestation report 378 (e.g. the measurements) from the Root of Trust (RoT) to the client. 379 In case of failure to communicate with the service, the client MUST 380 assume the service cannot be trusted and seek an alternative Security 381 Controller. 383 Since some forms of RoT require serialised access (i.e. due to slow 384 access to hardware), latency of getting an attestation report could 385 increase with simultaneous requests. Simultaneous requests could 386 occur if multiple Trusted Third Parties (TTP) request for attestation 387 reports at the same time. This MAY be improved through batching of 388 requests, in a special manner. In a typical remote attestation 389 protocol, the client sends a random number ("nonce") to the RoT in 390 order to detect any replay attacks. Therefore, caching of an 391 attestation report does not work, since there is the possibility that 392 it may not be a fresh report. The solution is to batch the nonce for 393 each requestor until the RoT is ready for creating the attestation 394 report. The report will be signed by the embedded identity of the 395 RoT to provide data integrity and authenticity, and the report will 396 include all the nonces of the requestors. Regardless of the number 397 of the number of nonces included, the requestor verifying the 398 attestation report MUST check to see if the requestor's nonce was 399 included in order to detect replay attacks. In addition to the 400 attestation report containing PCRs, an additional report known as an 401 SML (Secure Measurement Log) can be returned to the requestor to 402 provide more information on how to verify the report (e.g. how to 403 reproduce the PCR values). The integrity of the SML is protected by 404 a PCR measurement in the RoT. An example of an open standard for 405 responses is [TCGIRSS]. Further details are discussed in 406 Section 5.2. 408 As part of initial contact, the Security Controller MAY present a 409 list of external TTPs that the client can use to verify it. However, 410 the client MUST assess whether these external verifiers can be 411 trusted. The client can also choose to ignore or discard the 412 presented verifiers. 414 Finally, to prevent malicious relaying of attestation reports from a 415 different host, the authentication material of the secure channel 416 (e.g. TLS, IPSec, etc.) SHOULD be bound to the RoT and verified by 417 the connected client, unless the lowest levels of assurance have been 418 chosen and an explicit warning issued. This is also addressed in 419 Section 5.1. 421 4.1.3. Secure Boot 423 Using a mechanism such as Secure Boot helps provide strong prevention 424 of software attacks. Furthermore, in combination with a hardware- 425 based TPM, Secure Boot can provide some resilience to physical 426 attacks (e.g. preventing a class of offline attacks and unauthorised 427 system replacement). For NSF providers, it is RECOMMENDED that 428 Secure Boot is employed wherever possible with an appropriate 429 firmware update mechanism, due to the possible threat of software/ 430 firmware modifications in either public places or privately with 431 inside attackers. 433 5. Remote Attestation Procedures 435 The establishment of trust with the Security Controller and the NSF 436 platform consists of three main phases, which need to be coordinated 437 by the client: 439 1. Trusted channel with the Security Controller. During this phase, 440 the client securely connects to the Security Controller to avoid 441 that any data can be tampered with or modified by an attacker if 442 the network cannot be considered trusted. The establishment of 443 the trusted channel is completed after the next step. 445 2. Security Controller attestation. During this phase, the client 446 verifies that the Security Controller components responsible for 447 handling the credentials and for the isolation with respect to 448 other potential clients are behaving correctly. Furthermore, it 449 is verified that the identity of the platform attested is the 450 same of the one presented by the Security Controller during the 451 establishment of the secure connection. 453 3. Platform attestation. During this step, that can be repeated 454 periodically until the connection is terminated, the Security 455 Controller verifies the integrity of the elements composing the 456 NSF platform. The components responsible for this task have been 457 already attested during the previous phase. 459 +----------+ 460 3. Attestation | Trusted | 3. Attestation 461 +--------------------> Third <----------+ 462 | | Party | | 463 | +----------+ +--------+-------+ 464 +----------v-------+ | +-----v-----+ | 465 | Client | | | Security | | 466 | | 1. Trusted channel | | Controller| | 467 | 2. Get Cert +------+ handshake +---------> | | 468 | 3. Attestation | | +-----------+ | 469 | 4. Cont.handshake| | | 470 | | | | 471 | | | +---------+ | 472 | | | | vNSF | | 473 | | | +---------+ | 474 +------------------+ +----------------+ 476 Figure 2: Steps for remote attestation 478 In the following each step, as depicted in the above figure, is 479 discussed in more detail. 481 5.1. Trusted Channel with the Security Controller 483 A trusted channel is an enhanced version of the secured channel that, 484 differently from the latter, requires the integrity verification of 485 the contacted endpoint by the other peer during the initial 486 handshake. However, simply transmitting the integrity measurements 487 over the channel does not guarantee that the platform verified is the 488 channel endpoint. The public key or the certificate for the secure 489 communication MUST be included as part of the measurements presented 490 by the contacted endpoint during the remote attestation. This way, a 491 malicious platform cannot relay the attestation to another platform 492 as its certificate will not be present in the measurements list of 493 the genuine platform. 495 In addition, the problem of a potential loss of control of the 496 private key must be addressed (a malicious endpoint could prove the 497 identity of the genuine endpoint). This is done by defining a long- 498 lived Platform Property Certificate. Since this certificate connects 499 the platform identity to the AIK public key, an attacker cannot use a 500 stolen private key without revealing his identity, as it may use the 501 certificate of the genuine endpoint but cannot create a quote with 502 the AIK of the other platform. 504 Finally, since the platform identity can be verified from the 505 Platform Property Certificate, the information in the certificate to 506 be presented during the establishment of a secure communication is 507 redundant. This allows for the use of self-signed certificates, what 508 would simplify operational procedures in many environments, 509 especially when they are multi-tenant. Thus, in place of 510 certificates signed by trusted CAs, the use of self-signed 511 certificates (which still need to be included in the measurements 512 list) is RECOMMENDED. 514 The steps required for the establishment of a trusted channel with 515 the Security Controller are as follows: 517 1. The client begins the trusted channel handshake with the selected 518 Security Controller. 520 2. The certificate of the Security Controller is collected and used 521 for verifying the binding of the attestation result to the 522 contacted endpoint. 524 3. The client performs the remote attestation protocol with the 525 Security Controller, either directly or with the help of a 526 Trusted Third Party. The Trusted Third Party MAY perform the 527 verification of attestation quotes on behalf of multiple clients. 529 4. If the result of the attestation is positive, the application 530 continues the handshake and establishes the trusted channel. 531 Otherwise, it closes the connection. 533 5.2. Security Controller Attestation 535 During the establishment of the trusted channel, the client attests 536 the Security Controller by verifying the identity of the contacted 537 endpoint and its integrity. Initially the Security Controller 538 measures all the hardware and software components involved in the 539 boot process of the vNSF platform, in order to build the chain of 540 trust. 542 Since a client may not have enough capabilities to perform the 543 integrity verification of a Security Controller the client MAY 544 request the status of a Security Controller to a Trusted Third Party 545 (TTP), which is in charge of communicating with it. This choice has 546 the additional advantage of preventing an attacker from easily 547 determining the software running at the Security Controller. 549 If the client directly performs the remote attestation it performs 550 the following steps: 552 1. Ask the Security Controller to generate an integrity report with 553 the format defined in [TCGIRSS]. 555 2. The Security Controller retrieves the measurements and asks the 556 TPM to sign the PCRs with an Attestation Identity Key (AIK). 557 This signature provides the client with the evidence that the 558 measurements received belong to the Security Controller being 559 attested. 561 3. Once the integrity report has been generated it is sent back to 562 the client. 564 4. The client first checks if the integrity report is valid by 565 verifying the quote and the certificate associated to the AIK, 566 and then determines if the Security Controller is behaving as 567 expected, i.e. its software has not been compromised and 568 isolation among the clients connected to it is enforced. As part 569 of the verification, the client also checks that the digest of 570 the certificate, received during the trusted channel handshake, 571 is present among measurements. 573 If the client has limited computation resources, or requires an 574 independent external element whom he can trust the measurements from, 575 it may contact a TTP it may contact a TTP which, in turn, attests the 576 Security Controller and returns the result of the integrity 577 evaluation to the client, following the same steps depicted above. 579 5.3. Platform Attestation 581 The main outcome of the Security Controller attestation is to detect 582 whether or not it is correctly configuring the operational 583 environment for NSFs to be managed by the connecting client (the NSF 584 platform, or just platform) in a way that any user traffic is 585 processed only by these NSFs within the platform. Platform 586 attestation, instead, evaluates the integrity of the NSFs running 587 within the platform. 589 Platform attestation does not imply a validation of the mechanisms 590 the Security Controller can apply to select the appropriate NSFs to 591 enforce the Service Policies applicable to specific flows. The 592 selection of these NSFs is supposed to happen independently of the 593 attestation procedures, and trust on the selection process and the 594 translation of policies into function capabilities has to be based on 595 the trust clients have on the Security Controller being attested as 596 the one it was intended to be used. An attestation of the selection 597 and policy mapping procedures constitute an interesting research 598 matter, but it is out of the scope of this document. 600 The procedures are essentially similar to the ones described in the 601 previous section. This step MAY be applied periodically if the level 602 of assurance selected by the user requires it. 604 Attesting NSFs, especially if they are running as virtual machines, 605 can become a rather costly operation, especially if periodic 606 monitoring is required by the requested level of assurance, and there 607 are several proposals to make them feasible, from the proposal of 608 virtual TPMs in [VTPM] to the application of Virtual Machine 609 Introspection through an integrity monitor described by [VMIA]. 611 6. Security Considerations 613 This document is specifically oriented to security and it is 614 considered along the whole text. 616 7. IANA Considerations 618 This document requires no IANA actions. 620 8. References 621 8.1. Normative References 623 [I-D.ietf-i2nsf-framework] 624 elopez@fortinet.com, e., Lopez, D., Dunbar, L., Strassner, 625 J., Zhuang, X., Parrott, J., Krishnan, R., and S. Durbha, 626 "Framework for Interface to Network Security Functions", 627 draft-ietf-i2nsf-framework-02 (work in progress), 628 July 2016. 630 [I-D.pastor-i2nsf-merged-use-cases] 631 Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M., 632 Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M. 633 Georgiades, "Use Cases and Requirements for an Interface 634 to Network Security Functions", 635 draft-pastor-i2nsf-merged-use-cases-00 (work in progress), 636 June 2015. 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 640 RFC2119, March 1997, 641 . 643 [TCG] "Trusted Computing Group (TCG)", 644 . 646 [TCGGSS] "TCG Generic Server Specification, Version 1.0", 647 . 649 [TCGIRSS] "Infrastructure Work Group Integrity Report Schema 650 Specification, Version 1.0", 651 . 653 8.2. Informative References 655 [UEFI] "UEFI Specification Version 2.2 (Errata D), Tech. Rep.". 657 [VMIA] Schiffman, J., Vijayakumar, H., and T. Jaeger, "Verifying 658 System Integrity by Proxy", 659 . 661 [VTPM] "vTPM:Virtualizing the Trusted Platform Module", . 664 Authors' Addresses 666 Antonio Pastor 667 Telefonica I+D 668 Zurbaran, 12 669 Madrid, 28010 670 Spain 672 Phone: +34 913 128 778 673 Email: antonio.pastorperales@telefonica.com 675 Diego R. Lopez 676 Telefonica I+D 677 Zurbaran, 12 678 Madrid, 28010 679 Spain 681 Phone: +34 913 129 041 682 Email: diego.r.lopez@telefonica.com 684 Adrian L. Shaw 685 Hewlett Packard Labs 686 Long Down Avenue 687 Bristol, BS34 8QZ 688 UK 690 Phone: +44 117 316 2877 691 Email: als@hpe.com