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