-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-coffin-sacm-nea-swid-patnc-02.xml
2902 lines (2730 loc) · 204 KB
/
draft-coffin-sacm-nea-swid-patnc-02.xml
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
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC7171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7171.xml">
<!ENTITY RFC5198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-coffin-sacm-nea-swid-patnc-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="SW M&A for PA-TNC">Software Message and Attributes for PA-TNC</title>
<!-- Another author who claims to be an editor -->
<author fullname="Chris Coffin" initials="C.C." surname="Coffin">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Daniel Haynes" initials="D.H." surname="Haynes">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Charles Schmidt" initials="C.S." surname="Schmidt">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jessica Fitzgerald-McKay" initials="J.M."
surname="Fitzgerald-McKay">
<organization>Department of Defense</organization>
<address>
<postal>
<street>9800 Savage Road</street>
<city>Ft. Meade</city>
<region>Maryland</region>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="12" month="September" year="2016"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>SACM</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>SWID</keyword>
<keyword>PA-TNC</keyword>
<keyword>NEA</keyword>
<keyword>Software inventory</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document specifies the Software Message and Attributes for PA-TNC. It extends the
PA-TNC specification <xref target="RFC5792"/> by providing specific attributes
and message exchanges to allow endpoints to report their software inventory information
to a NEA server (as described in <xref target="RFC5209"/>).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Scope and Audience">
<t>The Network Endpoint Assessment (NEA) Working Group defines an open solution architecture
that enables network operators to collect and utilize information about endpoint configuration and
state. This information can be used to enforce policies, monitor endpoint health, and for many other
activities. Information about the software present on an endpoint is an important consideration for
such activities. Such information can come from multiple sources, including tag files (such as ISO SWID tags
<xref target="SWID"/>, reports from third party inventory tools, output from package managers, and other
sources. The
attributes defined in this document are used to communicate software inventory evidence, collected from a
range of possible sources, from the posture collector on the endpoint to the posture validator on a NEA
Server using the PA-TNC interface,
as shown in
<xref target="NEA-reference-model"/> below.</t>
<figure anchor="NEA-reference-model" title="NEA Reference Model">
<artwork>
<![CDATA[
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
NEA CLIENT NEA SERVER
]]>
</artwork>
</figure>
<t>This specification defines a new set of PA-TNC attributes, carried over PA-TNC messages, which are used
to communicate requests for software information and software events, and for conveying that
information back to a NEA Server.</t>
<t>Possession of a list of an endpoint's installed software is very useful in understanding and maintaining the
security state of an enterprise. For example, if an enterprise policy requires the presence of certain
pieces of software and/or prohibits the presence of other software, reported software inventory
lists can be used to
indicate compliance or non-compliance with these requirements. Software
presence and the patch level of that software can be compared to vulnerability or threat alerts to
determine an endpoint's exposure to attack. All of these uses make an understanding of an endpoint's
software collection highly
useful to NEA Servers and other enterprise security applications.</t>
<t>Before reading this specification any further, the reader should review and understand the NEA reference
architecture as described in the Network Endpoint Assessment (NEA): Overview and
Requirements <xref target="RFC5209"/>.
The reader should also
understand the capabilities and requirements common to PA-TNC interfaces as defined in
RFC 5792 <xref target="RFC5792"/>.</t>
<t>This document is based on standards published by the Trusted Computing Group's Trusted Network
Communications (TNC)
workgroup. The TNC and NEA architectures are interoperable and the following components are equivalent:</t>
<texttable
anchor="TNC-NEA-equivalence"
title="Equivalent components in TNC and NEA architectures">
<ttcol>TNC Component</ttcol>
<ttcol>NEA Component</ttcol>
<c>Integrity Measurement Verifier (IMV)</c>
<c>Posture Validator</c>
<c>Integrity Measurement Collector (IMC)</c>
<c>Posture Collector</c>
<c>TNC Server (TNCS)</c>
<c>Posture Broker Server</c>
<c>TNC Client (TNCC)</c>
<c>Posture Broker Client</c>
</texttable>
</section>
<section title="Keywords">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be
interpreted as described in RFC 2119 <xref target="RFC2119"/>. This specification does not distinguish blocks of informative
comments and normative requirements. Therefore, for the sake of clarity, note that lower case
instances of must, should, etc. do not indicate normative requirements.</t>
</section>
<section title="Definitions">
<t>This section defines terms with special meaning within this document.</t>
<t>SW-PC - A Posture Collector (PC) that conforms to this specification. Note that
such a posture collector might also support other PA-TNC exchanges beyond Software Message and Attributes
for PA-TNC.</t>
<t>SW-PV - A Posture Validator (PV) that conforms to this specification. Note that
such a posture verifier might also support other PA-TNC exchanges beyond Software Message and Attributes
for PA-TNC.</t>
<t>SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792 <xref target="RFC5792"/> extension
for conveying software inventory information. This specification defines several new attribute types.</t>
<t>Endpoint's Software Inventory Evidence Collection - The set of information regarding the set of
software installed on an endpoint and expressed using one of the Software Message and Attributes
data models, as described in the Software Data Model IANA table (see <xref target="IANA_Software_Data_Models"/>.
An endpoint's software inventory evidence
collection might include information created by or derived from
multiple sources, including but not limited to SWID tag files deposited on the file system during
software installation, information generated to report output from software discovery tools, and information
dynamically generated by a software or package management system on an endpoint.</t>
<t>Software Inventory Evidence Record - The endpoint's Software Inventory Evidence Collection is composed
of "records". Each record corresponds to one installed instance of a particular software product as reported by some
data source. It is
possible for a single installed instance to have multiple software inventory evidence records in an endpoint's
Software Inventory Evidence Collection - this can happen if multiple sources all report the same software
installation instance. </t>
<t>Software Identifier - A string associated with a specific version of a specific software product.
Each supported Software Message and Attributes for PA-TNC data model has its own rules for how a Software
Identifier (see <xref target="software-identifiers"/>) is derived from the representation of the
given software product using that data model,
and different sources for this information might populate relevant information differently. As such,
while each Software Identifier uniquely identifies a specific software product, the same software product
might be associated with multiple Software Identifiers reflecting differences between different information
sources and supported data models.</t>
</section>
</section>
<section title="Background">
<section anchor="Supported-use-cases" title="Supported Use Cases">
<t>This section describes the Software Message and Attributes for PA-TNC use cases supported by this
specification. The primary use of exchanging software inventory information over the PA-TNC interface is to
enable a challenger (e.g. NEA Server) to obtain inventory evidence about some system in a way that
conforms to NEA procedures and expressed using a standard format.
Collected software information can support a range of security activities including determining whether an
endpoint is permitted to connect to the enterprise, determining which endpoints contain software that
requires patching, and similar activities.</t>
<section title="Use Software Inventory as a Factor in Determining Endpoint Access">
<t>Some enterprises might define security policies that require connected endpoints to have certain
pieces of security software installed. By contrast, some security policies might prevent access by
endpoints that have certain prohibited pieces of software installed, such as applications that pose
known security risks. To support such policies, the NEA Server needs to collect evidence indicating the
software inventory of an endpoint that is seeking to initiate or continue connectivity to the enterprise.</t>
<t>Software Message and Attributes for PA-TNC facilitates policy decisions that consider an endpoint's
software inventory by providing the NEA Server with software inventory information from the endpoint.
The
SW-PC can provide a complete or partial inventory to the SW-PV as required to determine
policy compliance. The SW-PV can then use this as evidence of compliance or non-compliance
with enterprise policy.</t>
</section>
<section title="Maintain a Central Repository Reflecting an Endpoint's Software Inventory">
<t>Many tools can use information about an endpoint's software inventory to monitor and enforce the
security of an enterprise. For example, a software patching service can use an endpoint's software
inventory to determine whether certain endpoints have software that requires patching. A vulnerability
management tool might identify endpoints with known vulnerabilities (patched or otherwise) and use
this to gauge enterprise exposure to attack. A license management tool might verify that all copies of
a particular piece of software are accounted for within the enterprise. The presence of a central
repository representing a real-time understanding of each endpoint's software inventory facilitates all
such activities. Using a central repository that can ensure the freshness of its collected information is
generally more efficient than having each tool collect the same inventory information from each
endpoint individually and leads to a more consistent understanding of enterprise state.</t>
<t>Software Message and Attributes for PA-TNC supports this activity through a number of mechanisms. As
noted above, it allows a SW-PC to provide a complete list of software present in an endpoint's
Software Inventory Evidence Collection to the SW-PV, which can then pass this information on to a
central repository
such as a Configuration Management Database (CMDB) or similar application. In addition, SW-PCs
are required to be able to monitor for changes to an endpoint's Software Inventory Evidence Collection
in near real-time
and push reports of changes to the SW-PV as soon as those changes are detected. Thus
any central repository fed by a SW-PV receiving such information can be updated soon after the
change occurs. Keeping such a central repository synchronized with the state of each endpoint's
Software Inventory Evidence Collection allows tools that use this information for their own
security activities to make
decisions in a consistent, efficient manner.</t>
</section>
<section title="PA-TNC Use Cases">
<t>Software Message and Attributes for PA-TNC are intended to operate over the PA-TNC interface and, as such,
are intended to meet the use cases set out in the PA-TNC specification.</t>
</section>
</section>
<section title="Non-supported Use Cases">
<t>Some use cases not covered by this version of Software Message and Attributes for PA-TNC include:</t>
<t>
<list style="symbols">
<t>This specification does not address how the endpoint's Software Inventory Evidence Collection is populated. In
particular, NEA components are not expected to perform software discovery activities beyond
compiling information in an endpoint's Software Inventory Evidence Collection.
This collection might potentially come
from multiple sources on the endpoint (e.g., information generated dynamically by package
management tools or discovery tools, as well as SWID tag files discovered on the file system).
While an enterprise might make use of software discovery procedures to identify installed
software such procedures
are outside the scope of this specification.</t>
<t>This specification does not address converting inventory information expressed in a proprietary
format into the standard format used in the messages described in this specification. Instead, it
focuses exclusively on defining interfaces for the transportation of software information in the expectation
that this is the format around which reporting tools will converge.</t>
<t>This specification provides no mechanisms for a posture validator to request a specific list of software
information based on
arbitrary software properties. For example, requesting only information about
software from a particular vendor is not supported. After the endpoint's software inventory evidence
collection has
been copied to some central location, such as the CMDB, processes there can perform queries
based on any criteria present in the collected information, but this specification does not address
using such queries to constrain the initial collection of this information from the endpoint.</t>
<t>This specification does not address utilization of properties of certain sources of software information
that might facilitate
local tests (i.e., on the endpoint) of endpoint state. For example, the optional
package_footprint field of an ISO SWID tag can contain a list of files and hash values associated
with the software indicated by the tag. Tools on the endpoint can use the values in this field to
test for the presence of the indicated files. Successful evaluation of such tests leads to greater
assurance that the indicated software is present on the endpoint. Currently, most SWID tag
creators do not provide values for tag fields that support local testing. For this reason, the added
complexity of supporting endpoint testing using these fields is out of scope for this specification.
Future versions of this specification might add support for such testing.</t>
</list>
</t>
</section>
<section title="Specification Requirements">
<t>Below are the requirements that the Software Message and Attributes for PA-TNC specification is required
to meet in order to successfully play its role in the NEA architecture.</t>
<t>
<list style="symbols">
<t>Efficient</t>
</list>
</t>
<t>The NEA architecture enables delay of network access until the endpoint is determined not
to pose a security threat to the network based on its asserted integrity information. To
minimize user frustration, the Software Message and Attributes for PA-TNC ought to minimize
overhead delays and make PA-TNC communications as rapid and efficient as possible.</t>
<t>Efficiency is also important when one considers that some network endpoints are small and
low powered, some networks are low bandwidth and/or high latency, and some transport protocols
(such as PT-EAP, Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods <xref target="RFC7171"/>) or their underlying carrier protocol might allow
only one packet in flight at a time or only one roundtrip. However, when the underlying PT
protocol imposes fewer constraints on communications, this protocol ought to be capable of
taking advantage of more robust communication channels (e.g. using larger messages or
multiple roundtrips).</t>
<t>
<list style="symbols">
<t>Scalable</t>
</list>
</t>
<t>Software Message and Attributes for PA-TNC needs to be usable in enterprises that contain tens
of thousands of endpoints or more. As such, it needs to allow a security tools to make decisions based
on up-to-date information about an endpoint's software inventory without creating an
excessive burden on the enterprise's network.</t>
<t>
<list style="symbols">
<t>Interoperable</t>
</list>
</t>
<t>This specification defines the protocol for how PCs and PVs can exchange and use software information
to provide a NEA Server with information about an endpoint's software inventory. Therefore a
key goal for this specification is ensuring that all SW PCs and PVs, regardless of the
vendor who created them, are able to interoperate in their performance of these duties.</t>
<t>
<list style="symbols">
<t>Support precise and complete historical reporting</t>
</list>
</t>
<t>This specification outlines capabilities that support real-time understanding of
the state of endpoint in a network in a way that can be used by other tools.
One means of facilitating such an outcome is for a Configuration Management Database
(CMDB) to be able to contain information about all endpoints connected to the enterprise for all
points in time between the endpoint's first connection and the present. In such a scenario, it is necessary
that any PC be able to report any changes to its software inventory evidence
collection in near real-time while connected and, upon reconnection to the enterprise, be able
to update the NEA Server (and through it the CMDB) with regard to the state of its software inventory
evidence collection throughout the entire interval when it was not connected.</t>
</section>
<section title="Non-Requirements">
<t>There are certain requirements that the Software Message and Attributes for PA-TNC specification explicitly
is not required to meet. This list is not exhaustive.</t>
<t>
<list style="symbols">
<t>End to End Confidentiality</t>
</list>
</t>
<t>This specification does not define mechanism for confidentiality, nor is this property automatically
provided by PA-TNC interface use. Confidentiality is generally provided by the underlying
transport protocols, such as the PT Binding to TLS <xref target="RFC6876"/> or
PT-EAP Posture Transport for Tunneled EAP Methods
<xref target="RFC7171"/> - see <xref target="Relationship"/> for more information on related
standards. Should users wish
confidentiality protection of assessment instructions or results, this needs to be provided by
parts of the NEA architecture other than this specification.</t>
</section>
<section title="Assumptions">
<t>Here are the assumptions that Software Message and Attributes for PA-TNC makes about other
components in the NEA architecture.</t>
<t>
<list style="symbols">
<t>Reliable Message Delivery</t>
</list>
</t>
<t>The Posture Broker Client and Posture Broker Server are assumed to provide reliable delivery for PA-TNC messages
and therefore the Attributes sent between the SW PCs and the PVs. In the event
that reliable delivery cannot be provided, the Posture Collector or Posture Validator is expected to
terminate the connection.</t>
</section>
<section title="Non-Assumptions">
<t>The Software Message and Attributes for PA-TNC specification explicitly does not assume:</t>
<t>
<list style="symbols">
<t>Authenticity and Accuracy of the Software Inventory Evidence Collection with Regard to Endpoint Inventory</t>
</list>
</t>
<t>This specification makes no assumption as to whether the software information that it reports
correctly reflect the software
state on the endpoint. This specification does not attempt to detect when the endpoint is
providing false information, either through malice or error, but instead focuses on correctly
and reliably providing the reported Software Inventory Evidence Collection to the NEA Server.
Similarly, this specification makes
no assumption with regard to the completeness of the Software Inventory Evidence Collection's coverage of the
total set of software installed on the endpoint. It is possible, and even likely, that some
installed software is not represented by a record in an endpoints Software Inventory Evidence Collection. See
<xref target="Security"/> for more on this security consideration.</t>
</section>
<section title="Software Message and Attributes for PA-TNC Diagram Conventions">
<t>This specification defines the syntax of the Software Message and Attributes for PA-TNC using diagrams.
Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits
in each diagram as they are shown from left to right for each 32-bit quantity traversing the diagram
from top to bottom. Multi-octet fields representing numeric values MUST be sent in network (big
endian) byte order.</t>
<t>Descriptions of bit fields (e.g. flags) values refer to the position of the bit within the field. These bit
positions are numbered from the most significant bit through the least significant bit. As such, an octet
with only bit 0 set would have a value of 0x80 (1000 0000), an octet with only bit 1 set would have a
value of 0x40 (0100 0000), and an octet with only bit 7 set would have a value of 0x01 (0000 0001).</t>
</section>
</section>
<section title="Software Message and Attributes for PA-TNC System Requirements">
<t>The Software Message and Attributes for PA-TNC specification facilitates the exchange of software
inventory and event information. Specifically, each application supporting Software Message and
Attributes for PA-TNC includes a component known as the SW-PC that receives messages sent with
the SW Attributes component type. The SW-PC is also responsible for sending appropriate
SW Attributes back to the SW-PV in response. This section outlines what
software inventories and events are and the requirements
on SW-PCs and SW-PVs in order to support the stated use cases of this specification.</t>
<section anchor="Basic-exchange" title="Basic Inventory Exchange">
<t>In the most basic exchange supported by this specification, a SW-PV sends a request to the
SW-PC requesting all inventory information in the endpoint's Software Inventory Evidence Collection. This simple
exchange is shown in <xref target="Basic-sw-message-exchange"/>.</t>
<figure anchor="Basic-sw-message-exchange" title="Basic SW Message Exchange">
<artwork>
<![CDATA[
+-------------+ +--------------+
| SW-PC | | SW-PV | Time
+-------------+ +--------------+ |
| | |
|<--------------SW Request----------------| |
| | |
|---------------SW Response-------------->| |
| | V
]]>
</artwork>
</figure>
<t>Upon receiving such a SW Request from the SW-PV, the SW-PC is expected to collect all inventory
information from the endpoint's software evidence collection and place it within its
response attribute.</t>
<t>SW-PVs MUST discard without error any SW Response attributes that they receive for which
they do not know the SW Request parameters that led to this SW Response. This is due to the
fact that the SW Request includes parameters that control the nature of the response (as will be
described in the following sections) and without knowing those parameters the SW Response
cannot be reliably interpreted. Most often receiving an unsolicited SW Response attribute happens
when a NEA Server has multiple SW-PVs; one SW-PV sends a SW Request but, unless exclusive
delivery is used by the SW-PC in sending the response, both SW-PVs receive copies of the
resulting SW Response. In this case, the SW-PV that didn't send the SW Request would lack
the context necessary to correctly interpret the SW Response it received and would simply discard
it. Note, however, that proprietary measures might allow a SW-PV to discover the SW Request
parameters for a SW Response even if that SW-PV did not send the given SW Request. As
such, there is no blanket requirement for a SW-PV to discard all SW Responses to SW
Request the SW-PV did not generate itself, only that SW-PVs are required to discard SW
Responses for which they cannot get the necessary context to interpret.</t>
<t>In the case that it is possible to do so, the SW-PC SHOULD send its SW Response attribute to the
SW-PV that requested it using exclusive delivery as described in section 4.5 of RFC 5793
(PB-TNC) <xref target="RFC5793"/>. Exclusive delivery ensures that only the sender of the SW Request receives the
resulting SW Response.</t>
</section>
<section anchor="software-identifiers" title="Software Identifiers">
<t>Software information records contain a large amount of descriptive information about installed software
products. However, in many cases the complete level of detail in these records is not necessary. For example,
if one is simply tracking the installation or removal of known software products, one only needs enough
information to recognize the software added or removed. To allow such uses to be efficiently supported,
Software Message and Attributes for PA-TNC supports the use of Software Identifiers.</t>
<t>A Software Identifier uniquely identifies a specific version of a specific software product.
The Software Message and Attributes for PA-TNC specification does not dictate the structure of a
Software Identifier (beyond stating that it is a string) or define how it is created. Instead,
each data model described in the Software Data Model IANA table (<xref target="IANA_Software_Data_Models"/>
includes its own rules for how a Software Identifier is created based on a record in the Endpoint's
Software Inventory Evidence Collection expressed in that data model. Within the Software Message and
Attributes for PA-TNC specification, the Software Identifier is simply an opaque string.</t>
<t>Software Identifiers allow SW Response messages to identify software to a server at a fraction
of the bandwidth that would be needed to send the entire associated record. For some combinations
of data models and sources, the full record might never be necessary as the identifier can be
directly correlated to the contents of the full record. This is possible with authoritative
SWID tags, since these tags always have the same contents and thus a Software Identifier derived
from these tags can be used as a lookup to a local copy of the full tag. For other combinations of
source and data model, a server might not be able to determine the specific software product and
version associated with the identifier without requesting deliver of the full record. In either case,
however, a SW-PV can use Software Identifiers to track the presence of specific software products on
an endpoint over time in a bandwidth-efficient manner.</t>
<t>There are two important limitations of Software Identifiers to keep in mind:
<list>
<t> The identifiers do not necessarily change when the associated record changes. In some
situations, a record in the endpoint's Software Inventory Evidence Collection will change
due to new information becoming available or in order to correct prior errors in that information.
Such changes might or might not result in changes to the Software Identifier, depending on the
nature of the changes and the rules governing how Software Identifiers are derived from records
of the appropriate data model. </t>
<t>It is possible that a single software product is installed on a single endpoint multiple times.
If both of these installation instances are reported by the same source using the same data format,
then this will result in identical Software Identifiers for each installation instances. In other
words, Software Identifiers do not uniquely identify installation instances; they just uniquely
identify software products (which might have more than one installation instance). Instead,
to distinguish between multiple instances of a single software product, one needs to make use
of Record Identifiers, described in the following section.</t>
</list></t>
<section title="Record Identifiers" anchor="record_identifiers">
<t>A Record Identifier is a string generated by the SW-PC that is uniquely associated with a specific
record within the Endpoint's Software Inventory Evidence Collection. The SW-PC MUST assign a unique
identifier to each record when it is added to the Endpoint's Software Inventory Evidence Collection.
The Record Identifier SHOULD remain unchanged if that record is modified. The SWID-PC might wish to
assign Record Identifiers sequentially, but any scheme is acceptable provided that no two records receive
the same identifier.</t>
<t>Servers can use Record Identifiers to distinguish between multiple instances of a single software
product installed on an endpoint. Since each installation instance of a software product is associated
with a separate record, servers can use the record identifier to distinguish between instances. For
example, if an event is reported (as described in <xref target="Reporting-change-events"/>), the record
identifier will allow the server to discern which instance of a software product is involved.</t>
</section>
<section anchor="Using-record-identifiers-in-SW-attributes" title="Using Software and Record Identifiers in SW Attributes">
<t>A SW Attribute reporting an endpoint's Software Inventory Evidence Collection can contain Software Identifiers
instead of copies of software inventory evidence records. The message exchange is identical to the diagram
shown in <xref target="Basic-sw-message-exchange"/>,
but the contents of the SW Response are Software Identifiers instead
of evidence records. The SW Request attribute indicates whether the response is required to use full records or
Software Identifiers. Using Software Identifiers can reduce the attribute size of the response
by multiple orders of magnitude when compared to sending the same inventory using full records. A
SW-PC responds to a SW Request attribute requesting Software Identifiers the same
way it responds to a request for full software records, except that instead of copying each record entirely
into the attribute body of the response, it provides the specific values that comprise a Software
Identifier for each record.</t>
<t>All SW Response attributes include Record Identifiers for each reported record. This is true
regardless of whether the record is delivered in full or represented by a Software Identifier.</t>
</section>
</section>
<section anchor="Targeted-requests" title="Targeted Requests">
<t>Sometimes a SW-PV does not require information about every piece of software on an endpoint but only needs
to receive updates about certain software instances. For example, enterprise endpoints might be required to
have certain software products installed and to keep these updated. Instead of requesting a complete inventory
just to see if these products are present, the SW-PV can make a "targeted request" for the software in question.</t>
<t>Targeted requests follow the same message exchange described in <xref target="Basic-sw-message-exchange"/>.
The SW-PV targets
its request by providing one or more Software Identifiers in its SW Request attribute. The SW-PC
MUST then limit its response to contain only records that match the indicated Software Identifier(s). This
allows the network exchange to exclude information that is not relevant to a given policy question,
thus reducing unnecessary bandwidth consumption. The SW-PC's response might consist of full
records or of Software Identifiers, depending on the parameters of the SW Request.</t>
<t>Note that targeted requests identify the software relevant to the request only through Software
Identifiers. This specification does not support arbitrary, parameterized querying of
records. For example, one cannot request all records from a certain software publisher, or all records created
by a particular record source. Targeted requests only allow a requestor to request specific software (as
identified by their Software Identifiers) and receive a response that is limited to the named software.</t>
<t>There is
no assumption that a SW-PC will recognize "synonymous records" - that is, records from different sources
for the same software. Recall that different sources and data models may use different Software Identifier
strings for the same software product. The SW-PC returns only records that match the Software Identifiers
in the SW Request, even if there might be other records in the endpoint's Software Inventory Evidence Collection
for the same software product. This is necessary because SW-PCs might not have the ability to determine
that two Software Identifiers refer to the same product.</t>
<t>Targeted requests do not include Record Identifiers. The response to a targeted request MUST
include all records associated with the named Software Identifiers, including the case where
there are multiple records associated with a single Software Identifier.</t>
<t>SW-PCs MUST accept targeted requests and process them correctly as described above. SW-PVs
MUST be capable of making targeted requests and processing the responses thereto.</t>
</section>
<section anchor="Monitoring-changes-in-an-endpoint"
title="Monitoring Changes in an Endpoint's Software Inventory Evidence Collection">
<t>The software collection on an endpoint is not static. As software is installed, uninstalled, patched, or
updated, the Software Inventory Evidence Collection is expected to change to reflect the new software state on the
endpoint. Different record sources might update the evidence collection at different rates. For example, a
package manager might update its records in the Software Inventory Evidence Collection immediately whenever
it is used to add or remove a software product. By contrast, sources that perform periodic examination of the
endpoint would likely only update their records in the Software Inventory Evidence Collection after each
examination.</t>
<t>All SW-PCs MUST be able to be able to detect changes to the Software Inventory Evidence Collection.
Specifically, SW-PCs MUST be able to detect:</t>
<t>
<list style="symbols">
<t>The creation of records</t>
<t>The deletion of records</t>
<t>The alteration of records</t>
</list>
</t>
<t>An "alteration" is anything that modifies the contents of a record (or would modify it, if the record
is dynamically generated on demand) in any way, regardless of whether the change is functionally
meaningful. </t>
<t>SW-PCs MUST detect such changes to the endpoint's Software Inventory Evidence Collection in close to real-time
(i.e., within seconds) when the Posture Collector is operating. In addition, in the case where there is a period during
which the SW-PC is not operating, the SW-PC MUST be able to determine the net change to
the endpoint's Software Inventory Evidence Collection over the period it was not operational. Specifically, the "net
change" represents the difference between the state of the endpoint's Software Inventory Evidence Collection when the
SW-PC was last operational and monitoring its state, and the state of the endpoint's software inventory evidence
collection when the SW-PC resumed operation. Note that a net change might not reflect the total
number of change events over this interval. For example, if a record was altered three times
during a period when the SW-PC was unable to monitor for changes, the net change of this interval
might only note that there was an alteration to the record, but not how many individual alteration events
occurred. It is sufficient for a SW-PC's determination of a net change to note that there was a
difference between the earlier and current state rather than enumerating all the individual events that
allowed the current state to be reached.</t>
<t>The SW-PC MUST assign a time to each detected change in the endpoint's Software Inventory Evidence Collection.
These timestamps correspond to the SW-PC's best understanding as to when the detected
change occurred. These timestamps MUST be as accurate as possible. For changes to the
endpoint's Software Inventory Evidence Collection that occur while the SW-PC is operating, the SW-PC ought to
be able to assign a time to the event that is accurate to within a few seconds. For changes to the
endpoint's Software Inventory Evidence Collection that occur while the SW-PC is not operational, upon becoming
operational the SW-PC needs to make a best guess as to the time of the relevant events (possibly
by looking at timestamps on files), but these values might be off. In the case of dynamically
generated records, the time of change is the time at which the data from which the records are
generate changes, not the time at which a changed record is generated. For example, if records
are dynamically generated based on data in an RPM database, the time of change would be
when the RPM record was changed.</t>
<t>With regard to deletions of records, the SW-PC needs to detect the deletion and MUST retain
a copy of the full deleted record along with its Record Identifier so that the record itself can
be provided to the SW-PV upon request.
This copy of the record MUST be retained for a reasonable amount of time. Vendors and
administrators determine what "reasonable" means, but a copy of the record SHOULD be retained for
as long as the event recording the deletion of the record remains in the SW-PC's event log (as
described in <xref target="Reporting-change-events"/>). This is
recommended because, as long as the event is in the SW-PC's change logs, the SW-PC might
send an event attribute (described in <xref target="Reporting-change-events"/>) that references this record,
and a copy of the record is
needed if the SW-PV wanted a full copy of the relevant records.</t>
<t>With regard to alterations to a record, SW-PCs MUST detect any alterations to the contents
of a record. Alterations need to be detected even if they have no functional impact on the record. A
good guideline is that any alteration to a record that might change the value of a hash taken on the record's
contents needs to be detected by the SW-PC. A SW-PC might be unable to distinguish
modifications to the content of a record from modifications to the metadata the file system associates
with the record. For example, a SW-PC might use the "last modification" timestamp as an
indication of alteration to a given record, but a record's last modification time can change for reasons
other than modifications to the record contents. A SW-PC is still considered compliant with this
specification if it also reports metadata change events that do not change the record itself as
alterations to the record. In other words, while SW-PC authors are encouraged to exclude
modifications that do not affect the bytes within the record, discriminating between modifications
to file contents and changes to file metadata can be
difficult and time consuming on some systems. As such, as long as the alterations detected by a
SW-PC always cover all modifications to the contents of record, the SW-PC is considered
compliant even if it also registers alterations that do not modify the contents of a record as well. When
recording an alteration to a record, the SW-PC is only required to note that an alteration occurred.
The SW-PC is not required to note or record how the record altered, nor is it possible to include
such details in SW Attributes reporting the change to a SW-PV.</t>
</section>
<section anchor="Reporting-change-events" title="Reporting Change Events">
<t>As noted in the preceding section, SW-PCs MUST be able to detect changes to the endpoints software inventory
evidence collection (creation, deletion, and alteration) in near real-time while the SW-PC is
operational, and MUST be able to account for any net change to the endpoint's Software Inventory Evidence Collection
that occurs when the SW-PC is not operational. However, to be of use to the enterprise, the NEA Server
needs to be able to receive these events and be able to understand how new changes relate to earlier
changes. In Software Message and Attributes for PA-TNC, this is facilitated by reporting change events. All
SW-PCs MUST be capable of receiving requests for change events and sending change event
attributes. All SW-PVs MUST be capable of requesting and receiving change event attributes.</t>
<section anchor="Change-event-records" title="Change Event Records">
<t>A change event record consists of either a complete record or Software Identifier from the changed record along
with the following pieces of information:</t>
<t>
<list style="symbols">
<t>The nature of the change (i.e., creation, deletion, or lteration)</t>
<t>An Event Identifier (EID) value</t>
<t>An EID Epoch value</t>
</list>
</t>
<t>An EID is a 4-byte unsigned integer that the SW-PC assigns sequentially to each observed event
(whether detected in real-time or deduced by looking for net changes over a period of SW-PC
inactivity). All EIDs exist within the context of some "EID Epoch", which is also represented as a
4-byte unsigned integer. EID Epochs are used to ensure synchronization between the SW-PC and
any SW-PVs with which it communicates. EID Epoch values SHOULD be generated randomly
and in such a way that it is unlikely that the same EID Epoch is generated twice, even if the SW-PC
reverted to an earlier state (e.g., resetting it to factory defaults). In the case where a SW-PC
needs to reset its EID counter, either because it has exhausted all available EID values or because
the SW-PC's event log becomes corrupted, then a new EID Epoch MUST be selected.</t>
<t>Within an Epoch, EIDs MUST be assigned sequentially, so that if a particular event is assigned an
EID of N, the next observed event is given an EID of N+1. In some cases, events might occur
simultaneously, or the SW-PC might not otherwise be able to determine an ordering for events.
In these cases, the SW-PC creates an arbitrary ordering of the events and assigns EIDs according
to this ordering. Two change events MUST NOT ever be assigned the same EID within the same EID
Epoch. No meaningful comparison can be made between EID values of different Epochs.</t>
<t>The EID value of 0 is reserved and MUST NOT be associated with any event. Specifically, an EID of
0 in a SW Request attribute indicates that a SW-PV wants an inventory response rather than
an event response, while an EID of 0 in a SW Response is used to indicate the initial state of the
endpoint's Software Inventory Evidence Collection prior to the observation of any events. Thus the very first recorded
event in a SW-PC's records within an EID Epoch MUST be assigned a value of 1 or greater.
Note that EID and EID Epoch values are assigned by the SW-PC without regard to whether events
are being reported to one or more SW-PVs. The SW-PC records events and assigns EIDs
during its operation. Any and all SW-PVs that request event information from the SW-PC will
have those requests served from the same event records and thus will see the same EIDs and EID Epochs
for the same events.</t>
<t>The SW-PC MUST ensure there is no coverage gap (i.e., change events that are not recorded in
the SW-PC's records) in its change event records. This is necessary because a coverage gap
might give a SW-PV a false impression of the endpoint's state. For example, if a SW-PV saw
an event indicating that a particular record had been added to the endpoint's software inventory
evidence collection, and saw no subsequent events
indicating that record had been deleted, it might reasonably assume that this record was still present
and thus that the indicated software was still installed
(assuming the Epoch has not changed). If there is a coverage gap in the SW-PC's event records,
however, this assumption is false. For this reason, the SW-PC's event records MUST NOT contain
gaps. In the case where there are periods where it is possible that changes occurred without the
SW-PC detecting or recording them, the SW-PC MUST either compute a net change and
update its event records appropriately, or pick a new EID Epoch to indicate a discontinuity with previous
event records.</t>
<t>Within a given Epoch, once a particular event has been assigned an EID, this association MUST
NOT be changed. That is, within an Epoch, once an EID is assigned to an event, that EID cannot be
reassigned to a different event, and the event cannot be assigned a different EID. When the SW-PC's
Epoch changes, all of these associations between EIDs and events are cancelled, and EID
values once again become free for assignment.</t>
</section>
<section title="Updating Inventory Knowledge Based on Events">
<t>Modern endpoints can have hundreds of software products installed, most of which are unlikely to
change from one day to the next. As such, instead of exchanging a complete list of an endpoint's
inventory on a regular basis, one might wish to only identify changes since some earlier known state
of this inventory. This is readily facilitated by the use of EIDs to place change events in a context
relative to earlier state.</t>
<t>Every inventory sent by a SW-PC to a SW-PV (as described in <xref target="Basic-exchange"/> through
<xref target="Targeted-requests"/>)
includes the EID Epoch and EID of the last event recorded prior to that inventory being compiled.
This allows the SW-PV to place all subsequently received event records in context relative to this
inventory (since the EIDs represent a total ordering of all changes to the endpoint's software inventory evidence
collection). Specifically, a SW-PV (or, more likely, a database that collects and records its findings)
can record an endpoint's full inventory and also the EID and Epoch of the most recent event reflected
in that state. From that point on, if change events are observed, the attribute describing these events
indicates the nature of the change, the affected records, and the order in which these events
occurred (as indicated by the sequential EIDs). Using this information, any remote record of the
endpoint's Software Inventory Evidence Collection can be updated appropriately.</t>
</section>
<section anchor="Using-event-records-in-SW-attributes" title="Using Event Records in SW Attributes">
<t>A SW-PV MUST be able to request a list of event records instead of an inventory. The message
flow in such an exchange looks the same as the basic flow shown in <xref target="Basic-sw-message-exchange"/>.
The only difference is
that, in the SW Request attribute, the SW-PV provides an EID other than 0. (A value of 0 in
these fields represents a request for an inventory.) When the SW-PC receives such a request,
instead of identifying records from the endpoint's Software Inventory Evidence Collection, it consults its list of
detected changes. The SW-PC MUST add an event record to the SW Response attribute for
each recorded change event with an EID greater than or equal to the EID in the SW Request
attribute (although targeting of requests, as described in the next paragraph, might limit this list). A list
of event records MUST only contain events with EIDs that all come from the current Epoch.</t>
<t>SW-PVs can target requests for event records by including one or more Software Identifiers, as
described in <xref target="Targeted-requests"/>, in the SW Request that requests an event record list.
A targeted request
for event records is used to indicate that only events affecting software that match the provided
Software Identifiers are to be returned. Specifically, in response to a targeted request for event
records, the SW-PC MUST exclude any event records that are less than the indicated EID (within
the current EID Epoch) and exclude any event records where the affected software does not match
one of the provided Software Identifiers. This might mean that the resulting list of event records sent
in the response attribute does not provide a continuous sequence of EIDs. Both SW-PCs and
SWIC-PVs MUST support targeted request for event records.</t>
</section>
<section anchor="Partial-and-complete-lists-of-event-records"
title="Partial and Complete Lists of Event Records in SW Attributes">
<t>Over time, a SW-PC might record a large number of change events. If a SW-PV requests all
change events covering a large period of time, the resulting SW Response attribute might be
extremely large, especially if the SW-PV is requesting the use of full records instead of the use
of Software Identifiers (as described in <xref target="Using-record-identifiers-in-SW-attributes"/>).
In the case that the resulting attribute is
too large to send (either because it exceeds the 4GB attribute size limit imposed by the PA-TNC
specification, or because it exceeds some smaller size limit imposed on the SW-PC) the
SW-PC MAY send a partial list of event records back to the SW-PV.</t>
<t>Generation of a partial list of events in a SW Response attribute requires the SW-PC to identify
a "consulted range" of EIDs. A consulted range is the set of event records that are examined for
inclusion in the SW Response attribute and that are included in that attribute if applicable. Recall
that, if a SW Request is targeted, only event records that involve the indicated software would
be applicable. (See <xref target="Targeted-requests"/> for more on Targeted Request.)
If a request is not targeted, all event
records in the considered range are applicable and included in the SW Response attribute.</t>
<t>The lower bound of the consulted range MUST be the EID provided in the SW Request. (Recall
that a SW Request indicates a request for event records by providing a non-0 EID value in the
SW Request. See <xref target="Using-event-records-in-SW-attributes"/>.)
The upper bound of the consulted range is the EID of the latest
event record (as ordered by EID values) that is included in the SW Response attribute if it is
applicable to the request. The EID of this last event record is called the "Last Consulted EID". The
SW-PC chooses this Last Consulted EID based on the size of the event record list it is willing to
provide to the SW-PV.</t>
<t>A partial result list MUST include all applicable event records within the consulted range. This means
that for any applicable event record (i.e., any event record in an un-targeted request, or an event record
associated with software matching a requested Software Identifier in a targeted request)
whose EID is greater than or equal to the EID provided in the
SW Request and whose EID is less than or equal to the Last Consulted EID, that event record
MUST be included in the SW Response conveying this partial list of event records. This ensures
that every partial list of event records is always complete within its indicated range.</t>
<t>All SW Response attributes that convey event records (either using full records or using Software
Identifiers) include an Epoch, Last EID, and Last Consulted EID field. The Last EID
contains the EID of the last event record known to the SW-PC at the time that the SW Response
attribute was generated. The Last EID might or might not be part of the consulted range. As noted
above, the Last Consulted EID field contains the EID of the last event record in the consulted range.
The Epoch field contains the EID Epoch associated with the Last EID and Last Consulted EID fields
as well as all the EIDs in event records contained within the SW Response attribute. Note that, if
responding to a targeted SW Request, the SW Response attribute might not contain the event
record whose EID matches the Last Consulted EID value. For example, the last consulted EID record
might have been deemed inapplicable because it did not match the specified list of Software
Identifiers in the SW Request.</t>
<t>If a SW-PV receives a SW Response attribute where the Last EID and Last Consulted EID
fields are identical, the SW-PV knows that it has received a result list that is complete, given the
parameters of the request, up to the present time. On the other hand, if the Last EID and Last
Consulted EID values differ, the SW-PV has received a partial result list. In the latter case, if the
SW-PV wishes to try to collect the rest of the partially delivered result list it then sends a new
SW Request whose EID is one greater than the Last Consulted EID in the preceding response.
Doing this causes the SW-PC to generate another SW Response attribute containing event
records where the earliest reported event record is the one immediately after the event record with
the Last Consulted EID (since EIDs are assigned sequentially). By repeating this process until it
receives a SW Response where the Last EID and Last Consulted EID are equal, the SW-PV is
able to collect all event records over a given range, even if the complete set of event records would
be too large to deliver via a single attribute.</t>
<t>Implementers need to be aware that a SW Request might specify an EID that is greater than the
EID of the last event recorded by a SW-PC. In accordance with the behaviors described in
<xref target="Using-event-records-in-SW-attributes"/>,
a SW-PC MUST respond to such a request with a SW Response attribute of the
appropriate type (using full records or Software Identifiers as specified in the SW Request)
that contains zero event records. This is because the SW-PC has recorded no event records with
EIDs greater than or equal to the EID in the SW Request. In such a case, the Last Consulted EID
field MUST be set to the same value as the Last EID field in this SW Response attribute. This case
is called out because the consulted range on a SW-PC in such a situation is a negative range, where
the "first" EID in the range (provided in the SW Request) is greater than the "last" EID in the range
(this being the EID of the last recorded event on the SW-PC). Implementers need to ensure that
SW-PCs do not experience problems in such a circumstance.</t>
<t>Note that this specification only supports the returning of partial results when returning event records.
There is no way to return a partial inventory list under this specification.</t>
</section>
<section anchor="Synchronizing-event-identifiers-and-epochs" title="Synchronizing Event Identifiers and Epochs">
<t>Since EIDs are sequential within an Epoch, if a SW-PV's list of event records contains gaps in the
EID values within a single Epoch, the SW-PV knows that there are events that have not been
accounted for. The SW-PV can either request a new event list to collect the missing events or
request a full inventory to re-sync its understanding of the state of the Endpoint's Software Inventory
Evidence Collection. In
either case, after the SW-PV's record of the endpoint's Software Inventory Evidence Collection has been updated,
the SW-PV can record the new latest EID value and track events normally from that point on.</t>
<t>If the SW-PV receives any attribute from a SW-PC where the EID Epoch differs from the EID
Epoch that was used previously, then SW-PV or any entity using this information to track the
endpoint's Software Inventory Evidence Collection knows that there is a discontinuity in their understanding of the
endpoint's state. To move past this discontinuity and reestablish a current understanding of the state
of the endpoint's Software Inventory Evidence Collection, the SW-PV needs to receive a full inventory from the
endpoint. The SW-PV cannot be brought in sync with the endpoint's state through the collection of any
set of event records in this situation.
This is because it is not possible to account for all events on the SW-PC over the interval
since the previous Epoch was used, because there is no way to query for EIDs from a previous
Epoch. Once the SW-PV has received a full inventory for the new Epoch, the SW-PV records
the latest EID reported in this new Epoch and can track further events normally.</t>
<t>A SW-PC MUST NOT report events with EIDs from any Epoch other than the current EID Epoch.
The SW-PC MAY choose to purge all event records from a previous Epoch from memory after an
Epoch change. Alternately, the SW-PC MAY choose to retain some event records from a previous
EID Epoch and assign them new EIDs in the current Epoch. However, in the case where a SW-PC
chooses the latter option it MUST ensure that the order of events according to their EIDs is
unchanged and that there is no coverage gap between the first retained event recorded during the
previous Epoch (now reassigned with an EID in the current Epoch) and the first event recorded during
the current Epoch. In particular, the SW-PC MUST ensure that all change events that occurred
after the last recorded event from the previous Epoch are known and recorded. (This might not be
possible if the Epoch change is due to state corruption on the SW-PC.) A SW-PC might choose
to reassign EIDs to records from a preceding Epoch to create a "sliding window" of events, where
each Epoch change represents a shift in the window of available events.</t>
<t>In the case where a SW-PC suffers a crash and loses track of its current EID Epoch or current
EID, then it MUST generate a new EID Epoch value and begin assigning EIDs within that Epoch. In
this case, the SW-PC MUST purge all event records from before the crash as it cannot ensure
that there is not a gap between the last of those records and the next detected event. The process
for generating a new EID Epoch MUST minimize the possibility that the newly generated EID Epoch
is the same as a previously used EID Epoch.</t>
<t>The SW-PV will normally never receive an attribute indicating that the latest EID is less than the
latest EID reported in a previous attribute within the same EID Epoch. If this occurs, the SW-PC
has suffered an error of some kind, possibly indicative of at least partial corruption of its event log. In
this case, the SW-PV SHOULD treat the situation as if there was a change in Epoch and treat any
local copy of the endpoint's Software Inventory Evidence Collection as out-of-sync until a full inventory can be reported
by the SW-PC. In this case, the SW-PV SHOULD flag the occurrence so the SW-PC can be examined to
ensure it is now operating properly.</t>
</section>
</section>
<section anchor="subscriptions" title="Subscriptions">
<t>Thus far, all message exchanges discussed assume that a SW-PV sent an SW Request
attribute and the SW-PC is providing a direct response to that request. The Software Message and
Attributes for PA-TNC specification also supports the ability for a SW-PC to send a message with a
SW Attribute to the SW-PV in response to observed changes in the endpoint's software inventory evidence
collection, instead of in direct response to a SW Request. An agreement by a SW-PC to send
content when certain changes are detected to the endpoint's Software Inventory Evidence Collection is referred to in this
specification as a "subscription", and the SW-PV that receives this content is said to be
"subscribed to" the given SW-PC. All SW-PCs and SW-PVs MUST support the use of
subscriptions.</t>
<section title="Establishing Subscriptions">
<t>A SW-PV establishes a subscription on a particular SW-PC by sending a SW Request
attribute with the Subscription flag set. The SW Request attribute is otherwise identical to the SW
Requests discussed in previous sections. Specifically, such a SW Request might request full records
or Software Identifiers, might be targeted, and might request change event records or endpoint
inventory. Assuming no error is encountered, a SW-PC MUST send a SW Response attribute
in direct response to this SW Request attribute, just as if the Subscription flag was not set. As such,
the message exchange that establishes a new subscription in a SW-PC has the same flow seen
in the previous message exchanges, as depicted in <xref target="Basic-sw-message-exchange"/>.
If the SW-PV does not receive a
PA-TNC Error attribute (as described in <xref target="Error-handling"/> and
<xref target="PA-TNC-error-as-used-by-SW"/>)
in response to their subscription request,
the subscription has been successfully established on the SW-PC. The SW Request attribute
that establishes a new subscription is referred to as the "establishing request" for that subscription.</t>
<t>When a subscription is established it is assigned a Subscription ID value. The Subscription ID is
equal to the value of the Request ID of the establishing request. (For more about Request IDs, see
<xref target="Request-ids"/>.)</t>
<t>A SW-PC MUST have the ability to record and support multiple simultaneous subscriptions from
a single party and from multiple parties. A SW-PV MUST have the ability to record
and support multiple simultaneous subscriptions to a single party and subscriptions to multiple
parties.</t>
</section>
<section anchor="Managing-subscriptions" title="Managing Subscriptions">
<t>The SW-PC MUST record each accepted subscription along with the identity of the party to whom
attributes are to be pushed in compliance with the subscription. This identity includes both the
NEA Server's connection ID and the Posture Validator Identifier from the PB-PA message that delivered
the request. </t>
<t>Likewise, SW-PVs MUST record each accepted subscription for which they are the subscribing
party along with the associated Subscription ID and the identity of the SW-PC that will be fulfilling the
subscription. The SW-PV needs to retain this information in order to correctly interpret pushed
SW Response attributes sent in fulfillment of the subscription. The identity of the SW-PC is
given in the Posture Collector Identifier of the PB-PA message header in all messages from
that SW-PC.</t>
</section>
<section anchor="Terminating-subscriptions" title="Terminating Subscriptions">
<t>Subscriptions MAY be terminated at any time by the subscribing SW-PV by setting the Clear
Subscriptions flag in a SW Request. (See <xref target="SW-request"/> for more on using this flag.) In the case that
a SW Request with the Clear Subscriptions flag set is received the SW-PC MUST only clear subscriptions that
match both the NEA server connection ID and the SW-PV ID for this SW Request,
and MUST clear all such subscriptions. </t>
<t>This specification does not give the SW-PV the ability to terminate subscriptions individually - all
subscriptions to the SW-PV are cleared when the Clear Subscriptions flag is set.</t>
<t>This specification does not give the SW-PC the ability to unilaterally terminate a subscription.
However, if the SW-PC experiences a fatal error fulfilling a subscription, resulting in sending a
PA-TNC Error attribute of type SW_SUBSCRIPTION_FULFILLMENT_ERROR, then the
subscription whose fulfillment led to the error MUST be treated as terminated by both the SW-PC
and the SW-PV. Only the subscription experiencing the error is cancelled and other subscriptions
are unaffected. See <xref target="Error-handling"/> for more on this error condition.</t>
<t>Finally, a subscription is terminated if the connection between the SW-PC and SW-PV is
deleted. This occurs when the connection ID used in the messages between the SW-PC and the SW-PV
becomes unbound. Loss of this connection ID would prevent the SW-PC from sending messages in fulfillment
of this subscription. As such, loss of the connection ID necessarily forces subscription termination
between the affected parties.</t>
</section>
<section title="Subscription Status">