idnits 2.17.1 draft-pastor-i2nsf-nsf-remote-attestation-07.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 (February 11, 2019) is 1900 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-sfc-proof-of-transit-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interface to Network Security Functions A. Pastor 3 Internet-Draft D. Lopez 4 Intended status: Experimental Telefonica I+D 5 Expires: August 15, 2019 A. Shaw 6 ARM 7 February 11, 2019 9 Remote Attestation Procedures for Network Security Functions (NSFs) 10 through the I2NSF Security Controller 11 draft-pastor-i2nsf-nsf-remote-attestation-07 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 August 15, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . 5 61 3.3. Trusted Computing . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Topology Attestation . . . . . . . . . . . . . . . . . . . 7 63 4. NSF Attestation Principles . . . . . . . . . . . . . . . . . . 8 64 4.1. Requirements for a Trusted NSF Platform . . . . . . . . . 9 65 4.1.1. Trusted Boot . . . . . . . . . . . . . . . . . . . . . 9 66 4.1.2. Remote Attestation Service . . . . . . . . . . . . . . 10 67 4.1.3. Secure Boot . . . . . . . . . . . . . . . . . . . . . 11 68 5. Remote Attestation Procedures . . . . . . . . . . . . . . . . 11 69 5.1. Trusted Channel with the Security Controller . . . . . . . 12 70 5.2. Security Controller Attestation . . . . . . . . . . . . . 14 71 5.3. Platform Attestation . . . . . . . . . . . . . . . . . . . 15 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 As described in [RFC8192], the use of externally provided NSF implies 83 several additional concerns in security. The most relevant threats 84 associated with a externalized platform are detailed in [RFC8329]. 85 As stated there, mutual authentication between the user and the NSF 86 environment and, more importantly, the attestation of the components 87 in this environment by clients, could address these threats and 88 provide an acceptable level of risk. In particular: 90 o Client impersonation will be minimized by mutual authentication, 91 and since appropriate records of such authentications will be made 92 available, events are suitable for auditing (as a minimum) in the 93 case of an incident. 95 o Attestation of the NSF environment, especially when performed 96 periodically, will allow clients to detect the alteration of the 97 processing components, or the installation of malformed 98 components. Mutual authentication will again provide an audit 99 trail. 101 o Attestation relying on independent Trusted Third Parties will 102 alleviate the impact of malicious activity on the side of the 103 provider by issuing the appropriate alarms in the event of any NSF 104 environment manipulation. 106 o While it is true that any environment is vulnerable to malicious 107 activity with full physical access (and this is obviously beyond 108 the scope of this document), the application of attestation 109 mechanisms raises the degree of physical control necessary to 110 perform an untraceable malicious modification of the environment. 112 The client can have a proof that their NSFs and policies are 113 correctly (from the client point of view) enforced by the Security 114 Controller. Taking into account the threats identified in [RFC8329], 115 this document first identifies the user expectations regarding remote 116 trust establishment, briefly analyzes Trusted Computing techniques, 117 and finally describes the proposed mechanisms for remote 118 establishment of trust through the Security Controller. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 In this document, these words will appear with that interpretation 127 only when in ALL CAPS. Lower case uses of these words are not to be 128 interpreted as carrying RFC-2119 significance. 130 3. Establishing Client Trust 132 From a high-level standpoint, in any I2NSF platform, the client 133 connects and authenticates to the Security Controller, which then 134 initializes the procedures for authentication and authorization (and 135 likely accounting and auditing) to track the loading and unloading of 136 the client's NSFs, addressing the verification of the whole software 137 stack: firmware, (host and guest) OSes, NSFs themselves and, in a 138 virtualized environment, the virtualization system (hypervisors, 139 container frameworks...). Afterwards, user traffic from the client 140 domain goes through the NSF platform that hosts the corresponding 141 NSFs. The user's expectations of the platform behavior are thus 142 twofold: 144 o The user traffic will be treated according to the client-specified 145 NSFs, and no other processing will be performed by the Security 146 Controller or the platform itself (e.g. traffic eavesdropping). 148 o Each NSF (and its corresponding policies) behaves as configured by 149 the client. 151 We will refer to the attestation of these two expectations as the 152 "client-agnostic attestation" and the "client-specific attestation". 153 Trusted Computing techniques play a key role in addressing these 154 expectations. 156 3.1. First Step: Client-Agnostic Attestation 158 This is the first interaction between a client and a Security 159 Controller: the client wants to attest that he is connected to a 160 genuine Security Controller before continuing with the 161 authentication. In this context, two properties characterize the 162 genuineness of the Security Controller: 164 1. That the identity of the Security Controller is correct 166 2. That it will process the client credentials and set up the client 167 NSFs and policies properly. 169 Once these two properties are proven to the client, the client knows 170 that their credentials will only be used by the Security Controller 171 to set up the execution of their NSFs. 173 3.2. Second Step: Client-Specific Attestation 175 From the security enforcement point of view, the client agnostic 176 attestation focuses on the initialization of the execution platform 177 for the NSFs. This second step aims to prove to clients that their 178 security is enforced accordingly with their choices (i.e. NSFs and 179 policies). The attestation can be performed at the initialization of 180 the NSFs, before any user traffic is processed by the NSFs, and 181 optionally during the execution of the NSFs. 183 Support of static attestation, performed at initialization time, for 184 the execution platform and the NSFs is REQUIRED for a Security 185 Controller managing NSFs, and MUST be performed before any user 186 traffic is redirected through any set of NSFs. The Security 187 Controller MUST provide proof to the client that the instantiated 188 NSFs and policies are the ones chosen. 190 In addition to the platform and executable component attestation, the 191 infrastructure network topology supporting the NSFs may need to 192 attested, in order to assess the enforcement of the security policies 193 requested by the client. Whilst platform and NSF attestation can be 194 considered sufficient in I2NSF environments in which network elements 195 are connected following a fairly static configuration, the dynamicity 196 brought by networking techniques such as NFV, SDN and SFC make 197 attestation of dynamic topology network topologies a desirable 198 feature in a number of cases. Depending on the level of asurance 199 desired, the client MAY request the Security Controller proof of the 200 network topology connecting the instantiated NSFs. 202 Additionally to the NSFs instantiation attestation, a continuous 203 attestation of the Security Controller and the NSF execution MAY be 204 required by a client to ensure their security. The sampling periods 205 for the continuous attestation of NSFs an Controller MAY be 206 different. 208 3.3. Trusted Computing 210 In a nutshell, Trusted Computing (TC) aims at answering the following 211 question: "As a user or administrator, how can I have some assurance 212 that a computing system is behaving as it should?". The major 213 enterprise level TC initiative is the Trusted Computing Group [TCG], 214 which has been established for more than a decade, that primarily 215 focuses on developing TC for commodity computers (servers, desktops, 216 laptops, etc.). 218 The overall scheme proposed by TCG for using Trusted Computing is 219 based on a step-by-step extension of trust, called a Chain of Trust. 220 It uses a transitive mechanism: if a user can trust the first 221 execution step and each step correctly attests the next executable 222 software for trustworthiness, then a user can trust the system. 224 +-----------+ 225 | | extends PCR 226 | Platform +------------------------+ 227 | | | 228 +-----^-----+ | 229 | | 230 |measures | 231 +-----------+ | 232 | Security | extends PCR | 233 | +---------------------+ | 234 | Controller| | | 235 +-----^-----+ | | 236 | | | 237 |measures +-v--v----------+ 238 +-----------+ | | 239 | | extends PCR | | 240 | Bootloader+-------------------> Root of Trust | 241 | | | | 242 +-----^-----+ | | 243 | +-^--^----------+ 244 |measures | | 245 +-----------+ | | 246 | | extends PCR | | 247 | BIOS +---------------------+ | 248 | | | 249 +-----^-----+ | 250 | | 251 |measures | 252 +-----------+ | 253 | Bootblock | extends PCR | 254 | (CRTM) +------------------------+ 255 | | 256 +-----------+ 258 Figure 1: Applying Trusted Computing 260 Effectively, during the loading of each piece of software, the 261 integrity of each piece of software is measured and stored inside a 262 log that reflects the different boot stages, as illustrated in the 263 figure above. Later, at the request of a user, the platform can 264 present this log (signed with the unique identity of the platform), 265 which can be checked to prove the platform identity and attest the 266 state of the system. The base element for the extension of the Chain 267 of Trust is called the Core Root of Trust. 269 The TCG has created a standard for the design and usage of a secure 270 crypto-processor to address the storage of keys, general secrets, 271 identities, and platform integrity measurements: the Trusted Platform 272 Module (TPM). When using a TPM as a root of trust, measurements of 273 the software stack are stored in special on-board Platform 274 Configuration Registers (PCRs) on a discrete TPM. There are normally 275 a small number of PCRs that can be used for storing measurements; 276 however, it is not possible to directly write to a PCR. Instead, 277 measurements must be stored using a process called Extending PCRs. 279 The extend operation can update a PCR by producing a global hash of 280 the concatenated values of the previous PCR value with the new 281 measurement value. The Extend operation allows for an unlimited 282 number of measurements to be captured in a single PCR, since the size 283 of the value is always the same and it retains a verifiable ordered 284 chain of all the previous measurements. 286 Attestation of the virtualization platform will thus rely on a 287 process of measuring the booted software and storing a chained log of 288 measurements, typically referred to as Trusted Boot. The user will 289 either validate the signed set of measurements with a trusted third 290 party verifier who will assess whether the software configuration is 291 trusted, or the user can check for themselves against their own set 292 of reference digest values (measurements) that they have obtained a 293 priori, and having already known the public endorsement key of the 294 remote Root of Trust. 296 Trusted Boot should not be confused with a different mechanism known 297 as "Secure Boot", as they both are designed to solve different 298 problems. Secure Boot is a mechanism for a platform owner to lock a 299 platform to only execute particular software. Software components 300 that do not match the configuration digests will not be loaded or 301 executed. This mechanism is particularly useful in preventing 302 malicious software that attempts to install itself in the boot record 303 (a bootkit) from successfully infecting a platform on reboot. A 304 common standard for implementing Secure Boot is described in [UEFI]. 305 Secure Boot only enforces a particular configuration of software, it 306 does not allow a user to attest or quote for a series of 307 measurements. 309 3.4. Topology Attestation 311 There are two methods able to attest the deployment of a topology 312 addressing client requirements on a dynamically controled network 313 infrastructure. The first one asumes the newtork infrastructure is 314 built by means of SDN-enabled fowarding elements, and the second 315 relies on the application of SFC [RFC7665] to build the NSF 316 processing paths. In both cases, a network topology verifier is 317 used. 319 In the first case, a SDN verifier is introduced, and network 320 forwarding elements required to provide attestation features, as 321 described in the previous section, to provide measures on the 322 enforced SDN configuration. The SDN verifier retrieves from the SDN 323 controller the configuration for the attested network elements, 324 challenges them for their SDN configuration, and assessesit is 325 consistent with the expected SDN configuration retrieved from the SDN 326 controller. The SDN verifier on the network elements leverage a TPM, 327 with the network element implementing a regular measured boot. 329 The second option considers the application of Proof of Transit (POT) 330 [I-D.ietf-sfc-proof-of-transit] to a SFC-based network, where the 331 NSFs act as service functions. A SFC verifier can inject specific 332 packets requesting POT, and verifying it at the egress of the service 333 path to assess a correct topoloogy is being enforced, by means of the 334 cryptographic proof provided by POT. 336 4. NSF Attestation Principles 338 Following the general requirements described in [RFC8329] the 339 Security Controller will become the essential element to implement 340 the measurements described above, relying on a TPM for the Root of 341 Trust. 343 A mutual authentication of clients and the Security Controller MUST 344 be performed, establishing the desired level of assurance. This 345 level of assurance will determine how stringent are the requirements 346 for authentication (in both directions), and how detailed the 347 collected measurements and their verification will be. Furthermore, 348 the NSF platform MUST run a TPM, able to collect measurements of the 349 platform itself, the Security Controller, and the NSFs being 350 executed. The availability of a network topology verifier is 351 OPTIONAL, though a client MAY require it to fulfill the required 352 level of assurance. The Security Controller MUST make the 353 attestation measurements available to the client, directly or by 354 means of a Trusted Third Party. 356 As described in [RFC8329], a trusted connection between the client 357 and the Security Controller MUST be established and all traffic to 358 and from the NSF environment MUST flow through this connection 360 NOTE: The reference to results from WGs such as NEA and SACM is 361 currently under consideration and will be included here. 363 4.1. Requirements for a Trusted NSF Platform 365 Although a discrete hardware TPM is RECOMMENDED, relaxed alternatives 366 (such as embedded CPU TPMs, or memory and execution isolation 367 mechanisms) MAY also be applied when the required level of assurance 368 is lower. This reduced level of assurance MUST be communicated to 369 the client by the Security Controller during the initial mutual 370 authentication phase. The Security Controller MUST use a set of 371 capabilities to negotiate the level of assurance with the client. 373 4.1.1. Trusted Boot 375 NOTE: This section is derived from the original version of the 376 document, focused on virtual NSFs. Although it seems to be 377 applicable to any modern physical appliance, we must be sure all 378 these considerations are 100% applicable to physical NSFs as well, 379 and provide exceptions when that is not the case. Support from an 380 expert in physical node attestation is required here. 382 All clients who interact with a Security Controller MUST be able to: 384 a. Identify the Security Controller based on the public key of a 385 Root of Trust. 387 b. Retrieve a set of measurements of all the base software the 388 Security Controller has booted (i.e. the NSF platform). 390 This requires that firmware and software MUST be measured before 391 loading, with the resulting value being used to extend the 392 appropriate PCR register. The general usage of PCRs by each software 393 component SHOULD conform to open standards, in order to make 394 verifying attestation reports interoperable, as it is the case of TCG 395 Generic Server Specification [TCGGSS]. 397 The following list describes which PCR registers SHOULD be used 398 during a Trusted Boot process: 400 o PCRs 00-03: for use by the CRTM (Core Root of Trust for 401 Measurement, at the initial EEPROM or PC BIOS) 403 o PCRs 04-07: for use by the bootloader stages 405 o PCRs 08-15: for use by the booted base system 407 A signed audit log of boot measurements should also be provided. The 408 PCR values can also be used as an identity for dynamically decrypting 409 encrypted blobs on the platform (such as encryption keys or 410 configurations that belong to operating system components). Software 411 can choose to submit pieces of data to be encrypted by the Root of 412 Trust (which has its own private asymmetric key and PCR registers) 413 and only have it decrypted based on some criteria. These criteria 414 can be that the platform booted into a particular state (e.g. a set 415 of PCR values). Once the desired criteria are described and the 416 sensitive data is encrypted by the root of trust, the data has been 417 sealed to that platform state. The sealed data will only be 418 decrypted when the platform measurements held in the root of trust 419 match the particular state. 421 Trusted Boot requires the use of a root of trust for safely storing 422 measurements and secrets. Since the Root of Trust is self-contained 423 and isolated from all the software that is measured, it is able to 424 produce a signed set of platform measurements to a local or remote 425 user. However, Trusted Boot does not provide enforcement of a 426 configuration, since the root of trust is a passive component not in 427 the execution path, and is solely used for safe independent storage 428 of secrets and platform measurements. It will respond to attestation 429 requests with the exact measurements that were made during the 430 software boot process. Sealing and unsealing of sensitive data is 431 also a strong advantage of Trusted Boot, since it prevents leakage of 432 secrets in the event of an untrusted software configuration. 434 4.1.2. Remote Attestation Service 436 A service MUST be present for providing signed attestation report 437 (e.g. the measurements) from the Root of Trust (RoT) to the client. 438 In case of failure to communicate with the service, the client MUST 439 assume the service cannot be trusted and seek an alternative Security 440 Controller. 442 Since some forms of RoT require serialised access (i.e. due to slow 443 access to hardware), latency of getting an attestation report could 444 increase with simultaneous requests. Simultaneous requests could 445 occur if multiple Trusted Third Parties (TTP) request attestation 446 reports at the same time. This MAY be improved through batching of 447 requests, in a special manner. In a typical remote attestation 448 protocol, the client sends a random number ("nonce") to the RoT in 449 order to detect any replay attacks. Therefore, caching of an 450 attestation report does not work, since there is the possibility that 451 it may not be a fresh report. The solution is to batch the nonce for 452 each requestor until the RoT is ready for creating the attestation 453 report. The report will be signed by the embedded identity of the 454 RoT to provide data integrity and authenticity, and the report will 455 include all the nonces of the requestors. Regardless of the number 456 of the number of nonces included, the requestor verifying the 457 attestation report MUST check to see if the requestor's nonce was 458 included in order to detect replay attacks. In addition to the 459 attestation report containing PCRs, an additional report known as an 460 SML (Secure Measurement Log) can be returned to the requestor to 461 provide more information on how to verify the report (e.g. how to 462 reproduce the PCR values). The integrity of the SML is protected by 463 a PCR measurement in the RoT. An example of an open standard for 464 responses is [TCGIRSS]. Further details are discussed in 465 Section 5.2. 467 As part of initial contact, the Security Controller MAY present a 468 list of external TTPs that the client can use to verify it. However, 469 the client MUST assess whether these external verifiers can be 470 trusted. The client can also choose to ignore or discard the 471 presented verifiers. 473 If available, the network topology verifier MUST be colocated or 474 integrated with the RoT. 476 Finally, to prevent malicious relaying of attestation reports from a 477 different host, the authentication material of the secure channel 478 (e.g. TLS, IPSec, etc.) SHOULD be bound to the RoT and verified by 479 the connected client, unless the lowest levels of assurance have been 480 chosen and an explicit warning issued. This is also addressed in 481 Section 5.1. 483 4.1.3. Secure Boot 485 Using a mechanism such as Secure Boot helps provide strong prevention 486 of software attacks. Furthermore, in combination with a hardware- 487 based TPM, Secure Boot can provide some resilience to physical 488 attacks (e.g. preventing a class of offline attacks and unauthorized 489 system replacement). For NSF providers, it is RECOMMENDED that 490 Secure Boot is employed wherever possible with an appropriate 491 firmware update mechanism, due to the possible threat of software/ 492 firmware modifications in either public places or privately with 493 inside attackers. 495 5. Remote Attestation Procedures 497 The establishment of trust with the Security Controller and the NSF 498 platform consists of three main phases, which need to be coordinated 499 by the client: 501 1. Trusted channel with the Security Controller. During this phase, 502 the client securely connects to the Security Controller to avoid 503 that any data can be tampered with or modified by an attacker if 504 the network cannot be considered trusted. The establishment of 505 the trusted channel is completed after the next step. 507 2. Security Controller attestation. During this phase, the client 508 verifies that the Security Controller components responsible for 509 handling the credentials and for the isolation with respect to 510 other potential clients are behaving correctly. Furthermore, it 511 is verified that the identity of the platform attested is the 512 same of the one presented by the Security Controller during the 513 establishment of the secure connection. 515 3. Platform attestation. During this step, which can be repeated 516 periodically until the connection is terminated, the Security 517 Controller verifies the integrity of the elements composing the 518 NSF platform. The components responsible for this task have been 519 already attested during the previous phase. 521 +----------+ 522 3. Attestation | Trusted | 3. Attestation 523 +--------------------> Third <----------+ 524 | | Party | | 525 | +----------+ +--------+-------+ 526 +----------v-------+ | +-----v-----+ | 527 | Client | | | Security | | 528 | | 1. Trusted channel | | Controller| | 529 | 2. Get Cert +------+ handshake +---------> | | 530 | 3. Attestation | | +-----------+ | 531 | 4. Cont.handshake| | | 532 | | | | 533 | | | +---------+ | 534 | | | | NSF | | 535 | | | +---------+ | 536 +------------------+ +----------------+ 538 Figure 2: Steps for remote attestation 540 In the following each step, as depicted in the above figure, is 541 discussed in more detail. 543 5.1. Trusted Channel with the Security Controller 545 A trusted channel is an enhanced version of the secured channel that. 546 It adds the requirement of integrity verification of the contacted 547 endpoint by the other peer during the initial handshake to the 548 functionality of the secured channel. However, simply transmitting 549 the integrity measurements over the channel does not guarantee that 550 the platform verified is the channel endpoint. The public key or the 551 certificate for the secure communication MUST be included as part of 552 the measurements presented by the contacted endpoint during the 553 remote attestation. This way, a malicious platform cannot relay the 554 attestation to another platform as its certificate will not be 555 present in the measurements list of the genuine platform. 557 In addition, the problem of a potential loss of control of the 558 private key must be addressed (a malicious endpoint could prove the 559 identity of the genuine endpoint). This is done by defining a long- 560 lived Platform Property Certificate. Since this certificate connects 561 the platform identity to the AIK public key, an attacker cannot use a 562 stolen private key without revealing his identity, as it may use the 563 certificate of the genuine endpoint but cannot create a quote with 564 the AIK of the other platform. 566 Finally, since the platform identity can be verified from the 567 Platform Property Certificate, the information in the certificate to 568 be presented during the establishment of a secure communication is 569 redundant. This allows for the use of self-signed certificates. 570 This would simplify operational procedures in many environments, 571 especially when they are multi-tenant. Thus, in place of 572 certificates signed by trusted CAs, the use of self-signed 573 certificates (which still need to be included in the measurements 574 list) is RECOMMENDED. 576 The steps required for the establishment of a trusted channel with 577 the Security Controller are as follows: 579 1. The client begins the trusted channel handshake with the selected 580 Security Controller. 582 2. The certificate of the Security Controller is collected and used 583 for verifying the binding of the attestation result to the 584 contacted endpoint. 586 3. The client performs the remote attestation protocol with the 587 Security Controller, either directly or with the help of a 588 Trusted Third Party. The Trusted Third Party MAY perform the 589 verification of attestation quotes on behalf of multiple clients. 591 4. If the result of the attestation is positive, the application 592 continues the handshake and establishes the trusted channel. 593 Otherwise, it closes the connection. 595 5.2. Security Controller Attestation 597 During the establishment of the trusted channel, the client attests 598 the Security Controller by verifying the identity of the contacted 599 endpoint and its integrity. Initially the Security Controller 600 measures all of the hardware and software components involved in the 601 boot process of the NSF platform, in order to build the chain of 602 trust. 604 Since a client may not have enough functionality to perform the 605 integrity verification of a Security Controller, the client MAY 606 request the status of a Security Controller to be computed by a 607 Trusted Third Party (TTP). This choice has the additional advantage 608 of preventing an attacker from easily determining the software 609 running at the Security Controller. 611 If the client directly performs the remote attestation, it executes 612 the following steps: 614 1. Ask the Security Controller to generate an integrity report with 615 the format defined in [TCGIRSS]. 617 2. The Security Controller retrieves the measurements and asks the 618 TPM to sign the PCRs with an Attestation Identity Key (AIK). 619 This signature provides the client with the evidence that the 620 measurements received belong to the Security Controller being 621 attested. 623 3. Once the integrity report has been generated it is sent back to 624 the client. 626 4. The client first checks if the integrity report is valid by 627 verifying the quote and the certificate associated to the AIK, 628 and then determines if the Security Controller is behaving as 629 expected (i.e. its software has not been compromised and 630 isolation among the clients connected to it is enforced). As 631 part of the verification, the client also checks that the digest 632 of the certificate, received during the trusted channel 633 handshake, is present among measurements. 635 If the client has limited computation resources, it may contact a TTP 636 which, in turn, attests the Security Controller and returns the 637 result of the integrity evaluation to the client, following the same 638 steps depicted above. 640 5.3. Platform Attestation 642 The main outcome of the Security Controller attestation is to detect 643 whether or not it is correctly configuring the operational 644 environment for NSFs to be managed by the connecting client (the NSF 645 platform, or just platform) in a way that any user traffic is 646 processed only by these NSFs that are part of the platform. Platform 647 attestation, instead, evaluates the integrity of the NSFs running on 648 the platform. 650 Platform attestation does not imply a validation of the mechanisms 651 the Security Controller can apply to select the appropriate NSFs to 652 enforce the Service Policies applicable to specific flows. The 653 selection of these NSFs is supposed to happen independent of the 654 attestation procedures, and trust on the selection process and the 655 translation of policies into function capabilities has to be based on 656 the trust clients have on the Security Controller being attested as 657 the one that was intended to be used. An attestation of the 658 selection and policy mapping procedures constitute an interesting 659 research problem, but it is out of the scope of this document. 661 The procedures are essentially similar to the ones described in the 662 previous section. This step MAY be applied periodically if the level 663 of assurance selected by the user requires it. 665 Attesting NSFs, especially if they are running as virtual machines, 666 can become a costly operation, especially if periodic monitoring is 667 required by the requested level of assurance. There are several 668 proposals to make this feasible, from the proposal of virtual TPMs in 669 [VTPM] to the application of Virtual Machine Introspection through an 670 integrity monitor described by [VMIA]. 672 6. Security Considerations 674 This document is specifically oriented to security and it is 675 considered along the whole text. 677 7. IANA Considerations 679 This document requires no IANA actions. 681 8. Acknowledgments 683 This work has been partially supported by the European Commission 684 under Horizon 2020 grant agreement no. 700199 "Securing against 685 intruders and other threats through a NFV-enabled environment 686 (SHIELD)". This support does not imply endorsement. 688 9. References 690 9.1. Normative References 692 [I-D.ietf-sfc-proof-of-transit] 693 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 694 Leddy, J., Youell, S., Mozes, D., Mizrahi, T., Aguado, A., 695 and D. Lopez, "Proof of Transit", 696 draft-ietf-sfc-proof-of-transit-01 (work in progress), 697 October 2018. 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 701 RFC2119, March 1997, 702 . 704 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 705 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/ 706 RFC7665, October 2015, 707 . 709 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 710 and J. Jeong, "Interface to Network Security Functions 711 (I2NSF): Problem Statement and Use Cases", RFC 8192, 712 DOI 10.17487/RFC8192, July 2017, 713 . 715 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 716 Kumar, "Framework for Interface to Network Security 717 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 718 . 720 [TCG] "Trusted Computing Group (TCG)", 721 . 723 [TCGGSS] "TCG Generic Server Specification, Version 1.0", 724 . 726 [TCGIRSS] "Infrastructure Work Group Integrity Report Schema 727 Specification, Version 1.0", 728 . 730 9.2. Informative References 732 [UEFI] "UEFI Specification Version 2.2 (Errata D), Tech. Rep.". 734 [VMIA] Schiffman, J., Vijayakumar, H., and T. Jaeger, "Verifying 735 System Integrity by Proxy", 736 . 738 [VTPM] "vTPM:Virtualizing the Trusted Platform Module", . 741 Authors' Addresses 743 Antonio Pastor 744 Telefonica I+D 745 Zurbaran, 12 746 Madrid, 28010 747 Spain 749 Phone: +34 913 128 778 750 Email: antonio.pastorperales@telefonica.com 752 Diego R. Lopez 753 Telefonica I+D 754 Editor Jose Manuel Lara, 9 (1-B) 755 Seville, 41013 756 Spain 758 Phone: +34 913 129 041 759 Email: diego.r.lopez@telefonica.com 761 Adrian L. Shaw 762 ARM 764 Email: als@arm.com