draft-coffin-sacm-nea-swid-patnc-02.txt   draft-coffin-sacm-nea-swid-patnc-03.txt 
SACM C. Coffin SACM C. Coffin
Internet-Draft D. Haynes Internet-Draft D. Haynes
Intended status: Standards Track C. Schmidt Intended status: Standards Track C. Schmidt
Expires: March 16, 2017 The MITRE Corporation Expires: May 4, 2017 The MITRE Corporation
J. Fitzgerald-McKay J. Fitzgerald-McKay
Department of Defense Department of Defense
September 12, 2016 October 31, 2016
Software Message and Attributes for PA-TNC Software Inventory Message and Attributes (SWIMA) for PA-TNC
draft-coffin-sacm-nea-swid-patnc-02 draft-coffin-sacm-nea-swid-patnc-03
Abstract Abstract
This document specifies the Software Message and Attributes for PA- This document specifies the Software Inventory Message and Attributes
TNC. It extends the PA-TNC specification [RFC5792] by providing for PA-TNC. It extends the PA-TNC specification [RFC5792] by
specific attributes and message exchanges to allow endpoints to providing specific attributes and message exchanges to allow
report their software inventory information to a NEA server (as endpoints to report their installed software inventory information to
described in [RFC5209]). a NEA server (as described in [RFC5209]).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope and Audience . . . . . . . . . . . . . . . . . . . 4 1.1. Network Endpoint Assessment (NEA) . . . . . . . . . . . . 5
1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 7 2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8
2.1.1. Use Software Inventory as a Factor in Determining 2.1.1. Use Software Inventory as a Factor in Determining
Endpoint Access . . . . . . . . . . . . . . . . . . . 8 Endpoint Access . . . . . . . . . . . . . . . . . . . 8
2.1.2. Maintain a Central Repository Reflecting an 2.1.2. Maintain a Central Repository Reflecting an
Endpoint's Software Inventory . . . . . . . . . . . . 8 Endpoint's Software Inventory . . . . . . . . . . . . 9
2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 9 2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10
2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 9 2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 10
2.3. Specification Requirements . . . . . . . . . . . . . . . 10 2.3. Specification Requirements . . . . . . . . . . . . . . . 11
2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 11 2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 12
2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 12 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 13
2.7. Software Message and Attributes for PA-TNC Diagram 2.7. Software Inventory Message and Attributes for PA-TNC
Conventions . . . . . . . . . . . . . . . . . . . . . . . 12 Diagram Conventions . . . . . . . . . . . . . . . . . . . 13
3. Software Message and Attributes for PA-TNC System 3. Software Inventory Message and Attributes for PA-TNC System
Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Basic Inventory Exchange . . . . . . . . . . . . . . . . 13 3.1. Basic Attribute Exchange . . . . . . . . . . . . . . . . 14
3.2. Software Identifiers . . . . . . . . . . . . . . . . . . 14 3.2. Core Software Reporting Information . . . . . . . . . . . 15
3.2.1. Record Identifiers . . . . . . . . . . . . . . . . . 15 3.2.1. Software Identifiers . . . . . . . . . . . . . . . . 15
3.2.2. Using Software and Record Identifiers in SW 3.2.1.1. Record Identifiers . . . . . . . . . . . . . . . 16
Attributes . . . . . . . . . . . . . . . . . . . . . 16 3.2.1.2. Software Locators . . . . . . . . . . . . . . . . 17
3.3. Targeted Requests . . . . . . . . . . . . . . . . . . . . 16 3.2.1.3. Using Software and Record Identifiers in SW
Attributes . . . . . . . . . . . . . . . . . . . 18
3.3. Targeted Requests . . . . . . . . . . . . . . . . . . . . 18
3.4. Monitoring Changes in an Endpoint's Software Inventory 3.4. Monitoring Changes in an Endpoint's Software Inventory
Evidence Collection . . . . . . . . . . . . . . . . . . . 17 Evidence Collection . . . . . . . . . . . . . . . . . . . 19
3.5. Reporting Change Events . . . . . . . . . . . . . . . . . 19 3.5. Reporting Change Events . . . . . . . . . . . . . . . . . 22
3.5.1. Change Event Records . . . . . . . . . . . . . . . . 20 3.5.1. Event Identifiers . . . . . . . . . . . . . . . . . . 22
3.5.2. Updating Inventory Knowledge Based on Events . . . . 21 3.5.2. Core Event Tracking Information . . . . . . . . . . . 23
3.5.3. Using Event Records in SW Attributes . . . . . . . . 22 3.5.3. Updating Inventory Knowledge Based on Events . . . . 24
3.5.4. Partial and Complete Lists of Event Records in SW 3.5.4. Using Event Records in SW Attributes . . . . . . . . 24
Attributes . . . . . . . . . . . . . . . . . . . . . 22 3.5.5. Partial and Complete Lists of Event Records in SW
3.5.5. Synchronizing Event Identifiers and Epochs . . . . . 24 Attributes . . . . . . . . . . . . . . . . . . . . . 25
3.6. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 26 3.5.6. Synchronizing Event Identifiers and Epochs . . . . . 27
3.6.1. Establishing Subscriptions . . . . . . . . . . . . . 26 3.6. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 28
3.6.2. Managing Subscriptions . . . . . . . . . . . . . . . 27 3.6.1. Establishing Subscriptions . . . . . . . . . . . . . 29
3.6.3. Terminating Subscriptions . . . . . . . . . . . . . . 27 3.6.2. Managing Subscriptions . . . . . . . . . . . . . . . 29
3.6.4. Subscription Status . . . . . . . . . . . . . . . . . 28 3.6.3. Terminating Subscriptions . . . . . . . . . . . . . . 30
3.6.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 28 3.6.4. Subscription Status . . . . . . . . . . . . . . . . . 30
3.6.5.1. Subscriptions Reporting Inventories . . . . . . . 30 3.6.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 31
3.6.5.2. Subscriptions Reporting Events . . . . . . . . . 30 3.6.5.1. Subscriptions Reporting Inventories . . . . . . . 32
3.6.5.3. Targeted Subscriptions . . . . . . . . . . . . . 31 3.6.5.2. Subscriptions Reporting Events . . . . . . . . . 32
3.6.5.4. No Subscription Consolidation . . . . . . . . . . 32 3.6.5.3. Targeted Subscriptions . . . . . . . . . . . . . 34
3.6.5.5. Delayed Subscription Fulfillment . . . . . . . . 32 3.6.5.4. No Subscription Consolidation . . . . . . . . . . 34
3.7. Multiple Sources of Software Inventory Evidence Records . 33 3.6.5.5. Delayed Subscription Fulfillment . . . . . . . . 35
3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 34 3.7. Multiple Sources of Software Inventory Evidence Records . 35
4. Software Message and Attributes for PA-TNC Protocol . . . . . 36 3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 37
4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 36 4. Software Inventory Message and Attributes for PA-TNC Protocol 38
4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 36 4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 38
4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 37 4.2. SW Attribute Overview . . . . . . . . . . . . . . . . . . 39
4.4. SW Attribute Overview . . . . . . . . . . . . . . . . . . 38 4.3. SW Attribute Exchanges . . . . . . . . . . . . . . . . . 41
4.5. SW Attribute Exchanges . . . . . . . . . . . . . . . . . 40 4.4. Software Inventory Message and Attributes for PA-TNC
4.6. Software Message and Attributes for PA-TNC Attribute Attribute Enumeration . . . . . . . . . . . . . . . . . . 43
Enumeration . . . . . . . . . . . . . . . . . . . . . . . 42 4.5. Normalization of Text Encoding . . . . . . . . . . . . . 44
4.7. Normalization of Text Encoding . . . . . . . . . . . . . 43 4.6. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 44
4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 44 4.7. SW Request . . . . . . . . . . . . . . . . . . . . . . . 45
4.9. SW Request . . . . . . . . . . . . . . . . . . . . . . . 45 4.8. Software Identifier Inventory . . . . . . . . . . . . . . 49
4.10. Software Identifier Inventory . . . . . . . . . . . . . . 48 4.9. Software Identifier Events . . . . . . . . . . . . . . . 52
4.11. Software Identifier Events . . . . . . . . . . . . . . . 51 4.10. Software Inventory . . . . . . . . . . . . . . . . . . . 57
4.12. Software Inventory . . . . . . . . . . . . . . . . . . . 56 4.11. Software Events . . . . . . . . . . . . . . . . . . . . . 60
4.13. Software Events . . . . . . . . . . . . . . . . . . . . . 58 4.12. Subscription Status Request . . . . . . . . . . . . . . . 64
4.14. Subscription Status Request . . . . . . . . . . . . . . . 62 4.13. Subscription Status Response . . . . . . . . . . . . . . 65
4.15. Subscription Status Response . . . . . . . . . . . . . . 62 4.14. PA-TNC Error as Used by Software Inventory Message and
4.16. PA-TNC Error as Used by Software Message and Attributes Attributes for PA-TNC . . . . . . . . . . . . . . . . . . 67
for PA-TNC . . . . . . . . . . . . . . . . . . . . . . . 64 4.14.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and
4.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 69
SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 66 4.14.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 70
4.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 68 4.14.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 72
4.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 69 5. Supported Data Models . . . . . . . . . . . . . . . . . . . . 74
5. Supported Data Models . . . . . . . . . . . . . . . . . . . . 71 5.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 74
5.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 71
5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID 5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID
Tags using XML . . . . . . . . . . . . . . . . . . . 72 Tags using XML . . . . . . . . . . . . . . . . . . . 74
5.1.2. Guidance on Creation of Software Identifiers from ISO 5.1.2. Guidance on Creation of Software Identifiers from ISO
2015 SWID Tags . . . . . . . . . . . . . . . . . . . 72 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 75
5.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 72 5.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 75
5.2.1. Guidance on Normalizing Source Data to ISO 2015 SWID 5.2.1. Guidance on Normalizing Source Data to ISO 2015 SWID
Tags using XML . . . . . . . . . . . . . . . . . . . 72 Tags using XML . . . . . . . . . . . . . . . . . . . 75
5.2.2. Guidance on Creation of Software Identifiers from ISO 5.2.2. Guidance on Creation of Software Identifiers from ISO
2015 SWID Tags . . . . . . . . . . . . . . . . . . . 73 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 75
6. Security Considerations . . . . . . . . . . . . . . . . . . . 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 76
6.1. Evidentiary Value of Software Inventory Evidence Records 73 6.1. Evidentiary Value of Software Inventory Evidence Records 76
6.2. Sensitivity of Collected Records . . . . . . . . . . . . 74 6.2. Sensitivity of Collected Records . . . . . . . . . . . . 76
6.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 75 6.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 78
6.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 75 6.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 78
6.5. Sanitization of Record Fields . . . . . . . . . . . . . . 76 6.5. Sanitization of Record Fields . . . . . . . . . . . . . . 79
6.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 76 6.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 79
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 76
8. Relationship to Other Specifications . . . . . . . . . . . . 77 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 79
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 8. Relationship to Other Specifications . . . . . . . . . . . . 79
9.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
9.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 78 9.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 80
9.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 79 9.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 81
9.4. Registry for Software Data Models . . . . . . . . . . . . 80 9.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 82
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.4. Registry for Software Data Models . . . . . . . . . . . . 83
10.1. Normative References . . . . . . . . . . . . . . . . . . 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.2. Informative References . . . . . . . . . . . . . . . . . 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 10.2. Informative References . . . . . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction 1. Introduction
1.1. Scope and Audience 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 installation inventory lists can
be used to indicate compliance or non-compliance with these
requirements. Software installation inventories and the patch level
of the identified 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 installed software
inventory highly useful to NEA Servers and other enterprise security
applications.
There is a need for a standardized method for exchanging software
inventory that carries a software identifier (a unique identifier
associated with a specific software product and version thereof). In
some cases, it may also be necessary to convey information that
characterizes this product (i.e., provides metadata about the product
beyond its identifier) as well as observable installation
information. These "Messages and Attributes" would enable software
identification, installation, and characterization information to be
provided for any software installed on any endpoint that supports
this specification.
To that end, 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.
This specification is designed only to report software that is
installed on an endpoint. In particular, it does not monitor or
report information about what software is running on the endpoint.
Likewise, it is not intended to report individual files, libraries,
installation packages, or similar artifacts. While all of this
information has its uses, this information requires different
metadata and different methods of monitoring the endpoint. As a
result, this specification focuses solely on installed software,
leaving reporting of other classes of endpoint information to other
specifications.
1.1. Network Endpoint Assessment (NEA)
The Network Endpoint Assessment (NEA) Working Group defines an open The Network Endpoint Assessment (NEA) Working Group defines an open
solution architecture that enables network operators to collect and solution architecture that enables network operators to collect and
utilize information about endpoint configuration and state. This utilize information about endpoint configuration and state. This
information can be used to enforce policies, monitor endpoint health, information can be used to enforce policies, monitor endpoint health,
and for many other activities. Information about the software and for many other activities. Information about the software
present on an endpoint is an important consideration for such present on an endpoint is an important consideration for such
activities. Such information can come from multiple sources, activities. Such information can come from multiple sources,
including tag files (such as ISO SWID tags [SWID], reports from third including tag files (such as ISO SWID tags [SWID], reports from third
party inventory tools, output from package managers, and other party inventory tools, output from package managers, and other
skipping to change at page 5, line 30 skipping to change at page 6, line 30
+-------------+ +--------------+ +-------------+ +--------------+
| Posture | | Posture | | Posture | | Posture |
| Transport | <--------PT--------> | Transport | | Transport | <--------PT--------> | Transport |
| Client | | Server | | Client | | Server |
| (1 .. N) | | (1 .. N) | | (1 .. N) | | (1 .. N) |
+-------------+ +--------------+ +-------------+ +--------------+
NEA CLIENT NEA SERVER NEA CLIENT NEA SERVER
Figure 1: NEA Reference Model Figure 1: NEA Reference Model
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.
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.
Before reading this specification any further, the reader should Before reading this specification any further, the reader should
review and understand the NEA reference architecture as described in review and understand the NEA reference architecture as described in
the Network Endpoint Assessment (NEA): Overview and Requirements the Network Endpoint Assessment (NEA): Overview and Requirements
[RFC5209]. The reader should also understand the capabilities and [RFC5209]. The reader should also understand the capabilities and
requirements common to PA-TNC interfaces as defined in RFC 5792 requirements common to PA-TNC interfaces as defined in RFC 5792
[RFC5792]. [RFC5792].
This document is based on standards published by the Trusted This document is based on standards published by the Trusted
Computing Group's Trusted Network Communications (TNC) workgroup. Computing Group's Trusted Network Communications (TNC) workgroup.
The TNC and NEA architectures are interoperable and the following The TNC and NEA architectures are interoperable and the following
skipping to change at page 6, line 42 skipping to change at page 7, line 35
informative comments and normative requirements. Therefore, for the informative comments and normative requirements. Therefore, for the
sake of clarity, note that lower case instances of must, should, etc. sake of clarity, note that lower case instances of must, should, etc.
do not indicate normative requirements. do not indicate normative requirements.
1.3. Definitions 1.3. Definitions
This section defines terms with special meaning within this document. This section defines terms with special meaning within this document.
SW-PC - A Posture Collector (PC) that conforms to this specification. SW-PC - A Posture Collector (PC) that conforms to this specification.
Note that such a posture collector might also support other PA-TNC Note that such a posture collector might also support other PA-TNC
exchanges beyond Software Message and Attributes for PA-TNC. exchanges beyond Software Inventory Message and Attributes for PA-
TNC.
SW-PV - A Posture Validator (PV) that conforms to this specification. SW-PV - A Posture Validator (PV) that conforms to this specification.
Note that such a posture verifier might also support other PA-TNC Note that such a posture verifier might also support other PA-TNC
exchanges beyond Software Message and Attributes for PA-TNC. exchanges beyond Software Inventory Message and Attributes for PA-
TNC.
SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792 SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792
[RFC5792] extension for conveying software inventory information. [RFC5792] extension for conveying software inventory information.
This specification defines several new attribute types. This specification defines several new attribute types.
Endpoint's Software Inventory Evidence Collection - The set of Endpoint's Software Inventory Evidence Collection - The set of
information regarding the set of software installed on an endpoint information regarding the set of software installed on an endpoint.
and expressed using one of the Software Message and Attributes data An endpoint's software inventory evidence collection might include
models, as described in the Software Data Model IANA table (see information created by or derived from multiple sources, including
Section 9.4. An endpoint's software inventory evidence collection but not limited to SWID tag files deposited on the file system during
might include information created by or derived from multiple software installation, information generated to report output from
sources, including but not limited to SWID tag files deposited on the software discovery tools, and information dynamically generated by a
file system during software installation, information generated to software or package management system on an endpoint.
report output from software discovery tools, and information
dynamically generated by a software or package management system on
an endpoint.
Software Inventory Evidence Record - The endpoint's Software Software Inventory Evidence Record - The endpoint's Software
Inventory Evidence Collection is composed of "records". Each record Inventory Evidence Collection is composed of "records". Each record
corresponds to one installed instance of a particular software corresponds to one installed instance of a particular software
product as reported by some data source. It is possible for a single product as reported by some data source. It is possible for a single
installed instance to have multiple software inventory evidence installed instance to have multiple software inventory evidence
records in an endpoint's Software Inventory Evidence Collection - records in an endpoint's Software Inventory Evidence Collection -
this can happen if multiple sources all report the same software this can happen if multiple sources all report the same software
installation instance. installation instance.
Software Identifier - A string associated with a specific version of Software Identifier - A string associated with a specific version of
a specific software product. Each supported Software Message and a specific software product. Each supported Software Inventory
Attributes for PA-TNC data model has its own rules for how a Software Message and Attributes for PA-TNC data model has its own rules for
Identifier (see Section 3.2) is derived from the representation of how a Software Identifier (see Section 3.2.1) is derived from the
the given software product using that data model, and different representation of the given software product using that data model,
sources for this information might populate relevant information and different sources for this information might populate relevant
differently. As such, while each Software Identifier uniquely information differently. As such, while each Software Identifier
identifies a specific software product, the same software product uniquely identifies a specific software product, the same software
might be associated with multiple Software Identifiers reflecting product might be associated with multiple Software Identifiers
differences between different information sources and supported data reflecting differences between different information sources and
models. supported data models.
2. Background 2. Background
2.1. Supported Use Cases 2.1. Supported Use Cases
This section describes the Software Message and Attributes for PA-TNC This section describes the Software Inventory Message and Attributes
use cases supported by this specification. The primary use of for PA-TNC use cases supported by this specification. The primary
exchanging software inventory information over the PA-TNC interface use of exchanging software inventory information over the PA-TNC
is to enable a challenger (e.g. NEA Server) to obtain inventory interface is to enable a challenger (e.g. NEA Server) to obtain
evidence about some system in a way that conforms to NEA procedures inventory evidence about some system in a way that conforms to NEA
and expressed using a standard format. Collected software procedures and expressed using a standard format. Collected software
information can support a range of security activities including information can support a range of security activities including
determining whether an endpoint is permitted to connect to the determining whether an endpoint is permitted to connect to the
enterprise, determining which endpoints contain software that enterprise, determining which endpoints contain software that
requires patching, and similar activities. requires patching, and similar activities.
2.1.1. Use Software Inventory as a Factor in Determining Endpoint 2.1.1. Use Software Inventory as a Factor in Determining Endpoint
Access Access
Some enterprises might define security policies that require Some enterprises might define security policies that require
connected endpoints to have certain pieces of security software connected endpoints to have certain pieces of security software
installed. By contrast, some security policies might prevent access installed. By contrast, some security policies might prevent access
by endpoints that have certain prohibited pieces of software by endpoints that have certain prohibited pieces of software
installed, such as applications that pose known security risks. To installed, such as applications that pose known security risks. To
support such policies, the NEA Server needs to collect evidence support such policies, the NEA Server needs to collect evidence
indicating the software inventory of an endpoint that is seeking to indicating the software inventory of an endpoint that is seeking to
initiate or continue connectivity to the enterprise. initiate or continue connectivity to the enterprise.
Software Message and Attributes for PA-TNC facilitates policy Software Inventory Message and Attributes for PA-TNC facilitates
decisions that consider an endpoint's software inventory by providing policy decisions that consider an endpoint's software inventory by
the NEA Server with software inventory information from the endpoint. providing the NEA Server with software inventory information from the
The SW-PC can provide a complete or partial inventory to the SW-PV as endpoint. The SW-PC can provide a complete or partial inventory to
required to determine policy compliance. The SW-PV can then use this the SW-PV as required to determine policy compliance. The SW-PV can
as evidence of compliance or non-compliance with enterprise policy. then use this as evidence of compliance or non-compliance with
enterprise policy.
2.1.2. Maintain a Central Repository Reflecting an Endpoint's Software 2.1.2. Maintain a Central Repository Reflecting an Endpoint's Software
Inventory Inventory
Many tools can use information about an endpoint's software inventory Many tools can use information about an endpoint's software inventory
to monitor and enforce the security of an enterprise. For example, a to monitor and enforce the security of an enterprise. For example, a
software patching service can use an endpoint's software inventory to software patching service can use an endpoint's software inventory to
determine whether certain endpoints have software that requires determine whether certain endpoints have software that requires
patching. A vulnerability management tool might identify endpoints patching. A vulnerability management tool might identify endpoints
with known vulnerabilities (patched or otherwise) and use this to with known vulnerabilities (patched or otherwise) and use this to
gauge enterprise exposure to attack. A license management tool might gauge enterprise exposure to attack. A license management tool might
verify that all copies of a particular piece of software are verify that all copies of a particular piece of software are
accounted for within the enterprise. The presence of a central accounted for within the enterprise. The presence of a central
repository representing a real-time understanding of each endpoint's repository representing a real-time understanding of each endpoint's
software inventory facilitates all such activities. Using a central software inventory facilitates all such activities. Using a central
repository that can ensure the freshness of its collected information repository that can ensure the freshness of its collected information
is generally more efficient than having each tool collect the same is generally more efficient than having each tool collect the same
inventory information from each endpoint individually and leads to a inventory information from each endpoint individually and leads to a
more consistent understanding of enterprise state. more consistent understanding of enterprise state.
Software Message and Attributes for PA-TNC supports this activity Software Inventory Message and Attributes for PA-TNC supports this
through a number of mechanisms. As noted above, it allows a SW-PC to activity through a number of mechanisms. As noted above, it allows a
provide a complete list of software present in an endpoint's Software SW-PC to provide a complete list of software present in an endpoint's
Inventory Evidence Collection to the SW-PV, which can then pass this Software Inventory Evidence Collection to the SW-PV, which can then
information on to a central repository such as a Configuration pass this information on to a central repository such as a
Management Database (CMDB) or similar application. In addition, SW- Configuration Management Database (CMDB) or similar application. In
PCs are required to be able to monitor for changes to an endpoint's addition, SW-PCs are required to be able to monitor for changes to an
Software Inventory Evidence Collection in near real-time and push endpoint's Software Inventory Evidence Collection in near real-time
reports of changes to the SW-PV as soon as those changes are 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 detected. Thus any central repository fed by a SW-PV receiving such
information can be updated soon after the change occurs. Keeping information can be updated soon after the change occurs. Keeping
such a central repository synchronized with the state of each such a central repository synchronized with the state of each
endpoint's Software Inventory Evidence Collection allows tools that endpoint's Software Inventory Evidence Collection allows tools that
use this information for their own security activities to make use this information for their own security activities to make
decisions in a consistent, efficient manner. decisions in a consistent, efficient manner.
2.1.3. PA-TNC Use Cases 2.1.3. PA-TNC Use Cases
Software Message and Attributes for PA-TNC are intended to operate Software Inventory Message and Attributes for PA-TNC are intended to
over the PA-TNC interface and, as such, are intended to meet the use operate over the PA-TNC interface and, as such, are intended to meet
cases set out in the PA-TNC specification. the use cases set out in the PA-TNC specification.
2.2. Non-supported Use Cases 2.2. Non-supported Use Cases
Some use cases not covered by this version of Software Message and Some use cases not covered by this version of Software Inventory
Attributes for PA-TNC include: Message and Attributes for PA-TNC include:
o This specification does not address how the endpoint's Software o This specification does not address how the endpoint's Software
Inventory Evidence Collection is populated. In particular, NEA Inventory Evidence Collection is populated. In particular, NEA
components are not expected to perform software discovery components are not expected to perform software discovery
activities beyond compiling information in an endpoint's Software activities beyond compiling information in an endpoint's Software
Inventory Evidence Collection. This collection might potentially Inventory Evidence Collection. This collection might potentially
come from multiple sources on the endpoint (e.g., information come from multiple sources on the endpoint (e.g., information
generated dynamically by package management tools or discovery generated dynamically by package management tools or discovery
tools, as well as SWID tag files discovered on the file system). tools, as well as SWID tag files discovered on the file system).
While an enterprise might make use of software discovery While an enterprise might make use of software discovery
procedures to identify installed software such procedures are procedures to identify installed software such procedures are
outside the scope of this specification. outside the scope of this specification.
o This specification does not address converting inventory o This specification does not address converting inventory
information expressed in a proprietary format into the standard information expressed in a proprietary format into formats used in
format used in the messages described in this specification. the attributes described in this specification. Instead, it
Instead, it focuses exclusively on defining interfaces for the focuses exclusively on defining interfaces for the transportation
transportation of software information in the expectation that of software information in the expectation that this is the format
this is the format around which reporting tools will converge. around which reporting tools will converge.
o This specification provides no mechanisms for a posture validator o This specification provides no mechanisms for a posture validator
to request a specific list of software information based on to request a specific list of software information based on
arbitrary software properties. For example, requesting only arbitrary software properties. For example, requesting only
information about software from a particular vendor is not information about software from a particular vendor is not
supported. After the endpoint's software inventory evidence supported. After the endpoint's software inventory evidence
collection has been copied to some central location, such as the collection has been copied to some central location, such as the
CMDB, processes there can perform queries based on any criteria CMDB, processes there can perform queries based on any criteria
present in the collected information, but this specification does present in the collected information, but this specification does
not address using such queries to constrain the initial collection not address using such queries to constrain the initial collection
skipping to change at page 10, line 22 skipping to change at page 11, line 14
files. Successful evaluation of such tests leads to greater files. Successful evaluation of such tests leads to greater
assurance that the indicated software is present on the endpoint. assurance that the indicated software is present on the endpoint.
Currently, most SWID tag creators do not provide values for tag Currently, most SWID tag creators do not provide values for tag
fields that support local testing. For this reason, the added fields that support local testing. For this reason, the added
complexity of supporting endpoint testing using these fields is complexity of supporting endpoint testing using these fields is
out of scope for this specification. Future versions of this out of scope for this specification. Future versions of this
specification might add support for such testing. specification might add support for such testing.
2.3. Specification Requirements 2.3. Specification Requirements
Below are the requirements that the Software Message and Attributes Below are the requirements that the Software Inventory Message and
for PA-TNC specification is required to meet in order to successfully Attributes for PA-TNC specification is required to meet in order to
play its role in the NEA architecture. successfully play its role in the NEA architecture.
o Efficient o Efficient
The NEA architecture enables delay of network access until the The NEA architecture enables delay of network access until the
endpoint is determined not to pose a security threat to the network endpoint is determined not to pose a security threat to the network
based on its asserted integrity information. To minimize user based on its asserted integrity information. To minimize user
frustration, the Software Message and Attributes for PA-TNC ought to frustration, the Software Inventory Message and Attributes for PA-TNC
minimize overhead delays and make PA-TNC communications as rapid and ought to minimize overhead delays and make PA-TNC communications as
efficient as possible. rapid and efficient as possible.
Efficiency is also important when one considers that some network Efficiency is also important when one considers that some network
endpoints are small and low powered, some networks are low bandwidth endpoints are small and low powered, some networks are low bandwidth
and/or high latency, and some transport protocols (such as PT-EAP, and/or high latency, and some transport protocols (such as PT-EAP,
Posture Transport (PT) Protocol for Extensible Authentication Posture Transport (PT) Protocol for Extensible Authentication
Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier
protocol might allow only one packet in flight at a time or only one protocol might allow only one packet in flight at a time or only one
roundtrip. However, when the underlying PT protocol imposes fewer roundtrip. However, when the underlying PT protocol imposes fewer
constraints on communications, this protocol ought to be capable of constraints on communications, this protocol ought to be capable of
taking advantage of more robust communication channels (e.g. using taking advantage of more robust communication channels (e.g. using
larger messages or multiple roundtrips). larger messages or multiple roundtrips).
o Scalable o Scalable
Software Message and Attributes for PA-TNC needs to be usable in Software Inventory Message and Attributes for PA-TNC needs to be
enterprises that contain tens of thousands of endpoints or more. As usable in enterprises that contain tens of thousands of endpoints or
such, it needs to allow a security tools to make decisions based on more. As such, it needs to allow a security tools to make decisions
up-to-date information about an endpoint's software inventory without based on up-to-date information about an endpoint's software
creating an excessive burden on the enterprise's network. inventory without creating an excessive burden on the enterprise's
network.
o Interoperable o Interoperable
This specification defines the protocol for how PCs and PVs can This specification defines the protocol for how PCs and PVs can
exchange and use software information to provide a NEA Server with exchange and use software information to provide a NEA Server with
information about an endpoint's software inventory. Therefore a key information about an endpoint's software inventory. Therefore a key
goal for this specification is ensuring that all SW PCs and PVs, goal for this specification is ensuring that all SW PCs and PVs,
regardless of the vendor who created them, are able to interoperate regardless of the vendor who created them, are able to interoperate
in their performance of these duties. in their performance of these duties.
skipping to change at page 11, line 31 skipping to change at page 12, line 25
points in time between the endpoint's first connection and the 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 present. In such a scenario, it is necessary that any PC be able to
report any changes to its software inventory evidence collection in report any changes to its software inventory evidence collection in
near real-time while connected and, upon reconnection to the near real-time while connected and, upon reconnection to the
enterprise, be able to update the NEA Server (and through it the enterprise, be able to update the NEA Server (and through it the
CMDB) with regard to the state of its software inventory evidence CMDB) with regard to the state of its software inventory evidence
collection throughout the entire interval when it was not connected. collection throughout the entire interval when it was not connected.
2.4. Non-Requirements 2.4. Non-Requirements
There are certain requirements that the Software Message and There are certain requirements that the Software Inventory Message
Attributes for PA-TNC specification explicitly is not required to and Attributes for PA-TNC specification explicitly is not required to
meet. This list is not exhaustive. meet. This list is not exhaustive.
o End to End Confidentiality o End to End Confidentiality
This specification does not define mechanism for confidentiality, nor This specification does not define mechanism for confidentiality, nor
is this property automatically provided by PA-TNC interface use. is this property automatically provided by PA-TNC interface use.
Confidentiality is generally provided by the underlying transport Confidentiality is generally provided by the underlying transport
protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP Posture protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP Posture
Transport for Tunneled EAP Methods [RFC7171] - see Section 8 for more Transport for Tunneled EAP Methods [RFC7171] - see Section 8 for more
information on related standards. Should users wish confidentiality information on related standards. Should users wish confidentiality
protection of assessment instructions or results, this needs to be protection of assessment instructions or results, this needs to be
provided by parts of the NEA architecture other than this provided by parts of the NEA architecture other than this
specification. specification.
2.5. Assumptions 2.5. Assumptions
Here are the assumptions that Software Message and Attributes for PA- Here are the assumptions that Software Inventory Message and
TNC makes about other components in the NEA architecture. Attributes for PA-TNC makes about other components in the NEA
architecture.
o Reliable Message Delivery o Reliable Message Delivery
The Posture Broker Client and Posture Broker Server are assumed to The Posture Broker Client and Posture Broker Server are assumed to
provide reliable delivery for PA-TNC messages and therefore the provide reliable delivery for PA-TNC messages and therefore the
Attributes sent between the SW PCs and the PVs. In the event that Attributes sent between the SW PCs and the PVs. In the event that
reliable delivery cannot be provided, the Posture Collector or reliable delivery cannot be provided, the Posture Collector or
Posture Validator is expected to terminate the connection. Posture Validator is expected to terminate the connection.
2.6. Non-Assumptions 2.6. Non-Assumptions
The Software Message and Attributes for PA-TNC specification The Software Inventory Message and Attributes for PA-TNC
explicitly does not assume: specification explicitly does not assume:
o Authenticity and Accuracy of the Software Inventory Evidence o Authenticity and Accuracy of the Software Inventory Evidence
Collection with Regard to Endpoint Inventory Collection with Regard to Endpoint Inventory
This specification makes no assumption as to whether the software This specification makes no assumption as to whether the software
information that it reports correctly reflect the software state on information that it reports correctly reflect the software state on
the endpoint. This specification does not attempt to detect when the the endpoint. This specification does not attempt to detect when the
endpoint is providing false information, either through malice or endpoint is providing false information, either through malice or
error, but instead focuses on correctly and reliably providing the error, but instead focuses on correctly and reliably providing the
reported Software Inventory Evidence Collection to the NEA Server. reported Software Inventory Evidence Collection to the NEA Server.
Similarly, this specification makes no assumption with regard to the Similarly, this specification makes no assumption with regard to the
completeness of the Software Inventory Evidence Collection's coverage completeness of the Software Inventory Evidence Collection's coverage
of the total set of software installed on the endpoint. It is of the total set of software installed on the endpoint. It is
possible, and even likely, that some installed software is not possible, and even likely, that some installed software is not
represented by a record in an endpoints Software Inventory Evidence represented by a record in an endpoints Software Inventory Evidence
Collection. See Section 6 for more on this security consideration. Collection. See Section 6 for more on this security consideration.
2.7. Software Message and Attributes for PA-TNC Diagram Conventions 2.7. Software Inventory Message and Attributes for PA-TNC Diagram
Conventions
This specification defines the syntax of the Software Message and This specification defines the syntax of the Software Inventory
Attributes for PA-TNC using diagrams. Each diagram depicts the Message and Attributes for PA-TNC using diagrams. Each diagram
format and size of each field in bits. Implementations MUST send the depicts the format and size of each field in bits. Implementations
bits in each diagram as they are shown from left to right for each MUST send the bits in each diagram as they are shown from left to
32-bit quantity traversing the diagram from top to bottom. Multi- right for each 32-bit quantity traversing the diagram from top to
octet fields representing numeric values MUST be sent in network (big bottom. Multi-octet fields representing numeric values MUST be sent
endian) byte order. in network (big endian) byte order.
Descriptions of bit fields (e.g. flags) values refer to the position Descriptions of bit fields (e.g. flags) values refer to the position
of the bit within the field. These bit positions are numbered from of the bit within the field. These bit positions are numbered from
the most significant bit through the least significant bit. As such, 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 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), 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 and an octet with only bit 7 set would have a value of 0x01 (0000
0001). 0001).
3. Software Message and Attributes for PA-TNC System Requirements 3. Software Inventory Message and Attributes for PA-TNC System
Requirements
The Software Message and Attributes for PA-TNC specification The Software Inventory Message and Attributes for PA-TNC
facilitates the exchange of software inventory and event information. specification facilitates the exchange of software inventory and
Specifically, each application supporting Software Message and event information. Specifically, each application supporting
Attributes for PA-TNC includes a component known as the SW-PC that Software Inventory Message and Attributes for PA-TNC includes a
receives messages sent with the SW Attributes component type. The component known as the SW-PC that receives messages sent with the SW
SW-PC is also responsible for sending appropriate SW Attributes back Attributes component type. The SW-PC is also responsible for sending
to the SW-PV in response. This section outlines what software appropriate SW Attributes back to the SW-PV in response. This
inventories and events are and the requirements on SW-PCs and SW-PVs section outlines what software inventories and events are and the
in order to support the stated use cases of this specification. requirements on SW-PCs and SW-PVs in order to support the stated use
cases of this specification.
3.1. Basic Inventory Exchange 3.1. Basic Attribute Exchange
In the most basic exchange supported by this specification, a SW-PV In the most basic exchange supported by this specification, a SW-PV
sends a request to the SW-PC requesting all inventory information in sends a request to the SW-PC requesting some type of information
the endpoint's Software Inventory Evidence Collection. This simple about the endpoint's software inventory. This simple exchange is
exchange is shown in Figure 2. shown in Figure 2.
+-------------+ +--------------+ +-------------+ +--------------+
| SW-PC | | SW-PV | Time | SW-PC | | SW-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
|<--------------SW Request----------------| | |<--------------SW Request----------------| |
| | | | | |
|---------------SW Response-------------->| | |---------------SW Response-------------->| |
| | V | | V
Figure 2: Basic SW Message Exchange Figure 2: Basic SW Attribute Exchange
Upon receiving such a SW Request from the SW-PV, the SW-PC is Upon receiving such a SW Request from the SW-PV, the SW-PC is
expected to collect all inventory information from the endpoint's expected to collect all the relevant software inventory information
software evidence collection and place it within its response from the endpoint's software evidence collection and place it within
attribute. its response attribute.
SW-PVs MUST discard without error any SW Response attributes that SW-PVs MUST discard without error any SW Response attributes that
they receive for which they do not know the SW Request parameters 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 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 Request includes parameters that control the nature of the response
(as will be described in the following sections) and without knowing (as will be described in the following sections) and without knowing
those parameters the SW Response cannot be reliably interpreted. those parameters the SW Response cannot be reliably interpreted.
Most often receiving an unsolicited SW Response attribute happens Most often receiving an unsolicited SW Response attribute happens
when a NEA Server has multiple SW-PVs; one SW-PV sends a SW Request 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 but, unless exclusive delivery is used by the SW-PC in sending the
skipping to change at page 14, line 20 skipping to change at page 15, line 22
generate itself, only that SW-PVs are required to discard SW generate itself, only that SW-PVs are required to discard SW
Responses for which they cannot get the necessary context to Responses for which they cannot get the necessary context to
interpret. interpret.
In the case that it is possible to do so, the SW-PC SHOULD send its 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 SW Response attribute to the SW-PV that requested it using exclusive
delivery as described in section 4.5 of RFC 5793 (PB-TNC) [RFC5793]. delivery as described in section 4.5 of RFC 5793 (PB-TNC) [RFC5793].
Exclusive delivery ensures that only the sender of the SW Request Exclusive delivery ensures that only the sender of the SW Request
receives the resulting SW Response. receives the resulting SW Response.
3.2. Software Identifiers 3.2. Core Software Reporting Information
Software information records contain a large amount of descriptive Different parameters in the SW Request can influence what information
information about installed software products. However, in many is returned in the SW Response. However, while each SW Response
cases the complete level of detail in these records is not necessary. provides different additional information about this installed
For example, if one is simply tracking the installation or removal of software, they all share a common set of fields that support reliable
known software products, one only needs enough information to software identification on an endpoint. These fields include:
recognize the software added or removed. To allow such uses to be Software Identifiers, Record Identifiers, and Software Locators.
efficiently supported, Software Message and Attributes for PA-TNC These three fields are present for each reported piece of software in
supports the use of Software Identifiers. each type of SW Response. The following sections examine these three
types of information in more detail.
3.2.1. Software Identifiers
A Software Identifier uniquely identifies a specific version of a A Software Identifier uniquely identifies a specific version of a
specific software product. The Software Message and Attributes for specific software product. The Software Inventory Message and
PA-TNC specification does not dictate the structure of a Software Attributes for PA-TNC specification does not dictate the structure of
Identifier (beyond stating that it is a string) or define how it is a Software Identifier (beyond stating that it is a string) or define
created. Instead, each data model described in the Software Data how it is created. Instead, each data model described in the
Model IANA table (Section 9.4 includes its own rules for how a Software Data Model IANA table (Section 9.4) includes its own rules
Software Identifier is created based on a record in the Endpoint's for how a Software Identifier is created based on a record in the
Software Inventory Evidence Collection expressed in that data model. Endpoint's Software Inventory Evidence Collection expressed in that
Within the Software Message and Attributes for PA-TNC specification, data model. Other data models will have their own procedures for the
the Software Identifier is simply an opaque string. creation of associated Software Identifiers. Within the Software
Inventory Message and Attributes for PA-TNC specification, the
Software Identifier is simply an opaque string and there is never any
need to unpack any information that might be part of that identifier.
Software Identifiers allow SW Response messages to identify software A Software Identifier is a fraction of the size of the inventory
to a server at a fraction of the bandwidth that would be needed to record from which it is derived. For some combinations of data
send the entire associated record. For some combinations of data
models and sources, the full record might never be necessary as the models and sources, the full record might never be necessary as the
identifier can be directly correlated to the contents of the full identifier can be directly correlated to the contents of the full
record. This is possible with authoritative SWID tags, since these record. This is possible with authoritative SWID tags, since these
tags always have the same contents and thus a Software Identifier 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 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 the full tag. For other combinations of source and data model, a
server might not be able to determine the specific software product server might not be able to determine the specific software product
and version associated with the identifier without requesting deliver and version associated with the identifier without requesting
of the full record. In either case, however, a SW-PV can use delivery of the full record. However, even in those cases,
Software Identifiers to track the presence of specific software downstream consumers of this information might never need the full
products on an endpoint over time in a bandwidth-efficient manner. record as long as the Software Identifiers they receive can be
tracked reliably. 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.
There are two important limitations of Software Identifiers to keep There are two important limitations of Software Identifiers to keep
in mind: in mind:
The identifiers do not necessarily change when the associated 1. The identifiers do not necessarily change when the associated
record changes. In some situations, a record in the endpoint's record changes. In some situations, a record in the endpoint's
Software Inventory Evidence Collection will change due to new Software Inventory Evidence Collection will change due to new
information becoming available or in order to correct prior errors information becoming available or in order to correct prior
in that information. Such changes might or might not result in errors in that information. Such changes might or might not
changes to the Software Identifier, depending on the nature of the result in changes to the Software Identifier, depending on the
changes and the rules governing how Software Identifiers are nature of the changes and the rules governing how Software
derived from records of the appropriate data model. Identifiers are derived from records of the appropriate data
model.
It is possible that a single software product is installed on a 2. It is possible that a single software product is installed on a
single endpoint multiple times. If both of these installation single endpoint multiple times. If both of these installation
instances are reported by the same source using the same data instances are reported by the same source using the same data
format, then this will result in identical Software Identifiers format, then this can result in identical Software Identifiers
for each installation instances. In other words, Software for each installation instances. In other words, Software
Identifiers do not uniquely identify installation instances; they Identifiers might not uniquely identify installation instances;
just uniquely identify software products (which might have more they just are intended to uniquely identify software products
than one installation instance). Instead, to distinguish between (which might have more than one installation instance). Instead,
multiple instances of a single software product, one needs to make to reliably distinguish between multiple instances of a single
use of Record Identifiers, described in the following section. software product, one needs to make use of Record Identifiers,
described in the following section.
3.2.1. Record Identifiers 3.2.1.1. Record Identifiers
A Record Identifier is a string generated by the SW-PC that is A Record Identifier is a 4-byte integer generated by the SW-PC that
uniquely associated with a specific record within the Endpoint's is uniquely associated with a specific record within the Endpoint's
Software Inventory Evidence Collection. The SW-PC MUST assign a Software Inventory Evidence Collection. The SW-PC MUST assign a
unique identifier to each record when it is added to the Endpoint's unique identifier to each record when it is added to the Endpoint's
Software Inventory Evidence Collection. The Record Identifier SHOULD Software Inventory Evidence Collection. The Record Identifier SHOULD
remain unchanged if that record is modified. The SWID-PC might wish remain unchanged if that record is modified. The SWID-PC might wish
to assign Record Identifiers sequentially, but any scheme is to assign Record Identifiers sequentially, but any scheme is
acceptable provided that no two records receive the same identifier. acceptable provided that no two records receive the same identifier.
Servers can use Record Identifiers to distinguish between multiple Servers can use Record Identifiers to distinguish between multiple
instances of a single software product installed on an endpoint. instances of a single software product installed on an endpoint.
Since each installation instance of a software product is associated Since each installation instance of a software product is associated
with a separate record, servers can use the record identifier to with a separate record, servers can use the record identifier to
distinguish between instances. For example, if an event is reported distinguish between instances. For example, if an event is reported
(as described in Section 3.5), the record identifier will allow the (as described in Section 3.5), the record identifier will allow the
server to discern which instance of a software product is involved. server to discern which instance of a software product is involved.
3.2.2. Using Software and Record Identifiers in SW Attributes 3.2.1.2. Software Locators
A SW Attribute reporting an endpoint's Software Inventory Evidence In addition to the need to identify software products, many use cases
Collection can contain Software Identifiers instead of copies of of inventory information need to know where software is located on
software inventory evidence records. The message exchange is the endpoint. This information might be needed to direct remediation
identical to the diagram shown in Figure 2, but the contents of the actions or similar processes. For this reason, every reported
SW Response are Software Identifiers instead of evidence records. software product also includes a Software Locator to identify where
The SW Request attribute indicates whether the response is required the software is installed on the endpoint.
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.
All SW Response attributes include Record Identifiers for each If the location is not provided directly by the record source the SW-
reported record. This is true regardless of whether the record is PC is responsible for attempting to determine the location of the
delivered in full or represented by a Software Identifier. software product. The "location" of a product SHOULD be the
directory in which the software products executables are kept.
However, if that directory is shared by other software products, the
"location" SHOULD be the location of the primary executable
associated with the software product. The source and/or SW-PC MUST
be consistent in reporting the location of a software product (i.e.,
it cannot use the executable location in one report and the directory
location in another).
The location is expressed as a URI string consisting of a scheme and
path. [RFC3986] The location URI does not include an authority part.
The URI schema describes the context of the described location. For
example, in most cases the location of the installed software product
will be expressed in terms of its path in the filesystem. For such
locations, the location URI scheme MUST be "file". It is possible
that other schemes could be used to represent other location
contexts. Apart from reserving the "file" and "unknown" (described
below) scheme to indicate an installation location expressed using a
path in the endpoint's file system, this specification does not
reserve schemes. When representing software products in other
location contexts, tools MUST be consistent in their use of schemes,
but the exact string used in those schemes is not normatively defined
here.
It is possible, that a SW-PC is unable to determine the location of a
reported software product. In this case, the SW-PC MUST assign that
software product a location of "unknown:". (I.e., the "unknown"
scheme and an empty path.) However, SW-PCs SHOULD only make such an
assignment as a last resort. Even a probable location for a software
product is preferable to using the unknown indicator.
3.2.1.3. Using Software and Record Identifiers in SW Attributes
A SW Attribute reporting an endpoint's Software Inventory Evidence
Collection always contains the Software Identifiers associated with
the identified software products. A SW Attribute might or might not
also contain copies of software inventory evidence records. The
attribute exchange is identical to the diagram shown in Figure 2
regardless of whether software inventory evidence records are
included. The SW Request attribute indicates whether the response is
required to include software inventory evidence records. Excluding
software inventory evidence records can reduce the attribute size of
the response by multiple orders of magnitude when compared to sending
the same inventory with full records.
3.3. Targeted Requests 3.3. Targeted Requests
Sometimes a SW-PV does not require information about every piece of Sometimes a SW-PV does not require information about every piece of
software on an endpoint but only needs to receive updates about software on an endpoint but only needs to receive updates about
certain software instances. For example, enterprise endpoints might certain software instances. For example, enterprise endpoints might
be required to have certain software products installed and to keep be required to have certain software products installed and to keep
these updated. Instead of requesting a complete inventory just to these updated. Instead of requesting a complete inventory just to
see if these products are present, the SW-PV can make a "targeted see if these products are present, the SW-PV can make a "targeted
request" for the software in question. request" for the software in question.
Targeted requests follow the same message exchange described in Targeted requests follow the same attribute exchange described in
Figure 2. The SW-PV targets its request by providing one or more Figure 2. The SW-PV targets its request by providing one or more
Software Identifiers in its SW Request attribute. The SW-PC MUST Software Identifiers in its SW Request attribute. The SW-PC MUST
then limit its response to contain only records that match the then limit its response to contain only records that match the
indicated Software Identifier(s). This allows the network exchange indicated Software Identifier(s). This allows the network exchange
to exclude information that is not relevant to a given policy to exclude information that is not relevant to a given policy
question, thus reducing unnecessary bandwidth consumption. The SW- question, thus reducing unnecessary bandwidth consumption. The SW-
PC's response might consist of full records or of Software PC's response might or might not include software inventory evidence
Identifiers, depending on the parameters of the SW Request. records, depending on the parameters of the SW Request.
Note that targeted requests identify the software relevant to the Note that targeted requests identify the software relevant to the
request only through Software Identifiers. This specification does request only through Software Identifiers. This specification does
not support arbitrary, parameterized querying of records. For not support arbitrary, parameterized querying of records. For
example, one cannot request all records from a certain software example, one cannot request all records from a certain software
publisher, or all records created by a particular record source. publisher, or all records created by a particular record source.
Targeted requests only allow a requestor to request specific software Targeted requests only allow a requestor to request specific software
(as identified by their Software Identifiers) and receive a response (as identified by their Software Identifiers) and receive a response
that is limited to the named software. that is limited to the named software.
skipping to change at page 17, line 18 skipping to change at page 19, line 16
records" - that is, records from different sources for the same records" - that is, records from different sources for the same
software. Recall that different sources and data models may use software. Recall that different sources and data models may use
different Software Identifier strings for the same software product. different Software Identifier strings for the same software product.
The SW-PC returns only records that match the Software Identifiers in The SW-PC returns only records that match the Software Identifiers in
the SW Request, even if there might be other records in the the SW Request, even if there might be other records in the
endpoint's Software Inventory Evidence Collection for the same endpoint's Software Inventory Evidence Collection for the same
software product. This is necessary because SW-PCs might not have software product. This is necessary because SW-PCs might not have
the ability to determine that two Software Identifiers refer to the the ability to determine that two Software Identifiers refer to the
same product. same product.
Targeted requests do not include Record Identifiers. The response to Targeted requests do not include Record Identifiers or Software
a targeted request MUST include all records associated with the named Locators. The response to a targeted request MUST include all
Software Identifiers, including the case where there are multiple records associated with the named Software Identifiers, including the
records associated with a single Software Identifier. case where there are multiple records associated with a single
Software Identifier.
SW-PCs MUST accept targeted requests and process them correctly as SW-PCs MUST accept targeted requests and process them correctly as
described above. SW-PVs MUST be capable of making targeted requests described above. SW-PVs MUST be capable of making targeted requests
and processing the responses thereto. and processing the responses thereto.
3.4. Monitoring Changes in an Endpoint's Software Inventory Evidence 3.4. Monitoring Changes in an Endpoint's Software Inventory Evidence
Collection Collection
The software collection on an endpoint is not static. As software is The software collection on an endpoint is not static. As software is
installed, uninstalled, patched, or updated, the Software Inventory installed, uninstalled, patched, or updated, the Software Inventory
skipping to change at page 18, line 46 skipping to change at page 20, line 44
to assign a time to the event that is accurate to within a few to assign a time to the event that is accurate to within a few
seconds. For changes to the endpoint's Software Inventory Evidence seconds. For changes to the endpoint's Software Inventory Evidence
Collection that occur while the SW-PC is not operational, upon 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 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 time of the relevant events (possibly by looking at timestamps on
files), but these values might be off. In the case of dynamically 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 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 from which the records are generate changes, not the time at which a
changed record is generated. For example, if records are dynamically changed record is generated. For example, if records are dynamically
generated based on data in an RPM database, the time of change would generated based on data in an RPM database, the time of change would
be when the RPM record was changed. be when the RPM database changed.
With regard to deletions of records, the SW-PC needs to detect the 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 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 associated Record Identifier and Software Locator so that the
the SW-PV upon request. This copy of the record MUST be retained for record and associated information can be provided to the SW-PV upon
a reasonable amount of time. Vendors and administrators determine request. This copy of the record MUST be retained for a reasonable
what "reasonable" means, but a copy of the record SHOULD be retained amount of time. Vendors and administrators determine what
for as long as the event recording the deletion of the record remains "reasonable" means, but a copy of the record SHOULD be retained for
in the SW-PC's event log (as described in Section 3.5). This is as long as the event recording the deletion of the record remains in
the SW-PC's event log (as described in Section 3.5). This is
recommended because, as long as the event is in the SW-PC's change 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 logs, the SW-PC might send an event attribute (described in
Section 3.5) that references this record, and a copy of the record is Section 3.5) that references this record, and a copy of the record is
needed if the SW-PV wanted a full copy of the relevant records. needed if the SW-PV wanted a full copy of the relevant records.
With regard to alterations to a record, SW-PCs MUST detect any With regard to alterations to a record, SW-PCs MUST detect any
alterations to the contents of a record. Alterations need to be alterations to the contents of a record. Alterations need to be
detected even if they have no functional impact on the record. A detected even if they have no functional impact on the record. A
good guideline is that any alteration to a record that might change 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 the value of a hash taken on the record's contents needs to be
skipping to change at page 19, line 38 skipping to change at page 21, line 37
that do not affect the bytes within the record, discriminating that do not affect the bytes within the record, discriminating
between modifications to file contents and changes to file metadata between modifications to file contents and changes to file metadata
can be difficult and time consuming on some systems. As such, as can be difficult and time consuming on some systems. As such, as
long as the alterations detected by a SW-PC always cover all long as the alterations detected by a SW-PC always cover all
modifications to the contents of record, the SW-PC is considered modifications to the contents of record, the SW-PC is considered
compliant even if it also registers alterations that do not modify compliant even if it also registers alterations that do not modify
the contents of a record as well. When recording an alteration to a 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 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 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 altered, nor is it possible to include such details in SW Attributes
reporting the change to a SW-PV. reporting the change to a SW-PV. There is no need to retain a copy
of the original record.
When a record changes it SHOULD retain the same Record Identifier.
The Software Locator might or might not change, depending on whether
the software changed locations during the changes that led to the
record change. A record change MUST retain the same Software
Identifier. This means that any action that changes a software
product (e.g., application of a patch that results in a change to the
product's version) MUST NOT be reflected by a record change but
instead MUST result in the deletion of the old record and the
creation of a new record. This reflects the requirement that a
record in the endpoint's Software Inventory Evidence Collection
correspond directly with an instance of a specific software product.
3.5. Reporting Change Events 3.5. Reporting Change Events
As noted in the preceding section, SW-PCs MUST be able to detect As noted in the preceding section, SW-PCs MUST be able to detect
changes to the endpoints software inventory evidence collection changes to the endpoints Software Inventory Evidence Collection
(creation, deletion, and alteration) in near real-time while the SW- (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 PC is operational, and MUST be able to account for any net change to
the endpoint's Software Inventory Evidence Collection that occurs the endpoint's Software Inventory Evidence Collection that occurs
when the SW-PC is not operational. However, to be of use to the 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 enterprise, the NEA Server needs to be able to receive these events
and be able to understand how new changes relate to earlier changes. and be able to understand how new changes relate to earlier changes.
In Software Message and Attributes for PA-TNC, this is facilitated by In Software Inventory Message and Attributes for PA-TNC, this is
reporting change events. All SW-PCs MUST be capable of receiving facilitated by reporting change events. All SW-PCs MUST be capable
requests for change events and sending change event attributes. All of receiving requests for change events and sending change event
SW-PVs MUST be capable of requesting and receiving change event attributes. All SW-PVs MUST be capable of requesting and receiving
attributes. change event attributes.
3.5.1. Change Event Records
A change event record consists of either a complete record or
Software Identifier from the changed record along with the following
pieces of information:
o The nature of the change (i.e., creation, deletion, or lteration)
o An Event Identifier (EID) value 3.5.1. Event Identifiers
o An EID Epoch value To be useful, change events need to be correctly ordered. Ordering
of events is facilitated by two pieces of information: an Event
Identifier (EID) value and an EID Epoch value.
An EID is a 4-byte unsigned integer that the SW-PC assigns An EID is a 4-byte unsigned integer that the SW-PC assigns
sequentially to each observed event (whether detected in real-time or sequentially to each observed event (whether detected in real-time or
deduced by looking for net changes over a period of SW-PC deduced by looking for net changes over a period of SW-PC
inactivity). All EIDs exist within the context of some "EID Epoch", inactivity). All EIDs exist within the context of some "EID Epoch",
which is also represented as a 4-byte unsigned integer. EID Epochs 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 are used to ensure synchronization between the SW-PC and any SW-PVs
with which it communicates. EID Epoch values SHOULD be generated with which it communicates. EID Epoch values SHOULD be generated
randomly and in such a way that it is unlikely that the same EID 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 Epoch is generated twice, even if the SW-PC reverted to an earlier
skipping to change at page 21, line 21 skipping to change at page 23, line 27
The SW-PC MUST ensure there is no coverage gap (i.e., change events 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 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 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 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 saw an event indicating that a particular record had been added to
the endpoint's software inventory evidence collection, and saw no the endpoint's software inventory evidence collection, and saw no
subsequent events indicating that record had been deleted, it might subsequent events indicating that record had been deleted, it might
reasonably assume that this record was still present and thus that reasonably assume that this record was still present and thus that
the indicated software was still installed (assuming the Epoch has the indicated software was still installed (assuming the Epoch has
not changed). If there is a coverage gap in the SW-PC's event 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- records, however, this assumption could be false. For this reason,
PC's event records MUST NOT contain gaps. In the case where there the SW-PC's event records MUST NOT contain gaps. In the case where
are periods where it is possible that changes occurred without the there are periods where it is possible that changes occurred without
SW-PC detecting or recording them, the SW-PC MUST either compute a the SW-PC detecting or recording them, the SW-PC MUST either compute
net change and update its event records appropriately, or pick a new a net change and update its event records appropriately, or pick a
EID Epoch to indicate a discontinuity with previous event records. new EID Epoch to indicate a discontinuity with previous event
records.
Within a given Epoch, once a particular event has been assigned an Within a given Epoch, once a particular event has been assigned an
EID, this association MUST NOT be changed. That is, within an Epoch, 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 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. a different event, and the event cannot be assigned a different EID.
When the SW-PC's Epoch changes, all of these associations between When the SW-PC's Epoch changes, all of these associations between
EIDs and events are cancelled, and EID values once again become free EIDs and events are cancelled, and EID values once again become free
for assignment. for assignment.
3.5.2. Updating Inventory Knowledge Based on Events 3.5.2. Core Event Tracking Information
Whether reporting events or full inventories it is important to know
how the reported information fits into the overall timeline of change
events. This is why all SW Response attributes include fields to
place that response within the sequence of detected events.
Specifically, all SW Responses include a Last EID and EID Epoch
field. The EID Epoch field identifies the EID Epoch in which the SW
Response was sent. If the SW Response is reporting events, all
reported events occurred within the named EID Epoch. The Last EID
(which is also always from the named EID Epoch) indicates the EID of
the last recorded change event at the time that the SW Response was
sent. These two fields allow any response to be placed in the
context of the complete set of detected change events within a given
EID Epoch.
3.5.3. Updating Inventory Knowledge Based on Events
Modern endpoints can have hundreds of software products installed, Modern endpoints can have hundreds of software products installed,
most of which are unlikely to change from one day to the next. As 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 such, instead of exchanging a complete list of an endpoint's
inventory on a regular basis, one might wish to only identify changes inventory on a regular basis, one might wish to only identify changes
since some earlier known state of this inventory. This is readily since some earlier known state of this inventory. This is readily
facilitated by the use of EIDs to place change events in a context facilitated by the use of EIDs to place change events in a context
relative to earlier state. relative to earlier state.
Every inventory sent by a SW-PC to a SW-PV (as described in As noted above, every SW Response sent by a SW-PC to a SW-PV (as
Section 3.1 through Section 3.3) includes the EID Epoch and EID of described in Section 3.1 through Section 3.3) includes the EID Epoch
the last event recorded prior to that inventory being compiled. This and EID of the last event recorded prior to that response being
allows the SW-PV to place all subsequently received event records in compiled. This allows the SW-PV to place all subsequently received
context relative to this inventory (since the EIDs represent a total event records in context relative to this SW Response attribute
ordering of all changes to the endpoint's software inventory evidence (since the EIDs represent a total ordering of all changes to the
collection). Specifically, a SW-PV (or, more likely, a database that endpoint's software inventory evidence collection). Specifically, a
collects and records its findings) can record an endpoint's full SW-PV (or, more likely, a database that collects and records its
inventory and also the EID and Epoch of the most recent event findings) can record an endpoint's full inventory and also the EID
reflected in that state. From that point on, if change events are and Epoch of the most recent event reflected at the time of that
observed, the attribute describing these events indicates the nature inventory. From that point on, if change events are observed, the
of the change, the affected records, and the order in which these attribute describing these events indicates the nature of the change,
events occurred (as indicated by the sequential EIDs). Using this the affected records, and the order in which these events occurred
information, any remote record of the endpoint's Software Inventory (as indicated by the sequential EIDs). Using this information, any
Evidence Collection can be updated appropriately. remote record of the endpoint's Software Inventory Evidence
Collection can be updated appropriately.
3.5.3. Using Event Records in SW Attributes 3.5.4. Using Event Records in SW Attributes
A SW-PV MUST be able to request a list of event records instead of an 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 inventory. The attribute flow in such an exchange looks the same as
the basic flow shown in Figure 2. The only difference is that, in the basic flow shown in Figure 2. The only difference is that, in
the SW Request attribute, the SW-PV provides an EID other than 0. (A 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.) value of 0 in these fields represents a request for an inventory.)
When the SW-PC receives such a request, instead of identifying When the SW-PC receives such a request, instead of identifying
records from the endpoint's Software Inventory Evidence Collection, records from the endpoint's Software Inventory Evidence Collection,
it consults its list of detected changes. The SW-PC MUST add an 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 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 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 attribute (although targeting of requests, as described in the next
paragraph, might limit this list). A list of event records MUST only paragraph, might limit this list). A list of event records MUST only
contain events with EIDs that all come from the current Epoch. contain events with EIDs that all come from the current Epoch.
SW-PVs can target requests for event records by including one or more SW-PVs can target requests for event records by including one or more
Software Identifiers, as described in Section 3.3, in the SW Request Software Identifiers, as described in Section 3.3, in the SW Request
that requests an event record list. A targeted request for event that requests an event record list. A targeted request for event
records is used to indicate that only events affecting software that records is used to indicate that only events affecting software that
match the provided Software Identifiers are to be returned. matches one of the provided Software Identifiers are to be returned.
Specifically, in response to a targeted request for event records, Specifically, in response to a targeted request for event records,
the SW-PC MUST exclude any event records that are less than the the SW-PC MUST exclude any event records that are less than the
indicated EID (within the current EID Epoch) and exclude any event indicated EID (within the current EID Epoch) and exclude any event
records where the affected software does not match one of the records where the affected software does not match one of the
provided Software Identifiers. This might mean that the resulting provided Software Identifiers. This might mean that the resulting
list of event records sent in the response attribute does not provide 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 a continuous sequence of EIDs. Both SW-PCs and SWIC-PVs MUST support
targeted request for event records. targeted request for event records.
3.5.4. Partial and Complete Lists of Event Records in SW Attributes 3.5.5. Partial and Complete Lists of Event Records in SW Attributes
Over time, a SW-PC might record a large number of change events. If 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, a SW-PV requests all change events covering a large period of time,
the resulting SW Response attribute might be extremely large, the resulting SW Response attribute might be extremely large,
especially if the SW-PV is requesting the use of full records instead especially if the SW-PV requests inclusion of software inventory
of the use of Software Identifiers (as described in Section 3.2.2). evidence records in the response. In the case that the resulting
In the case that the resulting attribute is too large to send (either attribute is too large to send (either because it exceeds the 4GB
because it exceeds the 4GB attribute size limit imposed by the PA-TNC attribute size limit imposed by the PA-TNC specification, or because
specification, or because it exceeds some smaller size limit imposed it exceeds some smaller size limit imposed on the SW-PC) the SW-PC
on the SW-PC) the SW-PC MAY send a partial list of event records back MAY send a partial list of event records back to the SW-PV.
to the SW-PV.
Generation of a partial list of events in a SW Response attribute Generation of a partial list of events in a SW Response attribute
requires the SW-PC to identify a "consulted range" of EIDs. A requires the SW-PC to identify a "consulted range" of EIDs. A
consulted range is the set of event records that are examined for consulted range is the set of event records that are examined for
inclusion in the SW Response attribute and that are included in that inclusion in the SW Response attribute and that are included in that
attribute if applicable. Recall that, if a SW Request is targeted, attribute if applicable. Recall that, if a SW Request is targeted,
only event records that involve the indicated software would be only event records that involve the indicated software would be
applicable. (See Section 3.3 for more on Targeted Request.) If a applicable. (See Section 3.3 for more on Targeted Request.) If a
request is not targeted, all event records in the considered range request is not targeted, all event records in the considered range
are applicable and included in the SW Response attribute. are applicable and included in the SW Response attribute.
The lower bound of the consulted range MUST be the EID provided in 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 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 event records by providing a non-0 EID value in the SW Request. See
Section 3.5.3.) The upper bound of the consulted range is the EID of Section 3.5.4.) The upper bound of the consulted range is the EID of
the latest event record (as ordered by EID values) that is included 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 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". 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 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. event record list it is willing to provide to the SW-PV.
A partial result list MUST include all applicable event records A partial result list MUST include all applicable event records
within the consulted range. This means that for any applicable event 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 (i.e., any event record in an un-targeted request, or any
record associated with software matching a requested Software event record associated with software matching a requested Software
Identifier in a targeted request) whose EID is greater than or equal 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 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 equal to the Last Consulted EID, that event record MUST be included
in the SW Response conveying this partial list of event records. in the SW Response conveying this partial list of event records.
This ensures that every partial list of event records is always This ensures that every partial list of event records is always
complete within its indicated range. complete within its indicated range.
All SW Response attributes that convey event records (either using All SW Response attributes that convey event records include a Last
full records or using Software Identifiers) include an Epoch, Last Consulted EID field. This is in addition to the EID Epoch and Last
EID, and Last Consulted EID field. The Last EID contains the EID of EID fields that are present in all SW Responses. Note that, if
the last event record known to the SW-PC at the time that the SW responding to a targeted SW Request, the SW Response attribute might
Response attribute was generated. The Last EID might or might not be not contain the event record whose EID matches the Last Consulted EID
part of the consulted range. As noted above, the Last Consulted EID value. For example, the last consulted EID record might have been
field contains the EID of the last event record in the consulted deemed inapplicable because it did not match the specified list of
range. The Epoch field contains the EID Epoch associated with the Software Identifiers in the SW Request.
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.
If a SW-PV receives a SW Response attribute where the Last EID and 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 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 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 request, up to the present time.
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 On the other hand, if the Last EID is greater than the Last Consulted
to collect the rest of the partially delivered result list it then EID, the SW-PV has received a partial result list. (The Last
sends a new SW Request whose EID is one greater than the Last Consulted EID MUST NOT exceed the Last EID.) In this case, if the
Consulted EID in the preceding response. Doing this causes the SW-PC SW-PV wishes to try to collect the rest of the partially delivered
to generate another SW Response attribute containing event records result list it then sends a new SW Request whose EID is one greater
where the earliest reported event record is the one immediately after than the Last Consulted EID in the preceding response. Doing this
the event record with the Last Consulted EID (since EIDs are assigned causes the SW-PC to generate another SW Response attribute containing
sequentially). By repeating this process until it receives a SW event records where the earliest reported event record is the one
Response where the Last EID and Last Consulted EID are equal, the SW- immediately after the event record with the Last Consulted EID (since
PV is able to collect all event records over a given range, even if EIDs are assigned sequentially). By repeating this process until it
the complete set of event records would be too large to deliver via a receives a SW Response where the Last EID and Last Consulted EID are
single attribute. 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.
Implementers need to be aware that a SW Request might specify an EID 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. that is greater than the EID of the last event recorded by a SW-PC.
In accordance with the behaviors described in Section 3.5.3, a SW-PC In accordance with the behaviors described in Section 3.5.4, a SW-PC
MUST respond to such a request with a SW Response attribute of the MUST respond to such a request with a SW Response attribute that
appropriate type (using full records or Software Identifiers as contains zero event records. This is because the SW-PC has recorded
specified in the SW Request) that contains zero event records. This no event records with EIDs greater than or equal to the EID in the SW
is because the SW-PC has recorded no event records with EIDs greater Request. In such a case, the Last Consulted EID field MUST be set to
than or equal to the EID in the SW Request. In such a case, the Last the same value as the Last EID field in this SW Response attribute.
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 This case is called out because the consulted range on a SW-PC in
the consulted range on a SW-PC in such a situation is a negative such a situation is a negative range, where the "first" EID in the
range, where the "first" EID in the range (provided in the SW range (provided in the SW Request) is greater than the "last" EID in
Request) is greater than the "last" EID in the range (this being the the range (this being the EID of the last recorded event on the SW-
EID of the last recorded event on the SW-PC). Implementers need to PC). Implementers need to ensure that SW-PCs do not experience
ensure that SW-PCs do not experience problems in such a circumstance. problems in such a circumstance.
Note that this specification only supports the returning of partial Note that this specification only supports the returning of partial
results when returning event records. There is no way to return a results when returning event records. There is no way to return a
partial inventory list under this specification. partial inventory list under this specification.
3.5.5. Synchronizing Event Identifiers and Epochs 3.5.6. Synchronizing Event Identifiers and Epochs
Since EIDs are sequential within an Epoch, if a SW-PV's list of event 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 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. 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 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 events or request a full inventory to re-sync its understanding of
the state of the Endpoint's Software Inventory Evidence Collection. the state of the endpoint's Software Inventory Evidence Collection.
In either case, after the SW-PV's record of the endpoint's Software 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 Inventory Evidence Collection has been updated, the SW-PV can record
the new latest EID value and track events normally from that point the new latest EID value and track events normally from that point
on. on.
If the SW-PV receives any attribute from a SW-PC where the EID Epoch 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 differs from the EID Epoch that was used previously, then SW-PV or
any entity using this information to track the endpoint's Software any entity using this information to track the endpoint's Software
Inventory Evidence Collection knows that there is a discontinuity in Inventory Evidence Collection knows that there is a discontinuity in
their understanding of the endpoint's state. To move past this their understanding of the endpoint's state. To move past this
discontinuity and reestablish a current understanding of the state of discontinuity and reestablish a current understanding of the state of
the endpoint's Software Inventory Evidence Collection, the SW-PV the endpoint's Software Inventory Evidence Collection, the SW-PV
needs to receive a full inventory from the endpoint. 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 cannot be brought in sync with the endpoint's state through the
collection of any set of event records in this situation. This is 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 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 since the previous Epoch was used, because there is no way to query
no way to query for EIDs from a previous Epoch. Once the SW-PV has for EIDs from a previous Epoch. Once the SW-PV has received a full
received a full inventory for the new Epoch, the SW-PV records the inventory for the new Epoch, the SW-PV records the latest EID
latest EID reported in this new Epoch and can track further events reported in this new Epoch and can track further events normally.
normally.
A SW-PC MUST NOT report events with EIDs from any Epoch other than 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 the current EID Epoch. The SW-PC MAY choose to purge all event
records from a previous Epoch from memory after an Epoch change. records from a previous Epoch from memory after an Epoch change.
Alternately, the SW-PC MAY choose to retain some event records from a 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. 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 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 ensure that the order of events according to their EIDs is unchanged
and that there is no coverage gap between the first retained event and that there is no coverage gap between the first retained event
recorded during the previous Epoch (now reassigned with an EID in the recorded during the previous Epoch (now reassigned with an EID in the
skipping to change at page 26, line 20 skipping to change at page 28, line 36
suffered an error of some kind, possibly indicative of at least suffered an error of some kind, possibly indicative of at least
partial corruption of its event log. In this case, the SW-PV SHOULD 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 treat the situation as if there was a change in Epoch and treat any
local copy of the endpoint's Software Inventory Evidence Collection 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. 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 In this case, the SW-PV SHOULD flag the occurrence so the SW-PC can
be examined to ensure it is now operating properly. be examined to ensure it is now operating properly.
3.6. Subscriptions 3.6. Subscriptions
Thus far, all message exchanges discussed assume that a SW-PV sent an Thus far, all attribute exchanges discussed assume that a SW-PV sent
SW Request attribute and the SW-PC is providing a direct response to an SW Request attribute and the SW-PC is providing a direct response
that request. The Software Message and Attributes for PA-TNC to that request. The Software Inventory Message and Attributes for
specification also supports the ability for a SW-PC to send a message PA-TNC specification also supports the ability for a SW-PC to send a
with a SW Attribute to the SW-PV in response to observed changes in SW Response to the SW-PV in response to observed changes in the
the endpoint's software inventory evidence collection, instead of in endpoint's software inventory evidence collection, instead of in
direct response to a SW Request. An agreement by a SW-PC to send 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 content when certain changes are detected to the endpoint's Software
Inventory Evidence Collection is referred to in this specification as Inventory Evidence Collection is referred to in this specification as
a "subscription", and the SW-PV that receives this content is said to 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 be "subscribed to" the given SW-PC. All SW-PCs and SW-PVs MUST
support the use of subscriptions. support the use of subscriptions.
3.6.1. Establishing Subscriptions 3.6.1. Establishing Subscriptions
A SW-PV establishes a subscription on a particular SW-PC by sending a 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 SW Request attribute with the Subscription flag set. The SW Request
attribute is otherwise identical to the SW Requests discussed in attribute is otherwise identical to the SW Requests discussed in
previous sections. Specifically, such a SW Request might request previous sections. Specifically, such a SW Request might or might
full records or Software Identifiers, might be targeted, and might not request inclusion of software inventory evidence records, might
request change event records or endpoint inventory. Assuming no or might not be targeted, and might request change event records or
error is encountered, a SW-PC MUST send a SW Response attribute in endpoint inventory. Assuming no error is encountered, a SW-PC MUST
direct response to this SW Request attribute, just as if the send a SW Response attribute in direct response to this SW Request
Subscription flag was not set. As such, the message exchange that attribute, just as if the Subscription flag was not set. As such,
establishes a new subscription in a SW-PC has the same flow seen in the attribute exchange that establishes a new subscription in a SW-PC
the previous message exchanges, as depicted in Figure 2. If the SW- has the same flow seen in the previous attribute exchanges, as
PV does not receive a PA-TNC Error attribute (as described in depicted in Figure 2. If the SW-PV does not receive a PA-TNC Error
Section 3.8 and Section 4.16) in response to their subscription attribute (as described in Section 3.8 and Section 4.14) in response
request, the subscription has been successfully established on the to their subscription request, the subscription has been successfully
SW-PC. The SW Request attribute that establishes a new subscription established on the SW-PC. The SW Request attribute that establishes
is referred to as the "establishing request" for that subscription. a new subscription is referred to as the "establishing request" for
that subscription.
When a subscription is established it is assigned a Subscription ID When a subscription is established it is assigned a Subscription ID
value. The Subscription ID is equal to the value of the Request ID value. The Subscription ID is equal to the value of the Request ID
of the establishing request. (For more about Request IDs, see of the establishing request. (For more about Request IDs, see
Section 4.8.) Section 4.6.)
A SW-PC MUST have the ability to record and support multiple A SW-PC MUST have the ability to record and support multiple
simultaneous subscriptions from a single party and from multiple simultaneous subscriptions from a single party and from multiple
parties. A SW-PV MUST have the ability to record and support parties. A SW-PV MUST have the ability to record and support
multiple simultaneous subscriptions to a single party and multiple simultaneous subscriptions to a single party and
subscriptions to multiple parties. subscriptions to multiple parties.
3.6.2. Managing Subscriptions 3.6.2. Managing Subscriptions
The SW-PC MUST record each accepted subscription along with the The SW-PC MUST record each accepted subscription along with the
skipping to change at page 27, line 37 skipping to change at page 30, line 9
subscription. The SW-PV needs to retain this information in order to subscription. The SW-PV needs to retain this information in order to
correctly interpret pushed SW Response attributes sent in fulfillment correctly interpret pushed SW Response attributes sent in fulfillment
of the subscription. The identity of the SW-PC is given in the of the subscription. The identity of the SW-PC is given in the
Posture Collector Identifier of the PB-PA message header in all Posture Collector Identifier of the PB-PA message header in all
messages from that SW-PC. messages from that SW-PC.
3.6.3. Terminating Subscriptions 3.6.3. Terminating Subscriptions
Subscriptions MAY be terminated at any time by the subscribing SW-PV Subscriptions MAY be terminated at any time by the subscribing SW-PV
by setting the Clear Subscriptions flag in a SW Request. (See by setting the Clear Subscriptions flag in a SW Request. (See
Section 4.9 for more on using this flag.) In the case that a SW Section 4.7 for more on using this flag.) In the case that a SW
Request with the Clear Subscriptions flag set is received the SW-PC Request with the Clear Subscriptions flag set is received the SW-PC
MUST only clear subscriptions that match both the NEA server MUST only clear subscriptions that match both the NEA server
connection ID and the SW-PV ID for this SW Request, and MUST clear connection ID and the SW-PV ID for this SW Request, and MUST clear
all such subscriptions. all such subscriptions.
This specification does not give the SW-PV the ability to terminate This specification does not give the SW-PV the ability to terminate
subscriptions individually - all subscriptions to the SW-PV are subscriptions individually - all subscriptions to the SW-PV are
cleared when the Clear Subscriptions flag is set. cleared when the Clear Subscriptions flag is set.
This specification does not give the SW-PC the ability to This specification does not give the SW-PC the ability to
skipping to change at page 28, line 19 skipping to change at page 30, line 40
SW-PC and SW-PV is deleted. This occurs when the connection ID used 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. 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 Loss of this connection ID would prevent the SW-PC from sending
messages in fulfillment of this subscription. As such, loss of the messages in fulfillment of this subscription. As such, loss of the
connection ID necessarily forces subscription termination between the connection ID necessarily forces subscription termination between the
affected parties. affected parties.
3.6.4. Subscription Status 3.6.4. Subscription Status
A SW-PV can request that a SW-PC report the list of active A SW-PV can request that a SW-PC report the list of active
subscriptions where the SW-PV is the subscriber. A SW-PV can use subscriptions for which the SW-PV is the subscriber. A SW-PV can use
this to recover lost information about active subscriptions. A SW-PV this to recover lost information about active subscriptions. A SW-PV
can also use this capability to verify that a SW-PC has not forgotten can also use this capability to verify that a SW-PC has not forgotten
any of its subscriptions. The latter is especially useful where a any of its subscriptions. The latter is especially useful where a
SW-PC does not send any attributes in fulfillment of a given SW-PC does not send any attributes in fulfillment of a given
subscription for a long period of time. The SW-PV can check the list subscription for a long period of time. The SW-PV can check the list
of active subscriptions on the SW-PC and verify whether the of active subscriptions on the SW-PC and verify whether the
inactivity is due to a lack of reportable events, or due to the SW-PC inactivity is due to a lack of reportable events or due to the SW-PC
forgetting its obligations to fulfill a given subscription. forgetting its obligations to fulfill a given subscription.
A SW-PV requests a list of its subscriptions on a given SW-PC by A SW-PV requests a list of its subscriptions on a given SW-PC by
sending that SW-PC a Subscription Status Request. The SW-PC MUST sending that SW-PC a Subscription Status Request. The SW-PC MUST
then respond with a Subscription Status Response (or a PA-TNC Error then respond with a Subscription Status Response (or a PA-TNC Error
if an error condition is experienced). The Subscription Status if an error condition is experienced). The Subscription Status
Response MUST contain one subscription record for each of the active Response MUST contain one subscription record for each of the active
subscriptions for which the SW-PV is the subscribing party. subscriptions for which the SW-PV is the subscribing party.
3.6.5. Fulfilling Subscriptions 3.6.5. Fulfilling Subscriptions
skipping to change at page 28, line 50 skipping to change at page 31, line 22
Collection in near real-time. For every active subscription, the SW- Collection in near real-time. For every active subscription, the SW-
PC MUST send an attribute to the subscribed SW-PV whenever a change PC MUST send an attribute to the subscribed SW-PV whenever a change
is detected to relevant records within the endpoint's Software is detected to relevant records within the endpoint's Software
Inventory Evidence Collection. Such an attribute is said to be sent Inventory Evidence Collection. Such an attribute is said to be sent
"in fulfillment of" the given subscription and any such attribute "in fulfillment of" the given subscription and any such attribute
MUST include that subscription's Subscription ID. If the MUST include that subscription's Subscription ID. If the
establishing request for that subscription was a targeted request, establishing request for that subscription was a targeted request,
then only records that match the Software Identifiers provided in then only records that match the Software Identifiers provided in
that establishing request are considered relevant. Otherwise, (i.e., that establishing request are considered relevant. Otherwise, (i.e.,
for non-targeted requests) any record is considered relevant for this for non-targeted requests) any record is considered relevant for this
purpose. Figure 3 shows a sample message exchange where a purpose. Figure 3 shows a sample attribute exchange where a
subscription is established and then later messages are sent from the subscription is established and then later attributes are sent from
SW-PC in fulfillment of the established subscription. the SW-PC in fulfillment of the established subscription.
+-------------+ +--------------+ +-------------+ +--------------+
| SW-PC | | SW-PV | Time | SW-PC | | SW-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
|<-----------SW Request-------------| | |<-----------SW Request-------------| |
| | | | | |
|------------SW Response----------->| | |------------SW Response----------->| |
| | | | | |
. . . . . .
skipping to change at page 29, line 36 skipping to change at page 32, line 11
| | V | | V
Figure 3: Subscription Establishment and Fulfillment Figure 3: Subscription Establishment and Fulfillment
The contents of an attribute sent in fulfillment of a subscription The contents of an attribute sent in fulfillment of a subscription
depend on the parameters provided in the establishing request for depend on the parameters provided in the establishing request for
that subscription. Specifically, the contents of an attribute sent that subscription. Specifically, the contents of an attribute sent
in fulfillment of a subscription have the same format as would a in fulfillment of a subscription have the same format as would a
direct response to the establishing request. For example, if the direct response to the establishing request. For example, if the
establishing request stipulated a response that contained an event establishing request stipulated a response that contained an event
record list wherein affected software indicated using Software record list that included software inventory evidence records, all
Identifiers, all attributes sent in fulfillment of this subscription attributes sent in fulfillment of this subscription will also consist
will also consist of event record lists expressed using Software of event record lists with software inventory evidence records. As
Identifiers. As such, all SW Responses displayed in the exchange such, all SW Responses displayed in the exchange depicted in Figure 3
depicted in Figure 3 have the same format. A SW Response generated have the same format. A SW Response generated in fulfillment of an
in fulfillment of an active subscription MUST be a valid SW Response active subscription MUST be a valid SW Response attribute according
attribute according to all the rules outlined in the preceding to all the rules outlined in the preceding sections. In other words,
sections. In other words, an attribute constructed in fulfillment of an attribute constructed in fulfillment of a subscription will look
a subscription will look the same as an attribute sent in direct the same as an attribute sent in direct response to an explicit
response to an explicit request from a SW-PV that had the same request from a SW-PV that had the same request parameters and which
request parameters and which arrived immediately after the given arrived immediately after the given change event. There are a few
change event. There are a few special rules that expand on this special rules that expand on this guideline:
guideline:
3.6.5.1. Subscriptions Reporting Inventories 3.6.5.1. Subscriptions Reporting Inventories
In the case that a SW-PV subscribes to a SW-PC requesting an In the case that a SW-PV subscribes to a SW-PC requesting an
inventory attribute whenever changes are detected (i.e. the EID in inventory attribute whenever changes are detected (i.e. the EID in
the establishing request is 0), then the SW-PC MUST send the the establishing request is 0), then the SW-PC MUST send the
requested inventory whenever a relevant change is detected. (A requested inventory whenever a relevant change is detected. (A
"relevant change" is any change for untargeted requests, or a change "relevant change" is any change for untargeted requests, or a change
to an indicated record in a targeted request.) Upon detection of a to an indicated record in a targeted request.) Upon detection of a
relevant change for an active subscription, the SW-PC sends the relevant change for an active subscription, the SW-PC sends the
skipping to change at page 31, line 11 skipping to change at page 33, line 30
Note that while a subscription is active, the subscribing SW-PV MAY Note that while a subscription is active, the subscribing SW-PV MAY
make other requests for event records that overlap with events that make other requests for event records that overlap with events that
are reported in fulfillment of a subscription. Such requests are are reported in fulfillment of a subscription. Such requests are
unaffected by the presence of the subscription, nor is the unaffected by the presence of the subscription, nor is the
subscription affected by such requests. In other words, a given subscription affected by such requests. In other words, a given
request will get the same results back whether or not there was a request will get the same results back whether or not there was a
subscription. Likewise, an attribute sent in fulfillment of a subscription. Likewise, an attribute sent in fulfillment of a
subscription will contain the same information whether or not other subscription will contain the same information whether or not other
requests had been received from the SW-PV. requests had been received from the SW-PV.
A SW-PV needs to pay attention to the EID Epoch in these messages, as A SW-PV needs to pay attention to the EID Epoch in these attributes,
changes in the Epoch might create discontinuities in the SW-PV's as changes in the Epoch might create discontinuities in the SW-PV's
understanding of the endpoint's Software Inventory Evidence understanding of the endpoint's Software Inventory Evidence
Collection state, as discussed in Section 3.5.5. In particular, once Collection state, as discussed in Section 3.5.6. In particular, once
the EID Epoch changes, a SW-PV is unable have confidence that it has the EID Epoch changes, a SW-PV is unable have confidence that it has
a correct understanding of the state of an endpoint's Software a correct understanding of the state of an endpoint's Software
Inventory Evidence Collection until after the SW-PV collects a Inventory Evidence Collection until after the SW-PV collects a
complete inventory. complete inventory.
SW-PCs MAY send partial lists of event records in fulfillment of a SW-PCs MAY send partial lists of event records in fulfillment of a
subscription. (See Section 3.5.4 for more on partial list of event subscription. (See Section 3.5.5 for more on partial list of event
records.) In the case that a SW-PC sends a partial list of event records.) In the case that a SW-PC sends a partial list of event
records, it MUST immediately send the next consecutive partial list, records in fulfillment of a subscription, it MUST immediately send
and continue doing so until it has sent the equivalent of the the next consecutive partial list, and continue doing so until it has
complete list of event records. In other words, if the SW-PC sends a sent the equivalent of the complete list of event records. In other
partial list it does not wait for another change event to send words, if the SW-PC sends a partial list it does not wait for another
another SW Response, but continues sending SW Responses until it has change event to send another SW Response, but continues sending SW
sent all event records that would have been included in a complete Responses until it has sent all event records that would have been
fulfillment of the subscription. included in a complete fulfillment of the subscription. Note that
the direct response to the establishing request is not considered to
be sent in fulfillment of a subscription. However, in this case the
SW-PC MUST treat the presence of unreported events as a triggering
event for pushing additional messages in fulfillment of the newly
established subscription. As such, the net effect is that, if the
direct response to the establishing request (i.e., the Subscription
Fulfillment flag is unset) is partial, the SW-PC will immediately
follow this with additional attributes (with the Subscription
Fulfillment flag set) until the complete set of events has been sent
to the SW-PV.
3.6.5.3. Targeted Subscriptions 3.6.5.3. Targeted Subscriptions
Subscriptions MAY be targeted to only apply to records that match a Subscriptions MAY be targeted to only apply to records that match a
given set of Software Identifiers. In the case where changes are given set of Software Identifiers. In the case where changes are
detected that affect multiple records, some matching the establishing detected that affect multiple records, some matching the establishing
request's Software Identifiers and some not, the attribute sent in request's Software Identifiers and some not, the attribute sent in
fulfillment of the subscription MUST only include inventory or events fulfillment of the subscription MUST only include inventory or events
(as appropriate) for records that match the establishing request's (as appropriate) for records that match the establishing request's
Software Identifiers. The SW-PC MUST NOT include non-matching Software Identifiers. The SW-PC MUST NOT include non-matching
skipping to change at page 33, line 30 skipping to change at page 36, line 14
A SW-PC is not required to identify every possible source of software A SW-PC is not required to identify every possible source of software
information on its endpoint. Some SW-PCs might be explicitly tied information on its endpoint. Some SW-PCs might be explicitly tied
only to one or a handful of software inventory sources. For all only to one or a handful of software inventory sources. For all
software inventory evidence sources that a particular SW-PC supports, software inventory evidence sources that a particular SW-PC supports,
it MUST completely support all requirements of this specification it MUST completely support all requirements of this specification
with regard to those sources. In other words, for supported sources, with regard to those sources. In other words, for supported sources,
the SW-PC is required to be capable of providing a complete set of the SW-PC is required to be capable of providing a complete set of
the provided software inventory evidence records; monitoring for the provided software inventory evidence records; monitoring for
changes in the records reported by those sources, correctly providing changes in the records reported by those sources, correctly providing
responses for both full and targeted requests that include records responses for both full and targeted requests for records from those
from those sources, and providing either complete records or Software sources, and delivering complete software inventory evidence records
Identifiers as appropriate. If the source's output is not in one of as appropriate. In all cases, the SW-PC MUST also be capable of
the data models identified in the Software Data Model IANA table (see deriving a Software Identifier from the resulting record and also
Section 9.4), the SW-PC MUST be capable of converting that output assigning that record a unique Record Identifier. The SW-PC MUST NOT
into one of the supported data models. In all cases, the SW-PC MUST provide any inventory or event information from software inventory
also be capable of deriving a Software Identifier from the resulting sources for which it cannot provide this full support. Note that the
record and also assigning that record a unique Record Identifier. SW-PC SHOULD be able to provide a Software Locator for each software
The SW-PC MUST NOT provide any inventory or event information from product reported by a given source, but it is recognized that this
software inventory sources for which it cannot provide this full might not be possible in all circumstances and the inability to do so
support. does not preclude use of the given source.
When providing a SW Response (either in direct response to a SW When providing a SW Response (either in direct response to a SW
Request or in fulfillment of a subscription) the SW-PC MUST include Request or in fulfillment of a subscription) the SW-PC MUST include
the complete set of relevant data from all supported sources of the complete set of relevant data from all supported sources of
software inventory evidence. In other words, a full inventory is software inventory evidence. In other words, a full inventory is
required to contain all records from all supported sources, a required to contain all records from all supported sources, a
targeted inventory is required to contain all relevant records from targeted inventory is required to contain all relevant records from
all sources, and event tracking is required to cover all events from all sources, and event tracking is required to cover all events from
all sources. With regard to events, a SW-PC's assignment of EIDs all sources. With regard to events, a SW-PC's assignment of EIDs
MUST reflect the presence and order of all events on the endpoint (at MUST reflect the presence and order of all events on the endpoint (at
least for supported sources) regardless of the source. This means least for supported sources) regardless of the source. This means
that if source A experiences an event, and then source B experiences that if source A experiences an event, and then source B experiences
two events, and then source A experiences another two events, the SW- two events, and then source A experiences another two events, the SW-
PC is required to capture five events with consecutive EID values PC is required to capture five events with consecutive EID values
reflecting the order in which the events occur. reflecting the order in which the events occur.
Note that, if a SW-PC collects data from multiple sources, it is Note that, if a SW-PC collects data from multiple sources, it is
possible that some software products might be "double counted". This possible that some software products might be "double counted". This
can happen if both sources of inventory evidence provide a record for can happen if both sources of inventory evidence provide a record for
a single installation of a software product. Moreover, each of these a single installation of a software product. Moreover, each of these
provided records might have different Software Identifiers. When a provided records might have different Software Identifier and
SW-PC reports information or records events from multiple inventory Software Locator values due to the different ways a source might
evidence sources, it MUST use the information those sources provide, report its information. When a SW-PC reports information or records
rather than attempting to perform some form of reduction. In other events from multiple inventory evidence sources, it MUST use the
words, if multiple sources report records corresponding to a single information those sources provide, rather than attempting to perform
installation of a software product, all such records from each source some form of reduction. In other words, if multiple sources report
are required to be part of the SW-PC's processing even if this might records corresponding to a single installation of a software product,
lead to multiple reporting, and the SW-PC is not to ignore some all such records from each source are required to be part of the SW-
records to avoid such multiple reporting. Similarly, in the case PC's processing even if this might lead to multiple reporting, and
that multiple sources report an event, the SW-PC MUST create separate the SW-PC is not to ignore some records to avoid such multiple
event records with separate EIDs for each of these, even if there is reporting. Similarly, in the case that multiple sources report an
the chance that they represent the two sources reporting the same event, the SW-PC MUST create separate event records with separate
action on the endpoint. Entities tracking software inventory EIDs for each of these, even if there is the chance that they
information collected via SW-PCs and SW-PVs need to be aware that represent multiple sources reporting the same action on the endpoint.
such double-reporting might occur. How (or if) such occurrences are Entities tracking software inventory information collected via SW-PCs
detected and resolved is up to the implementers of those entities. and SW-PVs need to be aware that such double-reporting might occur.
How (or if) such occurrences are detected and resolved is up to the
implementers of those entities.
3.8. Error Handling 3.8. Error Handling
In the case where the SW-PC detects an error in a SW Request In the case where the SW-PC detects an error in a SW Request
attribute that it receives it MUST respond with a PA-TNC Error attribute that it receives it MUST respond with a PA-TNC Error
attribute with an error code appropriate to the nature of the error. attribute with an error code appropriate to the nature of the error.
(See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC (See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC
Error attributes and error codes as well as Section 4.16 in this Error attributes and error codes as well as Section 4.14 in this
specification for error codes specific to SW Attributes.) In the specification for error codes specific to SW Attributes.) In the
case that an error is detected in a SW Request the SW-PC MUST NOT case that an error is detected in a SW Request the SW-PC MUST NOT
take any action requested by this SW Request, even if partial take any action requested by this SW Request, even if partial
completion of the SW is possible. In other words, a SW Request that completion of the SW is possible. In other words, a SW Request that
contains an error is completely ignored by the SW-PC (beyond sending contains an error is completely ignored by the SW-PC (beyond sending
a PA-TNC Error attribute, and possibly logging the error locally) a PA-TNC Error attribute, and possibly logging the error locally)
rather than being partially executed. rather than being partially executed.
In the case where the SW-PC receives a valid SW Request attribute but In the case where the SW-PC receives a valid SW Request attribute but
experiences an error during the process of responding to that experiences an error during the process of responding to that
skipping to change at page 35, line 43 skipping to change at page 38, line 29
PV. PV.
The SW-PV MUST NOT send any PA-TNC Error attributes to SW-PCs. In The SW-PV MUST NOT send any PA-TNC Error attributes to SW-PCs. In
the case that a SW-PV detects an error condition, it SHOULD log this the case that a SW-PV detects an error condition, it SHOULD log this
error but does not inform any SW-PC's of this event. Errors might error but does not inform any SW-PC's of this event. Errors might
include, but are not limited to, detection of malformed SW Response include, but are not limited to, detection of malformed SW Response
attributes sent from a given SW-PC, as well as detection of error attributes sent from a given SW-PC, as well as detection of error
conditions when the SW-PV processes SW Responses. conditions when the SW-PV processes SW Responses.
Both SW-PCs and SW-PVs SHOULD log errors so that administrators can Both SW-PCs and SW-PVs SHOULD log errors so that administrators can
trace the causes of errors. Log messages SHOULD include the type of trace the causes of errors. Log entries SHOULD include the type of
the error, the time it was detected, and additional descriptive the error, the time it was detected, and additional descriptive
information to aid in understanding the nature and cause of the information to aid in understanding the nature and cause of the
error. error.
4. Software Message and Attributes for PA-TNC Protocol 4. Software Inventory Message and Attributes for PA-TNC Protocol
This section describes the format and semantics of the Software This section describes the format and semantics of the Software
Message and Attributes for PA-TNC protocol. Software Message and Inventory Message and Attributes for PA-TNC protocol. Software
Attributes for PA-TNC uses the standard PA-TNC message header format. Inventory Message and Attributes for PA-TNC uses the standard PA-TNC
See the PA-TNC specification [RFC5792] for information on this header message header format. See the PA-TNC specification [RFC5792] for
format. information on this header format.
4.1. PA Subtype (AKA PA-TNC Component Type) 4.1. PA Subtype (AKA PA-TNC Component Type)
The NEA PB-TNC interface provides a general message-batching protocol The NEA PB-TNC interface provides a general message-batching protocol
capable of carrying one or more PA-TNC messages between the Posture capable of carrying one or more PA-TNC messages between the Posture
Broker Client and Posture Broker Server. When PB-TNC is carrying a Broker Client and Posture Broker Server. When PB-TNC is carrying a
PA-TNC message, the PB-TNC message headers contain a 32 bit PA-TNC message, the PB-TNC message headers contain a 32 bit
identifier called the PA Subtype. The PA Subtype field indicates the identifier called the PA Subtype. The PA Subtype field indicates the
type of component associated with all of the PA-TNC attributes type of component associated with all of the PA-TNC attributes
carried by the PB-TNC message. The core set of PA Subtypes is carried by the PB-TNC message. The core set of PA Subtypes is
defined in the PA-TNC specification. This specification adds the defined in the PA-TNC specification. This specification adds the
following enumeration element to the table in section 7.2 of the PA- following enumeration element to the IANA registry defined in section
TNC specification [RFC5792] using the IETF Standard name space (SMI 7.2 of the PA-TNC specification [RFC5792] using the IETF Standard
Private Enterprise Number 0x000000): name space (SMI Private Enterprise Number 0x000000):
+-----+---------+-------------+-------------------------------------+ +-----+---------+------------+--------------------------------------+
| PEN | Integer | Name | Defining Specification | | PEN | Integer | Name | Defining Specification |
+-----+---------+-------------+-------------------------------------+ +-----+---------+------------+--------------------------------------+
| 0 | 9 | SW | Software Message and Attributes for | | 0 | 9 | SW | Software Inventory Message and |
| | | Attributes | PA-TNC | | | | Attributes | Attributes for PA-TNC |
+-----+---------+-------------+-------------------------------------+ +-----+---------+------------+--------------------------------------+
Table 2: PA Subtype Table 2: PA Subtype
Each PA-TNC attribute described in this specification is intended to Each PA-TNC attribute described in this specification is intended to
be sent between the SW-PC and SW-PV, so will be carried in a PB-TNC be sent between the SW-PC and SW-PV, so will be carried in a PB-TNC
message indicating a PA Subtype of SW Attributes. Note that although message indicating a PA Subtype of SW Attributes. Note that although
the PA-TNC Error attribute is defined in the PA-TNC specification, the PA-TNC Error attribute is defined in the PA-TNC specification,
when it is used in a SW Attribute exchange, it uses the SW Attributes when it is used in a SW Attribute exchange, it uses the SW Attributes
Component Definition Value, as described in Section 4.2.8 of the PA- Component Definition Value, as described in Section 4.2.8 of the PA-
TNC specification [RFC5792]. PB-TNC messages MUST always include the TNC specification [RFC5792]. PB-TNC messages MUST always include the
SW Attributes Subtype defined in this section when carrying SW SW Attributes Subtype defined in this section when carrying SW
Attributes over PA-TNC. Attributes over PA-TNC.
4.2. PB-TNC and PA-TNC Messages
A PA-TNC message is wrapped within a PB-TNC message. A single PA-TNC
message might contain one or more PA-TNC attributes. All of these
attributes within a single PA-TNC message use the same PA Subtype
value. As such, SW Attributes are never sent in the same PA-TNC
message as attributes defined in other PA-TNC binding specifications.
Note, however, that a single PB-TNC batch might contain multiple PB-
TNC and PA-TNC messages, and each of those messages might use
different PA Subtypes.
For more information on PB-TNC and PA-TNC messages and message For more information on PB-TNC and PA-TNC messages and message
headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792] headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792]
specifications, respectively. specifications, respectively.
4.3. PA-TNC Attribute Header 4.2. SW Attribute Overview
The Software Message and Attributes for PA-TNC protocol described in
this specification is an extension of the PA-TNC protocol described
in the NEA Architecture. PA-TNC was designed to be very flexible in
order to carry many types of PA-TNC attributes that pertain to an
enumerated set of component types (e.g. Table 2). PA-TNC attributes
might be carried from Posture Collector to Posture Validator or vice
versa and might carry information about endpoint state or other
information to be sent between a Posture Validator and a Posture
Collector. Therefore, the Software Message and Attributes for PA-TNC
specification defines a collection of PA-TNC attributes relevant to
the collection and transmission of software inventories and
associated events.
Figure 4, reproduced from the PA-TNC specification, shows the format
of a PA-TNC attribute. Multiple PA-TNC attributes can be sent in a
single PB-TNC message, each housed within an attribute structure as
described below.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PA-TNC Header and Attribute Format
+-----------+-------------------------------------------------------+
| Field | Description |
+-----------+-------------------------------------------------------+
| Flags | This field defines flags affecting the processing of |
| | the Software Message and Attributes for PA-TNC. |
| | Permissible flags are given in the PA-TNC |
| | specification. [RFC5792] |
| | |
| Attribute | This field indicates the owner of the name space |
| Type | associated with the Attribute Type. Attributes |
| Vendor ID | defined in the Software Message and Attributes for |
| | PA-TNC specification have a value corresponding to |
| | the IETF SMI Private Enterprise Number value |
| | (0x000000). The PA-TNC Error attribute is defined in |
| | the PA-TNC specification [RFC5792] and also uses the |
| | IETF SMI Private Enterprise Number Value (0x000000). |
| | See Table 4 for more information. |
| | |
| Attribute | This field defines the type of the Attribute. The |
| Type | values corresponding to SW Attributes are given in |
| | Table 4. |
| | |
| Attribute | This field contains the length in octets of the |
| Length | entire Attribute, including the Attribute's header. |
| | |
| Attribute | This field contains the SW Attribute. |
| Value | |
+-----------+-------------------------------------------------------+
Table 3: Fields of the PA-TNC Attribute Format
4.4. SW Attribute Overview
The attributes defined in this specification appear below with a The attributes defined in this specification appear below with a
short summary of their purposes. Each attribute is described in short summary of their purposes. Each attribute is described in
greater detail in subsequent sections. greater detail in subsequent sections.
o SW Request - This attribute is used to request a software o SW Request - This attribute is used to request a software
inventory or software event list from an endpoint. This attribute inventory or software event list from an endpoint. This attribute
might also establish a subscription on the recipient SW-PC. A SW- might also establish a subscription on the recipient SW-PC. A SW-
PC MUST NOT send this attribute. PC MUST NOT send this attribute.
o Software Identifier Inventory - This attribute is used to convey o Software Identifier Inventory - This attribute is used to convey
an inventory expressed using Software Identifiers (instead of full an inventory without the inclusion of software inventory evidence
records). When a SW-PC receives a SW Request attribute requesting records. When a SW-PC receives a SW Request attribute requesting
an inventory using Software Identifiers, the SW-PC MUST send a an inventory without software inventory evidence records, the SW-
Software Identifier Inventory attribute (or a PA-TNC Error) in PC MUST send a Software Identifier Inventory attribute (or a PA-
response. This attribute also MAY be sent by the SW-PC in TNC Error) in response. This attribute also MAY be sent by the
fulfillment of an active subscription. A SW-PV MUST NOT send this SW-PC in fulfillment of an active subscription. A SW-PV MUST NOT
attribute. send this attribute.
o Software Identifier Events - This attribute is used to convey a o Software Identifier Events - This attribute is used to convey a
list of events concerning changes to an endpoint's Software list of events concerning changes to an endpoint's Software
Inventory Evidence Collection. Affected software inventory Inventory Evidence Collection. Reported events do not include
evidence records are indicated using Software Identifiers (instead software inventory evidence records. When a SW-PC receives a SW
of full records). When a SW-PC receives a SW Request attribute Request attribute requesting an event collection without software
requesting an event collection using Software Identifiers, the SW- inventory evidence records, the SW-PC MUST send a Software
PC MUST send a Software Identifier Events attribute (or a PA-TNC Identifier Events attribute (or a PA-TNC Error) in response. This
Error) in response. This attribute also MAY be sent by the SW-PC attribute also MAY be sent by the SW-PC in fulfillment of an
in fulfillment of an active subscription. A SW-PV MUST NOT send active subscription. A SW-PV MUST NOT send this attribute.
this attribute.
o Software Inventory - This attribute is used to convey an inventory o Software Inventory - This attribute is used to convey an inventory
expressed using full software inventory evidence records (instead expressed including software inventory evidence records. When a
of Software Identifiers). When a SW-PC receives a SW Request SW-PC receives a SW Request attribute requesting an inventory
attribute requesting an inventory using full software inventory including software inventory evidence records, the SW-PC MUST send
evidence records, the SW-PC MUST send a Software Inventory a Software Inventory attribute (or a PA-TNC Error) in response.
attribute (or a PA-TNC Error) in response. This attribute also This attribute also MAY be sent by the SW-PC in fulfillment of an
MAY be sent by the SW-PC in fulfillment of an active subscription. active subscription. A SW-PV MUST NOT send this attribute.
A SW-PV MUST NOT send this attribute.
o Software Events - This attribute is used to convey a list of o Software Events - This attribute is used to convey a list of
events concerning changes to an endpoint's inventory evidence events concerning changes to an endpoint's inventory evidence
collection. Affected software inventory evidence records are collection. Reported events include software inventory evidence
indicated using full records (instead of Software Identifiers). records. When a SW-PC receives a SW Request attribute requesting
When a SW-PC receives a SW Request attribute requesting an event an event collection including software inventory evidence records,
collection using full records, the SW-PC MUST send a Software the SW-PC MUST send a Software Events attribute (or a PA-TNC
Events attribute (or a PA-TNC Error) in response. This attribute Error) in response. This attribute also MAY be sent by the SW-PC
also MAY be sent by the SW-PC in fulfillment of an active in fulfillment of an active subscription. A SW-PV MUST NOT send
subscription. A SW-PV MUST NOT send this attribute. this attribute.
o Subscription Status Request - This attribute is used to request a o Subscription Status Request - This attribute is used to request a
SW-PC send a summary of all the active subscriptions it has where SW-PC send a summary of all the active subscriptions it has where
the requesting party is the subscriber. The SW-PC MUST respond the requesting party is the subscriber. The SW-PC MUST respond
with a Subscription Status Response (or a PA-TNC Error). A SW-PC with a Subscription Status Response (or a PA-TNC Error). A SW-PC
MUST NOT send this attribute. MUST NOT send this attribute.
o Subscription Status Response - This attribute is used to convey o Subscription Status Response - This attribute is used to convey
information about the active subscriptions that a SW-PC has for a information about the active subscriptions that a SW-PC has for a
given subscriber. A SW-PV MUST NOT send this attribute. given subscriber. A SW-PV MUST NOT send this attribute.
skipping to change at page 40, line 32 skipping to change at page 41, line 25
receiving and processing all SW Response attributes as well as PA-TNC receiving and processing all SW Response attributes as well as PA-TNC
Error attributes. All SW-PCs MUST be capable of receiving and Error attributes. All SW-PCs MUST be capable of receiving and
processing SW Requests and be capable of sending all types of SW processing SW Requests and be capable of sending all types of SW
Response attributes as well as PA-TNC Error attributes. In other Response attributes as well as PA-TNC Error attributes. In other
words, both SW-PVs and SW-PCs are required to support their role in words, both SW-PVs and SW-PCs are required to support their role in
exchanges using any of the attribute types defined in this section. exchanges using any of the attribute types defined in this section.
SW-PVs MUST ignore any SW Request attributes that they receive. SW- SW-PVs MUST ignore any SW Request attributes that they receive. SW-
PCs MUST ignore any SW Response attributes or PA-TNC Error attributes PCs MUST ignore any SW Response attributes or PA-TNC Error attributes
that they receive. that they receive.
4.5. SW Attribute Exchanges 4.3. SW Attribute Exchanges
A SW Attribute Exchange is used to provide the SW-PV with a software A SW Attribute Exchange is used to provide the SW-PV with a software
inventory or event collection from the queried endpoint. inventory or event collection from the queried endpoint.
+-------------+ +--------------+ +-------------+ +--------------+
| SW-PC | | SW-PV | Time | SW-PC | | SW-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
|<------------SW Request--------------| | |<------------SW Request--------------| |
| | | | | |
| SW Response* | | | SW Response* | |
|-----------------or----------------->| | |-----------------or----------------->| |
| PA-TNC Error | | | PA-TNC Error | |
| | V | | V
*SW Response is one of the following: Software Identifier *SW Response is one of the following: Software Identifier
Inventory, Software Identifier Events, Software Inventory, Inventory, Software Identifier Events, Software Inventory,
or Software Events. or Software Events.
Figure 5: SW Attribute Exchange (Direct Response to SW Request) Figure 4: SW Attribute Exchange (Direct Response to SW Request)
In this exchange, the SW-PV indicates to the SW-PC, via a SW Request, In this exchange, the SW-PV indicates to the SW-PC, via a SW Request,
the nature of the information it wishes to receive (inventory vs. the nature of the information it wishes to receive (inventory vs.
events, full or targeted) and how it wishes the returned inventory to events, full or targeted) and how it wishes the returned inventory to
be expressed (full records or Software Identifiers). The SW-PC be expressed (with or without software inventory evidence records).
responds with the requested information using the appropriate The SW-PC responds with the requested information using the
attribute type. A single SW Request MUST only lead to a single SW appropriate attribute type. A single SW Request MUST only lead to a
Response or PA-TNC Error that is in direct response to that request. single SW Response or PA-TNC Error that is in direct response to that
request.
In addition, if there is an active subscription on the endpoint, the In addition, if there is an active subscription on the endpoint, the
SW-PC sends a SW Response to the SW-PV following a change event on SW-PC sends a SW Response to the SW-PV following a change event on
the endpoint in fulfillment of that subscription. Such an exchange the endpoint in fulfillment of that subscription. Such an exchange
is shown in Figure 6. is shown in Figure 5.
+-------------+ +--------------+ +-------------+ +--------------+
| SW-PC | | SW-PV | Time | SW-PC | | SW-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
<Change Event>| | | <Change Event>| | |
|--------SW Response(s)*------->| | |--------SW Response(s)*------->| |
| | | | | |
*SW Response is one of the following: Software Identifier *SW Response is one of the following: Software Identifier
Inventory, Software Identifier Events, Software Inventory, Inventory, Software Identifier Events, Software Inventory,
or Software Events. or Software Events.
Figure 6: SW Attribute Exchange (In Fulfillment of an Active Figure 5: SW Attribute Exchange (In Fulfillment of an Active
Subscription) Subscription)
Note that, unlike direct responses to a SW Request, a single change Note that, unlike direct responses to a SW Request, a single change
event can precipitate multiple SW Responses for a single event can precipitate multiple SW Responses for a single
subscription, but only if all but the last of those SW Responses subscription, but only if all but the last of those SW Responses
convey partial lists of event records, and the last of those SW convey partial lists of event records, and the last of those SW
Responses conveys a complete list of event records. (That is, the Responses conveys a complete list of event records. (That is, the
initial responses are partial lists and the last response is the initial responses are partial lists and the last response is the
remainder of the relevant event records, completing the delivery of remainder of the relevant event records, completing the delivery of
all relevant events at the time of the change event.) A single all relevant events at the time of the change event.) A single
Change Event MUST NOT be followed by multiple SW Response or PA-TNC Change Event MUST NOT otherwise be followed by multiple SW Response
Error attributes in any combination except as noted earlier in this or PA-TNC Error attributes in any combination.
paragraph.
All SW-PVs and SW-PCs MUST support both types of exchanges. In All SW-PVs and SW-PCs MUST support both types of exchanges. In
particular, SW-PCs MUST be capable of pushing a SW Response to a SW- particular, SW-PCs MUST be capable of pushing a SW Response to a SW-
PV immediately upon detection of a change to the endpoint's Software PV immediately upon detection of a change to the endpoint's Software
Inventory Evidence Collection in fulfillment of established SW-PV Inventory Evidence Collection in fulfillment of established SW-PV
subscriptions, as described in Section 3.6. subscriptions, as described in Section 3.6.
4.6. Software Message and Attributes for PA-TNC Attribute Enumeration 4.4. Software Inventory Message and Attributes for PA-TNC Attribute
Enumeration
PA-TNC attribute types are identified in the PA-TNC Attribute Header PA-TNC attribute types are identified in the PA-TNC Attribute Header
(see Section 4.2) via the Attribute Type Vendor ID and Attribute Type via the Attribute Type Vendor ID and Attribute Type fields. Table 3
fields. Table 4 identifies the appropriate values for these fields identifies the appropriate values for these fields for each attribute
for each attribute type used within the Software Message and type used within the Software Inventory Message and Attributes for
Attributes for PA-TNC protocol. PA-TNC protocol.
+--------------+----------+------------+----------------------------+ +--------------+----------+------------+----------------------------+
| Attribute | PEN | Integer | Description | | Attribute | PEN | Integer | Description |
| Name | | | | | Name | | | |
+--------------+----------+------------+----------------------------+ +--------------+----------+------------+----------------------------+
| SW Request | 0x000000 | 0x00000011 | Request from a SW-PV to a | | SW Request | 0x000000 | 0x00000011 | Request from a SW-PV to a |
| | | | SW-PC for the SW-PC to | | | | | SW-PC for the SW-PC to |
| | | | provide a software | | | | | provide a software |
| | | | inventory or event list | | | | | inventory or event list |
| | | | | | | | | |
| Software | 0x000000 | 0x00000012 | A collection of Software | | Software | 0x000000 | 0x00000012 | An inventory sent without |
| Identifier | | | Identifiers sent from a | | Identifier | | | softare inventory evidence |
| Inventory | | | SW-PC. | | Inventory | | | records sent from a SW-PC. |
| | | | | | | | | |
| Software | 0x000000 | 0x00000013 | A collection of events | | Software | 0x000000 | 0x00000013 | A collection of events |
| Identifier | | | impacting the endpoint's | | Identifier | | | impacting the endpoint's |
| Events | | | Software Inventory | | Events | | | Software Inventory |
| | | | Evidence Collection, where | | | | | Evidence Collection, where |
| | | | impacted software | | | | | events do not include |
| | | | inventory evidence records | | | | | software inventory |
| | | | are indicated using | | | | | evidence records. |
| | | | Software Identifiers. |
| | | | | | | | | |
| Software | 0x000000 | 0x00000014 | A collection of software | | Software | 0x000000 | 0x00000014 | An inventory including |
| Inventory | | | inventory evidence records | | Inventory | | | software inventory |
| | | | sent from a SW-PC. | | | | | evidence records sent from |
| | | | a SW-PC. |
| | | | | | | | | |
| Software | 0x000000 | 0x00000015 | A collection of events | | Software | 0x000000 | 0x00000015 | A collection of events |
| Events | | | impacting the endpoint's | | Events | | | impacting the endpoint's |
| | | | Software Inventory | | | | | Software Inventory |
| | | | Evidence Collection, where | | | | | Evidence Collection, where |
| | | | impacted software | | | | | events include software |
| | | | inventory evidence records | | | | | inventory evidence |
| | | | are indicated using full |
| | | | records. | | | | | records. |
| | | | | | | | | |
| Subscription | 0x000000 | 0x00000016 | A request for a list of a | | Subscription | 0x000000 | 0x00000016 | A request for a list of a |
| Status | | | SW-PV's active | | Status | | | SW-PV's active |
| Request | | | subscription. | | Request | | | subscription. |
| | | | | | | | | |
| Subscription | 0x000000 | 0x00000017 | A list of a SW-PV's active | | Subscription | 0x000000 | 0x00000017 | A list of a SW-PV's active |
| Status | | | subscriptions. | | Status | | | subscriptions. |
| Response | | | | | Response | | | |
| | | | | | | | | |
| Reserved | 0x000000 | 0x00000018 | These attribute types are | | Reserved | 0x000000 | 0x00000018 | These attribute types are |
| | | - | reserved for future use in | | | | - | reserved for future use in |
| | | 0x0000001F | revisions to Software | | | | 0x0000001F | revisions to Software |
| | | | Message and Attributes for | | | | | Inventory Message and |
| | | | PA-TNC. | | | | | Attributes for PA-TNC. |
| | | | | | | | | |
| PA-TNC Error | 0x000000 | 0x00000008 | An error attribute as | | PA-TNC Error | 0x000000 | 0x00000008 | An error attribute as |
| | | | defined in the PA-TNC | | | | | defined in the PA-TNC |
| | | | specification [RFC5792]. | | | | | specification [RFC5792]. |
+--------------+----------+------------+----------------------------+ +--------------+----------+------------+----------------------------+
Table 4: SW Attribute Enumeration Table 3: SW Attribute Enumeration
4.7. Normalization of Text Encoding 4.5. Normalization of Text Encoding
In order to ensure consistency of transmitted attributes, a field In order to ensure consistency of transmitted attributes some fields
requiring normalization, as indicated in its description, MUST be require normalization of their format. When this is necessary, this
normalized to Network Unicode format as defined in RFC 5198 is indicated in the field's description. In such cases, the field
[RFC5198]. Network Unicode format defines a refinement of UTF-8 that contents MUST be normalized to Network Unicode format as defined in
ensures a normalized expression of characters. SW-PCs and SW-PVs RFC 5198 [RFC5198]. Network Unicode format defines a refinement of
MUST NOT perform conversion and normalization on any field values UTF-8 that ensures a normalized expression of characters. SW-PCs and
except those specifically identified as requiring normalization in SW-PVs MUST NOT perform conversion and normalization on any field
the following sections. Note, however, that some data models require values except those specifically identified as requiring
additional normalization before source information is added to an normalization in the following sections. Note, however, that some
Endpoint's Inventory Evidence Collection as a record. The references data models require additional normalization before source
from the Software Data Model IANA table (see section Section 9.4 will information is added to an Endpoint's Inventory Evidence Collection
note where this is necessary. as a record. The references from the Software Data Model IANA table
(see Section 9.4) will note where this is necessary.
4.8. Request IDs 4.6. Request IDs
All SW Request attributes MUST include a Request ID value. The All SW Request attributes MUST include a Request ID value. The
Request ID field provides a value that identifies a given request Request ID field provides a value that identifies a given request
relative to other requests between a SW-PV and the receiving SW-PC. relative to other requests between a SW-PV and the receiving SW-PC.
Specifically, the SW-PV assigns each SW Request attribute a Request Specifically, the SW-PV assigns each SW Request attribute a Request
ID value that is intended to be unique within the lifetime of a given ID value that is intended to be unique within the lifetime of a given
network connection ID as assigned by the SW-PV's Posture Broker network connection ID as assigned by the SW-PV's Posture Broker
Server. In the case where all possible Request ID values have been Server. In the case where all possible Request ID values have been
exhausted within the lifetime of a single network connection ID, the exhausted within the lifetime of a single network connection ID, the
sender MAY reuse previously used Request IDs within the same network sender MAY reuse previously used Request IDs within the same network
connection that are not being used as Subscription IDs. (See below connection that are not being used as Subscription IDs. (See below
in this section for an explanation of Subscription ID assignment.) in this section for an explanation of Subscription ID assignment.)
In this case of Request ID reuse, Request IDs SHOULD be reused in the In this case of Request ID reuse, Request IDs SHOULD be reused in the
order of their original use. For example, if a Request ID of X was order of their original use. In other words, a SW-PC SHOULD NOT use
the first Request ID used within a particular network connection and a given Request ID value more than once within a persistent
if the Request IDs are exhausted, X will be the first reused Request connection between a given Posture Broker Client-Posture Broker
ID. In other words, a SW-PC SHOULD NOT use a given Request ID value Server pair, but, in the case where reuse is necessary due to
more than once within a persistent connection between a given Posture exhaustion of possible ID values, the SW-PC SHOULD structure the
Broker Client-Posture Broker Server pair, but, in the case where reuse to maximize the time between original and subsequent use. The
reuse is necessary due to exhaustion of possible ID values, the SW-PC Request ID value is included in a SW Response attribute directly
SHOULD structure the reuse to maximize the time between original and responding to this SW Request to indicate which SW Request was
subsequent use. The Request ID value is included in a SW Response received and caused the response. Request IDs can be randomly
attribute directly responding to this SW Request to indicate which SW generated or sequential, as long as values are not repeated per the
Request was received and caused the response. Request IDs can be rules in this paragraph. SW-PCs are not required to check for
randomly generated or sequential, as long as values are not repeated duplicate Request IDs.
per the rules in this paragraph. SW-PCs are not required to check
for duplicate Request IDs.
In the case that a SW Request requests the establishment of a In the case that a SW Request requests the establishment of a
subscription and the receiving SW-PC agrees to that subscription, the subscription and the receiving SW-PC agrees to that subscription, the
Request ID of that SW Request (i.e., the establishing request of the Request ID of that SW Request (i.e., the establishing request of the
subscription) becomes that subscription's Subscription ID. All subscription) becomes that subscription's Subscription ID. All
attributes sent in fulfillment of this subscription include a flag attributes sent in fulfillment of this subscription include a flag
indicating that the attribute fulfills a subscription and the indicating that the attribute fulfills a subscription and the
subscription's Subscription ID. A SW-PV MUST NOT reuse a Request ID subscription's Subscription ID. A SW-PV MUST NOT reuse a Request ID
value in communicating to a given SW-PC while that Request ID is also value in communicating to a given SW-PC while that Request ID is also
serving as a Subscription ID for an active subscription with that SW- serving as a Subscription ID for an active subscription with that SW-
PC. In the case where a SW-PC receives a SW Request from a given SW- PC. In the case where a SW-PC receives a SW Request from a given SW-
PV where that Request ID is also the Subscription ID of an active PV where that Request ID is also the Subscription ID of an active
subscription with that SW-PV, the SW-PC MUST respond with a PA-TNC subscription with that SW-PV, the SW-PC MUST respond with a PA-TNC
Error attribute with an error code of SW_SUBSCRIPTION_ID_REUSE_ERROR. Error attribute with an error code of SW_SUBSCRIPTION_ID_REUSE_ERROR.
Note that this error does not cancel the indicated subscription. Note that this error does not cancel the indicated subscription.
Subscription Status Requests and Subscription Status Responses do not Subscription Status Requests and Subscription Status Responses do not
include Request IDs. include Request IDs.
4.9. SW Request 4.7. SW Request
A SW-PV sends this attribute to a SW-PC to request that the SW-PC A SW-PV sends this attribute to a SW-PC to request that the SW-PC
send software inventory information to the SW-PV. A SW-PC MUST NOT send software inventory information to the SW-PV. A SW-PC MUST NOT
send this attribute. send this attribute.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count | | Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID | | Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software ID (var length) | | Software Identifier Length | Software ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SW Request Attribute Figure 6: SW Request Attribute
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Field | Description | | Field | Description |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Flags: Bit 0 | If set (1), the SW-PC MUST delete all | | Flags: Bit 0 | If set (1), the SW-PC MUST delete all |
| - Clear | subscriptions established by the requesting SW-PV | | - Clear | subscriptions established by the requesting SW-PV |
| Subscriptions | (barring any errors). | | Subscriptions | (barring any errors). |
| | | | | |
| Flags: Bit 1 | If set (1), in addition to responding to the | | Flags: Bit 1 | If set (1), in addition to responding to the |
| - Subscribe | request as described, the SW-PC MUST establish a | | - Subscribe | request as described, the SW-PC MUST establish a |
| | subscription with parameters matching those in | | | subscription with parameters matching those in |
| | the request attribute (barring any errors). | | | the request attribute (barring any errors). |
| | | | | |
| Flags: Bit 2 | If unset (0), the SW-PC's response MUST consist | | Flags: Bit 2 | If unset (0), the SW-PC's response MUST include |
| - Result Type | of complete software inventory evidence records | | - Result Type | software inventory evidence records and thus the |
| | and thus the response MUST be a Software | | | response MUST be a Software Inventory, a Software |
| | Inventory, a Software Events, or a PA-TNC Error | | | Events, or a PA-TNC Error attribute. If set (1), |
| | attribute. If set (1), the response MUST consist | | | the response MUST NOT include software inventory |
| | of Software Identifiers and thus the response | | | evidence records and thus the response MUST be a |
| | MUST be a Software Identifier Inventory, a | | | Software Identifier Inventory, a Software |
| | Software Identifier Events, or a PA-TNC Error | | | Identifier Events, or a PA-TNC Error attribute. |
| | attribute. |
| | | | | |
| Flags: Bit | Reserved for future use. This field MUST be set | | Flags: Bit | Reserved for future use. This field MUST be set |
| 3-7 - | to zero on transmission and ignored upon | | 3-7 - | to zero on transmission and ignored upon |
| Reserved | reception. | | Reserved | reception. |
| | | | | |
| Software | A 3-byte unsigned integer indicating the number | | Software | A 3-byte unsigned integer indicating the number |
| Identifier | of Software Identifiers that follow. If this | | Identifier | of Software Identifiers that follow. If this |
| Count | value is non-zero, this is a targeted request, as | | Count | value is non-zero, this is a targeted request, as |
| | described in Section 3.3. The Software | | | described in Section 3.3. The Software |
| | Identifier Length and Software ID fields are | | | Identifier Length and Software ID fields are |
| | repeated, in order, the number of times indicated | | | repeated, in order, the number of times indicated |
| | in this field. In the case where Software | | | in this field. In the case where Software |
| | Identifiers are present, the SW-PC MUST only | | | Identifiers are present, the SW-PC MUST only |
| | respond with software inventory evidence records | | | report software that corresponds to the |
| | or Software Identifiers that correspond to the |
| | identifiers the SW-PV provided in this attribute | | | identifiers the SW-PV provided in this attribute |
| | (or with a PA-TNC Error attribute). This field | | | (or with a PA-TNC Error attribute). This field |
| | value MAY be 0, in which case there are no | | | value MAY be 0, in which case there are no |
| | instances of the Software Identifier Length and | | | instances of the Software Identifier Length and |
| | Software ID fields. In this case, the SW-PV is | | | Software ID fields. In this case, the SW-PV is |
| | indicating an interest in all software inventory | | | indicating an interest in all software inventory |
| | evidence records on the endpoint (i.e., this is | | | evidence records on the endpoint (i.e., this is |
| | not a targeted request). | | | not a targeted request). |
| | | | | |
| Request ID | A value that uniquely identifies this SW Request | | Request ID | A value that uniquely identifies this SW Request |
skipping to change at page 46, line 51 skipping to change at page 47, line 42
| | Identifier Inventory, or a PA-TNC Error | | | Identifier Inventory, or a PA-TNC Error |
| | attribute. | | | attribute. |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Identifier | in bytes of the Software ID field. | | Identifier | in bytes of the Software ID field. |
| Length | | | Length | |
| | | | | |
| Software ID | A string containing the Software Identifier value | | Software ID | A string containing the Software Identifier value |
| | from a software inventory evidence record. This | | | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode | | | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.5. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
Table 5: SW Request Attribute Fields Table 4: SW Request Attribute Fields
The SW-PV sends the SW Request attribute to a SW-PC to request the The SW-PV sends the SW Request attribute to a SW-PC to request the
indicated information. Note that between the Result Type flag and indicated information. Note that between the Result Type flag and
the Earliest EID field, the SW-PC is constrained to a single possible the Earliest EID field, the SW-PC is constrained to a single possible
SW Response attribute type (or a PA-TNC Error attribute) in its SW Response attribute type (or a PA-TNC Error attribute) in its
response to the request. response to the request.
The Subscribe and Clear Subscription flags are used to manage The Subscribe and Clear Subscription flags are used to manage
subscriptions for the requesting SW-PV on the receiving SW-PC. subscriptions for the requesting SW-PV on the receiving SW-PC.
Specifically, an attribute with the Subscribe flag set seeks to Specifically, an attribute with the Subscribe flag set seeks to
skipping to change at page 48, line 13 skipping to change at page 49, line 5
other words, do not first create the new subscription and then clear other words, do not first create the new subscription and then clear
all the subscriptions including the one that was just created.) In all the subscriptions including the one that was just created.) In
the case that the requested actions are successfully completed, the the case that the requested actions are successfully completed, the
SW-PC MUST respond with a SW Response attribute. (The specific type SW-PC MUST respond with a SW Response attribute. (The specific type
of SW Response attribute depends on the Result Type and Earliest EID of SW Response attribute depends on the Result Type and Earliest EID
fields, as described above.) In the case where there is a failure fields, as described above.) In the case where there is a failure
that prevents some part this request from completing, the SW-PC MUST that prevents some part this request from completing, the SW-PC MUST
NOT add a new subscription, MUST NOT clear the old subscriptions, and NOT add a new subscription, MUST NOT clear the old subscriptions, and
the SW-PC MUST respond with a PA-TNC Error attribute. In other the SW-PC MUST respond with a PA-TNC Error attribute. In other
words, the SW-PC MUST NOT partially succeed at implementing such a words, the SW-PC MUST NOT partially succeed at implementing such a
request; either both actions succeed, or neither succeed. request; either all actions succeed, or none succeed.
The Earliest EID field is used to indicate whether the SW-PV is The Earliest EID field is used to indicate whether the SW-PV is
requesting an inventory or event list from the SW-PC. A value of 0 requesting an inventory or event list from the SW-PC. A value of 0
(0x00000000) represents a request for inventory information. (0x00000000) represents a request for inventory information.
Otherwise, the SW-PV is requesting event information. For Earliest Otherwise, the SW-PV is requesting event information. For Earliest
EID values other than 0, the SW-PC's response MUST respond with event EID values other than 0, the SW-PC's response MUST respond with event
records, as described in Section 3.5. Note that the request does not records, as described in Section 3.5. Note that the request does not
identify a particular EID Epoch, since responses can only include identify a particular EID Epoch, since responses can only include
events in the SW-PC's current EID Epoch. events in the SW-PC's current EID Epoch.
The Software Identifier Count indicates the number of Software The Software Identifier Count indicates the number of Software
Identifiers in the attribute. This number might be any value between Identifiers in the attribute. This number might be any value between
0 and 16,777,216, inclusive. A single Software Identifier is 0 and 16,777,216, inclusive. A single Software Identifier is
represented by fields: Software Identifier Length and Software ID. represented by the following fields: Software Identifier Length and
The Software Identifier Length field indicates the number of bytes Software ID. These fields are repeated a number of times equal to
allocated to Software ID field. The Software Identifier field the Software Identifier Count. Note that this could be 0 times. The
contains a Software Identifier as describe in Section 3.2. The Software Identifier Length field indicates the number of bytes
allocated to the Software ID field. The Software Identifier field
contains a Software Identifier as describe in Section 3.2.1. The
presence of one or more Software Identifiers is used by the SW-PV to presence of one or more Software Identifiers is used by the SW-PV to
indicate a targeted request, which seeks only inventories of or indicate a targeted request, which seeks only inventories of or
events affecting software corresponding to the given identifiers. events affecting software corresponding to the given identifiers.
The SW-PC MUST only respond with records that match the Software The SW-PC MUST only report software that matched the Software
Identifiers provided in the SW-PVs SW Request attribute. Identifiers provided in the SW-PVs SW Request attribute.
4.10. Software Identifier Inventory 4.8. Software Identifier Inventory
A SW-PC sends this attribute to a SW-PV to convey the inventory of A SW-PC sends this attribute to a SW-PV to convey the inventory of
the endpoint's Software Inventory Evidence Collection expressed using the endpoint's Software Inventory Evidence Collection without the
Software Identifiers. This list might represent a complete inventory inclusion of software inventory evidence records. This list might
or a targeted list of records, depending on the parameters in the SW- represent a complete inventory or a targeted list of records,
PV's request. A SW-PV MUST NOT send this attribute. The SW-PC depending on the parameters in the SW-PV's request. A SW-PV MUST NOT
either sends this attribute in fulfillment of an existing send this attribute. The SW-PC either sends this attribute in
subscription where the establishing request has a Result Type of 1 fulfillment of an existing subscription where the establishing
and the Earliest EID is zero, or in direct response to a SW Request request has a Result Type of 1 and the Earliest EID is zero, or in
attribute where the Result Type is 1 and the Earliest EID is zero. direct response to a SW Request attribute where the Result Type is 1
and the Earliest EID is zero.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count | | Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID | | Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID | | Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data Model Type| Software IdentifierLength |SW ID (var len)| |Data Model Type| Software IdentifierLength |SW ID (var len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record ID Length | Record ID (variable length) | | Software Locator Length | Software Locator (variable len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Software Identifier Inventory Attribute Figure 7: Software Identifier Inventory Attribute
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that this attribute is sent in | | Flags: Bit 0 | In the case that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set | | - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct | | Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SW Request, this bit MUST be unset | | Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). | | | (0). |
| | | | | |
| Flags: Bit | Reserved for future use. This field MUST be set to | | Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. | | 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | | | Reserved | |
| | | | | |
| Software | The number of Software Identifiers that follow. | | Software | The number of Software Identifiers that follow. |
| Identifier | This field is an unsigned integer. The Data Model | | Identifier | This field is an unsigned integer. The Record ID, |
| Count | Type, Software Identifier Length, SW ID, Record ID | | Count | Data Model Type, Software Identifier Length, SW |
| | Length, and Record ID fields are repeated, in | | | ID, Software Locator Length, and Software Locator |
| | order, the number of times indicated in this | | | fields are repeated, in order, the number of times |
| | field. This field value MAY be 0, in which case | | | indicated in this field. This field value MAY be |
| | there are no instances of these fields. | | | 0, in which case there are no instances of these |
| | fields. |
| | | | | |
| Request ID | In the case where this attribute is in direct | | Request ID | In the case where this attribute is in direct |
| Copy / | response to a SW Request attribute from a SW-PV, | | Copy / | response to a SW Request attribute from a SW-PV, |
| Subscription | this field MUST contain an exact copy of the | | Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field from that SW Request. In the | | ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment | | | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain | | | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being | | | the Subscription ID of the subscription being |
| | fulfilled by this attribute. | | | fulfilled by this attribute. |
| | | | | |
| EID Epoch | The EID Epoch of the Last EID value. This field is | | EID Epoch | The EID Epoch of the Last EID value. This field is |
| | an unsigned 4-byte integer. | | | an unsigned 4-byte integer. |
| | | | | |
| Last EID | The EID of the last event recorded by the SW-PC, | | Last EID | The EID of the last event recorded by the SW-PC, |
| | or 0 if the SW-PC has no recorded events. This | | | or 0 if the SW-PC has no recorded events. This |
| | field is an unsigned 4-byte integer. | | | field is an unsigned 4-byte integer. |
| | | | | |
| Record ID | A 4-byte, unsigned integer containing the Record |
| | Identifier value from a software inventory |
| | evidence record. |
| | |
| Data Model | A 1-byte unsigned integer containing an identifier | | Data Model | A 1-byte unsigned integer containing an identifier |
| Type | number from the Software Data Model IANA table | | Type | number from the Software Data Model IANA table |
| | that identifies the data model of the reported | | | that identifies the data model of the reported |
| | record. | | | record. |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length in | | Software | A 2-byte unsigned integer indicating the length in |
| Identifier | bytes of the SW ID field. | | Identifier | bytes of the SW ID field. |
| Length | | | Length | |
| | | | | |
| SW ID | A string containing the Software Identifier value | | SW ID | A string containing the Software Identifier value |
| | from a software inventory evidence record. This | | | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode | | | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.5. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
| | | | | |
| Record ID | A 2-byte unsigned integer indicating the length in | | Software | A 2-byte unsigned integer indicating the length in |
| Length | bytes of the Record ID field. | | Locator | bytes of the Software Locator field. |
| Length | |
| | | | | |
| Record ID | A string containing the Record Identifier value | | Software | A string containing the Software Locator value. |
| | from a software inventory evidence record. This | | Locator | This is expressed as a URI. This field value MUST |
| | field value MUST be normalized to Network Unicode | | | be normalized to Network Unicode format as |
| | format, as described in Section 4.7. This string | | | described in Section 3.2.1.2. This string MUST NOT |
| | MUST NOT be NULL terminated. | | | be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 6: Software Identifier Inventory Attribute Fields Table 5: Software Identifier Inventory Attribute Fields
In the case that this attribute is sent in fulfillment of a In the case that this attribute is sent in fulfillment of a
subscription, the Subscription Fulfillment bit MUST be set (1). In subscription, the Subscription Fulfillment bit MUST be set (1). In
the case that this attribute is sent in direct response to a SW the case that this attribute is sent in direct response to a SW
Request, the Subscription Fulfillment bit MUST be unset (0). Note Request, the Subscription Fulfillment bit MUST be unset (0). Note
that the SW Response attribute sent in direct response to a SW that the SW Response attribute sent in direct response to a SW
Request that establishes a subscription (i.e., a subscription's Request that establishes a subscription (i.e., a subscription's
establishing request) MUST be treated as a direct response to that SW establishing request) MUST be treated as a direct response to that SW
Request (and thus the Subscription Fulfillment bit is unset). SW Request (and thus the Subscription Fulfillment bit is unset). SW
Response attributes are only treated as being in fulfillment of a Response attributes are only treated as being in fulfillment of a
subscription (i.e., Subscription Fulfillment bit set) if they are subscription (i.e., Subscription Fulfillment bit set) if they are
sent following a change event, as shown in Figure 3. sent following a change event, as shown in Figure 3.
The Software Identifier Count field indicates the number of Software The Software Identifier Count field indicates the number of Software
Identifiers present in this inventory. Each Software Identifier is Identifiers present in this inventory. Each Software Identifier is
represented by a set of five fields: Data Model Type, Software represented by the following set of fields: Record ID, Data Model
Identifier Length, SW ID, Record ID Length, and Record ID. These Type, Software Identifier Length, SW ID, Software Locator Length, and
fields will appear once for each reported record. Software Locator. These fields will appear once for each reported
record.
When responding directly to a SW Request attribute, the Request ID When responding directly to a SW Request attribute, the Request ID
Copy / Subscription ID field MUST contain an exact copy of the Copy / Subscription ID field MUST contain an exact copy of the
Request ID field from that SW Request. When this attribute is sent Request ID field from that SW Request. When this attribute is sent
in fulfillment of an existing subscription on this Posture Collector, in fulfillment of an existing subscription on this Posture Collector,
then this field MUST contain the Subscription ID of the fulfilled then this field MUST contain the Subscription ID of the fulfilled
subscription. subscription.
The EID Epoch field indicates the EID Epoch of the Last EID value. The EID Epoch field indicates the EID Epoch of the Last EID value.
The Last EID field MUST contain the EID of the last recorded change The Last EID field MUST contain the EID of the last recorded change
event (see Section 3.5 for more about EIDs and recorded events) at event (see Section 3.5 for more about EIDs and recorded events) at
the time this inventory was collected. In the case where there are the time this inventory was collected. In the case where there are
no recorded change events at the time that this inventory was no recorded change events at the time that this inventory was
collected, this field MUST contain 0. These fields can be collected, the Last EID field MUST contain 0. These fields can be
interpreted to indicate that the provided inventory (be it full or interpreted to indicate that the provided inventory reflects the
targeted) reflects the record of events on the endpoint after all state of the endpoint after all changes up to and including this last
changes up to and including this last event have been accounted for. event have been accounted for.
4.11. Software Identifier Events 4.9. Software Identifier Events
A SW-PC sends this attribute to a SW-PV to convey events where the A SW-PC sends this attribute to a SW-PV to convey events where the
affected records are expressed using Software Identifiers. A SW-PV affected records are reported without software inventory evidence
MUST NOT send this attribute. The SW-PC either sends this attribute records. A SW-PV MUST NOT send this attribute. The SW-PC either
in fulfillment of an existing subscription where the establishing sends this attribute in fulfillment of an existing subscription where
request has a Result Type is 1 and the Earliest EID is non-zero, or the establishing request has a Result Type is 1 and the Earliest EID
in direct response to a SW Request attribute where the Result Type is is non-zero, or in direct response to a SW Request attribute where
1 and the Earliest EID is non-zero. the Result Type is 1 and the Earliest EID is non-zero.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count | | Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID | | Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 52, line 30 skipping to change at page 53, line 30
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |Data Model Type| Software Identifier Length | | Action |Data Model Type| Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SW ID (var len)| Record ID Length |Record ID (var)| | Software Locator Length | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Software Identifier Events Attribute Figure 8: Software Identifier Events Attribute
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that this attribute is sent in | | Flags: Bit 0 | In the case that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set | | - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct | | Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SW Request, this bit MUST be unset | | Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). | | | (0). |
| | | | | |
| Flags: Bit | Reserved for future use. This field MUST be set to | | Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. | | 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | | | Reserved | |
| | | | | |
| Event Count | The number of events that are reported in this | | Event Count | The number of events that are reported in this |
| | attribute. This field is a 3-byte unsigned | | | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Action, Data Model | | | integer. The EID, Timestamp, Record ID, Action, |
| | Type, Software Identifier Length, SW ID, Record ID | | | Data Model Type, Software Identifier Length, |
| | Length, and Record ID fields are repeated, in | | | Software Locator Length, Software Identifier, and |
| | order, the number of times indicated in this | | | Software Locator fields are repeated, in order, |
| | field. (An instance of these fields is referred to | | | the number of times indicated in this field. This |
| | as an "event record" in this attribute. Thus the | | | field value MAY be 0, in which case there are no |
| | Event Count field indicates the number of event | | | instances of these fields. |
| | records.) This field value MAY be 0, in which case |
| | there are no instances of these fields. |
| | | | | |
| Request ID | In the case where this attribute is in direct | | Request ID | In the case where this attribute is in direct |
| Copy / | response to a SW Request attribute from a SW-PV, | | Copy / | response to a SW Request attribute from a SW-PV, |
| Subscription | this field MUST contain an exact copy of the | | Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field from that SW Request. In the | | ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment | | | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain | | | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being | | | the Subscription ID of the subscription being |
| | fulfilled by this attribute. | | | fulfilled by this attribute. |
| | | | | |
skipping to change at page 53, line 37 skipping to change at page 54, line 39
| | or 0 if the SW-PC has no recorded events. This | | | or 0 if the SW-PC has no recorded events. This |
| | field contains the EID of the SW-PC's last | | | field contains the EID of the SW-PC's last |
| | recorded change event (which might or might not be | | | recorded change event (which might or might not be |
| | included as an event record in this attribute). | | | included as an event record in this attribute). |
| | | | | |
| Last | The EID of the last event record that was | | Last | The EID of the last event record that was |
| Consulted | consulted when generating the event record list | | Consulted | consulted when generating the event record list |
| EID | included in this attribute. This is different from | | EID | included in this attribute. This is different from |
| | the Last EID field value if and only if this | | | the Last EID field value if and only if this |
| | attribute is conveying a partial list of event | | | attribute is conveying a partial list of event |
| | records. See Section 3.5.4 for more on partial | | | records. See Section 3.5.5 for more on partial |
| | list of event records. | | | list of event records. |
| | | | | |
| EID | The EID of the event in this event record. | | EID | The EID of the event in this event record. |
| | | | | |
| Timestamp | The timestamp associated with the event in this | | Timestamp | The timestamp associated with the event in this |
| | event record. This timestamps is the SW-PC's best | | | event record. This timestamps is the SW-PC's best |
| | understanding of when the given event occurred. | | | understanding of when the given event occurred. |
| | Note that this timestamp might be an estimate. | | | Note that this timestamp might be an estimate. |
| | The Timestamp date and time MUST be represented as | | | The Timestamp date and time MUST be represented as |
| | an RFC 3339 [5] compliant ASCII string in | | | an RFC 3339 [5] compliant ASCII string in |
skipping to change at page 54, line 12 skipping to change at page 55, line 14
| | the 'Z' suffix MUST be capitalized and fractional | | | the 'Z' suffix MUST be capitalized and fractional |
| | seconds (time-secfrac) MUST NOT be included. This | | | seconds (time-secfrac) MUST NOT be included. This |
| | field conforms to the date-time ABNF production | | | field conforms to the date-time ABNF production |
| | from section 5.6 of RFC 3339 [RFC3339] with the | | | from section 5.6 of RFC 3339 [RFC3339] with the |
| | above restrictions. Leap seconds are permitted | | | above restrictions. Leap seconds are permitted |
| | and SW-PVs MUST support them. The Timestamp | | | and SW-PVs MUST support them. The Timestamp |
| | string MUST NOT be NULL terminated or padded in | | | string MUST NOT be NULL terminated or padded in |
| | any way. The length of this field is always 20 | | | any way. The length of this field is always 20 |
| | octets. | | | octets. |
| | | | | |
| Record ID | A 4-byte, unsigned integer containing the Record |
| | Identifier value from a software inventory |
| | evidence record. |
| | |
| Action | The type of event that is recorded in this event | | Action | The type of event that is recorded in this event |
| | record. Possible values are: 1 = CREATION - the | | | record. Possible values are: 1 = CREATION - the |
| | addition of a record to the endpoint's Software | | | addition of a record to the endpoint's Software |
| | Inventory Evidence Collection; 2 = DELETION - the | | | Inventory Evidence Collection; 2 = DELETION - the |
| | removal of a record from the endpoint's Software | | | removal of a record from the endpoint's Software |
| | Inventory Evidence Collection; 3 = ALTERATION - | | | Inventory Evidence Collection; 3 = ALTERATION - |
| | There was an alteration to a record within the | | | There was an alteration to a record within the |
| | endpoint's Software Inventory Evidence Collection. | | | endpoint's Software Inventory Evidence Collection. |
| | All other values are reserved for future use and | | | All other values are reserved for future use and |
| | MUST NOT be used when sending attributes. In the | | | MUST NOT be used when sending attributes. In the |
skipping to change at page 54, line 34 skipping to change at page 55, line 40
| | here, it MUST ignore that event record but SHOULD | | | here, it MUST ignore that event record but SHOULD |
| | process other event records in this attribute as | | | process other event records in this attribute as |
| | normal. | | | normal. |
| | | | | |
| Data Model | A 1-byte unsigned integer containing an identifier | | Data Model | A 1-byte unsigned integer containing an identifier |
| Type | number from the Software Data Model IANA table | | Type | number from the Software Data Model IANA table |
| | that identifies the data model of the reported | | | that identifies the data model of the reported |
| | record. | | | record. |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length in | | Software | A 2-byte unsigned integer indicating the length in |
| Identifier | bytes of the SW ID field. | | Identifier | bytes of the Software Identifier field. |
| Length | | | Length | |
| | | | | |
| SW ID | A string containing the Software Identifier value | | Software | A 2-byte unsigned integer indicating the length in |
| | from a software inventory evidence record. This | | Locator | bytes of the Software Locator field. |
| | field value MUST be normalized to Network Unicode | | Length | |
| | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. |
| | |
| Record ID | A 2-byte unsigned integer indicating the length in |
| Length | bytes of the Record ID field. |
| | | | | |
| Record ID | A string containing the Record Identifier value | | Software | A string containing the Software Identifier value |
| | from a software inventory evidence record. This | | Identifier | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode | | | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.5. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This is expressed as a URI. This field value MUST |
| | be normalized to Network Unicode format as |
| | described in Section 3.2.1.2. This string MUST NOT |
| | be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 7: Software Identifier Events Attribute Fields
Table 6: Software Identifier Events Attribute Fields
The first few fields in the Software Identifier Events attribute The first few fields in the Software Identifier Events attribute
mirror those in the Software Identifier Inventory attribute. The mirror those in the Software Identifier Inventory attribute. The
primary difference is that, instead of conveying an inventory using primary difference is that, instead of conveying an inventory, the
Software Identifiers, the attribute conveys zero or more event attribute conveys zero or more event records, consisting of the EID,
records, consisting of the EID, timestamp, action type, data model timestamp, Record ID, action type, data model type, Software
type, Software Identifier, and Record Identifier of the affected Identifier, and Software Locator of the affected software inventory
software inventory evidence record. evidence record.
With regard to the Timestamp field, it is important to note that With regard to the Timestamp field, it is important to note that
clock skew between the SW-PC and SW-PV as well as between different clock skew between the SW-PC and SW-PV as well as between different
SW-PCs within an enterprise might make correlation of timestamp SW-PCs within an enterprise might make correlation of timestamp
values difficult. This specification does not attempt to resolve values difficult. This specification does not attempt to resolve
clock skew issues, although other mechanisms outside of this clock skew issues, although other mechanisms outside of this
specification do exist to reduce the impact of clock skew and make specification do exist to reduce the impact of clock skew and make
the timestamp more useful for such correlation. Instead, Software the timestamp more useful for such correlation. Instead, Software
Message and Attributes for PA-TNC uses Timestamp value primarily as a Inventory Message and Attributes for PA-TNC uses Timestamp value
means to indicate the amount of time between two events on a single primarily as a means to indicate the amount of time between two
endpoint. For example, by taking the difference of the times for events on a single endpoint. For example, by taking the difference
when a record was removed and then subsequently re-added, one can get of the times for when a record was removed and then subsequently re-
an indication as to how long the system was without the given record added, one can get an indication as to how long the system was
(and, thus without the associated software). Since this will involve without the given record (and, thus without the associated software).
comparison of timestamp values all originating on the same system, Since this will involve comparison of timestamp values all
clock skew between the SW-PC and SW-PV is not an issue. However, if originating on the same system, clock skew between the SW-PC and SW-
the SW-PC's clock was adjusted between two recorded events, it is PV is not an issue. However, if the SW-PC's clock was adjusted
possible for such a calculation to lead to incorrect understandings between two recorded events, it is possible for such a calculation to
of the temporal distance between events. Users of this field need to lead to incorrect understandings of the temporal distance between
be aware of the possibility for such occurrences. In the case where events. Users of this field need to be aware of the possibility for
the Timestamp values of two events appear to contradict the EID such occurrences. In the case where the Timestamp values of two
ordering of those events (i.e., the later EID has an earlier events appear to contradict the EID ordering of those events (i.e.,
timestamp) the recipient MUST treat the EID ordering as correct. the later EID has an earlier timestamp) the recipient MUST treat the
EID ordering as correct.
All event records in a Software Identifier Events Attribute are All events recorded in a Software Identifier Events Attribute are
required to be part of the same EID Epoch. Specifically, all required to be part of the same EID Epoch. Specifically, all
reported events MUST have an EID from the same EID Epoch as each reported events MUST have an EID from the same EID Epoch as each
other, and which is the same as the EID Epoch of the Last EID and other, and which is the same as the EID Epoch of the Last EID and
Last Consulted EID values. The SW-PC MUST NOT report events with Last Consulted EID values. The SW-PC MUST NOT report events with
EIDs from different EID Epochs. EIDs from different EID Epochs.
The Last Consulted EID field contains the EID of the last event The Last Consulted EID field contains the EID of the last event
record considered for inclusion in this attribute. If this attribute record considered for inclusion in this attribute. If this attribute
contains a partial event set (as described in Section 3.5.4) this contains a partial event set (as described in Section 3.5.5) this
field value will differ from that of the Last EID field; if this field value will be less than the Last EID value; if this attribute
attribute contains a complete event set, the Last EID and Last contains a complete event set, the Last EID and Last Consulted EID
Consulted EID values are identical. values are identical.
If multiple events are sent in a Software Identifier Events If multiple events are sent in a Software Identifier Events
attribute, the order in which they appear within the attribute is not attribute, the order in which they appear within the attribute is not
significant. The EIDs associated with them are used for ordering the significant. The EIDs associated with them are used for ordering the
indicated events appropriately. Also note that a single Software indicated events appropriately. Also note that a single software
Identifier might appear multiple times in an attribute, such as if record might be reported multiple times in an attribute, such as if
multiple events involving the associated record were being reported. multiple events involving the associated record were being reported.
4.12. Software Inventory 4.10. Software Inventory
A SW-PC sends this attribute to a SW-PV to convey a list of inventory A SW-PC sends this attribute to a SW-PV to convey a list of inventory
records. A SW-PV MUST NOT send this attribute. The SW-PC either records. A SW-PV MUST NOT send this attribute. The SW-PC either
sends this attribute in fulfillment of an existing subscription where sends this attribute in fulfillment of an existing subscription where
the establishing request had a Result Type of 0 and the Earliest EID the establishing request had a Result Type of 0 and the Earliest EID
is zero, or in direct response to a SW Request attribute where the is zero, or in direct response to a SW Request attribute where the
Result Type is 0 and the Earliest EID is zero. Result Type is 0 and the Earliest EID is zero.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Record Count | | Flags | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID | | Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID | | Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data Model Type| Record ID Length |Record ID (var)| | Record ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Locator Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length | | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (Variable) | |Data Model Type| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator (Variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (Variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Software Inventory Attribute Figure 9: Software Inventory Attribute
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that this attribute is sent in | | Flags: Bit 0 | In the case that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set | | - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct | | Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SW Request, this bit MUST be unset | | Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). | | | (0). |
| | | | | |
| Flags: Bit | Reserved for future use. This field MUST be set to | | Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. | | 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | | | Reserved | |
| | | | | |
| Record Count | The number of records that follow. This field is a | | Record Count | The number of records that follow. This field is a |
| | 3-byte unsigned integer. The Data Model Type, | | | 3-byte unsigned integer. The Record ID, Software |
| | Record Identifier Length, Record ID, Record | | | Identifier Length, Software Locator Length, Record |
| | Length, and Record fields are repeated, in order, | | | Length, Data Model Type, Software Identifier, |
| | the number of times indicated in this field. This | | | Software Locator, and Record fields are repeated, |
| | field value MAY be 0 in which case there are no | | | in order, the number of times indicated in this |
| | instances of these fields. | | | field. This field value MAY be 0 in which case |
| | there are no instances of these fields. |
| | | | | |
| Request ID | In the case where this attribute is in direct | | Request ID | In the case where this attribute is in direct |
| Copy / | response to a SW Request attribute from a SW-PV, | | Copy / | response to a SW Request attribute from a SW-PV, |
| Subscription | this field MUST contain an exact copy of the | | Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field from that SW Request. In the | | ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment | | | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain | | | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being | | | the Subscription ID of the subscription being |
| | fulfilled by this attribute. | | | fulfilled by this attribute. |
| | | | | |
| EID Epoch | The EID Epoch of the Last EID value. This field is | | EID Epoch | The EID Epoch of the Last EID value. This field is |
| | an unsigned 4-byte integer. | | | an unsigned 4-byte integer. |
| | | | | |
| Last EID | The EID of the last event recorded by the SW-PC, | | Last EID | The EID of the last event recorded by the SW-PC, |
| | or 0 if the SW-PC has no recorded events. This | | | or 0 if the SW-PC has no recorded events. This |
| | field is an unsigned 4-byte integer. | | | field is an unsigned 4-byte integer. |
| | | | | |
| Record ID | A 4-byte, unsigned integer containing the Record |
| | Identifier value from a software inventory |
| | evidence record. |
| | |
| Software | A 2-byte unsigned integer indicating the length in |
| Identifier | bytes of the Software Identifier field. |
| Length | |
| | |
| Software | A 2-byte unsigned integer indicating the length in |
| Locator | bytes of the Software Locator field. |
| Length | |
| | |
| Record Len | This is a 4-byte unsigned integer indicating the |
| | length of the Record field in bytes. |
| | |
| Data Model | A 1-byte unsigned integer containing an identifier | | Data Model | A 1-byte unsigned integer containing an identifier |
| Type | number from the Software Data Model IANA table | | Type | number from the Software Data Model IANA table |
| | that identifies the data model of the reported | | | that identifies the data model of the reported |
| | record. | | | record. |
| | | | | |
| Record ID | A 2-byte unsigned integer indicating the length in | | Software | A string containing the Software Identifier value |
| Length | bytes of the Record ID field. | | Identifier | from a software inventory evidence record. This |
| | |
| Record ID | A string containing the Record Identifier value |
| | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode | | | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.5. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
| | | | | |
| Record Len | This is a 4-byte unsigned integer indicating the | | Software | A string containing the Software Locator value. |
| | length of the following software inventory | | Locator | This is expressed as a URI. This field value MUST |
| | evidence record in bytes. | | | be normalized to Network Unicode format as |
| | described in Section 3.2.1.2. This string MUST NOT |
| | be NULL terminated. |
| | | | | |
| Record | A software inventory evidence record as a string. | | Record | A software inventory evidence record as a string. |
| | The record MUST be converted and normalized to | | | The record MUST be converted and normalized to |
| | Network Unicode format, as described in Section | | | Network Unicode format, as described in Section |
| | 4.7. This string MUST NOT be NULL terminated. | | | 4.5. This string MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 8: Software Inventory Attribute Fields Table 7: Software Inventory Attribute Fields
The Software Inventory attribute contains some number of software The Software Inventory attribute contains some number of software
inventory evidence records. Given that the size of records can vary inventory evidence records along with the core response attribute
considerably, the length of this attribute is highly variable and, if fields. Given that the size of records can vary considerably, the
transmitting a complete inventory, can be extremely large. length of this attribute is highly variable and, if transmitting a
Enterprises might wish to constrain the use of Software Inventory complete inventory, can be extremely large. Enterprises might wish
attributes to targeted requests to avoid over-burdening the network to constrain the use of Software Inventory attributes to targeted
unnecessarily. requests to avoid over-burdening the network unnecessarily.
When copying a software inventory evidence record into the Record When copying a software inventory evidence record into the Record
field, the record MUST be converted and normalized to use Network field, the record MUST be converted and normalized to use Network
Unicode format prior to its inclusion in the record field. Unicode format prior to its inclusion in the record field.
4.13. Software Events 4.11. Software Events
A SW-PC sends this attribute to a SW-PV to convey a list of events A SW-PC sends this attribute to a SW-PV to convey a list of events
where the affected software inventory evidence records are expressed that include software inventory evidence records. A SW-PV MUST NOT
using full records. A SW-PV MUST NOT send this attribute. The SW-PC send this attribute. The SW-PC either sends this attribute in
either sends this attribute in fulfillment of an existing fulfillment of an existing subscription where the establishing
subscription where the establishing request has a Result Type of 0 request has a Result Type of 0 and the Earliest EID is non-zero, or
and the Earliest EID is non-zero, or in direct response to a SW in direct response to a SW Request attribute where the Result Type is
Request attribute where the Result Type is 0 and the Earliest EID is 0 and the Earliest EID is non-zero.
non-zero.
Note that each record is reported along with its Record Identifier.
This can be used to link reported records to reported Software
Identifier + Record Identifier pairs.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count | | Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID | | Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 59, line 30 skipping to change at page 61, line 30
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |Data Model Type| Record ID Length | | Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier (Variable Length) | | Software Identifier Length | Software Locator Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Len | | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |Data Model Type| Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (Variable Length) | | Record (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Software Events Attribute Figure 10: Software Events Attribute
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that this attribute is sent in | | Flags: Bit 0 | In the case that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set | | - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct | | Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SW Request, this bit MUST be unset | | Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). | | | (0). |
| | | | | |
| Flags: Bit | Reserved for future use. This field MUST be set to | | Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. | | 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | | | Reserved | |
| | | | | |
| Event Count | The number of events being reported in this | | Event Count | The number of events being reported in this |
| | attribute. This field is a 3-byte unsigned | | | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Action, Data Model | | | integer. The EID, Timestamp, Record Identifier, |
| | Type, Record Identifier Length, Record Identifier, | | | Software Identifier Length, Software Locator |
| | Record Length, and Record fields are repeated, in | | | Length, Record Length, Action, Data Model Type, |
| | order, the number of times indicated in this | | | Software Identifier, Software Locator, and Record |
| | field. (An instance of these fields is referred to | | | fields are repeated, in order, the number of times |
| | as an "event record" in this attribute. Thus the | | | indicated in this field. This field value MAY be |
| | Event Count field indicates the number of event | | | 0, in which case there are no instances of these |
| | records.) This field value MAY be 0, in which case | | | fields. |
| | there are no instances of these fields. |
| | | | | |
| Request ID | In the case where this attribute is in direct | | Request ID | In the case where this attribute is in direct |
| Copy / | response to a SW Request attribute from a SW-PV, | | Copy / | response to a SW Request attribute from a SW-PV, |
| Subscription | this field MUST contain an exact copy of the | | Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field from that SW Request. In the | | ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment | | | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain | | | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being | | | the Subscription ID of the subscription being |
| | fulfilled by this attribute. | | | fulfilled by this attribute. |
| | | | | |
skipping to change at page 60, line 41 skipping to change at page 62, line 44
| | or 0 if the SW-PC has no recorded events. This | | | or 0 if the SW-PC has no recorded events. This |
| | field contains the EID of the SW-PC's last | | | field contains the EID of the SW-PC's last |
| | recorded change event (which might or might not be | | | recorded change event (which might or might not be |
| | included as an event record in this attribute). | | | included as an event record in this attribute). |
| | | | | |
| Last | The EID of the last event record that was | | Last | The EID of the last event record that was |
| Consulted | consulted when generating the event record list | | Consulted | consulted when generating the event record list |
| EID | included in this attribute. This is different from | | EID | included in this attribute. This is different from |
| | the Last EID field value if and only if this | | | the Last EID field value if and only if this |
| | attribute is conveying a partial list of event | | | attribute is conveying a partial list of event |
| | records. See Section 3.5.4 for more on partial | | | records. See Section 3.5.5 for more on partial |
| | list of event records. | | | list of event records. |
| | | | | |
| EID | The EID of the event in this event record. | | EID | The EID of the event in this event record. |
| | | | | |
| Timestamp | The timestamp associated with the event in this | | Timestamp | The timestamp associated with the event in this |
| | event record. This timestamp is the SW-PC's best | | | event record. This timestamp is the SW-PC's best |
| | understanding of when the given event occurred. | | | understanding of when the given event occurred. |
| | Note that this timestamp might be an estimate. | | | Note that this timestamp might be an estimate. |
| | The Timestamp date and time MUST be represented as | | | The Timestamp date and time MUST be represented as |
| | an RFC 3339 [5] compliant ASCII string in | | | an RFC 3339 [5] compliant ASCII string in |
skipping to change at page 61, line 16 skipping to change at page 63, line 19
| | the 'Z' suffix MUST be capitalized and fractional | | | the 'Z' suffix MUST be capitalized and fractional |
| | seconds (time-secfrac) MUST NOT be included. This | | | seconds (time-secfrac) MUST NOT be included. This |
| | field conforms to the date-time ABNF production | | | field conforms to the date-time ABNF production |
| | from section 5.6 of RFC 3339 [RFC3339] with the | | | from section 5.6 of RFC 3339 [RFC3339] with the |
| | above restrictions. Leap seconds are permitted | | | above restrictions. Leap seconds are permitted |
| | and SW-PVs MUST support them. The Timestamp | | | and SW-PVs MUST support them. The Timestamp |
| | string MUST NOT be NULL terminated or padded in | | | string MUST NOT be NULL terminated or padded in |
| | any way. The length of this field is always 20 | | | any way. The length of this field is always 20 |
| | octets. | | | octets. |
| | | | | |
| Record | A 4-byte, unsigned integer containing the Record |
| Identifier | Identifier value from a software inventory |
| | evidence record. |
| | |
| Software | A 2-byte unsigned integer indicating the length in |
| Identifier | bytes of the Software Identifier field. |
| Length | |
| | |
| Software | A 2-byte unsigned integer indicating the length in |
| Locator | bytes of the Software Locator field. |
| Length | |
| | |
| Record Len | This is a 4-byte unsigned integer indicating the |
| | length of the Record field in bytes. |
| | |
| Action | The type of event that is recorded in this event | | Action | The type of event that is recorded in this event |
| | record. Possible values are: 1 = CREATION - the | | | record. Possible values are: 1 = CREATION - the |
| | addition of a record to the endpoint's Software | | | addition of a record to the endpoint's Software |
| | Inventory Evidence Collection; 2 = DELETION - the | | | Inventory Evidence Collection; 2 = DELETION - the |
| | removal of a record from the endpoint's Software | | | removal of a record from the endpoint's Software |
| | Inventory Evidence Collection; 3 = ALTERATION - | | | Inventory Evidence Collection; 3 = ALTERATION - |
| | There was an alteration to a record within the | | | There was an alteration to a record within the |
| | endpoint's Software Inventory Evidence Collection. | | | endpoint's Software Inventory Evidence Collection. |
| | All other values are reserved for future use and | | | All other values are reserved for future use and |
| | MUST NOT be used when sending attributes. In the | | | MUST NOT be used when sending attributes. In the |
skipping to change at page 61, line 37 skipping to change at page 64, line 7
| | uses an action value other than the ones defined | | | uses an action value other than the ones defined |
| | here, it MUST ignore that event record but SHOULD | | | here, it MUST ignore that event record but SHOULD |
| | process other event records in this attribute as | | | process other event records in this attribute as |
| | normal. | | | normal. |
| | | | | |
| Data Model | A 1-byte unsigned integer containing an identifier | | Data Model | A 1-byte unsigned integer containing an identifier |
| Type | number from the Software Data Model IANA table | | Type | number from the Software Data Model IANA table |
| | that identifies the data model of the reported | | | that identifies the data model of the reported |
| | record. | | | record. |
| | | | | |
| Record ID | A 2-byte unsigned integer indicating the length in | | Software | A string containing the Software Identifier value |
| Length | bytes of the Record ID field. | | Identifier | from a software inventory evidence record. This |
| | |
| Record ID | A string containing the Record Identifier value |
| | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode | | | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.5. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
| | | | | |
| Record Len | This is a 4-byte unsigned integer indicating the | | Software | A string containing the Software Locator value. |
| | length of the following record in bytes. | | Locator | This is expressed as a URI. This field value MUST |
| | be normalized to Network Unicode format as |
| | described in Section 3.2.1.2. This string MUST NOT |
| | be NULL terminated. |
| | | | | |
| Record | A software inventory evidence record as a string. | | Record | A software inventory evidence record as a string. |
| | The record MUST be converted and normalized to | | | The record MUST be converted and normalized to |
| | Network Unicode format, as described in Section | | | Network Unicode format, as described in Section |
| | 4.7. This string MUST NOT be NULL terminated. | | | 4.5. This string MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 9: Software Events Attribute Fields Table 8: Software Events Attribute Fields
The fields of this attribute are used in the same way as the The fields of this attribute are used in the same way as the
corresponding fields of the previous attributes. As with the corresponding fields of the previous attributes. As with the
Software Inventory attribute, a Software Events attribute can be Software Inventory attribute, a Software Events attribute can be
quite large if many events have occurred following the event quite large if many events have occurred following the event
indicated by a request's Earliest EID. As such, it is recommended indicated by a request's Earliest EID. As such, it is recommended
that the SW Request attributes only request full records be sent that the SW Request attributes only request full records be sent
(Result Type set to 0) in a targeted request, thus constraining the (Result Type set to 0) in a targeted request, thus constraining the
response just to records that match a given set of Software response just to records that match a given set of Software
Identifiers. Identifiers.
As with the Software Identifier Events Attribute, this attribute MUST As with the Software Identifier Events Attribute, this attribute MUST
only contain event records with EIDs coming from the current EID only contain event records with EIDs coming from the current EID
Epoch of the SW-PC. Epoch of the SW-PC.
As with the Software Inventory Attribute, the SW-PC MUST perform As with the Software Inventory Attribute, the SW-PC MUST perform
conversion and normalization of the record. conversion and normalization of the record.
4.14. Subscription Status Request 4.12. Subscription Status Request
A SW-PV sends this attribute to a SW-PC to request a list of active A SW-PV sends this attribute to a SW-PC to request a list of active
subscriptions for which the requesting SW-PV is the subscriber. A subscriptions for which the requesting SW-PV is the subscriber. A
SW-PC MUST NOT send this attribute. SW-PC MUST NOT send this attribute.
This attribute has no fields. This attribute has no fields.
A SW-PC MUST respond to this attribute by sending a Subscription A SW-PC MUST respond to this attribute by sending a Subscription
Status Response attribute (or a PA-TNC Error attribute if it is Status Response attribute (or a PA-TNC Error attribute if it is
unable to correctly provide a response). unable to correctly provide a response).
4.15. Subscription Status Response 4.13. Subscription Status Response
A SW-PC sends this attribute to a SW-PV to report the list of active A SW-PC sends this attribute to a SW-PV to report the list of active
subscriptions for which the receiving SW-PV is the subscriber. A SW- subscriptions for which the receiving SW-PV is the subscriber. A SW-
PV MUST NOT send this attribute. PV MUST NOT send this attribute.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Flags | Subscription Record Count | | Status Flags | Subscription Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count | | Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID | | Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software ID (var length) | | Software Identifier Length | Software ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Subscription Status Response Attribute Figure 11: Subscription Status Response Attribute
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Field | Description | | Field | Description |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Flags: Bit 0-7 | Reserved for future use. This field MUST be set | | Flags: Bit 0-7 | Reserved for future use. This field MUST be set |
| - Reserved | to zero on transmission and ignored upon | | - Reserved | to zero on transmission and ignored upon |
| | reception. | | | reception. |
| | | | | |
| Subscription | The number of subscription records that follow. | | Subscription | The number of subscription records that follow. |
| Record Count | This field is a 3-byte unsigned integer. The | | Record Count | This field is a 3-byte unsigned integer. The |
skipping to change at page 63, line 47 skipping to change at page 66, line 31
| Flags, Software | For each active subscription, these fields | | Flags, Software | For each active subscription, these fields |
| Identifier | contain an exact copy of the fields with the | | Identifier | contain an exact copy of the fields with the |
| Count, Request | same name as provided in the subscription's | | Count, Request | same name as provided in the subscription's |
| ID, Earliest | establishing request. | | ID, Earliest | establishing request. |
| EID, Software | | | EID, Software | |
| Identifier | | | Identifier | |
| Length, and | | | Length, and | |
| Software ID | | | Software ID | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
Table 10: Subscription Status Response Fields Table 9: Subscription Status Response Fields
A Subscription Status Response contains zero or more subscription A Subscription Status Response contains zero or more subscription
records. Specifically, it MUST contain one subscription record for records. Specifically, it MUST contain one subscription record for
each active subscription associated with the party that sent the each active subscription associated with the party that sent the
Subscription Status Request to which this attribute is a response. Subscription Status Request to which this attribute is a response.
As described in Section 3.6.2, the SW-PC MUST use the requester's As described in Section 3.6.2, the SW-PC MUST use the requester's
Connection ID and its Posture Validator ID to determine which Connection ID and its Posture Validator ID to determine which
subscriptions are associated with the requester. subscriptions are associated with the requester.
A SW-PC MUST send a Subscription Status Response attribute in A SW-PC MUST send a Subscription Status Response attribute in
skipping to change at page 64, line 27 skipping to change at page 67, line 12
Flags field, a Subscription Record Count field with a value of 0, and Flags field, a Subscription Record Count field with a value of 0, and
no additional fields. no additional fields.
Each subscription record included in a Subscription Status Response Each subscription record included in a Subscription Status Response
attribute duplicates the fields of a SW Request attribute that was attribute duplicates the fields of a SW Request attribute that was
the establishing request of a subscription. Note that the Request ID the establishing request of a subscription. Note that the Request ID
field in the record captures the Subscription ID associated with the field in the record captures the Subscription ID associated with the
given subscription record (since the Subscription ID is the same as given subscription record (since the Subscription ID is the same as
the Request ID of the establishing request). Note also that if the the Request ID of the establishing request). Note also that if the
establishing request is targeted, then its Record Count field will be establishing request is targeted, then its Record Count field will be
non-zero and, within that subscription record, the Record Namespace non-zero and, within that subscription record, the Software
Length, Record Namespace, Record ID Length, and Record ID fields are Identifier Length and Software Identifier fields are repeated, in
repeated, in order, the number of times indicated in the Record Count order, the number of times indicated in the Record Count field. As
field. As such, each subscription record can be different sizes. If such, each subscription record can be different sizes. If the
the establishing request is not targeted (Record Count field is 0), establishing request is not targeted (Record Count field is 0), the
the subscription record has no Record Namespace Length, Record subscription record has no Software Identifier Length or Software
Namespace, Record ID Length, or Record ID fields. Identifier fields.
When a SW-PV compares the information received in a Subscription When a SW-PV compares the information received in a Subscription
Status Response to its own records of active subscriptions it should Status Response to its own records of active subscriptions it should
be aware that the SW-PC might be unable to distinguish this SW-PV be aware that the SW-PC might be unable to distinguish this SW-PV
from other SW-PVs on the same NEA Server. As a result, it is from other SW-PVs on the same NEA Server. As a result, it is
possible that the SW-PC will report more subscription records than possible that the SW-PC will report more subscription records than
the SW-PV recognizes. For this reason, SW-PVs SHOULD NOT the SW-PV recognizes. For this reason, SW-PVs SHOULD NOT
automatically assume that extra subscriptions reported in a automatically assume that extra subscriptions reported in a
Subscription Status Response indicate a problem. Subscription Status Response indicate a problem.
4.16. PA-TNC Error as Used by Software Message and Attributes for PA- 4.14. PA-TNC Error as Used by Software Inventory Message and Attributes
TNC for PA-TNC
The PA-TNC Error attribute is defined in the PA-TNC specification The PA-TNC Error attribute is defined in the PA-TNC specification
[RFC5792], and its use here conforms to that specification. A PA-TNC [RFC5792], and its use here conforms to that specification. A PA-TNC
Error can be sent due to any error in the PA-TNC exchange and might Error can be sent due to any error in the PA-TNC exchange and might
also be sent in response to error conditions specific to the Software also be sent in response to error conditions specific to the Software
Message and Attributes for PA-TNC exchange. The latter case utilizes Inventory Message and Attributes for PA-TNC exchange. The latter
error codes defined below. case utilizes error codes defined below.
A PA-TNC Error attribute is sent instead of a SW Response attribute A PA-TNC Error attribute is sent instead of a SW Response attribute
due to factors that prevent the reliable creation of a SW Response. due to factors that prevent the reliable creation of a SW Response.
As such, a SW-PC MUST NOT send both a PA-TNC Error attribute and a SW As such, a SW-PC MUST NOT send both a PA-TNC Error attribute and a SW
Response attribute in response to a single SW Request attribute. Response attribute in response to a single SW Request attribute.
Table 11 lists the Error Code values for the PA-TNC Error attribute Table 10 lists the Error Code values for the PA-TNC Error attribute
specific to the Software Message and Attributes for PA-TNC exchange. specific to the Software Inventory Message and Attributes for PA-TNC
In all of these cases, the Error Code Vendor ID field MUST be set to exchange. In all of these cases, the Error Code Vendor ID field MUST
0x000000, corresponding to the IETF SMI Private Enterprise Number. be set to 0x000000, corresponding to the IETF SMI Private Enterprise
The Error Information structures for each error type are described in Number. The Error Information structures for each error type are
the following subsections. described in the following subsections.
Note that a message with a Software Message and Attributes for PA-TNC Note that a message with a Software Inventory Message and Attributes
attribute might also result in an error condition covered by the for PA-TNC attribute might also result in an error condition covered
Standard PA-TNC Error Codes defined in PA-TNC. For example, a SW by the Standard PA-TNC Error Codes defined in PA-TNC. For example, a
Attribute might have an invalid parameter, leading to an error code SW Attribute might have an invalid parameter, leading to an error
of "Invalid Parameter". In this case, the SW-PC MUST use the code of "Invalid Parameter". In this case, the SW-PC MUST use the
appropriate PA-TNC Error Code value as defined in Section 4.2.8 of appropriate PA-TNC Error Code value as defined in Section 4.2.8 of
PA-TNC specification. PA-TNC specification.
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Error Code Value | Description | | Error Code Value | Description |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| 0x00000020 | SW_ERROR. This indicates a fatal error | | 0x00000020 | SW_ERROR. This indicates a fatal error |
| | (i.e., an error that precludes the | | | (i.e., an error that precludes the |
| | creation of a suitable response | | | creation of a suitable response |
| | attribute) other than the errors | | | attribute) other than the errors |
skipping to change at page 65, line 51 skipping to change at page 68, line 34
| | PV's request to establish a subscription. | | | PV's request to establish a subscription. |
| | The Description field SHOULD contain | | | The Description field SHOULD contain |
| | additional diagnostic information. | | | additional diagnostic information. |
| | | | | |
| 0x00000022 | SW_RESPONSE_TOO_LARGE_ERROR. This | | 0x00000022 | SW_RESPONSE_TOO_LARGE_ERROR. This |
| | indicates that the SW-PC's response to | | | indicates that the SW-PC's response to |
| | the SW-PV's request was too large to be | | | the SW-PV's request was too large to be |
| | serviced. The error information structure | | | serviced. The error information structure |
| | indicates the largest possible size of a | | | indicates the largest possible size of a |
| | response supported by the SW-PC (see | | | response supported by the SW-PC (see |
| | Section 4.16.2). The Description field | | | Section 4.14.2). The Description field |
| | SHOULD contain additional diagnostic | | | SHOULD contain additional diagnostic |
| | information. | | | information. |
| | | | | |
| 0x00000023 | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This | | 0x00000023 | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This |
| | indicates that the SW-PC experienced an | | | indicates that the SW-PC experienced an |
| | error fulfilling a given subscription. | | | error fulfilling a given subscription. |
| | The error information includes the | | | The error information includes the |
| | Subscription ID of the relevant | | | Subscription ID of the relevant |
| | subscription, as well as a sub-error that | | | subscription, as well as a sub-error that |
| | describes the nature of the error the SW- | | | describes the nature of the error the SW- |
skipping to change at page 66, line 29 skipping to change at page 69, line 12
| | indicates that the SW-PC received a SW | | | indicates that the SW-PC received a SW |
| | Request from a given SW-PV where the | | | Request from a given SW-PV where the |
| | Request ID of that SW Request is | | | Request ID of that SW Request is |
| | currently used as the Subscription ID of | | | currently used as the Subscription ID of |
| | an active subscription with that SW-PV. | | | an active subscription with that SW-PV. |
| | This error does not cancel the identified | | | This error does not cancel the identified |
| | subscription. | | | subscription. |
| | | | | |
| 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved | | 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved |
| | for use by future revisions of the | | | for use by future revisions of the |
| | Software Message and Attributes for PA- | | | Software Inventory Message and Attributes |
| | TNC specification. Any PA-TNC Error | | | for PA-TNC specification. Any PA-TNC |
| | attribute using one of these Error Codes | | | Error attribute using one of these Error |
| | MUST be treated as indicating a fatal | | | Codes MUST be treated as indicating a |
| | error on the sender without further | | | fatal error on the sender without further |
| | interpretation. | | | interpretation. |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
Table 11: PA-TNC Error Codes for Software Message and Attributes for Table 10: PA-TNC Error Codes for Software Inventory Message and
PA-TNC Attributes for PA-TNC
The following subsections describe the structures present in the The following subsections describe the structures present in the
Error Information fields. Error Information fields.
4.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and 4.14.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and
SW_SUBSCRIPTION_ID_REUSE_ERROR Information SW_SUBSCRIPTION_ID_REUSE_ERROR Information
The SW_ERROR error code indicates that the sender (the SW-PC) has The SW_ERROR error code indicates that the sender (the SW-PC) has
encountered an error related to the processing of a SW Request encountered an error related to the processing of a SW Request
attribute but which is not covered by more specific SW error codes. attribute but which is not covered by more specific SW error codes.
The SW_SUBSCRIPTION_DENIED_ERROR is used when the SW-PV requests to The SW_SUBSCRIPTION_DENIED_ERROR is used when the SW-PV requests to
establish a subscription or clear all subscriptions from the given establish a subscription or clear all subscriptions from the given
SW-PV, but the SW-PC is unable or unwilling to comply with this SW-PV, but the SW-PC is unable or unwilling to comply with this
request. The SW_SUBSCRIPTION_ID_REUSE_ERROR is used when the SW-PC request. The SW_SUBSCRIPTION_ID_REUSE_ERROR is used when the SW-PC
receives a SW Request whose Request ID duplicates a Subscription ID receives a SW Request whose Request ID duplicates a Subscription ID
skipping to change at page 67, line 17 skipping to change at page 69, line 48
error codes use the following error information structure. error codes use the following error information structure.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID | | Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) | | Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: SW Error, Subscription Error, and Subscription ID Reuse Figure 12: SW Error, Subscription Error, and Subscription ID Reuse
Information Information
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Copy of | In the case that this error condition is generated | | Copy of | In the case that this error condition is generated |
| Request ID / | in direct response to a SW Request attribute, this | | Request ID / | in direct response to a SW Request attribute, this |
| Subscription | field MUST contain an exact copy of the Request ID | | Subscription | field MUST contain an exact copy of the Request ID |
| ID | field in the SW Request attribute that caused this | | ID | field in the SW Request attribute that caused this |
| | error. In the case that the attribute in question | | | error. In the case that the attribute in question |
| | is generated in fulfillment of an active | | | is generated in fulfillment of an active |
| | subscription, this field MUST contain the | | | subscription, this field MUST contain the |
| | Subscription ID of the subscription for which the | | | Subscription ID of the subscription for which the |
| | attribute was generated. (This is only possible | | | attribute was generated. (This is only possible |
| | if the error code is SW_ERROR as the other errors | | | if the error code is SW_ERROR as the other errors |
| | are not generated by subscription fulfillment.) | | | are not generated by subscription fulfillment.) |
| | Note that, in this case, the indicated error | | | Note that, in this case, the indicated error |
| | appears as a sub-error for a | | | appears as a sub-error for a |
| | SW_SUBSCRIPTION_FULFILLMENT_ERROR, as described in | | | SW_SUBSCRIPTION_FULFILLMENT_ERROR, as described in |
| | Section 4.16.3. | | | Section 4.14.3. |
| | | | | |
| Description | A UTF-8 string describing the condition that | | Description | A UTF-8 string describing the condition that |
| | caused this error. This field MAY be 0-length. | | | caused this error. This field MAY be 0-length. |
| | However, senders SHOULD include some description | | | However, senders SHOULD include some description |
| | in all PA-TNC Error attributes of these types. | | | in all PA-TNC Error attributes of these types. |
| | This field MUST NOT be NULL terminated. | | | This field MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 12: SW Error, Subscription Error, and Subscription ID Reuse Table 11: SW Error, Subscription Error, and Subscription ID Reuse
Information Fields Information Fields
This error information structure is used with SW_ERROR, This error information structure is used with SW_ERROR,
SW_SUBSCRIPTION_DENIED_ERROR, and SW_SUBSCRIPTION_ID_REUSE_ERROR SW_SUBSCRIPTION_DENIED_ERROR, and SW_SUBSCRIPTION_ID_REUSE_ERROR
status codes to identify the SW Request attribute that precipitated status codes to identify the SW Request attribute that precipitated
the error condition and to describe the error. The Description field the error condition and to describe the error. The Description field
contains text describing the error. The SW-PC MAY encode machine- contains text describing the error. The SW-PC MAY encode machine-
interpretable information in this field, but SHOULD also include a interpretable information in this field, but SHOULD also include a
human-readable description of the error, since the receiving SW-PV human-readable description of the error, since the receiving SW-PV
might not recognize the SW-PC's encoded information. might not recognize the SW-PC's encoded information.
4.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information 4.14.2. SW_RESPONSE_TOO_LARGE_ERROR Information
The SW_RESPONSE_TOO_LARGE_ERROR error code indicates that a response The SW_RESPONSE_TOO_LARGE_ERROR error code indicates that a response
generated by a SW-PC in response to a SW-PV's SW Request attribute generated by a SW-PC in response to a SW-PV's SW Request attribute
was too large to send. was too large to send.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription I | | Copy of Request ID / Subscription I |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Allowed Size | | Maximum Allowed Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) | | Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SW Response Too Large Error Information Figure 13: SW Response Too Large Error Information
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Copy of | In the case that the attribute in question is | | Copy of | In the case that the attribute in question is |
| Request ID / | generated in direct response to a SW Request, this | | Request ID / | generated in direct response to a SW Request, this |
| Subscription | field MUST contain an exact copy of the Request ID | | Subscription | field MUST contain an exact copy of the Request ID |
| ID | field in the SW Request attribute that caused this | | ID | field in the SW Request attribute that caused this |
| | error. In the case that the attribute in question | | | error. In the case that the attribute in question |
| | is generated in fulfillment of an active | | | is generated in fulfillment of an active |
| | subscription, this field MUST contain the | | | subscription, this field MUST contain the |
| | Subscription ID of the subscription for which the | | | Subscription ID of the subscription for which the |
| | attribute was generated. Note that, in the latter | | | attribute was generated. Note that, in the latter |
| | case, the SW_RESPONSE_TOO_LARGE_ERROR appears as a | | | case, the SW_RESPONSE_TOO_LARGE_ERROR appears as a |
| | sub-error for a SW_SUBSCRIPTION_FULFILLMENT_ERROR, | | | sub-error for a SW_SUBSCRIPTION_FULFILLMENT_ERROR, |
| | as described in Section 4.16.3. | | | as described in Section 4.14.3. |
| | | | | |
| Maximum | This field MUST contain an unsigned integer | | Maximum | This field MUST contain an unsigned integer |
| Allowed Size | indicating the largest permissible size, in bytes, | | Allowed Size | indicating the largest permissible size, in bytes, |
| | of SW Attribute that the SW-PC is currently | | | of SW Attribute that the SW-PC is currently |
| | willing to send in response to a SW Request | | | willing to send in response to a SW Request |
| | attribute. | | | attribute. |
| | | | | |
| Description | A UTF-8 string describing the condition that | | Description | A UTF-8 string describing the condition that |
| | caused this error. This field MAY be 0-length. | | | caused this error. This field MAY be 0-length. |
| | However, senders SHOULD include some description | | | However, senders SHOULD include some description |
| | in all PA-TNC Error attributes of these types. | | | in all PA-TNC Error attributes of these types. |
| | This field MUST NOT be NULL terminated. | | | This field MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 13: SW Response Too Large Error Information Fields Table 12: SW Response Too Large Error Information Fields
This error structure is used with the SW_RESPONSE_TOO_LARGE_ERROR This error structure is used with the SW_RESPONSE_TOO_LARGE_ERROR
status code to identify the SW Request attribute that precipitated status code to identify the SW Request attribute that precipitated
the error condition and to describe the error. The Maximum Allowed the error condition and to describe the error. The Maximum Allowed
Size field indicates the largest attribute the SW-PC is willing to Size field indicates the largest attribute the SW-PC is willing to
send in response to a SW Request under the current circumstances. send in response to a SW Request under the current circumstances.
Note that under other circumstances, the SW-PC might be willing to Note that under other circumstances, the SW-PC might be willing to
return larger or smaller responses than indicated (such as if the return larger or smaller responses than indicated (such as if the
endpoint connects to the NEA Server using a different network endpoint connects to the NEA Server using a different network
protocol). The other fields in this error information structure have protocol). The other fields in this error information structure have
the same meanings as corresponding fields in the SW_ERROR and the same meanings as corresponding fields in the SW_ERROR and
SW_SUBSCRIPTION_DENIED_ERROR information structure. SW_SUBSCRIPTION_DENIED_ERROR information structure.
4.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information 4.14.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information
The SW_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the The SW_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the
SW-PC encountered an error while fulfilling a subscription. The SW-PC encountered an error while fulfilling a subscription. The
bytes after the first 4 octets duplicate a PA-TNC Error attribute (as bytes after the first 4 octets duplicate a PA-TNC Error attribute (as
described in Section 4.2.8 of PA-TNC) that is used to identify the described in Section 4.2.8 of PA-TNC) that is used to identify the
nature of the encountered error. nature of the encountered error.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subscription ID | | Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub Error Code Vendor ID | | Reserved | Sub Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Error Code | | Sub Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Error Information (Variable Length) | | Sub Error Information (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: SW Subscription Fulfillment Error Information Figure 14: SW Subscription Fulfillment Error Information
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Subscription | This field MUST contain the Subscription ID of the | | Subscription | This field MUST contain the Subscription ID of the |
| ID | subscription whose fulfillment caused this error. | | ID | subscription whose fulfillment caused this error. |
| | | | | |
| Reserved | This field MUST contain the value of the Reserved | | Reserved | This field MUST contain the value of the Reserved |
| | field of a PA-TNC Error attribute that describes | | | field of a PA-TNC Error attribute that describes |
| | the error condition encountered during | | | the error condition encountered during |
skipping to change at page 70, line 48 skipping to change at page 73, line 32
| Code | Code field of a PA-TNC Error attribute that | | Code | Code field of a PA-TNC Error attribute that |
| | describes the error condition encountered during | | | describes the error condition encountered during |
| | subscription processing. | | | subscription processing. |
| | | | | |
| Sub Error | This field MUST contain the value of the Error | | Sub Error | This field MUST contain the value of the Error |
| Information | Information field of a PA-TNC Error attribute that | | Information | Information field of a PA-TNC Error attribute that |
| | describes the error condition encountered during | | | describes the error condition encountered during |
| | subscription processing. | | | subscription processing. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 14: SW Subscription Fulfillment Error Information Fields Table 13: SW Subscription Fulfillment Error Information Fields
This error structure is used with the This error structure is used with the
SW_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets of SW_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets of
this error structure contain the Subscription ID of the subscription this error structure contain the Subscription ID of the subscription
that was being fulfilled when the error occurred. The remaining that was being fulfilled when the error occurred. The remaining
fields of this error structure duplicate the fields of a PA-TNC Error fields of this error structure duplicate the fields of a PA-TNC Error
attribute, referred to as the "sub-error". The error code of the attribute, referred to as the "sub-error". The error code of the
sub-error corresponds to the type of error that the SW-PC encountered sub-error corresponds to the type of error that the SW-PC encountered
while fulfilling the given subscription. The sub-error MUST NOT have while fulfilling the given subscription. The sub-error MUST NOT have
an error code of SW_SUBSCRIPTION_FULFILLMENT_ERROR. an error code of SW_SUBSCRIPTION_FULFILLMENT_ERROR.
The SW-PC sending a PA-TNC Error attribute with this error code, and The SW-PC sending a PA-TNC Error attribute with this error code, and
the SW-PV receiving it, MUST treat the subscription identified by the the SW-PV receiving it, MUST treat the subscription identified by the
Subscription ID field as cancelled. All other subscriptions are Subscription ID field as cancelled. All other subscriptions are
unaffected. unaffected.
5. Supported Data Models 5. Supported Data Models
Software Message and Attributes for PA-TNC supports an extensible Software Inventory Message and Attributes for PA-TNC supports an
list of data models for representing and transmitting software extensible list of data models for representing and transmitting
inventory information. This list of data models appears in the software inventory information. This list of data models appears in
Software Data Model IANA table (see Section 9.4). This document the Software Data Model IANA table (see Section 9.4). This document
provides guidance for an initial set of data models. Other documents provides guidance for an initial set of data models. Other documents
might provide guidance on the use of new data models by Software might provide guidance on the use of new data models by Software
Message and Attributes for PA-TNC, and will be referenced by Inventory Message and Attributes for PA-TNC, and will be referenced
extensions to the Software Data Model IANA table. by extensions to the Software Data Model IANA table.
5.1. ISO 2015 SWID Tags using XML 5.1. ISO 2015 SWID Tags using XML
The International Organization for Standardization and the The International Organization for Standardization and the
International Electrotechnical Commission (ISO/IEC) published the International Electrotechnical Commission (ISO/IEC) published the
specification governing SWID tag construction and use in 2009 with a specification governing SWID tag construction and use in 2009 with a
revised version published in 2015. [SWID] Since that time, a growing revised version published in 2015. [SWID] Since that time, a growing
number of vendors have integrated SWID tags into their software number of vendors have integrated SWID tags into their software
products. Doing so significantly simplifies the task of identifying products. Doing so significantly simplifies the task of identifying
these pieces of software: instead of relying on discovery processes these pieces of software: instead of relying on discovery processes
skipping to change at page 72, line 27 skipping to change at page 75, line 13
software author if you are not the author. software author if you are not the author.
5.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID 5.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID
Tags Tags
TBD TBD
Use combination of Tag Creator RegID and Unique ID fields. Use combination of Tag Creator RegID and Unique ID fields.
Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID, Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID,
where NUMBER is the length of TAG_CREATOR_REGID in bytes. The rest where NUMBER is the length of TAG_CREATOR_REGID in bytes. The rest
of the Software Identifier MUST be the concatination of the Tag of the Software Identifier MUST be the concatenation of the Tag
Creator RegID and the Unique ID from the tag, without any connecting Creator RegID and the Unique ID from the tag, without any connecting
character or whitespace. character or whitespace.
5.2. ISO 2009 SWID Tags using XML 5.2. ISO 2009 SWID Tags using XML
As noted above, ISO's SWID tag specification provides a useful data As noted above, ISO's SWID tag specification provides a useful data
model for representation of software information. As of the writing model for representation of software information. As of the writing
of this specification, while the 2015 specification is considered of this specification, while the 2015 specification is considered
more comprehensive and addresses some issues with the 2009 more comprehensive and addresses some issues with the 2009
specification, 2009-format SWID tags remain far more common in specification, 2009-format SWID tags remain far more common in
skipping to change at page 73, line 13 skipping to change at page 75, line 46
software author if you are not the author. software author if you are not the author.
5.2.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID 5.2.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID
Tags Tags
TBD TBD
Use combination of Tag Creator RegID and Unique ID fields. Use combination of Tag Creator RegID and Unique ID fields.
Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID, Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID,
where NUMBER is the length of TAG_CREATOR_REGID in bytes. The rest where NUMBER is the length of TAG_CREATOR_REGID in bytes. The rest
of the Software Identifier MUST be the concatination of the Tag of the Software Identifier MUST be the concatenation of the Tag
Creator RegID and the Unique ID from the tag, without any connecting Creator RegID and the Unique ID from the tag, without any connecting
character or whitespace. character or whitespace.
6. Security Considerations 6. Security Considerations
This section discusses some of the security threats facing Posture This section discusses some of the security threats facing Posture
Collectors and Posture Validators that implement the Software Message Collectors and Posture Validators that implement the Software
and Attributes for PA-TNC protocol. This section primarily notes Inventory Message and Attributes for PA-TNC protocol. This section
potential issues for implementers to consider, although it does primarily notes potential issues for implementers to consider,
contain a handful of normative requirements to address certain although it does contain a handful of normative requirements to
security issues. Implementers need to make the final decision as to address certain security issues. Implementers need to make the final
how their implementations address the given issues. The issues decision as to how their implementations address the given issues.
identified below focus on capabilities specific to this document. The issues identified below focus on capabilities specific to this
Implementers are advised to consult other relevant NEA specifications document. Implementers are advised to consult other relevant NEA
for security issues that are applicable to such components in specifications for security issues that are applicable to such
general. components in general.
Reading the Security Considerations section of any well-written Reading the Security Considerations section of any well-written
specification can be discouraging, as a long list of possible threats specification can be discouraging, as a long list of possible threats
is catalogued. Keep in mind that no security measure is absolute, is catalogued. Keep in mind that no security measure is absolute,
but each one can be beneficial. By understanding the weaknesses of but each one can be beneficial. By understanding the weaknesses of
each security measure, we can put in place countermeasures to protect each security measure, we can put in place countermeasures to protect
against exploitation of these weaknesses. against exploitation of these weaknesses.
6.1. Evidentiary Value of Software Inventory Evidence Records 6.1. Evidentiary Value of Software Inventory Evidence Records
skipping to change at page 73, line 52 skipping to change at page 76, line 40
software load and changes thereon is only as accurate as the tools software load and changes thereon is only as accurate as the tools
that populate and manage the software inventory evidence records in that populate and manage the software inventory evidence records in
this collection. Some tools might not be designed to update records this collection. Some tools might not be designed to update records
in the Software Inventory Evidence Collection in real time resulting in the Software Inventory Evidence Collection in real time resulting
in a collection that is out-of-step with actual system state. in a collection that is out-of-step with actual system state.
Moreover, tools might inaccurately characterize software, or fail to Moreover, tools might inaccurately characterize software, or fail to
properly record its removal. Finally, it is likely that there will properly record its removal. Finally, it is likely that there will
be software on the endpoint that is not tracked by any source and be software on the endpoint that is not tracked by any source and
thus is not reflected in the Software Inventory Evidence Collection. thus is not reflected in the Software Inventory Evidence Collection.
Users of collected software inventory evidence records need to Users of collected software inventory evidence records need to
understand that the information provided by the Software Message and understand that the information provided by the Software Inventory
Attributes for PA-TNC capability cannot be treated as completely Message and Attributes for PA-TNC capability cannot be treated as
accurate. Nonetheless, having endpoints report this information can completely accurate. Nonetheless, having endpoints report this
still provide useful insights into the state of the endpoint's information can still provide useful insights into the state of the
software load, and can alert administrators and policy tools of endpoint's software load, and can alert administrators and policy
situations that require remediation. tools of situations that require remediation.
6.2. Sensitivity of Collected Records 6.2. Sensitivity of Collected Records
Software records on an endpoint are generally not considered to be Software records on an endpoint are generally not considered to be
sensitive, although there can be exceptions to this generalization as sensitive, although there can be exceptions to this generalization as
noted in the section on Privacy Considerations. In general, an noted in the section on Privacy Considerations. In general, an
endpoint's Software Inventory Evidence Collection can be browsed and endpoint's Software Inventory Evidence Collection can be browsed and
individual records read by any party with access to the endpoint. individual records read by any party with access to the endpoint.
This is generally not considered to be problematic, as those with This is generally not considered to be problematic, as those with
access to the endpoint can usually learn of everything disclosed by access to the endpoint can usually learn of everything disclosed by
skipping to change at page 76, line 28 skipping to change at page 79, line 21
Inventory Evidence Record. As a result, it is important that the Inventory Evidence Record. As a result, it is important that the
contents of source information not be automatically trusted. In contents of source information not be automatically trusted. In
particular, tools that read source information and the Software particular, tools that read source information and the Software
Inventory Evidence Records derived therefrom, including SW-PCs, need Inventory Evidence Records derived therefrom, including SW-PCs, need
to be careful to sanitize input to prevent buffer overflow attacks, to be careful to sanitize input to prevent buffer overflow attacks,
encoding attacks, and other weaknesses that might be exploited by an encoding attacks, and other weaknesses that might be exploited by an
adversary who can control the contents of a record. adversary who can control the contents of a record.
6.6. PA-TNC Security Threats 6.6. PA-TNC Security Threats
In addition to the aforementioned considerations the Software Message In addition to the aforementioned considerations the Software
and Attributes for PA-TNC protocol is subject to the same security Inventory Message and Attributes for PA-TNC protocol is subject to
threats as other PA-TNC transactions, as noted in Section 5.2 of PA- the same security threats as other PA-TNC transactions, as noted in
TNC [RFC5792]. These include, but are not limited to, attribute Section 5.2 of PA-TNC [RFC5792]. These include, but are not limited
theft, message fabrication, attribute modification, attribute replay, to, attribute theft, message fabrication, attribute modification,
attribute insertion, and denial of service. Implementers are advised attribute replay, attribute insertion, and denial of service.
to consult the PA-TNC specification to better understand these Implementers are advised to consult the PA-TNC specification to
security issues. better understand these security issues.
7. Privacy Considerations 7. Privacy Considerations
As noted in Section 6.2, if an adversary can gain an understanding of As noted in Section 6.2, if an adversary can gain an understanding of
the software installed on an endpoint, they can utilize this to the software installed on an endpoint, they can utilize this to
launch attacks and maintain footholds on this endpoint. For this launch attacks and maintain footholds on this endpoint. For this
reason, the NEA Server needs to ensure adequate safeguards are in reason, the NEA Server needs to ensure adequate safeguards are in
place to prevent exposure of collected inventory records. For place to prevent exposure of collected inventory records. For
similar reasons, it is advisable that an endpoint only send records similar reasons, it is advisable that an endpoint only send records
to a NEA Server that is authorized to receive this information and to a NEA Server that is authorized to receive this information and
skipping to change at page 77, line 27 skipping to change at page 80, line 14
specification are delivered reliably, securely, and to the specification are delivered reliably, securely, and to the
appropriate party. appropriate party.
It is important to note that the Product Information, Numeric It is important to note that the Product Information, Numeric
Version, and String Version attributes defined in the PA-TNC Version, and String Version attributes defined in the PA-TNC
specification [RFC5792] are also meant to convey information about specification [RFC5792] are also meant to convey information about
installed applications and the versions thereof. As such, there is installed applications and the versions thereof. As such, there is
some conceptual overlap between those attributes and the intent of some conceptual overlap between those attributes and the intent of
this specification. However, PA-TNC was designed to respond to very this specification. However, PA-TNC was designed to respond to very
specific queries about specific classes of products, while the specific queries about specific classes of products, while the
Software Message and Attributes for PA-TNC specification is able to Software Inventory Message and Attributes for PA-TNC specification is
convey a broader query, resulting in a more comprehensive set of able to convey a broader query, resulting in a more comprehensive set
evidence regarding an endpoint's installed software. As such, this of evidence regarding an endpoint's installed software. As such,
specification provides important capabilities not present in the PA- this specification provides important capabilities not present in the
TNC specification. PA-TNC specification.
9. IANA Considerations 9. IANA Considerations
This section extends multiple existing IANA registries. This section extends multiple existing IANA registries.
Specifically, it extends the PA-TNC Attribute Types and PA-TNC Error Specifically, it extends the PA-TNC Attribute Types and PA-TNC Error
Codes defined in the PA-TNC specification [RFC5792] and the PA- Codes defined in the PA-TNC specification [RFC5792] and the PA-
Subtypes registry defined in the PB-TNC specification [RFC5793] and Subtypes registry defined in the PB-TNC specification [RFC5793] and
extended in PA-TNC. This specification only adds values to these extended in PA-TNC. This specification only adds values to these
registries and does not alter how these registries work or are registries and does not alter how these registries work or are
maintained. Consult the appropriate specifications for details on maintained. Consult the appropriate specifications for details on
the operations and maintenance of these registries. the operations and maintenance of these registries.
9.1. Registry for PA-TNC Attribute Types 9.1. Registry for PA-TNC Attribute Types
Section 4.6 of this specification defines several new PA-TNC Section 4.4 of this specification defines several new PA-TNC
attributes. The following values are added to the registry for PA- attributes. The following values are added to the registry for PA-
TNC Attribute Types defined in the PA-TNC specification. Note that TNC Attribute Types defined in the PA-TNC specification. Note that
Table 4 in Section 4.6 lists these attributes but uses a hexadecimal Table 3 in Section 4.4 lists these attributes but uses a hexadecimal
value to identify their associated integer. The integer values given value to identify their associated integer. The integer values given
in that table are identical to those provided here. Note also that in that table are identical to those provided here. Note also that
Table 4 includes an entry for PA-TNC Error attributes, but the IANA Table 3 includes an entry for PA-TNC Error attributes, but the IANA
information associated with that attribute is already defined in the information associated with that attribute is already defined in the
PA-TNC specification and is not reproduced here. PA-TNC specification and is not reproduced here.
+-----+---------+---------------------+-----------------------------+ +-----+---------+-------------------+-------------------------------+
| PEN | Integer | Name | Defining Specification | | PEN | Integer | Name | Defining Specification |
+-----+---------+---------------------+-----------------------------+ +-----+---------+-------------------+-------------------------------+
| 0 | 17 | SW Request | Software Message and | | 0 | 17 | SW Request | Software Inventory Message |
| | | | Attributes for PA-TNC | | | | | and Attributes for PA-TNC |
| | | | | | | | | |
| 0 | 18 | Software Identifier | Software Message and | | 0 | 18 | Software | Software Inventory Message |
| | | Inventory | Attributes for PA-TNC | | | | Identifier | and Attributes for PA-TNC |
| | | | | | | | Inventory | |
| 0 | 19 | Software Identifier | Software Message and | | | | | |
| | | Events | Attributes for PA-TNC | | 0 | 19 | Software | Software Inventory Message |
| | | | | | | | Identifier Events | and Attributes for PA-TNC |
| 0 | 20 | Software Inventory | Software Message and | | | | | |
| | | | Attributes for PA-TNC | | 0 | 20 | Software | Software Inventory Message |
| | | | | | | | Inventory | and Attributes for PA-TNC |
| 0 | 21 | Software Events | Software Message and | | | | | |
| | | | Attributes for PA-TNC | | 0 | 21 | Software Events | Software Inventory Message |
| | | | | | | | | and Attributes for PA-TNC |
| 0 | 22 | Subscription Status | Software Message and | | | | | |
| | | Request | Attributes for PA-TNC | | 0 | 22 | Subscription | Software Inventory Message |
| | | | | | | | Status Request | and Attributes for PA-TNC |
| 0 | 23 | Subscription Status | Software Message and | | | | | |
| | | Response | Attributes for PA-TNC | | 0 | 23 | Subscription | Software Inventory Message |
| | | | | | | | Status Response | and Attributes for PA-TNC |
| 0 | 24 | Subscription Status | Software Message and | | | | | |
| | | Response | Attributes for PA-TNC | | 0 | 24 | Subscription | Software Inventory Message |
| | | | | | | | Status Response | and Attributes for PA-TNC |
| 0 | 25 - 31 | Reserved for future | Software Message and | | | | | |
| | | use | Attributes for PA-TNC | | 0 | 25 - 31 | Reserved for | Software Inventory Message |
+-----+---------+---------------------+-----------------------------+ | | | future use | and Attributes for PA-TNC |
+-----+---------+-------------------+-------------------------------+
9.2. Registry for PA-TNC Error Codes 9.2. Registry for PA-TNC Error Codes
Section 4.16 of this specification defines several new PA-TNC Error Section 4.14 of this specification defines several new PA-TNC Error
Codes. The following values are added to the registry for PA-TNC Codes. The following values are added to the registry for PA-TNC
Error Codes defined in the PA-TNC specification. Note that Table 11 Error Codes defined in the PA-TNC specification. Note that Table 10
in Section 4.16 lists these codes but uses a hexadecimal value to in Section 4.14 lists these codes but uses a hexadecimal value to
identify their associated integer. The integer values given in that identify their associated integer. The integer values given in that
table are identical to those provided here. table are identical to those provided here.
+-----+---------+-----------------------------------+---------------+ +-----+---------+-----------------------------------+---------------+
| PEN | Integer | Name | Defining | | PEN | Integer | Name | Defining |
| | | | Specification | | | | | Specification |
+-----+---------+-----------------------------------+---------------+ +-----+---------+-----------------------------------+---------------+
| 0 | 32 | SW_ERROR | Software | | 0 | 32 | SW_ERROR | Software |
| | | | Inventory |
| | | | Message and | | | | | Message and |
| | | | Attributes | | | | | Attributes |
| | | | for PA-TNC | | | | | for PA-TNC |
| | | | | | | | | |
| 0 | 33 | SW_SUBSCRIPTION_DENIED_ERROR | Software | | 0 | 33 | SW_SUBSCRIPTION_DENIED_ERROR | Software |
| | | | Inventory |
| | | | Message and | | | | | Message and |
| | | | Attributes | | | | | Attributes |
| | | | for PA-TNC | | | | | for PA-TNC |
| | | | | | | | | |
| 0 | 34 | SW_RESPONSE_TOO_LARGE_ERROR | Software | | 0 | 34 | SW_RESPONSE_TOO_LARGE_ERROR | Software |
| | | | Inventory |
| | | | Message and | | | | | Message and |
| | | | Attributes | | | | | Attributes |
| | | | for PA-TNC | | | | | for PA-TNC |
| | | | | | | | | |
| 0 | 35 | SW_SUBSCRIPTION_FULFILLMENT_ERROR | Software | | 0 | 35 | SW_SUBSCRIPTION_FULFILLMENT_ERROR | Software |
| | | | Inventory |
| | | | Message and | | | | | Message and |
| | | | Attributes | | | | | Attributes |
| | | | for PA-TNC | | | | | for PA-TNC |
| | | | | | | | | |
| 0 | 36 | SW_SUBSCRIPTION_ID_REUSE_ERROR | Software | | 0 | 36 | SW_SUBSCRIPTION_ID_REUSE_ERROR | Software |
| | | | Inventory |
| | | | Message and | | | | | Message and |
| | | | Attributes | | | | | Attributes |
| | | | for PA-TNC | | | | | for PA-TNC |
| | | | | | | | | |
| 0 | 37-47 | Reserved for future use | Software | | 0 | 37-47 | Reserved for future use | Software |
| | | | Inventory |
| | | | Message and | | | | | Message and |
| | | | Attributes | | | | | Attributes |
| | | | for PA-TNC | | | | | for PA-TNC |
+-----+---------+-----------------------------------+---------------+ +-----+---------+-----------------------------------+---------------+
9.3. Registry for PA Subtypes 9.3. Registry for PA Subtypes
Section 4.1 of this specification defines one new PA Subtype. The Section 4.1 of this specification defines one new PA Subtype. The
following value is added to the registry for PA Subtypes defined in following value is added to the registry for PA Subtypes defined in
the PB-TNC specification. the PB-TNC specification.
+-----+---------+-------------+-------------------------------------+ +-----+---------+------------+--------------------------------------+
| PEN | Integer | Name | Defining Specification | | PEN | Integer | Name | Defining Specification |
+-----+---------+-------------+-------------------------------------+ +-----+---------+------------+--------------------------------------+
| 0 | 9 | SW | Software Message and Attributes for | | 0 | 9 | SW | Software Inventory Message and |
| | | Attributes | PA-TNC | | | | Attributes | Attributes for PA-TNC |
+-----+---------+-------------+-------------------------------------+ +-----+---------+------------+--------------------------------------+
9.4. Registry for Software Data Models 9.4. Registry for Software Data Models
TBD TBD
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <http://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<http://www.rfc-editor.org/info/rfc5198>. <http://www.rfc-editor.org/info/rfc5198>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<http://www.rfc-editor.org/info/rfc5209>. <http://www.rfc-editor.org/info/rfc5209>.
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
 End of changes. 233 change blocks. 
956 lines changed or deleted 1049 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/