idnits 2.17.1 draft-xia-rats-pubsub-model-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 8 instances of too long lines in the document, the longest one being 5 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 (October 21, 2019) is 1643 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Attester' is mentioned on line 152, but not defined == Missing Reference: 'Verifier' is mentioned on line 152, but not defined == Outdated reference: A later version (-03) exists of draft-birkholz-rats-architecture-02 == Outdated reference: A later version (-01) exists of draft-birkholz-rats-information-model-00 == Outdated reference: A later version (-03) exists of draft-birkholz-rats-reference-interaction-model-01 == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-01 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-01 == Outdated reference: A later version (-08) exists of draft-richardson-rats-usecases-05 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Remote ATtestation ProcedureS L. Xia 3 Internet-Draft W. Pan 4 Intended status: Standards Track Huawei 5 Expires: April 23, 2020 October 21, 2019 7 Using Netconf Pub/Sub Model for RATS Interaction Procedure 8 draft-xia-rats-pubsub-model-01 10 Abstract 12 This draft defines the a new method of using the netconf pub/sub 13 model in the RATS interaction procedure, to increse its flexibility, 14 efficiency and scalability. 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 April 23, 2020. 33 Copyright Notice 35 Copyright (c) 2019 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 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 52 3. Pub/sub Model for Remote Attestation Procedure . . . . . . . 4 53 3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Remote Attestation Event Stream Definition . . . . . . . 7 55 3.3. Remote Attestation Subscription Definition . . . . . . . 8 56 3.4. Remote Attestation Selection Filters Definition . . . . . 8 57 3.5. Remote Attestation Subscription Parameters Handling . . . 9 58 3.6. Remote Attestation Notification Distribution . . . . . . 9 59 3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4. The YANG Module for Sub/pub Model Remote Attestation 61 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 4.1. Tree Format . . . . . . . . . . . . . . . . . . . . . . . 12 63 4.2. Raw Format . . . . . . . . . . . . . . . . . . . . . . . 12 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 8.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 Remote attestation is for acquiring the evidence about various 75 integrity information from remote endpoints to assess its 76 trustworthiness (aka, behave in the expected manner). These evidence 77 should be about: system component identity, composition of system 78 components, roots of trust, system component integrity, system 79 component configuration, operational state and so on. 80 [I-D.richardson-rats-usecases] describes possible use cases which 81 remote attestation are using for different industries, like: network 82 devices, FIDO authentication for onlline transaction, Cryptographic 83 Key Attestation for mobile devices, and so on. 85 [I-D.birkholz-rats-architecture] lays a foundation of RATS 86 architecture about the key RATS roles (i.e., Relying Party, Verifier, 87 Attester and asserter) and the messages they exchange, as well as 88 some key concepts. Based on it, 89 [I-D.birkholz-rats-reference-interaction-model] specifies a basic 90 challenge-response-based interaction model for the remote attestation 91 procedure, which a complete remote attestation procedure is triggered 92 by a challenge message originated from the verifier, and finished 93 when the attester sends its response message back. This is a very 94 generic interaction model with wide adoption. This document proposes 95 an alternative interaction model for Remote attestation procedure, by 96 customizing the IETF NETCONF pub/sub model 97 [RFC8639][RFC8640][RFC8641]. With its nature of asynchronous 98 communication, the new pub/sub model for remote attestation procedure 99 is optimal for large-scale and loosely coupled distributed systems, 100 especially for the network devices, which has the advantages as: 101 loose coupling, scalability, time delivery sensitivity, supporting 102 filtering capability, and so on. The pub/sub model can be used 103 independently, or together with the challenge-response model to 104 complement each other as a whole. Note that in which way these 105 models are combinded together are currently out of the scope of this 106 draft. 108 In summary, by untilizing the pub/sub model in remote attestation 109 procedure, the gained benefits are as below: 111 o Flexibility: the verifier does not need to send the challenge 112 message every time. The whole thing of the verifier is to 113 subscibe a topic to the attester and then to anticipate the period 114 or timely on-change notification from the attester about its 115 integrity evidence. 117 o Efficiency: once the verifier has subscribed its interested topics 118 related with its triggering condition to the attester, it will get 119 all the condition triggerd notifications on time, which are the 120 integrity related evidence for remote attestation in fact. It 121 will ensure any integrity change/deviation of the remote endpoint 122 to be detected with the minimum latency. 124 o Scalability: it will save a lot of challenge messages by replacing 125 with single subscription message for one topic stream, and 126 decrease the total number of stateful connection between the 127 verifier and attester, especially for a very large scale network. 128 Thus, the scalability of the solution will increase. 130 This document is organized as follows. Section 2 defines conventions 131 and acronyms used. Section 3 discusses pub/sub model of remote 132 attestation procedure. 134 2. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 This document uses terminology defined in[I-D.birkholz-rats-architect 141 ure][I-D.birkholz-rats-reference-interaction-model] for security 142 related and RATS scoped terminology. 144 3. Pub/sub Model for Remote Attestation Procedure 146 3.1. Solution Overview 148 The following sequence diagram illustrates the reference remote 149 attestation procedure by utilizing the netconf pub/sub model defined 150 by this document. 152 [Attester] [Verifier] 153 | | 154 | <--Sub(nonce,authSecID,assertionSelection, event/period) | 155 | | 156 collectAssertions(assertionSelection) | 157 | => assertions | 158 | | 159 signAttestationEvidence(authSecID, assertions, nonce) | 160 | => signedAttestationEvidence | 161 | | 162 | signedAttestationEvidence ----------------------------------> | 163 | | 164 | verifyAttestationEvidence(signedAttestationEvidence, refAssertions) 165 | attestationResult <= | 166 | | 167 | ............................................................. | 168 | | 169 collectAssertions(assertionSelection) | 170 | => assertions | 171 | | 172 signAttestationEvidence(authSecID, assertions, nonce) | 173 | => signedAttestationEvidence | 174 | | 175 | signedAttestationEvidence ----------------------------------> | 176 | | 177 | verifyAttestationEvidence(signedAttestationEvidence, refAssertions) 178 | attestationResult <= | 179 | | 180 | ............................................................. | 181 | | 182 | | 183 |on-change/event happens | 184 | | | 185 | \|/ | 186 collectAssertions(assertionSelection) | 187 | => assertions | 188 | | 189 signAttestationEvidence(authSecID, assertions, nonce) | 190 | => signedAttestationEvidence | 191 | | 192 | signedAttestationEvidence ----------------------------------> | 193 | | 194 | verifyAttestationEvidence(signedAttestationEvidence, refAssertions) 195 | attestationResult <= | 196 | | 197 | ............................................................. | 199 Figure 1: Pub/sub model of Remote Attestation 201 In short, the basic idea of pub/sub model for remote attestation is 202 the verifier subscribes its interested event streams about the 203 integrity evidence to the attester. After the subscription succeeds, 204 the attester sends the subscribed integrity evidence back to the 205 verifier. During subscription, the verifier may also specify how the 206 attester returns the subscribed information, that is, the upate 207 trigger as periodic subscription or on-change subscription. And when 208 the selection filters are applied to the subscription, only the 209 information that pass the filter will be distributed out. 211 More detailed, the key steps of the remote attestation workflow with 212 this model can be summarized as below (using the network devices as 213 the example): 215 o The verifier subscribes its interested event streams about the 216 integrity evidence to the attester. More specifically: 218 * The event stream here refers to various integrity evidence 219 information related to device trustworthiness. The basic event 220 streams may include: software integrity information (including 221 PCR values and system boot logs) of each layer of the trust 222 chain recorded during device booting time; device identity 223 certificates & Attestation Key certificate; operating system, 224 application dynamic integrity information (e.g., IMA logs) and 225 the device configuration information recorded during device 226 running time. 228 * Periodic subscription is mainly used by the verifier for the 229 general and non-critical information collection, which are not 230 strictly time sensitive and aims for collecting the latest 231 integrity evidence and checking the possible deviation. In 232 contrary, on-change subscription is basically used to to 233 monitor the critical integrity evidence (e.g., integrity values 234 and log files during device booting time, or integrity values 235 of some key service processes). If these integrity values 236 change, notifications are sent immediately. 238 * The selection filters may be applied to the subscription, so 239 that only the event records that pass the filter will be 240 distributed out. Some specific examples include: event records 241 of a component (e.g., line card) in the composite device, the 242 event records in a specific time period that includes a start 243 time and an end time, and so on. 245 o Consider how to send the existing parameters (i.e., nonce, hash 246 signature algorithm, and specified TPM name, etc.) carried in the 247 challenge message of the previous challenge-response model to the 248 attester through the subscription message of the new sub/pub model 249 in advance, and the follow-up usage of them. A very important 250 point is how to ensure that the nonce carried in every 251 notification message is different, and both the attester and the 252 verifier know the correct value in advance. 254 o Both configuration subscription and dynamic subscription are 255 considered. More specifically: 257 * Configure subscription is for the important security event 258 stream. For example, it enables the monitoring the important 259 integrity information by using the on-change mode. 261 * Dynamic subscription is for the normal integrity information, 262 that is, periodically receive those related information during 263 NETCONF Session. The corresponding subscription RPC needs to 264 be established dynamically. This way can reduce unnecessary 265 NETCONF sessions. 267 o In addition to the update trigger of on-change, the other possible 268 update trigger may be certain pre-defined events according to 269 [I-D.bryskin-netconf-automation-yang], that is: When these events 270 occur, the specified integrity information is triggered to be 271 sent, which is the relevant event stream plus optional selection 272 filter. The events may include: device startup completion, device 273 upgrade completion, specific attack event, active/standby 274 switchover, line card insertion/removal/switchover, certificate 275 life cycle event (expiration), etc. 277 o The attester notification delivery mechanisms thus vary as the 278 above subscription mechanisms of verifier vary. 280 The following sections decribe the above key steps one by one. 282 3.2. Remote Attestation Event Stream Definition 284 The event streams here refers to various integrity evidence 285 information related to device trustworthiness. The basic event 286 streams may include: software integrity information (including PCR 287 values and system boot logs) of each layer of the trust chain 288 recorded during device booting time, device identity certificates & 289 Attestation Key certificate generation, operating system and 290 application dynamic integrity information (e.g., IMA logs) recorded 291 during device running time. 293 The event streams are created and managed by the attester. And their 294 formal definition should be conformed to the information model 295 definition like Attestation Evidence or others in 296 [I-D.birkholz-rats-information-model], and the claim data model 297 definition in [I-D.birkholz-rats-basic-yang-module] with YANG data 298 format, and [I-D.ietf-rats-eat] with COSE data format. 300 3.3. Remote Attestation Subscription Definition 302 NETCONF pub/sub model provides several suscription types in which 303 approriate one or more types are choosed and possibly used together 304 to meet the service requirements. 306 Particularly, periodic subscription is mainly used by the verifier 307 for the general and non-critical information collection, which are 308 not strictly time sensitive and aims for collecting the latest 309 integrity information and checking the possible deviation. In 310 contrary, on-change subscription is basically used to monitor the 311 critical integrity evidence (e.g., integrity values and log files 312 during device booting time, or integrity values of some key service 313 processes). If these integrity values change, notifications are sent 314 immediately. 316 Besides, both configuration subscription and dynamic subscription are 317 considered. In which, configure subscription is for the important 318 security data stream as it lasts even the NETCONF session is closed. 319 For example, it enables the monitoring of the status of important 320 security event stream by using the on-change mode. On the other 321 hand, dynamic subscription is for the general security event stream, 322 that is, periodically receive those related information during 323 NETCONF Session. The corresponding subscription RPC needs to be 324 established dynamically. This way can reduce unnecessary NETCONF 325 sessions. 327 Furthermore, certain pre-defined events can be the update trigger 328 too, that is: When these events occur, the specified integrity 329 information is triggered to be sent, which is the relevant event 330 stream plus optional selection filter. The events may include: 331 device startup completion, device upgrade completion, specific attack 332 event, active/standby switchover, line card insertion/removal/ 333 switchover, certificate life cycle event (expiration), etc. 335 3.4. Remote Attestation Selection Filters Definition 337 The selection filters may be applied to the subscription, so that 338 only the event that pass the filter will be distributed out. 340 A concrete example of selection filter is limiting the delivered 341 event stream to those originated from a specific component with id 342 ("xxxxxxxxxx") of a designated vendor ("xxx-vendor-device"). 344 3.5. Remote Attestation Subscription Parameters Handling 346 Most of the parameters carried in the subscription message are not 347 changed during the remote attestation procedure, like: hash signature 348 algorithm, specified TPM name and so on. Their main goal is to 349 enable the dynamic negotiation with the attester about what 350 information the verifier needs and how to construct them together. A 351 very important point is how to ensure that the nonce carried in every 352 notification message is different, and both the attester and the 353 verifier know the correct value in advance. For this purpose, the 354 basic idea is to ensure that the nonce in two sides of the 355 communication is synchronously changed, and the randomness of the 356 nonce is maintained. Specifically, there may be several ways to do 357 it: 359 o Verifier sends a seed with hash algorithm to the attester in the 360 subscription message, and then perform the synchronization 361 operation on both sides. 363 o In fact, the nonce does not need to be random every time. As long 364 as the receive endpoint (here for verifier) can identify 365 duplicated packets, other means may be used. For example: The 366 timestamp and increasing count. 368 o The RATS TUDA mechanism [I-D.birkholz-rats-tuda] can also be used 369 here to ensure the freshness of information. 371 3.6. Remote Attestation Notification Distribution 373 To be written. 375 3.7. Summary 377 Based on the above discussion, this section gives some examples to 378 illustrate the overall application of sub/pub model to remote 379 attestation procedure. 381 Below is a configured subscription example with on-change update 382 trigger, with specific contents as: 384 o There are 3 integrity evidence related event streams as follows: 385 pcr-trust-evidence, bios-log-trust-evidence and ima-log-trust- 386 evidence. The subscribed one is pcr-trust-evidence. 388 o The other parameters of the subscription include: pcr-list: {{1, 389 3, 7}}, tcg-hash-algo-id: TPM_ALG_SHA256, nonce-value: 0x564ac291, 390 TPM_ALG_ID-value: TPM_ALG_ECDSA, pub-key-id: 0x784a22bf, tpms: 391 {"tpm1"}. 393 o The selection filter is set as follows: a specific component with 394 id ("xxxxxxxxxx") of a designated vendor ("xxx-vendor-device"). 396 397 399 400 100 401 pcr-trust-evidence 402 403 405 xxxxxxxxxx 406 407 408 409 410 1 411 3 412 7 413 414 TPM_ALG_SHA256 415 416 417 418 0x564ac291 419 TPM_ALG_ECDSA 420 0x784a22bf 421 422 tpm1 423 424 425 100 426 427 428 429 431 Figure 2: Configured On-change Subscription Message 433 Below is a dynamic subscription RPC example with periodic update 434 trigger, with specific contents as: 436 o There are 3 integrity evidence related event streams as follows: 437 pcr-trust-evidence, bios-log-trust-evidence and ima-log-trust- 438 evidence. The subscribed one is bios-log-trust-evidence. 440 o The other parameters of the dynamic subscription include: tpms: 441 {"tpm1"}, last-entry-value: 0xa34568baac79, log-type: bios, pcr- 442 list: {{2, 4, 8}}, tcg-hash-algo-id: TPM_ALG_SHA256. 444 o The selection filter is set as follows: a specific component with 445 id ("xxxxxxxxxx") of a designated vendor ("xxx-vendor-device"). 447 o Subscription period: 500 centiseconds. 449 451 453 bios-log-trust-evidence 454 455 457 xxxxxxxxxx 458 459 460 461 tpm1 462 463 0xa34568baac79 464 bios 465 466 467 2 468 4 469 8 470 471 TPM_ALG_SHA256 472 473 474 475 476 500 477 478 479 481 Figure 3: Dynamic Periodic Subscription Message 483 Below is a configured subscription RPC example with pre-defined 484 events as the update trigger, with specific contents as: 486 o There are 3 integrity evidence related event streams as follows: 487 pcr-trust-evidence, bios-log-trust-evidence and ima-log-trust- 488 evidence. The subscribed one is pcr-trust-evidence. 490 o The other parameters of the subscription include: pcr-list: {{1, 491 3, 7}}, tcg-hash-algo-id: TPM_ALG_SHA256, nonce-value: 0x564ac291, 492 TPM_ALG_ID-value: TPM_ALG_ECDSA, pub-key-id: 0x784a22bf, tpms: 493 {"tpm1"}. 495 o The selection filter is set as follows: a specific component with 496 id ("xxxxxxxxxx") of a designated vendor ("xxx-vendor-device"). 498 o The event which triggers the intergrity evidence delivery is 499 defined as: id: 1001, type: master-slave-swithover 501 Figure 4: Configured Event-triggered Subscription Message 503 4. The YANG Module for Sub/pub Model Remote Attestation Procedures 505 4.1. Tree Format 507 To be written. 509 4.2. Raw Format 511 To be written. 513 5. Security Considerations 515 To be written 517 6. Acknowledgements 519 Thanks to ... 521 7. IANA Considerations 523 To be written, possibly. 525 8. References 527 8.1. Normative References 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, 531 DOI 10.17487/RFC2119, March 1997, 532 . 534 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 535 E., and A. Tripathy, "Subscription to YANG Notifications", 536 RFC 8639, DOI 10.17487/RFC8639, September 2019, 537 . 539 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 540 E., and A. Tripathy, "Dynamic Subscription to YANG Events 541 and Datastores over NETCONF", RFC 8640, 542 DOI 10.17487/RFC8640, September 2019, 543 . 545 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 546 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 547 September 2019, . 549 8.2. Informative References 551 [I-D.birkholz-rats-architecture] 552 Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith, 553 "Remote Attestation Procedures Architecture", draft- 554 birkholz-rats-architecture-02 (work in progress), 555 September 2019. 557 [I-D.birkholz-rats-basic-yang-module] 558 Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, 559 E., Xia, L., Laffey, T., and G. Fedorkow, "YANG Module for 560 Basic Challenge-Response-based Remote Attestation 561 Procedures", draft-birkholz-rats-basic-yang-module-01 562 (work in progress), July 2019. 564 [I-D.birkholz-rats-information-model] 565 Birkholz, H. and M. Eckel, "An Information Model for 566 Assertions used in RATS", draft-birkholz-rats-information- 567 model-00 (work in progress), July 2019. 569 [I-D.birkholz-rats-reference-interaction-model] 570 Birkholz, H. and M. Eckel, "Reference Interaction Model 571 for Challenge-Response-based Remote Attestation", draft- 572 birkholz-rats-reference-interaction-model-01 (work in 573 progress), July 2019. 575 [I-D.birkholz-rats-tuda] 576 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 577 "Time-Based Uni-Directional Attestation", draft-birkholz- 578 rats-tuda-01 (work in progress), September 2019. 580 [I-D.bryskin-netconf-automation-yang] 581 Bryskin, I., Liu, X., Clemm, A., Birkholz, H., and T. 582 Zhou, "Generalized Network Control Automation YANG Model", 583 draft-bryskin-netconf-automation-yang-03 (work in 584 progress), July 2019. 586 [I-D.ietf-rats-eat] 587 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 588 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 589 ietf-rats-eat-01 (work in progress), July 2019. 591 [I-D.richardson-rats-usecases] 592 Richardson, M., Wallace, C., and W. Pan, "Use cases for 593 Remote Attestation common encodings", draft-richardson- 594 rats-usecases-05 (work in progress), October 2019. 596 Authors' Addresses 598 Liang Xia (Frank) 599 Huawei 600 101 Software Avenue, Yuhuatai District, 601 Nanjing, Jiangsu 210012 602 China 604 Email: frank.xialiang@huawei.com 606 Wei Pan 607 Huawei 608 101 Software Avenue, Yuhuatai District 609 Nanjing, Jiangsu 210012 610 China 612 Email: william.panwei@huawei.com