idnits 2.17.1 draft-xia-rats-pubsub-model-02.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 (February 27, 2020) is 1518 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 156, but not defined == Missing Reference: 'Verifier' is mentioned on line 156, but not defined == Outdated reference: A later version (-03) exists of draft-birkholz-rats-reference-interaction-model-02 == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-01 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-01 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-03 == Outdated reference: A later version (-22) exists of draft-ietf-rats-yang-tpm-charra-00 == Outdated reference: A later version (-08) exists of draft-richardson-rats-usecases-06 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: August 30, 2020 February 27, 2020 7 Using NETCONF Pub/Sub Model for RATS Interaction Procedures 8 draft-xia-rats-pubsub-model-02 10 Abstract 12 This draft defines a new method of using the netconf pub/sub model in 13 the RATS interaction procedure, to increase 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 August 30, 2020. 33 Copyright Notice 35 Copyright (c) 2020 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 . . . . . 9 57 3.5. Remote Attestation Subscription Parameters Handling . . . 9 58 3.6. Remote Attestation Notification Distribution . . . . . . 10 59 3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 4. The YANG Module for Sub/pub Model Remote Attestation 61 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 4.1. Tree Format . . . . . . . . . . . . . . . . . . . . . . . 13 63 4.2. Raw Format . . . . . . . . . . . . . . . . . . . . . . . 13 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 68 7.2. Informative References . . . . . . . . . . . . . . . . . 14 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 online transaction, Cryptographic 83 Key Attestation for mobile devices, and so on. 85 [I-D.ietf-rats-architecture] lays a foundation of RATS architecture 86 about the key RATS roles (i.e., Relying Party, Verifier, Attester and 87 asserter) and the messages they exchange, as well as some key 88 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 NETCONF pub/sub model [RFC8639][RFC8640][RFC8641]. 97 YANG push [RFC8641] is basically an extensive NETCONF pub/sub model 98 mainly for the YANG datastore. With the nature of asynchronous 99 communication, the pub/sub model for remote attestation procedure is 100 optimal for large-scale and loosely coupled distributed systems, 101 especially for the network devices, which has the advantages as: 102 loose coupling, scalability, time delivery sensitivity, supporting 103 filtering capability, event-driven and so on. The pub/sub model can 104 be used independently, or together with the challenge-response model 105 to complement each other as a whole. Note that in which way these 106 models are combined together are currently out of the scope of this 107 draft. 109 In summary, by utilizing the pub/sub model in remote attestation 110 procedure, the gained benefits are as below: 112 o Flexibility: the verifier does not need to send the challenge 113 message every time. The whole thing of the verifier is to 114 subscribe a topic to the attester and then to anticipate the 115 period or timely on-change notification from the attester about 116 its integrity evidence. 118 o Efficiency: once the verifier has subscribed its interested topics 119 related with its triggering condition to the attester, it will get 120 all the condition triggered notifications on time, which are the 121 integrity related evidence for remote attestation in fact. It 122 will ensure any integrity change/deviation of the remote endpoint 123 to be detected with the minimum latency. 125 o Scalability: it will save a lot of challenge messages by replacing 126 with single subscription message for one topic stream, and 127 decrease the total number of stateful connection between the 128 verifier and attester, especially for a very large scale network. 129 Thus, the scalability of the solution will increase. 131 This document is organized as follows. Section 2 defines conventions 132 and acronyms used. Section 3 discusses pub/sub model of remote 133 attestation procedure. 135 2. Conventions Used in This Document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 This document uses terminology defined in 144 [I-D.ietf-rats-architecture] and 145 [I-D.birkholz-rats-reference-interaction-model] for security related 146 and RATS scoped terminology. 148 3. Pub/sub Model for Remote Attestation Procedure 150 3.1. Solution Overview 152 The following sequence diagram illustrates the reference remote 153 attestation procedure by utilizing the NETCONF pub/sub model defined 154 by this document. 156 [Attester] [Verifier] 157 | | 158 | <--Sub(nonce,authSecID,assertionSelection, event/period) | 159 | | 160 collectAssertions(assertionSelection) | 161 | => assertions | 162 | | 163 signAttestationEvidence(authSecID, assertions, nonce) | 164 | => signedAttestationEvidence | 165 | | 166 | signedAttestationEvidence ----------------------------------> | 167 | | 168 | verifyAttestationEvidence(signedAttestationEvidence, refAssertions) 169 | attestationResult <= | 170 | | 171 | ............................................................. | 172 | | 173 collectAssertions(assertionSelection) | 174 | => assertions | 175 | | 176 signAttestationEvidence(authSecID, assertions, nonce) | 177 | => signedAttestationEvidence | 178 | | 179 | signedAttestationEvidence ----------------------------------> | 180 | | 181 | verifyAttestationEvidence(signedAttestationEvidence, refAssertions) 182 | attestationResult <= | 183 | | 184 | ............................................................. | 185 | | 186 | | 187 |on-change/event happens | 188 | | | 189 | \|/ | 190 collectAssertions(assertionSelection) | 191 | => assertions | 192 | | 193 signAttestationEvidence(authSecID, assertions, nonce) | 194 | => signedAttestationEvidence | 195 | | 196 | signedAttestationEvidence ----------------------------------> | 197 | | 198 | verifyAttestationEvidence(signedAttestationEvidence, refAssertions) 199 | attestationResult <= | 200 | | 201 | ............................................................. | 203 Figure 1: Pub/sub model of Remote Attestation 205 In short, the basic idea of pub/sub model for remote attestation is 206 the verifier subscribes its interested event streams about the 207 integrity evidence to the attester. The event streams can be in the 208 YANG datastore, or not. After the subscription succeeds, the 209 attester sends the subscribed integrity evidence back to the 210 verifier. During subscription, the verifier may also specify how the 211 attester returns the subscribed information, that is, the update 212 trigger as periodic subscription or on-change subscription. And when 213 the selection filters are applied to the subscription, only the 214 information that pass the filter will be distributed out. 216 More detailed, the key steps of the remote attestation workflow with 217 this model can be summarized as below (using the network devices as 218 the example): 220 o The verifier subscribes its interested event streams about the 221 integrity evidence to the attester. More specifically: 223 * The event stream here refers to various integrity evidence 224 information related to device trustworthiness, which can be in 225 YANG datastore, or not. The basic event streams may include: 226 software integrity information (including PCR values and system 227 boot logs) of each layer of the trust chain recorded during 228 device booting time; device identity certificates & Attestation 229 Key certificate; operating system, application dynamic 230 integrity information (e.g., IMA logs) and the device 231 configuration information recorded during device running time. 233 * Periodic subscription is mainly used by the verifier for the 234 general and non-critical information collection, which are not 235 strictly time sensitive and aims for collecting the latest 236 integrity evidence and checking the possible deviation. In 237 contrary, on-change subscription is basically used to to 238 monitor the critical integrity evidence (e.g., integrity values 239 and log files during device booting time, or integrity values 240 of some key service processes). If these integrity values 241 change, notifications are sent immediately. 243 * The selection filters may be applied to the subscription, so 244 that only the event records that pass the filter will be 245 distributed out. Some specific examples include: event records 246 of a component (e.g., line card) in the composite device, the 247 event records in a specific time period that includes a start 248 time and an end time, and so on. 250 o Consider how to send the existing parameters (i.e., nonce, hash 251 signature algorithm, and specified TPM name, etc.) carried in the 252 challenge message of the previous challenge-response model to the 253 attester through the subscription message of the new sub/pub model 254 in advance, and the follow-up usage of them. A very important 255 point is how to ensure that the nonce carried in every 256 notification message is different, and both the attester and the 257 verifier know the correct value in advance. 259 o Both configuration subscription and dynamic subscription are 260 considered. More specifically: 262 * Configure subscription is for the important security event 263 stream. For example, it enables the monitoring the important 264 integrity information by using the on-change mode. 266 * Dynamic subscription is for the normal integrity information, 267 that is, periodically receive those related information during 268 NETCONF Session. The corresponding subscription RPC needs to 269 be established dynamically. This way can reduce unnecessary 270 NETCONF sessions. 272 o In addition to the update trigger of on-change, the other possible 273 update trigger may be certain pre-defined events according to 274 [I-D.bryskin-netconf-automation-yang], that is: When these events 275 occur, the specified integrity information is triggered to be 276 sent, which is the relevant event stream plus optional selection 277 filter. The events may include: device startup completion, device 278 upgrade completion, specific attack event, active/standby 279 switchover, line card insertion/removal/switchover, certificate 280 life cycle event (expiration), etc. 282 o The attester notification delivery mechanisms thus vary as the 283 above subscription mechanisms of verifier vary. 285 The following sections describes the above key steps one by one. 287 3.2. Remote Attestation Event Stream Definition 289 The event streams here refers to various integrity evidence 290 information related to device trustworthiness. By definition, 291 evidence is typically a set of claims about device's software and 292 hardware platform. So, the remote attestation event stream is 293 composed by the claims. For remote attestation, the basic event 294 streams may generally include: system integrity information 295 (including PCR values and system boot logs) of each layer of the 296 trust chain recorded during device booting time, device credentials 297 and their change, operating system and files integrity information 298 (e.g., IMA logs) recorded during device running time, and so on. 300 The event streams are created and managed by the attester. And their 301 formal definition should be conformed to the information model 302 definition like Attestation Evidence or others in 303 [I-D.birkholz-rats-information-model], and the claim data model 304 definition in [I-D.ietf-rats-yang-tpm-charra] with YANG data format, 305 and [I-D.ietf-rats-eat] with COSE data format. 307 More specific, for current RATS claims YANG data model in 308 [I-D.ietf-rats-yang-tpm-charra] , the following event streams may be 309 defined if necessary: 311 o the rats-support-structures datastore node, or its subtree nodes 312 like: tpms, compute-nodes. All these nodes can be subscribed for 313 pushing their values periodically or on-change; 315 o For all the YANG RPCs, whether their output are the YANG datastore 316 nodes or information stored in the device with other way, the 317 event streams can be defined for all of them, such as: tpm12- 318 attestation-response, tpm20-attestation-response, attestation- 319 certificates and system-event-logs. If needed, the more fine- 320 grained event stream can be defined for the substructure of the 321 above, like: endorsement-cert or attestation-cer of the 322 attestation-certificates, bios-event-logs or ima-event-logs of the 323 system-event-logs. 325 3.3. Remote Attestation Subscription Definition 327 NETCONF pub/sub model provides several subscription types in which 328 approriate one or more types are chosen and possibly used together to 329 meet the service requirements. 331 Particularly, periodic subscription is mainly used by the verifier 332 for the general and non-critical information collection, which are 333 not strictly time sensitive and aims for collecting the latest 334 integrity information and checking the possible deviation. In 335 contrary, on-change subscription is basically used to monitor the 336 critical integrity evidence (e.g., integrity values and log files 337 during device booting time, or integrity values of some important 338 files). If these integrity values change, notifications are sent 339 immediately. 341 Besides, both configuration subscription and dynamic subscription are 342 considered. In which, configure subscription is for the important 343 security event stream as it lasts even the NETCONF session is closed. 344 For example, it enables the monitoring of the status of important 345 security event stream by using the on-change mode. On the other 346 hand, dynamic subscription is for the general security event stream, 347 that is, periodically receive those related information during 348 NETCONF Session. The corresponding subscription RPC needs to be 349 established dynamically. This way can reduce unnecessary NETCONF 350 sessions. 352 For the remote attestation event streams described in the previous 353 section, some relatively critical and not frequently changed ones can 354 be subscribed as the configuration and on-change subscription, so 355 that the verifier can always receive them very timely. Some examples 356 are: tpms, compute-nodes and attestation-certificates event streams. 357 In contrary, some normal and frequently changed event streams can be 358 the dynamic and/or periodic subscription, the verifier just want to 359 receive and monitor them occasionally and reduce the processing. One 360 example is ima-event-logs event stream. 362 Furthermore, certain pre-defined events according to 363 [I-D.bryskin-netconf-automation-yang], can be the update trigger too, 364 that is: When these events occur, the specified integrity information 365 is triggered to be sent, which is the relevant event stream with 366 optional selection filter. The events may include: device startup 367 completion, device upgrade completion, specific attack event, active/ 368 standby switchover, line card insertion/removal/switchover, 369 certificate life cycle event (expiration), etc. 371 3.4. Remote Attestation Selection Filters Definition 373 The selection filters may be applied to the subscription, so that 374 only the event that pass the filter will be distributed out. Both 375 the pub/sub and the YANG push selection filters can be considered. 377 A concrete example of selection filter is limiting the delivered 378 event stream to those originated from a specific component with id 379 ("xxxxxxxxxx") of a designated vendor ("xxx-vendor-device"). 381 The other example is filtering the event records in a specific time 382 period that has a start time and an end time. 384 3.5. Remote Attestation Subscription Parameters Handling 386 Most of the parameters carried in the subscription message are not 387 changed during the remote attestation procedure, like: hash signature 388 algorithm, specified TPM name and so on. Their main goal is to 389 enable the dynamic negotiation with the attester about what 390 information the verifier needs and how to construct them together. A 391 very important point is how to ensure that the nonce carried in every 392 notification message is different, and both the attester and the 393 verifier know the correct value in advance. For this purpose, the 394 basic idea is to ensure that the nonce in two sides of the 395 communication is synchronously changed, and the randomness of the 396 nonce is maintained. Specifically, there may be several ways to do 397 it: 399 o Verifier sends a seed with hash algorithm to the attester in the 400 subscription message, and then perform the synchronization 401 operation on both sides. 403 o In fact, the nonce does not need to be random every time. As long 404 as the receive endpoint (here for verifier) can identify 405 duplicated packets, other means may be used. For example: The 406 timestamp and increasing count. 408 o The RATS TUDA mechanism [I-D.birkholz-rats-tuda] can also be used 409 here to ensure the freshness of information. 411 3.6. Remote Attestation Notification Distribution 413 Basically, the remote attestation notification is the event stream in 414 the YANG notification structure, and the event stream is defined 415 above with the same YANG structure as the corresponding the YANG 416 datastore node or RPC's output. 418 More details are to be added. 420 3.7. Summary 422 Based on the above discussion, this section gives some examples to 423 illustrate the overall application of sub/pub model to remote 424 attestation procedure. 426 Below is a configured subscription example with on-change update 427 trigger, with specific contents as: 429 o There are 3 integrity evidence related event streams as follows: 430 pcr-trust-evidence, bios-log-trust-evidence and ima-log-trust- 431 evidence. The subscribed one is pcr-trust-evidence. 433 o The other parameters of the subscription include: pcr-list: {{1, 434 3, 7}}, tcg-hash-algo-id: TPM_ALG_SHA256, nonce-value: 0x564ac291, 435 TPM_ALG_ID-value: TPM_ALG_ECDSA, pub-key-id: 0x784a22bf, tpms: 436 {"tpm1"}. 438 o The selection filter is set as follows: a specific component with 439 id ("xxxxxxxxxx") of a designated vendor ("xxx-vendor-device"). 441 442 444 445 100 446 pcr-trust-evidence 447 448 450 xxxxxxxxxx 451 452 453 454 455 1 456 3 457 7 458 459 TPM_ALG_SHA256 460 461 462 463 0x564ac291 464 TPM_ALG_ECDSA 465 0x784a22bf 466 467 tpm1 468 469 470 100 471 472 473 474 476 Figure 2: Configured On-change Subscription Message 478 Below is a dynamic subscription RPC example with periodic update 479 trigger, with specific contents as: 481 o There are 3 integrity evidence related event streams as follows: 482 pcr-trust-evidence, bios-log-trust-evidence and ima-log-trust- 483 evidence. The subscribed one is bios-log-trust-evidence. 485 o The other parameters of the dynamic subscription include: tpms: 486 {"tpm1"}, last-entry-value: 0xa34568baac79, log-type: bios, pcr- 487 list: {{2, 4, 8}}, tcg-hash-algo-id: TPM_ALG_SHA256. 489 o The selection filter is set as follows: a specific component with 490 id ("xxxxxxxxxx") of a designated vendor ("xxx-vendor-device"). 492 o Subscription period: 500 centiseconds. 494 496 498 bios-log-trust-evidence 499 500 502 xxxxxxxxxx 503 504 505 506 tpm1 507 508 0xa34568baac79 509 bios 510 511 512 2 513 4 514 8 515 516 TPM_ALG_SHA256 517 518 519 520 521 500 522 523 524 526 Figure 3: Dynamic Periodic Subscription Message 528 Below is a configured subscription RPC example with pre-defined 529 events as the update trigger, with specific contents as: 531 o There are 3 integrity evidence related event streams as follows: 532 pcr-trust-evidence, bios-log-trust-evidence and ima-log-trust- 533 evidence. The subscribed one is pcr-trust-evidence. 535 o The other parameters of the subscription include: pcr-list: {{1, 536 3, 7}}, tcg-hash-algo-id: TPM_ALG_SHA256, nonce-value: 0x564ac291, 537 TPM_ALG_ID-value: TPM_ALG_ECDSA, pub-key-id: 0x784a22bf, tpms: 538 {"tpm1"}. 540 o The selection filter is set as follows: a specific component with 541 id ("xxxxxxxxxx") of a designated vendor ("xxx-vendor-device"). 543 o The event which triggers the intergrity evidence delivery is 544 defined as: id: 1001, type: master-slave-swithover 546 NO FIGURE YET 548 Figure 4: Configured Event-triggered Subscription Message 550 4. The YANG Module for Sub/pub Model Remote Attestation Procedures 552 4.1. Tree Format 554 To be written. 556 4.2. Raw Format 558 To be written. 560 5. Security Considerations 562 To be written. 564 6. IANA Considerations 566 To be written, possibly. 568 7. References 570 7.1. Normative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, 574 DOI 10.17487/RFC2119, March 1997, 575 . 577 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 578 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 579 May 2017, . 581 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 582 E., and A. Tripathy, "Subscription to YANG Notifications", 583 RFC 8639, DOI 10.17487/RFC8639, September 2019, 584 . 586 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 587 E., and A. Tripathy, "Dynamic Subscription to YANG Events 588 and Datastores over NETCONF", RFC 8640, 589 DOI 10.17487/RFC8640, September 2019, 590 . 592 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 593 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 594 September 2019, . 596 7.2. Informative References 598 [I-D.birkholz-rats-information-model] 599 Birkholz, H. and M. Eckel, "An Information Model for 600 Claims used in RATS", draft-birkholz-rats-information- 601 model-01 (work in progress), January 2020. 603 [I-D.birkholz-rats-reference-interaction-model] 604 Birkholz, H. and M. Eckel, "Reference Interaction Models 605 for Remote Attestation Procedures", draft-birkholz-rats- 606 reference-interaction-model-02 (work in progress), January 607 2020. 609 [I-D.birkholz-rats-tuda] 610 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 611 "Time-Based Uni-Directional Attestation", draft-birkholz- 612 rats-tuda-01 (work in progress), September 2019. 614 [I-D.bryskin-netconf-automation-yang] 615 Bryskin, I., Liu, X., Clemm, A., Birkholz, H., and T. 616 Zhou, "Generalized Network Control Automation YANG Model", 617 draft-bryskin-netconf-automation-yang-03 (work in 618 progress), July 2019. 620 [I-D.ietf-rats-architecture] 621 Birkholz, H., Thaler, D., Richardson, M., and N. Smith, 622 "Remote Attestation Procedures Architecture", draft-ietf- 623 rats-architecture-01 (work in progress), February 2020. 625 [I-D.ietf-rats-eat] 626 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 627 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 628 ietf-rats-eat-03 (work in progress), February 2020. 630 [I-D.ietf-rats-yang-tpm-charra] 631 Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, 632 E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data 633 Model for Challenge-Response-based Remote Attestation 634 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-00 635 (work in progress), January 2020. 637 [I-D.richardson-rats-usecases] 638 Richardson, M., Wallace, C., and W. Pan, "Use cases for 639 Remote Attestation common encodings", draft-richardson- 640 rats-usecases-06 (work in progress), November 2019. 642 Acknowledgements 644 Thanks to ... 646 Authors' Addresses 648 Liang Xia (Frank) 649 Huawei 650 101 Software Avenue, Yuhuatai District, 651 Nanjing, Jiangsu 210012 652 China 654 Email: frank.xialiang@huawei.com 656 Wei Pan 657 Huawei 658 101 Software Avenue, Yuhuatai District 659 Nanjing, Jiangsu 210012 660 China 662 Email: william.panwei@huawei.com