idnits 2.17.1 draft-rein-remote-attestation-nfv-use-cases-01.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 : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 04, 2018) is 2062 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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. Rein 3 Internet-Draft L. Xia 4 Intended status: Informational Huawei 5 Expires: March 8, 2019 September 04, 2018 7 The Remote Attestation NFV Use Cases 8 draft-rein-remote-attestation-nfv-use-cases-01 10 Abstract 12 This document proposes the use cases on an architectural level in 13 terms of Remote Attestation for virtualized environments, especially 14 in the context of Network Function Virtualization (NFV). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 8, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Stakeholders . . . . . . . . . . . . . . . . . . . . . . 2 52 1.2. Major Issue . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 56 3. Remote Attestation Use Cases . . . . . . . . . . . . . . . . 4 57 3.1. Decentralized Model Use Case . . . . . . . . . . . . . . 5 58 3.2. Centralized Model (in a Single Trust Domain) Use Case . . 8 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 11 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 65 1. Introduction 67 1.1. Stakeholders 69 Stakeholders play a major role in NFV and there is a strict 70 hierarchical separation between the stakeholders in terms of 71 responsibility, accessibility and visibility within the the NFV 72 architecture. Although these issues are also relevant for other 73 virtualized environments, for example in private or hybrid clouds, 74 they are most apparent in NFV, especially in multi vendor 75 deployments. 77 The stakeholders in NFV are: 79 o Cloud Service Provider (CSP): The CSP provides the platform, i.e. 80 the hardware and core services, acting as the Virtual Machine 81 Manager (VMM) or hypervisor for the provisioning of Virtual 82 Machines (VM). With regard to this document, the CSP is not 83 responsible for the provisioning itself. The CSP only provides 84 the platform w.r.t. to CSP NFV Infrastructure (CSP:NFVI) role. 85 The actual provisioning of specific VMs is carried out by the CSP 86 Management and Orchestration (CSP:MANO) role, whereas both roles 87 may be represented by the same or different organizations. This 88 contribution, however, is not concerned with the internal 89 operations and procedures of the CSP:MANO and therefore does 90 address CSP:MANO neither as a role nor as a functional component. 92 o Cloud Service Customer (CSC): The CSC is the actual user of the 93 VMM and requests the provisioning of specific VMs that eventually 94 provide some service. The CSC is also in full control in terms of 95 which specific VM is actually launched and thus not constrained in 96 this regard. 98 o Cloud Service User (CSU): The CSU is an external entity that uses 99 the CSC's provided services. The CSU only has access to public 100 API's provided by the offered service and has neither any 101 responsibilities nor obligations within the NFV internals. 103 1.2. Major Issue 105 The most significant issue related to remote attestation is that the 106 stakeholders may be constrained with regards to the information 107 available to them. This means that in a strict model that involves a 108 multi-vendor NFV deployment, access to certain information may only 109 be available to one particular stakeholder. For instance, the CSP 110 may only have direct access to the collected platform information and 111 not to the information of provisioned VMs. Similarly, the CSC may be 112 limited to the information collected on the provisioned VMs and does 113 not have access to the information of the platform. This issue can 114 be resolved by generally allowing the access to the information to 115 all interested entities, w.r.t. a relaxed model, or allowing the 116 access based on the enforcement of access permission policies. 118 More severe is the information necessary to carry out an appraisal of 119 the measured information, that is the information about the expected 120 configuration of the specific entity. 122 In principle there are two concerns, either this appraisal 123 information should not be made available to a different entity (a 124 stakeholder from a different organization) or the other entity does 125 not want to carry out the appraisal by itself for any system not 126 under its control. This means, even under the consideration that the 127 collected information is shared between multiple stakeholders, the 128 information necessary for carrying out the appraisal may not be 129 available for different reasons. 131 To simplify the terminology, this contribution distinguishes between 132 Remote Attestation Information Providers (RAIP) and Remote 133 Attestation Information Consumers (RAIC). In particular: 135 o CSP is limited to acting only as a RAIP for all authorized 136 entities 138 o CSC is limited to acting as a RAIP for all authorized entities and 139 is a specific RAIC of CSP 141 o RATP is limited to acting as a RAIP for all authorized entities 142 and is a specific RAIC of CSP and CSC 144 Furthermore a new term, the Level of Assurance (LoA) is introduced. 145 The LoA is defined as an hierarchical model that specifies the 146 systems and components to be attested and whether an attestation is 147 carried out on a local or remote basis. 149 With regards to this document, the overall targeted LoA equivalent to 150 the NFV defined LoA levels 4 and 5 that corresponds to the remote 151 attestation of the VMMs and VMs including the appraisal of load and 152 runtime of applications within the VM's scope. 154 2. Terminology 156 2.1. Key Words 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2.2. Definition of Terms 164 3. Remote Attestation Use Cases 166 With regard to the main issue mentioned above, there are two options: 168 o Decentralized Model: Each entity carries out the remote 169 attestation only for the particular system under its control. 170 This is referred to as the decentralized remote attestation model 171 and involved multiple remote attestation servers. 173 o Centralized Model: A new entity, referred to as a Remote 174 Attestation Trusted Party (RATP), is introduced that has access to 175 all information necessary to carry out a remote attestation on its 176 own. This is referred to as the centralized remote attestation 177 model. 179 However, the goal of the remote attestation is to convince an 180 internal or external entity that a specific service (a networking 181 function) has been provided by a trusted VM that was executed on a 182 trusted VMM. For case (1.) this implies that the internal or 183 external entity that want to know about the trustworthiness of a 184 service must inherently trust the appraised results of both, the CSP 185 and CSC. For case (2.) this means that the internal or external 186 entity must only trust in the decision made by the RATP. 188 3.1. Decentralized Model Use Case 190 In this case there are multiple independent remote attestation 191 servers controlled and maintained by the CSP or CSC stakeholders. 193 Assumptions: 195 o It is assumed that the model satisfies LoA of 4 and 5 197 Pre-Conditions: 199 o Relevant collected evidence (RA measurement information) is 200 available. Access permissions policies are either defined or 201 enforced, or information is available to all RAICs. 203 o Role-specific RA appraisal information is available to the RAIC, 204 but limited to the systems and components directly managed by the 205 corresponding stakeholder. 207 Use case description: 209 A deployed NFV system consists of multiple RAIPs and RAICs that are 210 under the control of stakeholders from different organizations. The 211 RAIPs collect evidence on systems and offer this information, for the 212 purpose of appraising them, to RAICs that are also under the control 213 of stakeholders from the same organization. 215 For example, any RAIP under the control of stakeholder S1 will only 216 share its collected evidence with RAICs that are also under the 217 control of stakeholder S1. 219 In addition, the information necessary to carry out an appraisal of 220 the collected evidences (i.e., the RA appraisal information) are 221 limited; RAICs from stakeholder S1 only have access to appraisal 222 information for RAIPs that are under the control of the same 223 stakeholder, i.e. S1. For this reason, a RAIC can only appraise 224 collected evidence from a RAIP operated by the same stakeholder. 226 For example, there is RAIP1 (i.e. a VMM) and RAIC1 both under the 227 control of CSP. RAIC1 receives the collected evidence from RAIP1, 228 appraises it and makes a statement based on the appraised evidence 229 (i.e. AR1). 231 VMM 232 -------- -------- ----- 233 CSP: |RAIP 1| ---> |RAIC 1| --> |AR1| 234 -------- -------- ----- 236 Similarly, there is RAIP2 (i.e. a VM instantiated on top of CSP's 237 VMM) and RAIC2 both under the control of CSC. RAIC2 receives the 238 collected evidence from RAIP2, appraises it and makes a statement 239 based on the appraised evidence (i.e. AR2). 241 VM 242 -------- -------- ----- 243 CSC: |RAIP 2| ---> |RAIC 2| --> |AR2| 244 -------- -------- ----- 246 Under the consideration of the requirements defined by LoA 4 and 5 a 247 single RAIC does not have the capability to satisfy these 248 requirements. More specifically this means that at least CSP's and 249 CSC's RAICs must work together to be compliant to LoA 4 and 5 250 requirements. As a result, RAICs may share appraisal results with 251 other RAICs or other external entities. This sharing may be 252 constrained by access permission policies. For instance an external 253 entity may request AR1 from RAIC1 and AR2 from RAIC2 and derive AR12 254 under the assumption it trusts the individual appraised results from 255 either RAIC. 257 -------- -------- ----- 258 |RAIP 1| ---> |RAIC 1| -->|AR1|--| 259 -------- -------- ----- | ----------------- ------ 260 |---> |external entity|---->|AR12| 261 -------- -------- ----- | ----------------- ------ 262 |RAIP 2| ---> |RAIC 2| -->|AR2|--| 263 -------- -------- ----- 265 However, the appraisal result generated from any other system but a 266 RAIC (e.g. derived by an arbitrary external entity) is not trusted by 267 any other entity (e.g. CSP, CSC or CSU). This mean that in this 268 case AR12 only has any semantic meaning for the system (i.e. external 269 entity) who derived it. 271 Alternatively, RAIC2 may use AR1 as an additional input to RAIP2's 272 collected evidence input and derive AR12 accordingly. This is also 273 under the consideration that RAIC2 implicitly trusts the statement 274 made by RAIC1. 276 VMM 277 -------- -------- ----- 278 CSP: |RAIP 1| ---> |RAIC 1| --> |AR1| 279 -------- -------- ----- 280 | 281 ,----------' 282 | 283 VM v 284 -------- -------- ------ 285 CSC: |RAIP 2| ---> |RAIC 2| --> |AR12| 286 -------- -------- ------ 288 In this case, AR12 is derived from CSC's RAIC and therefore other 289 systems do trust this statement because it came from an authorized 290 entity within the system. 292 See the summary table as below: 294 +-------------+------------+-------------+-----------+------------+ 295 | | CSP | CSC | CSU | External | 296 | | | | | Entity | 297 +=============+============+=============+===========+============+ 298 | Provides | anyone | anyone | - | - | 299 | RA | authorized | authorized | | | 300 | measurement | | | | | 301 | information | | | | | 302 | | | | | | 303 +-------------+------------+-------------+-----------+------------+ 304 | Has RA | Only CSP | Only CSC | - | - | 305 | appraisal | | | | | 306 | information | | | | | 307 | | | | | | 308 +-------------+------------+-------------+-----------+------------+ 309 | Provides | anyone | anyone | - | - | 310 | RA | authorized | authorized | | | 311 | appraisal | | | | | 312 | results | | | | | 313 | | | | | | 314 +-------------+------------+-------------+-----------+------------+ 315 | Has | From CSP | From CSC | From CSC | From CSC | 316 | access to | and, if | and, if | or CSP | or CSP | 317 | RA | eligible, | eligible, | (if | (if | 318 | Appraisal | CSC | CSP | eligible) | eligible) | 319 | Results | | | | | 320 | | | | | | 321 +-------------+------------+-------------+-----------+------------+ 323 3.2. Centralized Model (in a Single Trust Domain) Use Case 325 In this case there are multiple independent remote attestation 326 servers controlled and maintained by the CSP or CSC stakeholders. 328 Assumptions: 330 o It is assumed that the model satisfies LoA of 4 and 5 332 Pre-Conditions: 334 o Relevant collected evidence (RA measurement information) is 335 available to RATP without any restriction. 337 o Role-specific RA appraisal information is available to RATP 338 without any restriction. 340 Use case description: 342 A deployed NFV system consists of multiple RAIPs and RAICs that are 343 under the control of stakeholders from different organizations and, 344 in addition one RATP that is implicitly trusted by the other entities 345 in the system. The RAIPs collect evidence on systems and offer this 346 information, for the purpose of appraising them, to RAICs that are 347 also under the control of stakeholders from the same organization or 348 to RATP. 350 For example, any RAIP under the control of stakeholder S1 will only 351 share its collected evidence with RAICs that are also under the 352 control of stakeholder S1 and RATP. 354 In addition, the information necessary to carry out an appraisal of 355 the collected evidences (i.e., the RA appraisal information) are 356 limited; RAICs from stakeholder S1 only have access to appraisal 357 information for RAIPs that are under the control of the same 358 stakeholder, i.e. S1. 360 In contrast to this, RATP has access to all appraisal information of 361 any system under evaluation from all stakeholders, i.e. CSP and CSC. 363 Similar to use-case 1, a RAIC can only appraise collected evidence 364 from a RAIP operated by the same stakeholder, whereas RATP can 365 appraise collected evidence from all stakeholders. 367 For example, there is RAIP1 (i.e. a VMM) under the control of CSP and 368 RATP. RATP receives the collected evidence from RAIP1, appraises it 369 and makes a statement based on the appraised evidence (i.e. AR1). 371 VMM 372 -------- ------ ----- 373 CSP: |RAIP 1| ---> |RATP| --> |AR1| 374 -------- ------ ----- 376 Similarly, there is RAIP2 (i.e. a VM instantiated on top of CSP's 377 VMM) under the control of CSC and RATP. RAIC2 receives the collected 378 evidence from RAIP2, appraises it and makes a statement based on the 379 appraised evidence (i.e. AR2). 381 VM 382 -------- ------ ----- 383 CSC: |RAIP 2| ---> |RATP| --> |AR2| 384 -------- ------ ----- 386 Under the consideration of the requirements defined by LoA 4 and 5, 387 RATP satisfies these requirements under the assumption that it 388 received the correlated collected evidences from both VMM and VM. 389 RATP may share its appraisal results with any other entity, however, 390 access permissions policies may constrain access to the information. 391 For instance, considering access permissions allow it, an external 392 entity may request AR12 from RATP. 394 -------- 395 |RAIP 1| -, 396 -------- | ------ ------ ----------------- 397 -> |RATP| ---> |AR12| -> |external entity| 398 -------- | ------ ------ ----------------- 399 |RAIP 2| -' 400 -------- 402 Important to note in this case is that the appraisal result provided 403 by RATP is ultimately trusted by all participating systems from any 404 stakeholder and all external entities the request this appraisal 405 result. 407 See the summary table as below: 409 +-------------+-----------+-----------+-----------+-----------+-----------+ 410 | | CSP | CSC | CSU | RATP | External | 411 | | | | | | System | 412 +=============+===========+===========+===========+===========+===========+ 413 | Provides | To RATP | To RATP | - | - | | 414 | RA | or CSP | or CSC | | | | 415 | measurement | | | | | | 416 | information | | | | | | 417 +-------------+-----------+-----------+-----------+-----------+-----------+ 418 | Has RA | Only CSP | Only CSC | - | CSP and | | 419 | appraisal | | | | CSC | | 420 | information | | | | | | 421 +-------------+-----------+-----------+-----------+-----------+-----------+ 422 | Provides RA | - | - | - | For CSP, | | 423 | appraisal | | | | CSC, CSU, | | 424 | results | | | | External | | 425 | | | | | system | | 426 | | | | | (access | | 427 | | | | | restricti | | 428 | | | | | ons | | 429 | | | | | may be | | 430 | | | | | defined) | | 431 +-------------+-----------+-----------+-----------+-----------+-----------+ 432 | Has access | From RATP | From RATP | From RATP | From RATP | From RATP | 433 | to RA | | | | | | 434 | Appraisal | (if | (if | (if | (if | (if | 435 | results | eligible) | eligible) | eligible) | eligible) | eligible) | 436 | | | | | | | 437 | | | | | | | 438 +-------------+-----------+-----------+-----------+-----------+-----------+ 440 4. IANA Considerations 442 This document makes no request of IANA. 444 Note to RFC Editor: this section may be removed on publication as an 445 RFC. 447 5. Security Considerations 449 To be added. 451 6. Acknowledgements 452 7. Normative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, 456 DOI 10.17487/RFC2119, March 1997, 457 . 459 Authors' Addresses 461 Andre Rein 462 Huawei 464 Email: Andre.Rein@huawei.com 466 Liang Xia 467 Huawei 469 Email: frank.xialiang@huawei.com