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