-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-birkholz-rats-network-device-subscription-00v2020-06-05.txt
1119 lines (811 loc) · 40.1 KB
/
draft-birkholz-rats-network-device-subscription-00v2020-06-05.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
***** Pre-DRAFT VERSION - THIS IS NOT YET POSTED to the IETF *****
RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track E. Voit
Expires: December 7, 2020 Cisco
W. Pan
Huawei
June 05, 2020
Attestation Event Stream Subscription
draft-birkholz-rats-network-device-subscription-00
Abstract
This document defines how to subscribe to a stream of attestation
related Evidence on TPM-based network devices.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 7, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Birkholz, et al. Expires December 7, 2020 [Page 1]
Internet-Draft RATS Subscription June 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
3. Operational Model . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Sequence Diagram . . . . . . . . . . . . . . . . . . . . 3
3.2. Continuously Verifying Freshness . . . . . . . . . . . . 5
3.2.1. TPM 1.2 Quote . . . . . . . . . . . . . . . . . . . . 5
3.2.2. TPM 2 Quote . . . . . . . . . . . . . . . . . . . . . 5
4. Remote Attestation Event Stream . . . . . . . . . . . . . . . 6
4.1. Subscription to the <attestation> Event Stream . . . . . 7
4.2. Replaying a history of previous TPM extend operations . . 7
4.2.1. TPM2 Heartbeat . . . . . . . . . . . . . . . . . . . 8
4.3. YANG notifications placed on the <attestation> Event
Stream . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. tpm-extend . . . . . . . . . . . . . . . . . . . . . 8
4.3.2. tpm12-attestation . . . . . . . . . . . . . . . . . . 9
4.3.3. tpm20-attestation . . . . . . . . . . . . . . . . . . 10
4.4. Filtering Evidence at the Attester . . . . . . . . . . . 11
4.5. Replaying previous PCR Extend events . . . . . . . . . . 11
4.6. Configuring the <attestation> Event Stream . . . . . . . 12
5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
[I-D.fedorkow-rats-network-device-attestation] and
[I-D.ietf-rats-yang-tpm-charra] define the operational prerequisites
and a YANG Model for the acquisition of Evidence from a TPM-based
network device. However there is a limitation inherant in the
challenge-response interaction models upon which these documents are
based. This limitation is that it is up to the Verifier to request
Evidence. The result is that the interval between the occurrence of
a security event, and the event's visibility within the Relying Party
can be unacceptably long.
This limitation results in two adverse effects:
1. Evidence is not streamed to an interested Verifier as soon as it
is generated.
Birkholz, et al. Expires December 7, 2020 [Page 2]
Internet-Draft RATS Subscription June 2020
2. If it were to be streamed, the Evidence is not appraisable for
freshness.
This specification addresses the first adverse effect by enabling a
Verifier to subscribe via [RFC8639] to an <attestation> Event Stream
which exists upon the Attester. When subscribed, the Attester will
continuously stream a requested set of Evidence to the Verifier.
The second adverse effect results from the nonce based challenge-
response of [I-D.ietf-rats-yang-tpm-charra]. In that document an
Attester must wait for a new nonce from a Verifier before it
generates a new TPM Quote. To address delays resulting from such a
wait, this specification enables freshness to be asserted
asynchronously.
By removing these two adverse effects, it becomes possible for a
Verifier to continously maintain an appraisal of the Attested device
without relying on continous polling.
2. Terminology
The following terms are imported from [I-D.ietf-rats-architecture]:
Attester, Evidence, Relying Party, and Verifier. Also imported are
the time definitions time(vg), time(ns), time(eg), time(rg), and
time(ra) from that document's appendices. The following terms at
imported from [RFC8639]: Event Stream, Subscription, Event Stream
Filter, Dynamic Subscription.
2.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Operational Model
3.1. Sequence Diagram
Figure 1 below is a sequence diagram which updates Figure 5 of
[I-D.fedorkow-rats-network-device-attestation]. This sequence
diagram replaces the [I-D.fedorkow-rats-network-device-attestation]
challenge-response interaction model with an [RFC8639] Dynamic
Subscription to an <attestation> Event Stream. The contents of the
<attestation> Event Stream are defined below within Section 4.
Birkholz, et al. Expires December 7, 2020 [Page 3]
Internet-Draft RATS Subscription June 2020
.----------. .--------------------------.
| Attester | | Relying Party / Verifier |
'----------' '--------------------------'
time(vg) |
|<---------establish-subscription(<attestation>)--time(ns)
| |
time(eg) |
|--filter(<tpm-extend>)---------------------------->|
|--<tpm12-attestation> or <tpm20-attestation>------>|
| |
| verify time(eg) Evidence @ time(rg,ra)
| |
~ ~
time(vg',eg') |
|--filter(<tpm-extend>)---------------------------->|
|--<tpm12-attestation> or <tpm20-attestation>------>|
| |
| verify time(eg') Evidence @ time(rg',ra')
Figure 1: YANG Subscription Model for Remote Attestation
o time(vg,rg,ra) are identical to the corresponding times from
Figure 5 of [I-D.fedorkow-rats-network-device-attestation].
o time(rg',ra') are subsequent instances of the corresponding times
from Figure 5 of [I-D.fedorkow-rats-network-device-attestation].
o time(ns): The Verifier generates a nonce and makes an [RFC8639]
<establish-subscription> request. This request also includes the
augmentations defined in this document's YANG model. Key
subscription RPC parameters include:
* the nonce
* a set of PCRs of interest which the Verifier wants to appraise
* an optional filter which can reduce the logged events on the
<attestation> stream pushed to the Verifier.
o time(eg) - An initial response of Evidence is returned to the
Verifier. This includes:
* A replay of filtered log entries which have extended into a PCR
of interest since boot are sent in the <tpm-extend>
notification.
Birkholz, et al. Expires December 7, 2020 [Page 4]
Internet-Draft RATS Subscription June 2020
* A signed TPM quote that contains at least the PCRs from the
<establish-subscription> RPC are included in a
<tpm12-attestation> or <tpm20-attestation>). This quote must
have included the nonce provided at time(ns).
o time(vg',eg') - This occurs when a PCR is extended subsequent to
time(eg). Immediately after the extension, the following
information needs to be pushed to the Verifier:
* Any values extended into a PCR of interest, and
* a signed TPM Quote showing the result the PCR extension.
3.2. Continuously Verifying Freshness
As there is no new Verifier nonce provided at time(eg'), it is
important to validate the freshness of TPM Quotes which are delivered
at that time. The method of doing this verification will vary based
on the capabilities of the TPM cryptoprocessor used.
3.2.1. TPM 1.2 Quote
The [RFC8639] notification format includes the <eventTime> object.
This can be used to determine the amount of time subsequent to the
initial subscription each notification was sent. However this time
is not part of the signed results which are returned from the Quote,
and therefore is not trustworthy as objects returned in the Quote.
Therefore a Verifier MUST periodically issue a new nonce, and receive
this nonce within a TPM quote response in order to ensure the
freshness of the results. This can be done using the <tpm12-
challenge-response-attestation> RPC from
[I-D.ietf-rats-yang-tpm-charra].
3.2.2. TPM 2 Quote
When the Attester includes a TPM2 compliant cryptoprocessor, internal
time-related counters are included within the signed TPM Quote. By
including a initial nonce in the [RFC8639] subscription request,
fresh values for these counters are pushed as part of the first TPM
Quote returned to the Verifier. And then as shown by
[I-D.birkholz-rats-tuda], subsequent TPM Quotes delivered to the
Verifier can the be appraised for freshness based on the predictable
incrementing of these time-related countersr.
The relevant internal time-related counters defined within [TPM2.0]
can be seen within <tpms-clock-info>. These counters include the
<clock>, <reset-counter>, and <restart-counter> objects. The rules
for appraising these objects are as follows:
Birkholz, et al. Expires December 7, 2020 [Page 5]
Internet-Draft RATS Subscription June 2020
o If the <clock> has incremented for no more than the same duration
as both the <eventTime> and the Verifier's internal time since the
initial time(eg) and any previous time(eg'), then the TPM Quote
may be considered fresh. Note that [TPM2.0] allows for +/- 15%
clock drift. However many chips significantly improve on this
maximum drift. If available, chip specific maximum drifts SHOULD
be considered during the appraisal process.
o If the <reset-counter>, <restart-counter> has incremented. The
existing subscription MUST be terminated, and a new <establish-
subscription> SHOULD be generated.
o If a TPM Quote on any subscribed PCR has not been pushed to the
Verifier for a duration of an Attester defined heartbeat interval,
then a new TPM Quote notification should be sent to the Verifier.
This may often be the case, as certain PCRs might be infrequently
updated.
.----------. .--------------------------.
| Attester | | Relying Party / Verifier |
'----------' '--------------------------'
time(vg',eg') |
|-<tpm20-attestation>------------------------------>|
| : |
~ Heartbeat interval ~
| : |
time(eg') : |
|-<tpm20-attestation>------------------------------>|
| |
4. Remote Attestation Event Stream
The <remote-attestation> Event Stream is an [RFC8639] complaint Event
Stream which is defined within this section and within the YANG
Module of [I-D.ietf-rats-yang-tpm-charra]. This Event Stream
contains YANG notifications which carry Evidence which assists a
Verifier in appraising the Trustworthiness Level of an Attester.
Data Nodes within Section 4.6 allow the configuration of this Event
Stream's contents on an Attester.
This <remote-attestation> Event Stream may only be exposed on
Attesters supporting [I-D.fedorkow-rats-network-device-attestation].
As with [I-D.fedorkow-rats-network-device-attestation], it is up to
the Verifier to understand which types of cryptoprocessors and keys
are acceptable.
Birkholz, et al. Expires December 7, 2020 [Page 6]
Internet-Draft RATS Subscription June 2020
4.1. Subscription to the <attestation> Event Stream
To establish a subscription to an Attester in a way which provides
provably fresh Evidence, initial randomness must be provided to the
Attester. This is done via the augmentation of a <nonce-value> into
[RFC8639] the <establish-subscription> RPC. Additionally, a Verifier
must ask for PCRs of interest from a platform.
augment /sn:establish-subscription/sn:input:
+---w nonce-value binary
+---w pcr-index* tpm:pcr
The result of the subscription will be that passing of the following
information:
1. <tpm12-attestation> and <tpm20-attestation> notifications which
include the provided <nonce-value>. These attestation
notifications MUST at least include all the <pcr-indicies>
requested in the RPC.
2. a series of <tpm-extend> notifications which reference the
requested PCRs on all TPM based cryptoprocessors on the Attester.
3. <tpm12-attestation> and <tpm20-attestation> notifications
generated within a few seconds of the <tpm-extend> notifications.
These attestation notifications MUST at least include any PCRs
extended.
If the Verifier does not want to see the logged extend operations for
all PCRs available from an Attester, an Event Stream Filter should be
applied. This filter will remove Evidence from any PCRs which are
not interesting to the Verifier.
4.2. Replaying a history of previous TPM extend operations
Unless it is relying on Known Good Values, a Verifier will need to
acquire a history of PCR extensions since the Attester has been
booted. This history may be requested from the Attester as part of
the <establish-subscription> RPC. This request is accomplished by
placing a very old <replay-start-time> within the original RPC
request. As the very old <replay-start-time> will pre-date the time
of Attester boot, a <replay-start-time-revision> will be returned in
the <establish-subscription> RPC response, indicating when the
Attester booted. Immediately following the response (and before the
notifications above) one or more <tpm-extend> notifications which
document all extend operations which have occurred for the requested
PCRs since boot will be sent. Many extend operations to a single PCR
Birkholz, et al. Expires December 7, 2020 [Page 7]
Internet-Draft RATS Subscription June 2020
index on a single TPM SHOULD be included within a single
notification.
Note that if a Verifier has a partial history of extensions, the
<replay-start-time> can be adjusted so that known extensions are not
forwarded.
The end of this history replay will be indicated with the [RFC8639]
<replay-completed> notification. For more on this sequence, see
Section 2.4.2.1 of [RFC8639].
After the <replay-complete> notification is provided, a TPM Quote
will be requested and the result passed to the Verifier via a
<tpm12-attestation> and <tpm20-attestation> notification. If there
have been any additional extend operations which have changed a
subscribed PCR value in this quote, these MUST be pushed to the
Verifier before the <tpm12-attestation> and <tpm20-attestation>
notification.
At this point the Verifier has sufficient Evidence appraise the
reported extend operations for each PCR, as well compare the expected
value of the PCR value against that signed by the TPM.
4.2.1. TPM2 Heartbeat
For TPM2, make sure that every requested PCR is sent within an
<tpm20-attestation> no less frequently than once per heartbeat
interval. This MAY be done with a single <tpm20-attestation>
notification that includes all requested PCRs every heartbeat
interval. This MAY be done with several <tpm20-attestation>
notifications at different times during that heartbeat interval.
4.3. YANG notifications placed on the <attestation> Event Stream
4.3.1. tpm-extend
This notification documents when a single subscribed PCR is extended
within a single TPM cryptoprocessor. It SHOULD be emmitted no less
than the <marshalling-period> after an the PCR is first extended.
(The reason for the marshalling is that it is quite possible that
multiple extensions to the same PCR have been made in quick
succession.) It MUST be emmitted prior to a <tpm12-attestation> or
<tpm20-attestation> notification which has included and signed the
results of any specific PCR extension.
Birkholz, et al. Expires December 7, 2020 [Page 8]
Internet-Draft RATS Subscription June 2020
+---n tpm-extend
+--ro tpm-path? string
+--ro pcr-index-changed tpm:pcr
+--ro attested-event* []
+--ro attested-event
+--ro extended-with binary
+--ro event-type? identityref
+--ro event-details? <anydata>
Each <tpm-extend> MUST include one or more values being extended into
the PCR. These are passed within the <extended-with> object. For
each extension, details of the event MAY be provided within the
<event-details> object.
The format of any included <event-details> is identified by the
<event-type>. This document includes two YANG structures which may
be inserted into the <event-details>. These two structures are:
<ima-event-log" and <bios-event-log>. Implementations wanting to
provide additional documentation of a type of PCR extension may
choose to define additional YANG structures which can be placed into
<event-details>.
Open question: do we need a notification correlator object to easily
allow correlation on which extensions have been embodied within a
specific attestation?
4.3.2. tpm12-attestation
This notification contains an instance of a TPM1.2 style signed
cryptoprocessor measurement. It is supplemented by Attester
information which is not signed. This notification is generated and
emitted from an Attester when at least one PCR identified within the
subscribed <pcr-indices> has changed from the previous
<tpm12-attestation> notification. This notification MUST NOT include
the results of any PCR extensions not previously reported by a <tpm-
extend>. This notification SHOULD be emitted within 10 seconds of a
<tpm-extend>:
Birkholz, et al. Expires December 7, 2020 [Page 9]
Internet-Draft RATS Subscription June 2020
+---n tpm12-attestation {tpm:TPM12}?
+--ro tpm-path? string
+--ro up-time? uint32
+--ro node-id? string
+--ro node-physical-index? int32 {ietfhw:entity-mib}?
+--ro fixed? binary
+--ro external-data? binary
+--ro signature-size? uint32
+--ro signature? binary
+--ro (tpm12-quote)
+--:(tpm12-quote1)
| +--ro version* []
| | +--ro major? uint8
| | +--ro minor? uint8
| | +--ro revMajor? uint8
| | +--ro revMinor? uint8
| +--ro digest-value? binary
| +--ro TPM_PCR_COMPOSITE* []
| +--ro pcr-index* pcr
| +--ro value-size? uint32
| +--ro tpm12-pcr-value* binary
+--:(tpm12-quote2)
+--ro tag? uint8
+--ro pcr-index* pcr
+--ro locality-at-release? uint8
+--ro digest-at-release? binary
All YANG objects above are defined within
[I-D.ietf-rats-yang-tpm-charra]. The <tpm12-attestation> is not
replayable.
4.3.3. tpm20-attestation
This notification contains an instance of TPM2 style signed
cryptoprocessor measurements. It is supplemented by Attester
information which is not signed. This notification is generated at
two points in time:
o every time at least one PCR has changed from a previous
tpm20-attestation. In this case, the notification SHOULD be
emitted within 10 seconds of the corresponding <tpm-extend> being
sent:
o after a locally configurable minimum heartbeat period since a
previous tpm20-attestation was sent.
Birkholz, et al. Expires December 7, 2020 [Page 10]
Internet-Draft RATS Subscription June 2020
+---n tpm20-attestation {tpm:TPM20}?
+--ro tpm-path? string
+--ro up-time? uint32
+--ro node-id? string
+--ro node-physical-index? int32 {ietfhw:entity-mib}?
+--ro quote? binary
+--ro quote-signature? binary
+--ro pcr-bank-values* []
| +--ro (algo-registry-type)
| | +--:(tcg)
| | | +--ro tcg-hash-algo-id? uint16
| | +--:(ietf)
| | +--ro ietf-ni-hash-algo-id? uint8
| +--ro pcr-values* [pcr-index]
| +--ro pcr-index uint16
| +--ro pcr-value? binary
+--ro pcr-digest-algo-in-quote
+--ro (algo-registry-type)
+--:(tcg)
| +--ro tcg-hash-algo-id? uint16
+--:(ietf)
+--ro ietf-ni-hash-algo-id? uint8
All YANG objects above are defined within
[I-D.ietf-rats-yang-tpm-charra]. The <tpm20-attestation> is not
replayable.
4.4. Filtering Evidence at the Attester
It can be useful _not_ to receive all Evidence related to a PCR. An
example of this is would be a when a Verifier maintains known good
values of a PCR. In this case, it is not necessary to send each
extend operation.
To accomplish this reduction, when an RFC8639 <establish-
subscription> RPC is sent, a <stream-filter> as per RFC8639,
Section 2.2 can be set to discard a <tpm-extend> notification when
the <pcr-index-changed> is uninteresting to the verifier.
4.5. Replaying previous PCR Extend events
To verify the value of a PCR, a Verifier must either know that the
value is a known good value [KGV] or be able to reconstruct the hash
value by viewing all the PCR-Extends since the Attester rebooted.
Wherever a hash reconstruction might be needed, the <remote-
attestation> Event Stream MUST support the RFC8639 <replay> feature.
Through the <replay> feature, it is possible for a Verifier to
retrieve and sequentially hash all of the PCR extending events since
Birkholz, et al. Expires December 7, 2020 [Page 11]
Internet-Draft RATS Subscription June 2020
an Attester booted. And thus, the Verifier has access to all the
evidence needed to verify a PCR's current value.
4.6. Configuring the <attestation> Event Stream
Figure 2 is tree diagram which exposes the operator configurable
elements of the <remote-attestation> Event Stream. This allows an
Attester to select what information should be available on the
stream. A fetch operation also allows an external device such as a
Verifier to understand the current configuration of stream.
Almost all YANG objects below are defined via reference from
[I-D.ietf-rats-yang-tpm-charra]. There is one object which is new
with this model however. <tpm2-heartbeat> defines the maximum amount
of time which should pass before a subscriber to the Event Stream
should get a <tpm20-attestation> notification from devices which
contain a TPM2.
+--rw rats-support-structures
+--rw rats-support-structures
+--rw supported-algos* uint16
+--rw tpms* [tpm-name]
| +--rw tpm-name string
| +--rw tras:leafref-to-keystore? string
| +--rw (tras:subscribable)?
| +--:(tras:tpm12-stream) {tpm:TPM12}?
| | +--rw tras:tpm12-pcr-index* tpm:pcr
| +--:(tras:tpm20-stream) {tpm:TPM20}?
| +--rw tras:tpm20-pcr-index* tpm:pcr
+--rw tras:marshalling-period? uint8
+--rw tras:tpm12-subscribed-signature-scheme?
| -> ../tpm:supported-algos {tpm:TPM12}?
+--rw tras:tpm20-subscribed-signature-scheme?
| -> ../tpm:supported-algos {tpm:TPM20}?
+--rw tras:tpm20-subscription-heartbeat? uint16
{tpm:TPM20}?
Figure 2: Configuring the Attestation Stream
5. YANG Module
This YANG module imports modules from [I-D.ietf-rats-yang-tpm-charra]
and [RFC8639]. It is also work-in-progress.
<CODE BEGINS> [email protected]
module ietf-tpm-remote-attestation-stream {
yang-version 1.1;
Birkholz, et al. Expires December 7, 2020 [Page 12]
Internet-Draft RATS Subscription June 2020
namespace
"urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream";
prefix tras;
import ietf-subscribed-notifications {
prefix sn;
reference
"RFC 8639: Subscription to YANG Notifications";
}
import ietf-tpm-remote-attestation {
prefix tpm;
reference
"draft-ietf-rats-yang-tpm-charra";
}
import ietf-yang-structure-ext {
prefix sx;
reference
"draft-ietf-netmod-yang-data-ext";
}
organization "IETF";
contact
"WG Web: <http://tools.ietf.org/wg/rats/>
WG List: <mailto:[email protected]>
Editor: Eric Voit
<mailto:[email protected]>";
description
"This module contains conceptual YANG specifications for
subscribing to attestation streams being generated from TPM chips.
Copyright (c) 2020 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Birkholz, et al. Expires December 7, 2020 [Page 13]
Internet-Draft RATS Subscription June 2020
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2020-06-05 {
description
"Initial version.";
reference
"draft-birkholz-rats-network-device-subscription";
}
/*
* IDENTITIES
*/
identity pcr-unsubscribable {
base sn:establish-subscription-error;
description
"Requested PCR is subscribable by the Attester.";
}
/*
* Groupings
*/
grouping heartbeat {
description
"Allows an Attester to push verifiable, current TPM PCR values even
when there have been no recent changes to PCRs.";
leaf tpm20-subscription-heartbeat {
type uint16;
description
"Number of seconds before the Attestation stream should send a new
notification with a fresh quote. This allows confirmation
that the PCR values haven't changed since the last
tpm20-attestation.";
}
}
Birkholz, et al. Expires December 7, 2020 [Page 14]
Internet-Draft RATS Subscription June 2020
/*
* RPCs
*/
augment "/sn:establish-subscription/sn:input" {
when 'derived-from-or-self(sn:stream, "attestation")';
description
"This augmentation adds a nonce to as a subscription parameters
that apply specifically to datastore updates to RPC input.";
uses tpm:nonce;
leaf-list pcr-index {
type tpm:pcr;
min-elements 1;
description
"The numbers/indexes of the PCRs. This will act as a filter for the
subscription so that 'tpm-extend' notifications related to
non-requested PCRs will not be sent to a subscriber.";
}
}
/*
* NOTIFICATIONS
*/
notification tpm-extend {
description
"This notification indicates that a PCR has extended within a TPM based
cryptoprocessor. In less that 10 seconds, it should be followed with
either a tpm12-attestation or tpm20-attestation notification.";
uses tpm:tpm-name;
leaf pcr-index-changed {
type tpm:pcr;
mandatory true;
description
"The number of the PCR extended.";
}
list attested-event {
description
"A set of events which extended an Attester PCR. The sequence of
elements represented in list must match the sequence of events
placed into the TPM.";
container attested-event {
description
"An instance of an event which extended an Attester PCR";
leaf extended-with {
type binary;
mandatory true;
description
Birkholz, et al. Expires December 7, 2020 [Page 15]
Internet-Draft RATS Subscription June 2020
"Information extending the PCR.";
}
leaf event-type {
type identityref {
base tpm:attested-event-log-type;
}
description
"Indicates what kind of event happened the Attester thought was
worthy of recording in a PCR.";
}
anydata event-details {
description
"Any structure reference 'event-type' contains supporting
information which allows an Attester to evaluate the trust
implications.
Event details may be populated with YANG log structures defined
at the bottom of this module.";
}
}
}
}
notification tpm12-attestation {
if-feature "tpm:TPM12";
description
"Contains an instance of TPM1.2 style signed cryptoprocessor
measurements. It is supplemented by unsigned Attester information.";
uses tpm:tpm12-attestation;
}
notification tpm20-attestation {
if-feature "tpm:TPM20";
description
"Contains an instance of TPM2 style signed cryptoprocessor
measurements. It is supplemented by unsigned Attester information.";
uses tpm:tpm20-attestation;
}
/*
* DATA NODES
*/
augment "/tpm:rats-support-structures" {
description
"Defines platform wide 'attestation' stream subscription parameters.";
leaf marshalling-period {
Birkholz, et al. Expires December 7, 2020 [Page 16]
Internet-Draft RATS Subscription June 2020
config true;
type uint8;
default 5;
description
"The maximum number of seconds between the time an event extends a PCR,
and the 'tpm-extend' notification which reports it to a subscribed
Verifier. This period allows multiple extend operations bundled
together and handled as a group.";
}
leaf tpm12-subscribed-signature-scheme {
if-feature "tpm:TPM12";
type leafref {
path "../tpm:supported-algos";
/* a specific algorithm, need to check syntax */
}
description
"A single signature-scheme which will be used to sign the evidence
from a TPM 1.2. which is then placed onto the 'attestation' event
stream.";
}
leaf tpm20-subscribed-signature-scheme {
if-feature "tpm:TPM20";
type leafref {
path "../tpm:supported-algos";
/* a specific algorithm, need to check syntax */
}
description
"A single signature-scheme which will be used to sign the evidence
from a TPM 2.0. which is then placed onto the 'attestation' event
stream.";
}
uses heartbeat{
if-feature "tpm:TPM20";
}
}
augment "/tpm:rats-support-structures/tpm:tpms" {
description
"Allows the configuration 'attestation' stream parameters for a TPM.";
leaf leafref-to-keystore {
config true;
type string;
description
"needs to be replaced with Reference to keystore draft.";
}
choice subscribable {
config true;
description
Birkholz, et al. Expires December 7, 2020 [Page 17]
Internet-Draft RATS Subscription June 2020
"Indicates that the set of notifications which comprise the attestation
stream can be modified or tuned by a network adminsitrator.";
case tpm12-stream {
if-feature "tpm:TPM12";
description
"Configuration elements for a TPM1.2 event stream.";
leaf-list tpm12-pcr-index {
type tpm:pcr;
description
"The numbers/indexes of the PCRs which can be subscribed.";
}
}
case tpm20-stream {
if-feature "tpm:TPM20";
description
"Configuration elements for a TPM2.0 event stream.";
leaf-list tpm20-pcr-index {
type tpm:pcr;
description
"The numbers/indexes of the PCRs which can be subscribed.";
}
/* We need to decide if more than one hash-algo is subscribable */
}
}
}
/*
* STRUCTURES - these contain the schema of reportable event types
*/
sx:structure bios-event-log {
when 'derived-from(../event-type, "bios-event-log")';
description
"BIOS/UEFI event log format";
uses tpm:bios-event-log;
}
sx:structure ima-event-log {
when 'derived-from(../event-type, "ima-event-log")';
description
"IMA event log format";
uses tpm:ima-event-log;
}
}