draft-ietf-sacm-nea-swid-patnc-00.txt   draft-ietf-sacm-nea-swid-patnc-01.txt 
SACM C. Schmidt SACM C. Schmidt
Internet-Draft D. Haynes Internet-Draft D. Haynes
Intended status: Standards Track C. Coffin Intended status: Standards Track C. Coffin
Expires: July 9, 2017 The MITRE Corporation Expires: September 14, 2017 The MITRE Corporation
D. Waltermire
National Institute of Standards and Technology
J. Fitzgerald-McKay J. Fitzgerald-McKay
Department of Defense Department of Defense
January 5, 2017 March 13, 2017
Software Inventory Message and Attributes (SWIMA) for PA-TNC Software Inventory Message and Attributes (SWIMA) for PA-TNC
draft-ietf-sacm-nea-swid-patnc-00 draft-ietf-sacm-nea-swid-patnc-01
Abstract Abstract
This document specifies the Software Inventory Message and Attributes This document 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 installed software inventory information to a NEA server
endpoints to report their installed software inventory information to (as 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 July 9, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 16 skipping to change at page 2, line 17
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. Network Endpoint Assessment (NEA) . . . . . . . . . . . . 5 1.1. Network Endpoint Assessment (NEA) . . . . . . . . . . . . 5
1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8 2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8
2.1.1. Use Software Inventory as a Factor in Determining 2.1.1. Use Software Inventory as an Access Control Factor . 8
Endpoint Access . . . . . . . . . . . . . . . . . . . 8 2.1.2. Central Stores of Up-to-Date Endpoint Software
2.1.2. Maintain a Central Repository Reflecting an Inventory Data . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . 12 2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 12
2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 13 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 12
2.7. Software Inventory Message and Attributes for PA-TNC 3. System Requirements . . . . . . . . . . . . . . . . . . . . . 12
Diagram Conventions . . . . . . . . . . . . . . . . . . . 13 3.1. Data Sources . . . . . . . . . . . . . . . . . . . . . . 13
3. Software Inventory Message and Attributes for PA-TNC System 3.2. Data Models . . . . . . . . . . . . . . . . . . . . . . . 14
Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Basic Attribute Exchange . . . . . . . . . . . . . . . . 15
3.1. Information Sources . . . . . . . . . . . . . . . . . . . 14 3.4. Core Software Reporting Information . . . . . . . . . . . 16
3.2. Data Models . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.1. Software Identifiers . . . . . . . . . . . . . . . . 16
3.3. Basic Attribute Exchange . . . . . . . . . . . . . . . . 16 3.4.2. Data Model Type . . . . . . . . . . . . . . . . . . . 17
3.4. Core Software Reporting Information . . . . . . . . . . . 17 3.4.3. Record Identifiers . . . . . . . . . . . . . . . . . 18
3.4.1. Software Identifiers . . . . . . . . . . . . . . . . 17 3.4.4. Software Locators . . . . . . . . . . . . . . . . . . 18
3.4.2. Data Model Type . . . . . . . . . . . . . . . . . . . 18 3.4.5. Source Identifiers . . . . . . . . . . . . . . . . . 19
3.4.3. Record Identifiers . . . . . . . . . . . . . . . . . 19
3.4.4. Software Locators . . . . . . . . . . . . . . . . . . 19
3.4.5. Source Identifiers . . . . . . . . . . . . . . . . . 20
3.4.6. Using Software and Record Identifiers in SW 3.4.6. Using Software and Record Identifiers in SW
Attributes . . . . . . . . . . . . . . . . . . . . . 21 Attributes . . . . . . . . . . . . . . . . . . . . . 20
3.5. Targeted Requests . . . . . . . . . . . . . . . . . . . . 21 3.5. Targeted Requests . . . . . . . . . . . . . . . . . . . . 21
3.6. Monitoring Changes in an Endpoint's Software Inventory 3.6. Monitoring Changes in an Endpoint's Software Inventory
Evidence Collection . . . . . . . . . . . . . . . . . . . 22 Evidence Collection . . . . . . . . . . . . . . . . . . . 22
3.7. Reporting Change Events . . . . . . . . . . . . . . . . . 25 3.7. Reporting Change Events . . . . . . . . . . . . . . . . . 24
3.7.1. Event Identifiers . . . . . . . . . . . . . . . . . . 25 3.7.1. Event Identifiers . . . . . . . . . . . . . . . . . . 25
3.7.2. Core Event Tracking Information . . . . . . . . . . . 27 3.7.2. Core Event Tracking Information . . . . . . . . . . . 26
3.7.3. Updating Inventory Knowledge Based on Events . . . . 27 3.7.3. Updating Inventory Knowledge Based on Events . . . . 27
3.7.4. Using Event Records in SW Attributes . . . . . . . . 28 3.7.4. Using Event Records in SW Attributes . . . . . . . . 27
3.7.5. Partial and Complete Lists of Event Records in SW 3.7.5. Partial and Complete Lists of Event Records in SW
Attributes . . . . . . . . . . . . . . . . . . . . . 28 Attributes . . . . . . . . . . . . . . . . . . . . . 28
3.7.6. Synchronizing Event Identifiers and Epochs . . . . . 30 3.7.6. Synchronizing Event Identifiers and Epochs . . . . . 30
3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 31
3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 32 3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 31
3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 32 3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 32
3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 33 3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 32
3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 33 3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 33
3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 34
3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 34 3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 34
3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 35 3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 35
3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 36 3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 35
3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 37 3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 37
3.8.5.4. No Subscription Consolidation . . . . . . . . . . 38 3.8.5.4. No Subscription Consolidation . . . . . . . . . . 37
3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 38 3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 37
3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 39 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 38
4. Software Inventory Message and Attributes for PA-TNC Protocol 40 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 40 4.1. Direct Response to a SW Request . . . . . . . . . . . . . 40
4.2. SW Attribute Overview . . . . . . . . . . . . . . . . . . 41 4.2. Subscription-Based Response . . . . . . . . . . . . . . . 40
4.3. SW Attribute Exchanges . . . . . . . . . . . . . . . . . 43 4.3. Required Exchanges . . . . . . . . . . . . . . . . . . . 41
4.4. Software Inventory Message and Attributes for PA-TNC 5. Software Inventory Messages and Attributes . . . . . . . . . 41
Attribute Enumeration . . . . . . . . . . . . . . . . . . 45 5.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 42
4.5. Normalization of Text Encoding . . . . . . . . . . . . . 46 5.2. SW Attribute Overview . . . . . . . . . . . . . . . . . . 42
4.6. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 47 5.3. Message Diagram Syntax . . . . . . . . . . . . . . . . . 44
4.7. SW Request . . . . . . . . . . . . . . . . . . . . . . . 48 5.4. Software Inventory Message and Attributes for PA-TNC
4.8. Software Identifier Inventory . . . . . . . . . . . . . . 51 Attribute Enumeration . . . . . . . . . . . . . . . . . . 44
4.9. Software Identifier Events . . . . . . . . . . . . . . . 55 5.5. Normalization of Text Encoding . . . . . . . . . . . . . 45
4.10. Software Inventory . . . . . . . . . . . . . . . . . . . 60 5.6. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 46
4.11. Software Events . . . . . . . . . . . . . . . . . . . . . 63 5.7. SW Request . . . . . . . . . . . . . . . . . . . . . . . 47
4.12. Subscription Status Request . . . . . . . . . . . . . . . 68 5.8. Software Identifier Inventory . . . . . . . . . . . . . . 50
4.13. Subscription Status Response . . . . . . . . . . . . . . 68 5.9. Software Identifier Events . . . . . . . . . . . . . . . 54
4.14. PA-TNC Error as Used by Software Inventory Message and 5.10. Software Inventory . . . . . . . . . . . . . . . . . . . 59
Attributes for PA-TNC . . . . . . . . . . . . . . . . . . 70 5.11. Software Events . . . . . . . . . . . . . . . . . . . . . 62
4.14.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and 5.12. Subscription Status Request . . . . . . . . . . . . . . . 67
SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 72 5.13. Subscription Status Response . . . . . . . . . . . . . . 67
4.14.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 73 5.14. Source Metadata Request . . . . . . . . . . . . . . . . . 69
4.14.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 75 5.15. Source Metadata Response . . . . . . . . . . . . . . . . 69
5. Supported Data Models . . . . . . . . . . . . . . . . . . . . 77 5.16. PA-TNC Error as Used by Software Inventory Message and
5.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 77 Attributes for PA-TNC . . . . . . . . . . . . . . . . . . 71
5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID 5.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and
Tags using XML . . . . . . . . . . . . . . . . . . . 77 SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 73
5.1.2. Guidance on Creation of Software Identifiers from ISO 5.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 75
2015 SWID Tags . . . . . . . . . . . . . . . . . . . 78 5.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 76
5.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 78 6. Supported Data Models . . . . . . . . . . . . . . . . . . . . 78
5.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID 6.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 78
Tags using XML . . . . . . . . . . . . . . . . . . . 78 6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID
5.2.2. Guidance on Creation of Software Identifiers from ISO Tags using XML . . . . . . . . . . . . . . . . . . . 79
2009 SWID Tags . . . . . . . . . . . . . . . . . . . 79 6.1.2. Guidance on Creation of Software Identifiers from ISO
6. Security Considerations . . . . . . . . . . . . . . . . . . . 79 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 79
6.1. Evidentiary Value of Software Inventory Evidence Records 79 6.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 79
6.2. Sensitivity of Collected Records . . . . . . . . . . . . 80 6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID
6.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 81 Tags using XML . . . . . . . . . . . . . . . . . . . 80
6.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 81 6.2.2. Guidance on Creation of Software Identifiers from ISO
6.5. Sanitization of Record Fields . . . . . . . . . . . . . . 82 2009 SWID Tags . . . . . . . . . . . . . . . . . . . 80
6.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 80
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 82 7.1. Evidentiary Value of Software Inventory Evidence Records 81
8. Relationship to Other Specifications . . . . . . . . . . . . 82 7.2. Sensitivity of Collected Records . . . . . . . . . . . . 81
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 7.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 82
9.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 83 7.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 83
9.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 84 7.5. Sanitization of Record Fields . . . . . . . . . . . . . . 83
9.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 85 7.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 83
9.4. Registry for Software Data Models . . . . . . . . . . . . 86 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 84
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 9. Relationship to Other Specifications . . . . . . . . . . . . 84
10.1. Normative References . . . . . . . . . . . . . . . . . . 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
10.2. Informative References . . . . . . . . . . . . . . . . . 88 10.1. PA Subtypes . . . . . . . . . . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 10.2. Registry for PA-TNC Attribute Types . . . . . . . . . . 85
10.3. Registry for PA-TNC Error Codes . . . . . . . . . . . . 86
10.4. Registry for Software Data Models . . . . . . . . . . . 87
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
11.1. Normative References . . . . . . . . . . . . . . . . . . 88
11.2. Informative References . . . . . . . . . . . . . . . . . 89
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
Possession of a list of an endpoint's installed software is very Knowing the list of the software installed on endpoints is useful to
useful in understanding and maintaining the security state of an understand and maintain the security state of a network. For
enterprise. For example, if an enterprise policy requires the example, if an enterprise policy requires the presence of certain
presence of certain pieces of software and/or prohibits the presence software and prohibits the presence of other software, reported
of other software, reported software installation inventory lists can software installation information can be used to indicate compliance
be used to indicate compliance or non-compliance with these and non-compliance with these requirements. When reported endpoint
requirements. Software installation inventories and the patch level software installation inventory lists, shortened to "software
of the identified software can be compared to vulnerability or threat inventories" for the remainder of this document, contain patch level
alerts to determine an endpoint's exposure to attack. All of these data for identified software, further comparison to vulnerability or
uses make an understanding of an endpoint's installed software threat alerts can be used to determine an endpoint's exposure to
inventory highly useful to NEA Servers and other enterprise security attack. These are some of the highly useful management use cases
applications. supported by software inventory data provided by this specification.
There is a need for a standardized method for exchanging software There is a need for a standardized method for exchanging software
inventory that carries a software identifier (a unique identifier inventory data that includes a unique software identifier associated
associated with a specific software product and version thereof). In with a specific version of a software product. In some cases, it may
some cases, it may also be necessary to convey information that also be necessary to convey observable installation information and
characterizes this product (i.e., provides metadata about the product characterization information for a software product including
beyond its identifier) as well as observable installation metadata about the product beyond its identifier. These "Messages
information. These "Messages and Attributes" would enable software and Attributes" enable software identification, installation, and
identification, installation, and characterization information to be characterization information to be provided for any software
provided for any software installed on any endpoint that supports installed on any endpoint that supports this specification. Such
this specification. information can come from multiple sources, including tag files (such
as ISO SWID tags [SWID15]), reports from third party inventory tools,
To that end, this specification defines a new set of PA-TNC output from package managers, and other sources.
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 This specification is designed to only report software that is
installed on an endpoint. In particular, it does not monitor or installed on an endpoint. In particular, it does not monitor or
report information about what software is running on the endpoint. report information about what software is running on the endpoint.
Likewise, it is not intended to report individual files, libraries, Likewise, it is not intended to report individual files, libraries,
installation packages, or similar artifacts. While all of this installation packages, or similar artifacts. While all of this
information has its uses, this information requires different information has its uses, this information requires different
metadata and different methods of monitoring the endpoint. As a metadata and monitoring methods. As a result, this specification
result, this specification focuses solely on installed software, focuses solely on software inventory information, leaving reporting
leaving reporting of other classes of endpoint information to other of other classes of endpoint information to other specifications.
specifications.
This specification defines a new set of PA-TNC attributes, which are
used to communicate requests for software inventory information and
software installation change events. The exchange of these messages
allows software inventory information to be sent to a NEA Server,
which can make this information available to other applications.
1.1. Network Endpoint Assessment (NEA) 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. The attributes defined in this document are used to
including tag files (such as ISO SWID tags [SWID15], reports from
third party inventory tools, output from package managers, and other
sources. The attributes defined in this document are used to
communicate software inventory evidence, collected from a range of communicate software inventory evidence, collected from a range of
possible sources, from the posture collector on the endpoint to the possible sources, from the posture collector on the endpoint to the
posture validator on a NEA Server using the PA-TNC interface, as posture validator on a NEA Server using the PA-TNC interface, as
shown in Figure 1 below. shown in Figure 1 below.
+-------------+ +--------------+ +-------------+ +--------------+
| Posture | <--------PA--------> | Posture | | Posture | <--------PA--------> | Posture |
| Collectors | | Validators | | Collectors | | Validators |
| (1 .. N) | | (1 .. N) | | (1 .. N) | | (1 .. N) |
+-------------+ +--------------+ +-------------+ +--------------+
skipping to change at page 6, 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
Before reading this specification any further, the reader should To better understand this specification, the reader should review the
review and understand the NEA reference architecture as described in NEA reference architecture as described in the Network Endpoint
the Network Endpoint Assessment (NEA): Overview and Requirements Assessment (NEA): Overview and Requirements [RFC5209]. The reader
[RFC5209]. The reader should also understand the capabilities and should also review the 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
components are equivalent: components are equivalent:
+---------------------------------------+-----------------------+ +---------------------------------------+-----------------------+
| TNC Component | NEA Component | | TNC Component | NEA Component |
+---------------------------------------+-----------------------+ +---------------------------------------+-----------------------+
skipping to change at page 7, line 35 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 Inventory Message and Attributes for PA- exchanges beyond those defined herein.
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 Inventory Message and Attributes for PA- exchanges beyond those defined herein.
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.
An endpoint's software inventory evidence collection might include An endpoint's software inventory evidence collection might include
information created by or derived from multiple sources, including information created by or derived from multiple sources, including
but not limited to SWID tag files deposited on the file system during but not limited to SWID tag files deposited on the file system during
skipping to change at page 8, line 17 skipping to change at page 8, line 15
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 Inventory a specific software product. Each supported SWIMA data model has its
Message and Attributes for PA-TNC data model has its own rules for own rules for how a software identifier (see Section 3.4.1) is
how a Software Identifier (see Section 3.4.1) is derived from the derived from the representation of the given software product using
representation of the given software product using that data model, that data model, and different sources for this information might
and different sources for this information might populate relevant populate relevant information differently. As such, while each
information differently. As such, while each Software Identifier software identifier uniquely identifies a specific software product,
uniquely identifies a specific software product, the same software the same software product might be associated with multiple software
product might be associated with multiple Software Identifiers identifiers reflecting differences between different data sources and
reflecting differences between different information sources and
supported data models. supported data models.
2. Background 2. Background
2.1. Supported Use Cases 2.1. Supported Use Cases
This section describes the Software Inventory Message and Attributes This section describes the use cases supported by this specification.
for PA-TNC use cases supported by this specification. The primary The primary use of exchanging software inventory information over the
use of exchanging software inventory information over the PA-TNC PA-TNC interface is to enable a challenger (e.g. NEA Server) to
interface is to enable a challenger (e.g. NEA Server) to obtain obtain inventory evidence about some system in a way that conforms to
inventory evidence about some system in a way that conforms to NEA NEA procedures and expressed using a standard format. Collected
procedures and expressed using a standard format. Collected software software information can support a range of security activities
information can support a range of security activities including including determining whether an endpoint is permitted to connect to
determining whether an endpoint is permitted to connect to the 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 an Access Control Factor
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 to resources by endpoints that have certain prohibited pieces of
installed, such as applications that pose known security risks. To software installed, since such applications might pose a security
support such policies, the NEA Server needs to collect evidence risk. To support such policies, the NEA Server needs to collect
indicating the software inventory of an endpoint that is seeking to software inventory evidence from an endpoint that is seeking to
initiate or continue connectivity to the enterprise. initiate or continue connectivity to the enterprise resource.
Software Inventory Message and Attributes for PA-TNC facilitates Based on this specification, the SW-PC can provide a complete or
policy decisions that consider an endpoint's software inventory by partial inventory to the SW-PV as required to determine policy
providing the NEA Server with software inventory information from the compliance. The SW-PV can then use this as evidence of compliance or
endpoint. The SW-PC can provide a complete or partial inventory to non-compliance to make a policy-based access decision.
the SW-PV as required to determine policy compliance. The SW-PV can
then use this as evidence of compliance or non-compliance with
enterprise policy.
2.1.2. Maintain a Central Repository Reflecting an Endpoint's Software 2.1.2. Central Stores of Up-to-Date Endpoint Software Inventory Data
Inventory
Many tools can use information about an endpoint's software inventory Many tools use information about an endpoint's software inventory to
to monitor and enforce the security of an enterprise. For example, a monitor and enforce the security of a network. For example, a
software patching service can use an endpoint's software inventory to software patching tool needs to determine if there is out-of-date
determine whether certain endpoints have software that requires software installed that needs to be updated. A vulnerability
patching. A vulnerability management tool might identify endpoints management tool needs to identify endpoints with known vulnerable
with known vulnerabilities (patched or otherwise) and use this to software installed (patched or otherwise) to gauge an endpoint's
gauge enterprise exposure to attack. A license management tool might relative exposure to attack. A license management tool needs to
verify that all copies of a particular piece of software are verify that all installed software within the enterprise is accounted
accounted for within the enterprise. The presence of a central for. A central repository representing an up-to-date understanding
repository representing a real-time understanding of each endpoint's of each endpoint's software inventory facilitates these activities.
software inventory facilitates all such activities. Using a central Multiple tools can share such a repository ensuring that software
repository that can ensure the freshness of its collected information inventory information is collected more frequently and efficiently,
is generally more efficient than having each tool collect the same leading to a more complete and consistent understanding of installed
inventory information from each endpoint individually and leads to a software state as compared to each tool collecting the same inventory
more consistent understanding of enterprise state. information from endpoints individually.
Software Inventory Message and Attributes for PA-TNC supports this This specification supports these activities through a number of
activity through a number of mechanisms. As noted above, it allows a mechanisms. As noted above, a SW-PC can provide a complete list of
SW-PC to provide a complete list of software present in an endpoint's software present in an endpoint's Software Inventory Evidence
Software Inventory Evidence Collection to the SW-PV, which can then Collection to the SW-PV, which can then pass this information on to a
pass this information on to a central repository such as a central repository, such as a Configuration Management Database
Configuration Management Database (CMDB) or similar application. In (CMDB) or similar application. In addition, SW-PCs are required to
addition, SW-PCs are required to be able to monitor for changes to an be able to monitor for changes to an endpoint's Software Inventory
endpoint's Software Inventory Evidence Collection in near real-time Evidence Collection in near real-time and immediately push reports of
and push reports of changes to the SW-PV as soon as those changes are detected changes to the SW-PV. Thus any central repository fed by a
detected. Thus any central repository fed by a SW-PV receiving such SW-PV receiving inventory information can be updated quickly after a
information can be updated soon after the change occurs. Keeping change occurs. Keeping a central repository synchronized with
such a central repository synchronized with the state of each current software inventory information in this way allows tools to
endpoint's Software Inventory Evidence Collection allows tools that make efficient decisions based on up-to-date, consistent information.
use this information for their own security activities to make
decisions in a consistent, efficient manner.
2.1.3. PA-TNC Use Cases 2.1.3. PA-TNC Use Cases
Software Inventory Message and Attributes for PA-TNC are intended to Software Inventory Message and Attributes for PA-TNC are intended to
operate over the PA-TNC interface and, as such, are intended to meet operate over the PA-TNC interface and, as such, are intended to meet
the use 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 Inventory Some use cases not covered by this specification include:
Message and Attributes for PA-TNC include:
o This specification does not address how the endpoint's Software o Addressing how the endpoint's Software Inventory Evidence
Inventory Evidence Collection is populated. In particular, NEA Collection is populated. In particular, NEA components are not
components are not expected to perform software discovery expected to perform software discovery activities beyond compiling
activities beyond compiling information in an endpoint's Software information in an endpoint's Software Inventory Evidence
Inventory Evidence Collection. This collection might potentially Collection. This collection might come from multiple sources on
come from multiple sources on the endpoint (e.g., information the endpoint (e.g., information generated dynamically by package
generated dynamically by package management tools or discovery management tools or discovery tools, as well as SWID tag files
tools, as well as SWID tag files discovered on the file system). discovered on the file system). While an enterprise might make
While an enterprise might make use of software discovery use of software discovery capabilities to identify installed
procedures to identify installed software such procedures are software, such capabilities are outside the scope of this
outside the scope of this specification. specification.
o This specification does not address converting inventory o Converting inventory information expressed in a proprietary format
information expressed in a proprietary format into formats used in into formats used in the attributes described in this
the attributes described in this specification. Instead, it specification. Instead, this specification focuses exclusively on
focuses exclusively on defining interfaces for the transportation defining interfaces for the transportation of software information
of software information in the expectation that this is the format expecting that reporting tools will converge around some set of
around which reporting tools will converge. standardized formats for this information.
o This specification provides no mechanisms for a posture validator o Mechanisms for a posture validator to request a specific list of
to request a specific list of software information based on software information based on arbitrary software properties. For
arbitrary software properties. For example, requesting only example, requesting only information about software from a
information about software from a particular vendor is not particular vendor is not supported. After the endpoint's Software
supported. After the endpoint's software inventory evidence Inventory Evidence Collection has been copied to some central
collection has been copied to some central location, such as the location, such as the CMDB, processes there can perform queries
CMDB, processes there can perform queries based on any criteria based on any criteria present in the collected information, but
present in the collected information, but this specification does this specification does not address using such queries to
not address using such queries to constrain the initial collection constrain the initial collection of this information from the
of this information from the endpoint. endpoint.
o This specification does not address utilization of properties of o Use of properties of certain sources of software information that
certain sources of software information that might facilitate might facilitate local tests (i.e., on the endpoint) of endpoint
local tests (i.e., on the endpoint) of endpoint state. For state. For example, the optional package_footprint field of an
example, the optional package_footprint field of an ISO SWID tag ISO SWID tag can contain a list of files and hash values
can contain a list of files and hash values associated with the associated with the software indicated by the tag. Tools on the
software indicated by the tag. Tools on the endpoint can use the endpoint can use the values in this field to test for the presence
values in this field to test for the presence of the indicated of the indicated files. Successful evaluation of such tests leads
files. Successful evaluation of such tests leads to greater to greater assurance that the indicated software is present on the
assurance that the indicated software is present on the endpoint. endpoint. Currently, most SWID tag creators do not provide values
Currently, most SWID tag creators do not provide values for tag for tag fields that support local testing. For this reason, the
fields that support local testing. For this reason, the added added complexity of supporting endpoint testing using these fields
complexity of supporting endpoint testing using these fields is is out of scope for this specification, but may be considered in a
out of scope for this specification. Future versions of this future version.
specification might add support for such testing.
2.3. Specification Requirements 2.3. Specification Requirements
Below are the requirements that the Software Inventory Message and Below are the requirements that the Software Inventory Message and
Attributes for PA-TNC specification is required to meet in order to Attributes for PA-TNC specification is required to meet in order to
successfully play its role in the NEA architecture. successfully play its role in the NEA architecture.
o Efficient Efficient: The NEA architecture enables delay of network access
until the endpoint is determined not to pose a security threat to
The NEA architecture enables delay of network access until the the network based on its asserted integrity information. To
endpoint is determined not to pose a security threat to the network minimize user frustration, the Software Inventory Message and
based on its asserted integrity information. To minimize user Attributes for PA-TNC ought to minimize overhead delays and make
frustration, the Software Inventory Message and Attributes for PA-TNC PA-TNC communications as rapid and efficient as possible.
ought to minimize overhead delays and make PA-TNC communications as
rapid and efficient as possible.
Efficiency is also important when one considers that some network
endpoints are small and low powered, some networks are low bandwidth
and/or high latency, and some transport protocols (such as PT-EAP,
Posture Transport (PT) Protocol for Extensible Authentication
Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier
protocol might allow only one packet in flight at a time or only one
roundtrip. However, when the underlying PT protocol imposes fewer
constraints on communications, this protocol ought to be capable of
taking advantage of more robust communication channels (e.g. using
larger messages or multiple roundtrips).
o Scalable
Software Inventory Message and Attributes for PA-TNC needs to be
usable in enterprises that contain tens of thousands of endpoints or
more. As such, it needs to allow a security tools to make decisions
based on up-to-date information about an endpoint's software
inventory without creating an excessive burden on the enterprise's
network.
o Interoperable Efficiency is also important when one considers that some network
endpoints are small and low powered, some networks are low
bandwidth and/or high latency, and some transport protocols (such
as PT-EAP, Posture Transport (PT) Protocol for Extensible
Authentication Protocol (EAP) Tunnel Methods [RFC7171]) or their
underlying carrier protocol might allow only one packet in flight
at a time or only one roundtrip. However, when the underlying PT
protocol imposes fewer constraints on communications, this
protocol ought to be capable of taking advantage of more robust
communication channels (e.g. using larger messages or multiple
roundtrips).
This specification defines the protocol for how PCs and PVs can Scalable: Software Inventory Message and Attributes for PA-TNC needs
exchange and use software information to provide a NEA Server with to be usable in enterprises that contain tens of thousands of
information about an endpoint's software inventory. Therefore a key endpoints or more. As such, it needs to allow a security tools to
goal for this specification is ensuring that all SW PCs and PVs, make decisions based on up-to-date information about an endpoint's
regardless of the vendor who created them, are able to interoperate software inventory without creating an excessive burden on the
in their performance of these duties. enterprise's network.
o Support precise and complete historical reporting Interoperable: This specification defines the protocol for how PCs
and PVs can exchange and use software information to provide a NEA
Server with information about an endpoint's software inventory.
Therefore, a key goal for this specification is ensuring that all
SW PCs and PVs, regardless of the vendor who created them, are
able to interoperate in their performance of these duties.
This specification outlines capabilities that support real-time Support precise and complete historical reporting: This
understanding of the state of endpoint in a network in a way that can specification outlines capabilities that support real-time
be used by other tools. One means of facilitating such an outcome is understanding of the state of endpoint in a network in a way that
for a Configuration Management Database (CMDB) to be able to contain can be used by other tools. One means of facilitating such an
information about all endpoints connected to the enterprise for all outcome is for a CMDB to be able to contain information about all
points in time between the endpoint's first connection and the endpoints connected to the enterprise for all points in time
present. In such a scenario, it is necessary that any PC be able to between the endpoint's first connection and the present. In such
report any changes to its software inventory evidence collection in a scenario, it is necessary that any PC be able to report any
near real-time while connected and, upon reconnection to the changes to its software inventory evidence collection in near
enterprise, be able to update the NEA Server (and through it the real-time while connected and, upon reconnection to the
CMDB) with regard to the state of its software inventory evidence enterprise, be able to update the NEA Server (and through it the
collection throughout the entire interval when it was not connected. CMDB) with regard to the state of its software inventory evidence
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 Inventory Message There are certain requirements that the Software Inventory Message
and 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 End to End Confidentiality: This specification does not define a
mechanism for confidentiality, nor is this property automatically
This specification does not define mechanism for confidentiality, nor provided by using the PA-TNC interface. In the NEA architecture,
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
protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP Posture Posture Transport for Tunneled EAP Methods [RFC7171] - see
Transport for Tunneled EAP Methods [RFC7171] - see Section 8 for more Section 9 for more information on related standards. Should users
information on related standards. Should users wish confidentiality wish to protect the confidentiality of assessment instructions or
protection of assessment instructions or results, this needs to be results, then an appropriate transport needs to be used.
provided by parts of the NEA architecture other than this
specification.
2.5. Assumptions 2.5. Assumptions
Here are the assumptions that Software Inventory Message and
Attributes for PA-TNC makes about other components in the NEA
architecture.
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 attributes sent
Attributes sent between the SW PCs and the PVs. In the event that between the SW-PCs and the SW-PVs. In the event that reliable
reliable delivery cannot be provided, the Posture Collector or delivery cannot be provided, the Posture Collector or Posture
Posture Validator is expected to terminate the connection. Validator is expected to terminate the connection.
2.6. Non-Assumptions 2.6. Non-Assumptions
The Software Inventory Message and Attributes for PA-TNC This specification explicitly does not assume that software inventory
specification explicitly does not assume: information exchanges reflect the software installation state of the
endpoint. This specification does not attempt to detect when the
o Authenticity and Accuracy of the Software Inventory Evidence
Collection with Regard to Endpoint Inventory
This specification makes no assumption as to whether the software
information that it reports correctly reflect the software state on
the endpoint. This specification does not attempt to detect when the
endpoint is providing false information, either through malice or 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 about 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 7 for more on this security consideration.
2.7. Software Inventory Message and Attributes for PA-TNC Diagram
Conventions
This specification defines the syntax of the Software Inventory
Message and Attributes for PA-TNC using diagrams. Each diagram
depicts the format and size of each field in bits. Implementations
MUST send the bits in each diagram as they are shown from left to
right for each 32-bit quantity traversing the diagram from top to
bottom. Multi-octet fields representing numeric values MUST be sent
in network (big endian) byte order.
Descriptions of bit fields (e.g. flags) values refer to the position
of the bit within the field. These bit positions are numbered from
the most significant bit through the least significant bit. As such,
an octet with only bit 0 set would have a value of 0x80 (1000 0000),
an octet with only bit 1 set would have a value of 0x40 (0100 0000),
and an octet with only bit 7 set would have a value of 0x01 (0000
0001).
3. Software Inventory Message and Attributes for PA-TNC System 3. System Requirements
Requirements
The Software Inventory Message and Attributes for PA-TNC The Software Inventory Message and Attributes for PA-TNC
specification facilitates the exchange of software inventory and specification facilitates the exchange of software inventory and
event information. Specifically, each application supporting event information. Specifically, each application supporting
Software Inventory Message and Attributes for PA-TNC includes a Software Inventory Message and Attributes for PA-TNC includes a
component known as the SW-PC that receives messages sent with the SW component known as the SW-PC that receives messages sent with the SW
Attributes component type. The SW-PC is also responsible for sending Attributes component type. The SW-PC is also responsible for sending
appropriate SW Attributes back to the SW-PV in response. This appropriate SW Attributes back to the SW-PV in response. This
section outlines what software inventories and events are and the section outlines what software inventories and events are and the
requirements on SW-PCs and SW-PVs in order to support the stated use requirements on SW-PCs and SW-PVs in order to support the stated use
cases of this specification. cases of this specification.
3.1. Information Sources 3.1. Data Sources
The records in an endpoint's software inventory evidence collection The records in an endpoint's software inventory evidence collection
come from one or more "sources". A source represents one collection come from one or more "sources". A source represents one collection
of software inventory information about the endpoint. Examples of of software inventory information about the endpoint. Examples of
sources include, but are not limited to, ISO SWID tags deposited on sources include, but are not limited to, ISO SWID tags deposited on
the filesystem and collected therefrom, information derived from the filesystem and collected therefrom, information derived from
package managers (e.g., RPM or YUM), and the output of software package managers (e.g., RPM or YUM), and the output of software
inventory scanning tools. inventory scanning tools.
There is no expectation that any one source of inventory information There is no expectation that any one source of inventory information
skipping to change at page 14, line 47 skipping to change at page 13, line 36
other means. other means.
A SW-PC is not required to utilize every possible source of software A SW-PC is not required to utilize 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, or it could only to one or a handful of software inventory sources, or it could
be designed to dynamically accommodate new sources. For all software be designed to dynamically accommodate new sources. For all software
inventory evidence sources that a particular SW-PC supports, it MUST inventory evidence sources that a particular SW-PC supports, it MUST
completely support all requirements of this specification with regard completely support all requirements of this specification with regard
to those sources. A potential source that cannot support some set of to those sources. A potential source that cannot support some set of
required functionality (e.g. it is unable to monitor the software it required functionality (e.g. it is unable to monitor the software it
reports for change events, as discussed in section 3.4), it MUST NOT reports for change events, as discussed in Section 3.6) MUST NOT be
be used as a source of endpoint software inventory information, even used as a source of endpoint software inventory information, even if
if it could provide some information. In other words, a source it could provide some information. In other words, a source either
either supports full functionality as described in this supports full functionality as described in this specification, or it
specification, or it cannot be used at all. cannot be used at all.
When sending information about installed software the SW-PC MUST When sending information about installed software the SW-PC MUST
include the complete set of relevant data from all supported sources include the complete set of relevant data from all supported sources
of software inventory evidence. In other words, sources need to be of software inventory evidence. In other words, sources need to be
used consistently. This is because, if a particular source is used consistently. This is because, if a particular source is
included in an initial inventory, but excluded from a later included in an initial inventory, but excluded from a later
inventory, the SW-PV receiving this information might reasonably inventory, the SW-PV receiving this information might reasonably
conclude that the software reported by that source was no longer conclude that the software reported by that source was no longer
installed on the endpoint. As such, it is important that all installed on the endpoint. As such, it is important that all
supported sources be used every time the SW-PC provides information supported sources be used every time the SW-PC provides information
skipping to change at page 15, line 29 skipping to change at page 14, line 18
a single installation of a software product. When a SW-PC reports a single installation of a software product. When a SW-PC reports
information or records events from multiple inventory evidence information or records events from multiple inventory evidence
sources, it MUST use the information those sources provide, rather sources, it MUST use the information those sources provide, rather
than attempting to perform some form of reduction. In other words, than attempting to perform some form of reduction. In other words,
if multiple sources report records corresponding to a single if multiple sources report records corresponding to a single
installation of a software product, all such records from each source installation of a software product, all such records from each source
are required to be part of the SW- PC's processing even if this might are required to be part of the SW- PC's processing even if this might
lead to multiple reporting, and the SW-PC is not to ignore some lead to multiple reporting, and the SW-PC is not to ignore some
records to avoid such multiple reporting. records to avoid such multiple reporting.
All inventory records reported by a SW-PC include a Source Identifier
linking them to a particular source. Source Identifiers are
discussed more in Section 3.4.5.
3.2. Data Models 3.2. Data Models
Software Inventory Message and Attributes supports an open set of Software Inventory Message and Attributes supports an open set of
data models by which installed software instances can be described. data models by which installed software instances can be described.
This reflects the fact that, as of the writing of this specification, This reflects the fact that, as of the writing of this specification,
no one software description data model has come to dominate use, and no one software description data model has come to dominate use, and
new models are being developed regularly. new models are being developed regularly. As a result, information
available to SW-PCs might come in a variety of formats, and a SW-PC
could have little control over the format of the data it is able to
collect.
The format of the data model used to convey software inventory The format of the data model used to convey software inventory
information had very little impact on the behavior of the components information had very little impact on the behavior of the components
defined in this specification. The SW-PV has no dependency on the defined in this specification. The SW-PV has no dependency on the
data model conveyed in SWIMA messages. For this reason, it MUST NOT data model conveyed in SWIMA messages. For this reason, it MUST NOT
reject a record or respond with a PA-TNC Error due to the data model reject a record or respond with a PA-TNC Error due to the data model
used in attributes it receives. (Note that the SW-PV might serve as used in attributes it receives. (Note that the SW-PV might serve as
the front-end of other functionality that does have a dependency on the front-end of other functionality that does have a dependency on
the data model used to express software information, but any such the data model used to express software information, but any such
dependency is beyond the scope of this specification and needs to be dependency is beyond the scope of this specification and needs to be
addressed outside the behaviors specified in this document. This addressed outside the behaviors specified in this document. This
specification is only concerned with collection and delivery of specification is only concerned with collection and delivery of
software inventory information; components that consume and use this software inventory information; components that consume and use this
information are a separate concern.) information are a separate concern.)
The SW-PC does have one functional dependency on the data models used The SW-PC does have one functional dependency on the data models used
in the software records it delivers, but only insofar as it is in the software records it delivers, but only insofar as it is
required to create a Software Identifier (described in Section 3.4.1) required to deterministically create a Software Identifier (described
based on each record it delivers. The SW-PC MUST be able to generate in Section 3.4.1) based on each record it delivers. The SW-PC MUST
a Software Identifier for each record it delivers, and if the SW-PC be able to generate a Software Identifier for each record it
cannot do so the record cannot be delivered by the SW-PC. All SW-PCs delivers, and if the SW-PC cannot do so the record cannot be
MUST be able to generate Software Identifiers for the data model delivered by the SW-PC. All SW-PCs MUST at least be able to generate
types specified in Section 5 of this document. Software Identifiers for the data model types specified in Section 6
of this document. A SW-PC MAY include the ability to generate
Software Identifiers for other data model types, and thus be able to
support them as well.
3.3. Basic Attribute Exchange 3.3. 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 some type of information sends a request to the SW-PC requesting some type of information
about the endpoint's software inventory. This simple exchange is about the endpoint's software inventory. This simple exchange is
shown in Figure 2. shown in Figure 2.
+-------------+ +--------------+ +-------------+ +--------------+
| SW-PC | | SW-PV | Time | SW-PC | | SW-PV | Time
skipping to change at page 17, line 35 skipping to change at page 16, line 34
following sections examine these three types of information in more following sections examine these three types of information in more
detail. detail.
3.4.1. Software Identifiers 3.4.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 Inventory Message and specific software product. The Software Inventory Message and
Attributes for PA-TNC specification does not dictate the structure of Attributes for PA-TNC specification does not dictate the structure of
a Software Identifier (beyond stating that it is a string) or define a Software Identifier (beyond stating that it is a string) or define
how it is created. Instead, each data model described in the how it is created. Instead, each data model described in the
Software Data Model IANA table (Section 9.4) includes its own rules Software Data Model IANA table (Section 10.4) includes its own rules
for how a Software Identifier is created based on a record in the for how a Software Identifier is created based on a record in the
Endpoint's Software Inventory Evidence Collection expressed in that Endpoint's Software Inventory Evidence Collection expressed in that
data model. Other data models will have their own procedures for the data model. Other data models will have their own procedures for the
creation of associated Software Identifiers. Within the Software creation of associated Software Identifiers. Within the Software
Inventory Message and Attributes for PA-TNC specification, the Inventory Message and Attributes for PA-TNC specification, the
Software Identifier is simply an opaque string and there is never any Software Identifier is simply an opaque string and there is never any
need to unpack any information that might be part of that identifier. need to unpack any information that might be part of that identifier.
A Software Identifier is a fraction of the size of the inventory A Software Identifier is a fraction of the size of the inventory
record from which it is derived. For some combinations of data record from which it is derived. For some combinations of data
skipping to change at page 19, line 11 skipping to change at page 18, line 11
might be different. Clearly identifying the type of data model from might be different. Clearly identifying the type of data model from
with the Software Identifier was derived thus provides useful context with the Software Identifier was derived thus provides useful context
for that value. for that value.
The PEN (or Private Enterprise Number) identifies the organization The PEN (or Private Enterprise Number) identifies the organization
that assigns meaning to the Data Model Type field value. PENs are that assigns meaning to the Data Model Type field value. PENs are
managed by IANA in the Private Enterprise Numbers registry. PENs managed by IANA in the Private Enterprise Numbers registry. PENs
allow vendors to designate their own set of data models for software allow vendors to designate their own set of data models for software
inventory description. IANA reserves the PEN of 0x000000. Data inventory description. IANA reserves the PEN of 0x000000. Data
Model Types associated with this PEN are defined in the Software Data Model Types associated with this PEN are defined in the Software Data
Model IANA table, created in Section 9.4 of this specification. Note Model IANA table, created in Section 10.4 of this specification.
that this IANA table reserves all values greater than or equal to Note that this IANA table reserves all values greater than or equal
0xC0 (192) for enterprise use. This means that local enterprises can to 0xC0 (192) for enterprise use. This means that local enterprises
use custom data formats and indicate them with the IANA PEN and a can use custom data formats and indicate them with the IANA PEN and a
Data Model Type value between 0xC0 and 0XFF, inclusive. Those Data Model Type value between 0xC0 and 0XFF, inclusive. Those
enterprises are responsible for configuring their SW-PCs to correctly enterprises are responsible for configuring their SW-PCs to correctly
report those custom data models. report those custom data models.
3.4.3. Record Identifiers 3.4.3. Record Identifiers
A Record Identifier is a 4-byte integer generated by the SW-PC that A Record Identifier is a 4-byte integer generated by the SW-PC that
is 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
skipping to change at page 20, line 37 skipping to change at page 19, line 37
scheme and an empty path.) However, SW-PCs SHOULD only make such an 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 assignment as a last resort. Even a probable location for a software
product is preferable to using the unknown indicator. product is preferable to using the unknown indicator.
3.4.5. Source Identifiers 3.4.5. Source Identifiers
All SW-PCs MUST track the source of each piece of software All SW-PCs MUST track the source of each piece of software
information they report. Each time a SW-PC gets information to send information they report. Each time a SW-PC gets information to send
to a given SW-PV from a new source (from the perspective of that SW- to a given SW-PV from a new source (from the perspective of that SW-
PV), the SW-PC MUST assign that source a Source Identification PV), the SW-PC MUST assign that source a Source Identification
Number, which is a 7-bit unsigned integer. Each item reported Number, which is an 8-bit unsigned integer. Each item reported
includes the Source Identification Number that provided that includes the Source Identification Number that provided that
information. The first time a source is used, the Source information. All information that is provided by that source, MUST
Identification Number is accompanied by setting the Source First Use be delivered with this same Source Identification Number. This MUST
flag. This MUST be done on all records from that source sent in the be done for each source used. If the SW-PC ever is unclear as to
attribute that sends those records. From that point on, all whether a given source is new or not, it MUST assume that this is a
information that is provided by that source, MUST be delivered with new source and assign it a new Source Identification Number. Source
this same Source Identification Number. This MUST be done for each Identification Numbers can help with (although will not completely
source used. If the SW-PC ever is unclear as to whether a given eliminate) the challenges posed by multiple reporting of a single
source is new or not, it MUST assume that this is a new source and software instance: since a single source would only report an
assign it a new Source Identification Number. Source Identification instance or event once, if multiple reports of a similar instance
Numbers can help with (although will not completely eliminate) the come from multiple sources, this might be an instance of multiple
challenges posed by multiple reporting of a single software instance: reporting (although it still might not be so). On the other hand, if
since a single source would only report an instance or event once, if multiple instances are reported by a single source, this almost
multiple reports of a similar instance come from multiple sources, certainly means that there are actually multiple instance that are
this might be an instance of multiple reporting (although it still being legitimately reported.
might not be so). On the other hand, if multiple instances are
reported by a single source, this almost certainly means that there The SW-PC is responsible for tracking associations between Source
are actually multiple instance that are being legitimately reported. Identifiers and the given data source. This association MUST remain
consistent with regard to a given SW-PV while there is an active PB-
TNC session with that SW-PV. The SW-PC MAY have a different Source
Identifier association for different SW-PVs. Likewise, the SW-PC MAY
change the Source Identifier association for a given SW-PV if the PB-
TNC session terminates. However, implementers of SW-PCs will
probably find it easier to manage associations by maintaining the
same association for all SW-PVs and across multiple sessions.
Of special note, events records reported from the SW-PC's event log
(discussed in Section 3.7) also need to be sent with their associated
data source. The Source Identifier reported with events MUST be the
current (i.e., at the time the event is sent) Source Identifier
associated with the data source that produced the event, regardless
of how long ago that event occurred. Event logs are likely to
persist far longer than a single PB-TNC session. SW-PCs MUST ensure
that each event can be linked to the appropriate data source, even if
the Source Identifiers used when the event was created have since
been reassigned. In other words, when sending an event, it needs to
be sent with the Source Identifier currently linked to the data
source that produced it, regardless of whether a different Source
Identifier would have been associated with the event when the event
was first created.
Note that the Source Identification Number is primarily used to Note that the Source Identification Number is primarily used to
support recognition, rather than identification, of sources. That is support recognition, rather than identification, of sources. That is
to say, a Software Identification Number can tell a recipient that to say, a Software Identification Number can tell a recipient that
two events were reported by the same source, but will not necessarily two events were reported by the same source, but will not necessarily
help that recipient determine which source was used. Moreover, help that recipient determine which source was used. Moreover,
different SW-PCs will not necessarily use the same Source different SW-PCs will not necessarily use the same Source
Identification Numbers for the same sources. SW-PCs MUST track the Identification Numbers for the same sources. SW-PCs MUST track the
assignment of Source Identification Numbers to ensure consistent assignment of Source Identification Numbers to ensure consistent
application thereof. SW-PCs MUST also track which Source application thereof. SW-PCs MUST also track which Source
Identification Numbers have been used with each SW-PV with which they Identification Numbers have been used with each SW-PV with which they
communicate. The "first use" of a source MUST correspond to the communicate.
first use as seen by each individual SW-PV.
3.4.6. Using Software and Record Identifiers in SW Attributes 3.4.6. Using Software and Record Identifiers in SW Attributes
A SW Attribute reporting an endpoint's Software Inventory Evidence A SW Attribute reporting an endpoint's Software Inventory Evidence
Collection always contains the Software Identifiers associated with Collection always contains the Software Identifiers associated with
the identified software products. A SW Attribute might or might not the identified software products. A SW Attribute might or might not
also contain copies of software inventory evidence records. The also contain copies of software inventory evidence records. The
attribute exchange is identical to the diagram shown in Figure 2 attribute exchange is identical to the diagram shown in Figure 2
regardless of whether software inventory evidence records are regardless of whether software inventory evidence records are
included. The SW Request attribute indicates whether the response is included. The SW Request attribute indicates whether the response is
skipping to change at page 32, line 37 skipping to change at page 32, line 11
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 or might previous sections. Specifically, such a SW Request might or might
not request inclusion of software inventory evidence records, might not request inclusion of software inventory evidence records, might
or might not be targeted, and might request change event records or or might not be targeted, and might request change event records or
endpoint inventory. Assuming no error is encountered, a SW-PC MUST endpoint inventory. Assuming no error is encountered, a SW-PC MUST
send a SW Response attribute in direct response to this SW Request send a SW Response attribute in direct response to this SW Request
attribute, just as if the Subscription flag was not set. As such, attribute, just as if the Subscription flag was not set. As such,
the attribute exchange that establishes a new subscription in a SW-PC the attribute exchange that establishes a new subscription in a SW-PC
has the same flow seen in the previous attribute exchanges, as has the same flow seen in the previous attribute exchanges, as
depicted in Figure 2. If the SW-PV does not receive a PA-TNC Error depicted in Figure 2. If the SW-PV does not receive a PA-TNC Error
attribute (as described in Section 3.9 and Section 4.14) in response attribute (as described in Section 3.9 and Section 5.16) in response
to their subscription request, the subscription has been successfully to their subscription request, the subscription has been successfully
established on the SW-PC. The SW Request attribute that establishes established on the SW-PC. The SW Request attribute that establishes
a new subscription is referred to as the "establishing request" for a new subscription is referred to as the "establishing request" for
that subscription. 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.6.) Section 5.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.8.2. Managing Subscriptions 3.8.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 33, line 26 skipping to change at page 32, line 49
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.8.3. Terminating Subscriptions 3.8.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.7 for more on using this flag.) In the case that a SW Section 5.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 39, line 25 skipping to change at page 38, line 44
unauthorized tampering. In other words, there needs to be some unauthorized tampering. In other words, there needs to be some
assurance that unauthorized individuals are not able to introduce assurance that unauthorized individuals are not able to introduce
long delays in subscription fulfillment. long delays in subscription fulfillment.
3.9. Error Handling 3.9. 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.14 in this Error attributes and error codes as well as Section 5.16 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 40, line 37 skipping to change at page 40, line 7
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 entries 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 Inventory Message and Attributes for PA-TNC Protocol 4. Protocol
This section describes the format and semantics of the Software
Inventory Message and Attributes for PA-TNC protocol. Software
Inventory Message and Attributes for PA-TNC uses the standard PA-TNC
message header format. See the PA-TNC specification [RFC5792] for
information on this header format.
4.1. PA Subtype (AKA PA-TNC Component Type)
The NEA PB-TNC interface provides a general message-batching protocol
capable of carrying one or more PA-TNC messages between the Posture
Broker Client and Posture Broker Server. When PB-TNC is carrying a
PA-TNC message, the PB-TNC message headers contain a 32 bit
identifier called the PA Subtype. The PA Subtype field indicates the
type of component associated with all of the PA-TNC attributes
carried by the PB-TNC message. The core set of PA Subtypes is
defined in the PA-TNC specification. This specification adds the
following enumeration element to the IANA registry defined in section
7.2 of the PA-TNC specification [RFC5792] using the IETF Standard
name space (SMI Private Enterprise Number 0x000000):
+-----+---------+------------+--------------------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+------------+--------------------------------------+
| 0 | 9 | SW | Software Inventory Message and |
| | | Attributes | Attributes for PA-TNC |
+-----+---------+------------+--------------------------------------+
Table 2: PA Subtype
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
message indicating a PA Subtype of SW Attributes. Note that although
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
Component Definition Value, as described in Section 4.2.8 of the PA-
TNC specification [RFC5792]. PB-TNC messages MUST always include the
SW Attributes Subtype defined in this section when carrying SW
Attributes over PA-TNC.
For more information on PB-TNC and PA-TNC messages and message
headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792]
specifications, respectively.
4.2. SW Attribute Overview
The attributes defined in this specification appear below with a
short summary of their purposes. Each attribute is described in
greater detail in subsequent sections.
o SW Request - This attribute is used to request a software
inventory or software event list from an endpoint. This attribute
might also establish a subscription on the recipient SW-PC. A SW-
PC MUST NOT send this attribute.
o Software Identifier Inventory - This attribute is used to convey
an inventory without the inclusion of software inventory evidence
records. When a SW-PC receives a SW Request attribute requesting
an inventory without software inventory evidence records, the SW-
PC MUST send a Software Identifier Inventory attribute (or a PA-
TNC Error) in response. This attribute also MAY be sent by the
SW-PC in fulfillment of an active subscription. A SW-PV MUST NOT
send this attribute.
o Software Identifier Events - This attribute is used to convey a
list of events concerning changes to an endpoint's Software
Inventory Evidence Collection. Reported events do not include
software inventory evidence records. When a SW-PC receives a SW
Request attribute requesting an event collection without software
inventory evidence records, the SW-PC MUST send a Software
Identifier Events attribute (or a PA-TNC Error) in response. This
attribute also MAY be sent by the SW-PC in fulfillment of an
active subscription. A SW-PV MUST NOT send this attribute.
o Software Inventory - This attribute is used to convey an inventory
expressed including software inventory evidence records. When a
SW-PC receives a SW Request attribute requesting an inventory
including software inventory evidence records, the SW-PC MUST send
a Software Inventory attribute (or a PA-TNC Error) in response.
This attribute also MAY be sent by the SW-PC in fulfillment of an
active subscription. A SW-PV MUST NOT send this attribute.
o Software Events - This attribute is used to convey a list of
events concerning changes to an endpoint's inventory evidence
collection. Reported events include software inventory evidence
records. When a SW-PC receives a SW Request attribute requesting
an event collection including software inventory evidence records,
the SW-PC MUST send a Software Events attribute (or a PA-TNC
Error) in response. This attribute also MAY be sent by the SW-PC
in fulfillment of an active subscription. A SW-PV MUST NOT send
this attribute.
o Subscription Status Request - This attribute is used to request a
SW-PC send a summary of all the active subscriptions it has where
the requesting party is the subscriber. The SW-PC MUST respond
with a Subscription Status Response (or a PA-TNC Error). A SW-PC
MUST NOT send this attribute.
o Subscription Status Response - This attribute is used to convey
information about the active subscriptions that a SW-PC has for a
given subscriber. A SW-PV MUST NOT send this attribute.
o PA-TNC Error - This is the standard PA-TNC Error attribute as
defined in PA-TNC [RFC5792] and is used to indicate that an error
was encountered during a SW Attribute exchange. It MUST be sent
by a SW-PC in response to a SW Request in the case where the SW-PC
encounters a fatal error (i.e., an error that prevents further
processing of an exchange) relating to the attribute exchange. A
SW-PV MUST NOT send this attribute. The SW-PC MUST then ignore
the erroneous attribute after a PA-TNC Error attribute is sent
(i.e., do not attempt to act on an attribute that generated a PA-
TNC Error beyond sending the PA-TNC Error). In the case where the
SW-PV experiences a fatal error, it MUST ignore the erroneous
attribute without sending a PA-TNC Error attribute. It MAY take
other actions in response to the error, such as logging the cause
of the error, or even taking actions to isolate the endpoint
Because one of the Software Identifier Inventory, Software Identifier
Events, Software Inventory, or Software Events attributes is expected
to be sent to a SW-PV in direct response to a SW Request attribute or
in fulfillment of an active subscription, those four attribute types
are referred to collectively in this document as "SW Response"
attributes.
All SW-PVs MUST be capable of sending SW Requests and be capable of The software inventory protocol supports two different types of
receiving and processing all SW Response attributes as well as PA-TNC message exchanges which are described the following subsections,
Error attributes. All SW-PCs MUST be capable of receiving and along with implementation requirements for supporting these
processing SW Requests and be capable of sending all types of SW exchanges.
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
exchanges using any of the attribute types defined in this section.
SW-PVs MUST ignore any SW Request attributes that they receive. SW-
PCs MUST ignore any SW Response attributes or PA-TNC Error attributes
that they receive.
4.3. SW Attribute Exchanges 4.1. Direct Response to a SW Request
A SW Attribute Exchange is used to provide the SW-PV with a software The first type of exchange is used to provide the SW-PV with a
inventory or event collection from the queried endpoint. software 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 | |
skipping to change at page 44, line 31 skipping to change at page 40, line 45
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 (with or without software inventory evidence records). be expressed (with or without software inventory evidence records).
The SW-PC responds with the requested information using the The SW-PC responds with the requested information using the
appropriate attribute type. A single SW Request MUST only lead to a appropriate attribute type. A single SW Request MUST only lead to a
single SW Response or PA-TNC Error that is in direct response to that single SW Response or PA-TNC Error that is in direct response to that
request. request.
In addition, if there is an active subscription on the endpoint, the 4.2. Subscription-Based Response
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 second type of exchange allows change event-based reporting based
is shown in Figure 5. on a subscription. 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 the endpoint in fulfillment of that subscription.
Such an exchange 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 5: 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. When providing multiple SW
Responses conveys a complete list of event records. (That is, the Responses in this way, the initial responses contain partial lists of
initial responses are partial lists and the last response is the event records and the last of those SW Responses conveys 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 in response to the change event. A single Change
Change Event MUST NOT otherwise be followed by multiple SW Response Event MUST NOT otherwise be followed by multiple SW Response or PA-
or PA-TNC Error attributes in any combination. TNC Error attributes in any combination.
4.3. Required Exchanges
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.8. subscriptions, as described in Section 3.8.
4.4. Software Inventory Message and Attributes for PA-TNC Attribute 5. Software Inventory Messages and Attributes
This section describes the format and semantics of the Software
Inventory Message and Attributes for PA-TNC protocol. This protocol
uses the PA-TNC message header format [RFC5792].
5.1. PA Subtype (AKA PA-TNC Component Type)
The NEA PB-TNC interface provides a general message-batching protocol
capable of carrying one or more PA-TNC messages between the Posture
Broker Client and Posture Broker Server. When PB-TNC is carrying a
PA-TNC message, the PB-TNC message headers contain a 32 bit
identifier called the PA Subtype. The PA Subtype field indicates the
type of component associated with all of the PA-TNC attributes
carried by the PB-TNC message. The core set of PA Subtypes is
defined in the PA-TNC specification. This specification defines a
new "SW Attributes" PA Subtype, which is registered in Section 10.1
of this document, which is used as a namespace for the collection of
SW attributes defined in this document.
For more information on PB-TNC and PA-TNC messages and message
headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792]
specifications, respectively.
5.2. SW Attribute Overview
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
message indicating a PA Subtype of "SW Attributes". PB-TNC messages
MUST always include the SW Attributes Subtype defined in Section 5.1
when carrying SW Attributes over PA-TNC. The attributes defined in
this specification appear below along with a short summary of their
purposes. Each attribute is described in greater detail in
subsequent sections.
SW Request: This attribute is used to request a software inventory
or software event list from an endpoint. This attribute might also
establish a subscription on the recipient SW-PC. See Section 5.7
for more information.
Software Identifier Inventory: This attribute is used to convey an
inventory without the inclusion of software inventory evidence
records. See Section 5.8 for more information.
Software Identifier Events: This attribute is used to convey a list
of events concerning changes to an endpoint's Software Inventory
Evidence Collection. Reported events do not include software
inventory evidence records. See Section 5.9 for more information.
Software Inventory: This attribute is used to convey an inventory
expressed including software inventory evidence records. See
Section 5.10 for more information.
Software Events: This attribute is used to convey a list of events
concerning changes to an endpoint's inventory evidence collection.
Reported events include software inventory evidence records. See
Section 5.11 for more information.
Subscription Status Request: This attribute is used to request a SW-
PC send a summary of all the active subscriptions it has where the
requesting party is the subscriber. See Section 5.12 for more
information.
Subscription Status Response: This attribute is used to convey
information about the active subscriptions that a SW-PC has for a
given subscriber. See Section 5.13 for more information.
Source Metadata Request: This attribute is used to request a SW-PC
send metadata about the sources is uses to collect software
inventory information. See Section 5.14 for more information.
Source Metadata Response: This attribute is used to convey
descriptive metadata about the sources a SW-PC uses to collect
software inventory information. See Section 5.15 for more
information.
PA-TNC Error: This is the standard PA-TNC Error attribute as defined
in PA-TNC [RFC5792] and is used to indicate that an error was
encountered during a software inventory exchange. Use of the PA-
TNC attribute by Software Inventory Message and Attributes for PA-
TNC is described in Section 5.16.
Because one of the Software Identifier Inventory, Software Identifier
Events, Software Inventory, or Software Events attributes are
expected to be sent to a SW-PV in direct response to a SW Request
attribute or in fulfillment of an active subscription, those four
attribute types are referred to collectively in this document as "SW
Response attributes".
All SW-PVs MUST be capable of sending SW Request attributes and be
capable of receiving and processing all SW Response attributes as
well as PA-TNC Error attributes. All SW-PCs MUST be capable of
receiving and processing SW Request attributes and be capable of
sending all types of SW 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 exchanges using any of the attribute types
defined in this section. SW-PVs MUST ignore any SW Request
attributes that they receive. SW-PCs MUST ignore any SW Response
attributes or PA-TNC Error attributes that they receive.
5.3. Message Diagram Syntax
This specification defines the syntax of new PA-TNC messages and
attributes using diagrams. Each diagram depicts the format and size
of each field in bits. Implementations MUST send the bits in each
diagram as they are shown from left to right for each 32-bit quantity
traversing the diagram from top to bottom. Multi-octet fields
representing numeric values MUST be sent in network (big endian) byte
order.
Descriptions of bit fields (e.g. flags) values refer to the position
of the bit within the field. These bit positions are numbered from
the most significant bit through the least significant bit. As such,
an octet with only bit 0 set would have a value of 0x80 (1000 0000),
an octet with only bit 1 set would have a value of 0x40 (0100 0000),
and an octet with only bit 7 set would have a value of 0x01 (0000
0001).
5.4. Software Inventory Message and Attributes for PA-TNC Attribute
Enumeration 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
via the Attribute Type Vendor ID and Attribute Type fields. Table 3 via the Attribute Type Vendor ID and Attribute Type fields. Table 2
identifies the appropriate values for these fields for each attribute identifies the appropriate values for these fields for each attribute
type used within the Software Inventory Message and Attributes for type used within the Software Inventory Message and Attributes for
PA-TNC protocol. PA-TNC protocol. The following is a summary of the registered
attributes. All attributes have a PEN value of 0x000000. For the
Integer value field, both the hexadecimal and decimal values are
provided.
+--------------+----------+------------+----------------------------+ +--------------+------------+---------------------------------------+
| Attribute | PEN | Integer | Description | | Attribute | Integer | Description |
| Name | | | | | Name | | |
+--------------+----------+------------+----------------------------+ +--------------+------------+---------------------------------------+
| SW Request | 0x000000 | 0x00000011 | Request from a SW-PV to a | | SW Request | 0x00000011 | Request from a SW-PV to a SW-PC for |
| | | | SW-PC for the SW-PC to | | | (17) | the SW-PC to provide a software |
| | | | provide a software | | | | inventory or event list |
| | | | inventory or event list | | | | |
| | | | | | Software | 0x00000012 | An inventory sent without software |
| Software | 0x000000 | 0x00000012 | An inventory sent without | | Identifier | (18) | inventory evidence records sent from |
| Identifier | | | software inventory | | Inventory | | a SW-PC. |
| Inventory | | | evidence records sent from | | | | |
| | | | a SW-PC. | | Software | 0x00000013 | A collection of events impacting the |
| | | | | | Identifier | (19) | endpoint's Software Inventory |
| Software | 0x000000 | 0x00000013 | A collection of events | | Events | | Evidence Collection, where events do |
| Identifier | | | impacting the endpoint's | | | | not include software inventory |
| Events | | | Software Inventory | | | | evidence records. |
| | | | Evidence Collection, where | | | | |
| | | | events do not include | | Software | 0x00000014 | An inventory including software |
| | | | software inventory | | Inventory | (20) | inventory evidence records sent from |
| | | | evidence records. | | | | a SW-PC. |
| | | | | | | | |
| Software | 0x000000 | 0x00000014 | An inventory including | | Software | 0x00000015 | A collection of events impacting the |
| Inventory | | | software inventory | | Events | (21) | endpoint's Software Inventory |
| | | | evidence records sent from | | | | Evidence Collection, where events |
| | | | a SW-PC. | | | | include software inventory evidence |
| | | | | | | | records. |
| Software | 0x000000 | 0x00000015 | A collection of events | | | | |
| Events | | | impacting the endpoint's | | Subscription | 0x00000016 | A request for a list of a SW-PV's |
| | | | Software Inventory | | Status | (22) | active subscription on a SW-PC. |
| | | | Evidence Collection, where | | Request | | |
| | | | events include software | | | | |
| | | | inventory evidence | | Subscription | 0x00000017 | A list of a SW-PV's active |
| | | | records. | | Status | (23) | subscriptions on a SW-PC. |
| | | | | | Response | | |
| Subscription | 0x000000 | 0x00000016 | A request for a list of a | | | | |
| Status | | | SW-PV's active | | Source | 0x00000018 | A request for information about a SW- |
| Request | | | subscription. | | Metadata | (24) | PC's data sources. |
| | | | | | Request | | |
| Subscription | 0x000000 | 0x00000017 | A list of a SW-PV's active | | | | |
| Status | | | subscriptions. | | Subscription | 0x00000019 | Descriptive metadata about a SW-PC's |
| Response | | | | | Status | (25) | data sources. |
| | | | | | Response | | |
| Reserved | 0x000000 | 0x00000018 | These attribute types are | | | | |
| | | - | reserved for future use in | | Reserved | 0x0000001A | These attribute types are reserved |
| | | 0x0000001F | revisions to Software | | | - | for future use in revisions to |
| | | | Inventory Message and | | | 0x0000001F | Software Inventory Message and |
| | | | Attributes for PA-TNC. | | | (26 - 31) | Attributes for PA-TNC. |
| | | | | | | | |
| PA-TNC Error | 0x000000 | 0x00000008 | An error attribute as | | PA-TNC Error | 0x00000008 | An error attribute as defined in the |
| | | | defined in the PA-TNC | | | (8) | PA-TNC specification [RFC5792]. |
| | | | specification [RFC5792]. | +--------------+------------+---------------------------------------+
+--------------+----------+------------+----------------------------+
Table 3: SW Attribute Enumeration Table 2: SW Attribute Enumeration
4.5. Normalization of Text Encoding 5.5. Normalization of Text Encoding
In order to ensure consistency of transmitted attributes some fields In order to ensure consistency of transmitted attributes some fields
require normalization of their format. When this is necessary, this require normalization of their format. When this is necessary, this
is indicated in the field's description. In such cases, the field is indicated in the field's description. In such cases, the field
contents MUST be normalized to Network Unicode format as defined in contents MUST be normalized to Network Unicode format as defined in
RFC 5198 [RFC5198]. Network Unicode format defines a refinement of RFC 5198 [RFC5198]. Network Unicode format defines a refinement of
UTF-8 that ensures a normalized expression of characters. SW-PCs and UTF-8 that ensures a normalized expression of characters. SW-PCs and
SW-PVs MUST NOT perform conversion and normalization on any field SW-PVs MUST NOT perform conversion and normalization on any field
values except those specifically identified as requiring values except those specifically identified as requiring
normalization in the following sections. Note, however, that some normalization in the following sections. Note, however, that some
data models require additional normalization before source data models require additional normalization before source
information is added to an Endpoint's Inventory Evidence Collection information is added to an Endpoint's Inventory Evidence Collection
as a record. The references from the Software Data Model IANA table as a record. The references from the Software Data Model IANA table
(see Section 9.4) will note where this is necessary. (see Section 10.4) will note where this is necessary.
4.6. Request IDs 5.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.
exhausted within the lifetime of a single network connection ID, the
sender MAY reuse previously used Request IDs within the same network
connection that are not being used as Subscription IDs. (See below
in this section for an explanation of Subscription ID assignment.)
In this case of Request ID reuse, Request IDs SHOULD be reused in the
order of their original use. In other words, a SW-PC SHOULD NOT use
a given Request ID value more than once within a persistent
connection between a given Posture Broker Client-Posture Broker
Server pair, but, in the case where reuse is necessary due to
exhaustion of possible ID values, the SW-PC SHOULD structure the
reuse to maximize the time between original and subsequent use. The
Request ID value is included in a SW Response attribute directly
responding to this SW Request to indicate which SW Request was
received and caused the response. Request IDs can be randomly
generated or sequential, as long as values are not repeated 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.7. SW Request In the case where all possible Request ID values have been exhausted
within the lifetime of a single network connection ID, the sender MAY
reuse previously used Request IDs within the same network connection
if the ID is not being used as a Subscription ID. In such a case of
Request ID reuse, Request IDs SHOULD be reused in the order of their
original use. In other words, a SW-PC SHOULD NOT use a given Request
ID value more than once within a persistent connection between a
given Posture Broker Client-Posture Broker Server pair. In the case
where reuse is necessary due to exhaustion of possible ID values, the
SW-PC SHOULD structure the reuse to maximize the time between
original and subsequent use. The Request ID value is included in a
SW Response attribute directly responding to this SW Request to
indicate which SW Request was received and caused the response.
Request IDs can be randomly generated or sequential, as long as
values are not repeated per the rules in this paragraph. SW-PCs are
not required to check for duplicate Request IDs.
5.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 49, line 49 skipping to change at page 49, line 4
| | 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 Identifier field. | | Identifier | in bytes of the Software Identifier field. |
| Length | | | Length | |
| | | | | |
| Software | A string containing the Software Identifier value | | Software | A string containing the Software Identifier value |
| Identifier | 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.5. This string | | | format, as described in Section 5.5. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
Table 4: SW Request Attribute Fields
Table 3: 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 50, line 30 skipping to change at page 49, line 34
requester are deleted as described in Section 3.8.3. A newly requester are deleted as described in Section 3.8.3. A newly
established subscription has the parameters outlined in the Request established subscription has the parameters outlined in the Request
attribute. Specifically, the Result Type flag indicates the type of attribute. Specifically, the Result Type flag indicates the type of
result to send in fulfillment of the subscription, the value of the result to send in fulfillment of the subscription, the value of the
Earliest EID field indicates whether the fulfillment attributes list Earliest EID field indicates whether the fulfillment attributes list
inventories or events, and the fields describing Software Identifiers inventories or events, and the fields describing Software Identifiers
(if present) indicate if and how a subscription is targeted. In the (if present) indicate if and how a subscription is targeted. In the
case that the SW-PC is unable or unwilling to comply with the SW-PV's case that the SW-PC is unable or unwilling to comply with the SW-PV's
request to establish or clear subscriptions, the SW-PC MUST respond request to establish or clear subscriptions, the SW-PC MUST respond
with a PA-TNC Error attribute with the SW_SUBSCRIPTION_DENIED_ERROR with a PA-TNC Error attribute with the SW_SUBSCRIPTION_DENIED_ERROR
error code. (Note that if the SW-PV requests that subscriptions be error code. If the SW-PV requests that subscriptions be cleared but
cleared but has no existing subscriptions, this is not an error.) has no existing subscriptions, this is not an error.
An attribute requesting the establishment of a subscription is An attribute requesting the establishment of a subscription is
effectively doing double-duty, as it is a request for an immediate effectively doing double-duty, as it is a request for an immediate
response from the SW-PC in addition to setting up the subscription. response from the SW-PC in addition to setting up the subscription.
Assuming the SW-PC is willing to comply with the subscription it MUST Assuming the SW-PC is willing to comply with the subscription it MUST
send an appropriate response attribute to a request with the send an appropriate response attribute to a request with the
Subscribe flag set containing all requested information. The same is Subscribe flag set containing all requested information. The same is
true of the Clear Subscription flag - assuming there is no error the true of the Clear Subscription flag - assuming there is no error the
SW-PC MUST generate a response attribute without regard to the SW-PC MUST generate a response attribute without regard to the
presence of this flag in addition to clearing its subscription list. presence of this flag in addition to clearing its subscription list.
Both the Subscribe and Clear Subscription flags MAY be set in a Both the Subscribe and Clear Subscription flags MAY be set in a
single SW Request attribute. In the case where this request is single SW Request attribute. In the case where this request is
successful, the end result MUST be equivalent to the SW-PC clearing successful, the end result MUST be equivalent to the SW-PC clearing
its subscription list for the given SW-PV first and then creating a its subscription list for the given SW-PV first and then creating a
new subscription in accordance with the request parameters. (In new subscription in accordance with the request parameters. In other
other words, do not first create the new subscription and then clear words, do not first create the new subscription and then clear all
all the subscriptions including the one that was just created.) In the subscriptions including the one that was just created. In the
the case that the requested actions are successfully completed, the case that the requested actions are successfully completed, the SW-PC
SW-PC MUST respond with a SW Response attribute. (The specific type MUST respond with a SW Response attribute. The specific type of SW
of SW Response attribute depends on the Result Type and Earliest EID 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 all actions succeed, or none 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 if the SW-PV is requesting
requesting an inventory or event list from the SW-PC. A value of 0 an inventory or event list from the SW-PC. A value of 0 (0x00000000)
(0x00000000) represents a request for inventory information. represents a request for inventory information. Otherwise, the SW-PV
Otherwise, the SW-PV is requesting event information. For Earliest is requesting event information. For Earliest EID values other than
EID values other than 0, the SW-PC's response MUST respond with event 0, the SW-PC's response MUST respond with event records, as described
records, as described in Section 3.7. Note that the request does not in Section 3.7. Note that the request does not identify a particular
identify a particular EID Epoch, since responses can only include EID Epoch, since responses can only include events in the SW-PC's
events in the SW-PC's current EID Epoch. 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 the following fields: Software Identifier Length and represented by the following fields: Software Identifier Length and
Software Identifier. These fields are repeated a number of times Software Identifier. These fields are repeated a number of times
equal to the Software Identifier Count. Note that this could be 0 equal to the Software Identifier Count, which may be 0. The Software
times. The Software Identifier Length field indicates the number of Identifier Length field indicates the number of bytes allocated to
bytes allocated to the Software Identifier field. The Software the Software Identifier field. The Software Identifier field
Identifier field contains a Software Identifier as describe in contains a Software Identifier as describe in Section 3.4.1. The
Section 3.4.1. The presence of one or more Software Identifiers is presence of one or more Software Identifiers is used by the SW-PV to
used by the SW-PV to indicate a targeted request, which seeks only indicate a targeted request, which seeks only inventories of or
inventories of or events affecting software corresponding to the events affecting software corresponding to the given identifiers.
given identifiers. The SW-PC MUST only report software that matched The SW-PC MUST only report software that matched the Software
the Software Identifiers provided in the SW-PVs SW Request attribute. Identifiers provided in the SW-PVs SW Request attribute.
4.8. Software Identifier Inventory 5.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 without the the endpoint's Software Inventory Evidence Collection without the
inclusion of software inventory evidence records. This list might inclusion of software inventory evidence records. This list might
represent a complete inventory or a targeted list of records, represent a complete inventory or a targeted list of records,
depending on the parameters in the SW-PV's request. A SW-PV MUST NOT depending on the parameters in the SW-PV's request. A SW-PV MUST NOT
send this attribute. The SW-PC either sends this attribute in send this attribute. The SW-PC either sends this attribute in
fulfillment of an existing subscription where the establishing fulfillment of an existing subscription where the establishing
request has a Result Type of 1 and the Earliest EID is zero, or in request has a Result Type of 1 and the Earliest EID is zero, or in
direct response to a SW Request attribute where the Result Type is 1 direct response to a SW Request attribute where the Result Type is 1
skipping to change at page 52, line 22 skipping to change at page 51, line 22
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID | | Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier | | Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type| | Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Locator Length | | Software Identifier Length | Software Locator Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|Source Id Num| Software Identifier (variable length) | | Source Id Num | Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator (variable length) | | Software Locator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: 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 |
skipping to change at page 52, line 46 skipping to change at page 51, line 46
| | be unset (0). | | | be unset (0). |
| | | | | |
| Flags: Bit 1-7 | Reserved for future use. This field MUST be set | | Flags: Bit 1-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. |
| | | | | |
| Software | The number of Software Identifiers that follow. | | Software | The number of Software Identifiers that follow. |
| Identifier | This field is an unsigned integer. The Record | | Identifier | This field is an unsigned integer. The Record |
| Count | Identifier, Data Model Type PEN, Data Model | | Count | Identifier, Data Model Type PEN, Data Model |
| | Type, Software Identifier Length, Software | | | Type, Software Identifier Length, Software |
| | Locator Length, Source First Use Flag (F), | | | Locator Length, Source Identification Number, |
| | Source Identification Number, Software | | | Software Identifier, and Software Locator fields |
| | Identifier, and Software Locator fields are | | | are repeated, in order, the number of times |
| | repeated, in order, the number of times |
| | indicated in this field. This field value MAY be | | | indicated in this field. This field value MAY be |
| | 0, in which case there are no instances of these | | | 0, in which case there are no instances of these |
| | fields. | | | 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 | | | of an active subscription, this field MUST |
skipping to change at page 53, line 43 skipping to change at page 52, line 42
| Type | identifier number that identifies the data model | | Type | identifier number that identifies the data model |
| | of the reported record. | | | of the reported record. |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Identifier | in bytes of the SW ID field. | | Identifier | in bytes of the SW ID field. |
| Length | | | Length | |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Locator Length | in bytes of the Software Locator field. | | Locator Length | in bytes of the Software Locator field. |
| | | | | |
| Source First | If set, the following Source Identification |
| Use Flag (F) | Number is the first use of that number. If |
| | unset, the Source Identification Number has been |
| | associated with a source in a previous message. |
| | |
| Source | The Source Identification Number associated with | | Source | The Source Identification Number associated with |
| Identification | the source from which this software installation | | Identification | the source from which this software installation |
| Number | inventory instance was reported. | | Number | inventory instance was reported. |
| | | | | |
| Software | A string containing the Software Identifier | | Software | A string containing the Software Identifier |
| Identifier | value from a software inventory evidence record. | | Identifier | value from a software inventory evidence record. |
| | This field value MUST be normalized to Network | | | This field value MUST be normalized to Network |
| | Unicode format, as described in Section 4.5. | | | Unicode format, as described in Section 5.5. |
| | This string MUST NOT be NULL terminated. | | | This string MUST NOT be NULL terminated. |
| | | | | |
| Software | A string containing the Software Locator value. | | Software | A string containing the Software Locator value. |
| Locator | This is expressed as a URI. This field value | | Locator | This is expressed as a URI. This field value |
| | MUST be normalized to Network Unicode format as | | | MUST be normalized to Network Unicode format as |
| | described in Section 3.4.4. This string MUST NOT | | | described in Section 3.4.4. This string MUST NOT |
| | be NULL terminated. | | | be NULL terminated. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Table 5: Software Identifier Inventory Attribute Fields Table 4: 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
skipping to change at page 55, line 11 skipping to change at page 54, line 5
no recorded change events at the time that this inventory was no recorded change events at the time that this inventory was
collected, the Last EID 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 reflects the interpreted to indicate that the provided inventory reflects the
state of the endpoint after all changes up to and including this last state of the endpoint after all changes up to and including this last
event have been accounted for. event have been accounted for.
The Data Model Type PEN and Data Model Type fields are used to The Data Model Type PEN and Data Model Type fields are used to
identify the data model associated with the given software record. identify the data model associated with the given software record.
These fields are discussed more in Section 3.4.2. These fields are discussed more in Section 3.4.2.
The Source First Use flag and the Source Identification Number field The Source Identification Number field is used to identify the source
are used to identify the source that provided the given record, as that provided the given record, as described in Section 3.1.
described in Section 3.1. Note that, when reporting from a source
for the first time, the Source First Use flag MUST be set in ALL
records from that source in the attribute. (I.e., one cannot just
set the flag in the first record from that source in the attribute
because the order of records in the attribute is not meaningful, and
thus there is no effective "first record" in an attribute.)
4.9. Software Identifier Events 5.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 reported without software inventory evidence affected records are reported without software inventory evidence
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 has a Result Type is 1 and the Earliest EID the establishing request has a Result Type is 1 and the Earliest EID
is non-zero, or in direct response to a SW Request attribute where is non-zero, or in direct response to a SW Request attribute where
the Result Type is 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
skipping to change at page 56, line 36 skipping to change at page 55, line 36
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier | | Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type| | Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Locator Length | | Software Identifier Length | Software Locator Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|Source Id Num| Action | Software Identifier (var len) | | Source Id Num | Action | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator (variable length) | | Software Locator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 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 |
skipping to change at page 57, line 13 skipping to change at page 56, line 13
| | | | | |
| Flags: Bit 1-7 | Reserved for future use. This field MUST be set | | Flags: Bit 1-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. |
| | | | | |
| 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, Record Identifier, | | | integer. The EID, Timestamp, Record Identifier, |
| | Data Model Type PEN, Data Model Type, Software | | | Data Model Type PEN, Data Model Type, Software |
| | Identifier Length, Software Locator Length, | | | Identifier Length, Software Locator Length, |
| | Source First Use flag (F), Source Identification | | | Source Identification Number, Action, Software |
| | Number, Action, Software Identifier, and | | | Identifier, and Software Locator fields are |
| | Software Locator fields are repeated, in order, | | | repeated, in order, the number of times |
| | the number of times indicated in this field. | | | indicated in this field. This field value MAY be |
| | This field value MAY be 0, in which case there | | | 0, in which case there are no instances of these |
| | are no instances of these fields. | | | 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 | | | of an active subscription, this field MUST |
| | contain the Subscription ID of the subscription | | | contain the Subscription ID of the subscription |
| | being fulfilled by this attribute. | | | being fulfilled by this attribute. |
| | | | | |
skipping to change at page 58, line 39 skipping to change at page 57, line 39
| Type | identifier number that identifies the data model | | Type | identifier number that identifies the data model |
| | of the reported record. | | | of the reported record. |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Identifier | in bytes of the SW ID field. | | Identifier | in bytes of the SW ID field. |
| Length | | | Length | |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Locator Length | in bytes of the Software Locator field. | | Locator Length | in bytes of the Software Locator field. |
| | | | | |
| Source First | If set, the following Source Identification |
| Use Flag (F) | Number is the first use of that number. If |
| | unset, the Source Identification Number has been |
| | associated with a source in a previous message. |
| | |
| Source | The Source Identification Number associated with | | Source | The Source Identification Number associated with |
| Identification | the source from which this software installation | | Identification | the source from which this software installation |
| Number | inventory instance was reported. | | Number | inventory instance was reported. |
| | | | | |
| 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 - | | | Inventory Evidence Collection; 2 = DELETION - |
| | the removal of a record from the endpoint's | | | the removal of a record from the endpoint's |
| | Software Inventory Evidence Collection; 3 = | | | Software Inventory Evidence Collection; 3 = |
skipping to change at page 59, line 19 skipping to change at page 58, line 14
| | reserved for future use and MUST NOT be used | | | reserved for future use and MUST NOT be used |
| | when sending attributes. In the case where a SW- | | | when sending attributes. In the case where a SW- |
| | PV receives an event record that uses an action | | | PV receives an event record that uses an action |
| | value other than the ones defined here, it MUST | | | value other than the ones defined here, it MUST |
| | ignore that event record but SHOULD process | | | ignore that event record but SHOULD process |
| | other event records in this attribute as normal. | | | other event records in this attribute as normal. |
| | | | | |
| Software | A string containing the Software Identifier | | Software | A string containing the Software Identifier |
| Identifier | value from a software inventory evidence record. | | Identifier | value from a software inventory evidence record. |
| | This field value MUST be normalized to Network | | | This field value MUST be normalized to Network |
| | Unicode format, as described in Section 4.5. | | | Unicode format, as described in Section 5.5. |
| | This string MUST NOT be NULL terminated. | | | This string MUST NOT be NULL terminated. |
| | | | | |
| Software | A string containing the Software Locator value. | | Software | A string containing the Software Locator value. |
| Locator | This is expressed as a URI. This field value | | Locator | This is expressed as a URI. This field value |
| | MUST be normalized to Network Unicode format as | | | MUST be normalized to Network Unicode format as |
| | described in Section 3.4.4. This string MUST NOT | | | described in Section 3.4.4. This string MUST NOT |
| | be NULL terminated. | | | be NULL terminated. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Table 6: Software Identifier Events Attribute Fields Table 5: 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, the primary difference is that, instead of conveying an inventory, the
attribute conveys zero or more event records, consisting of the EID, attribute conveys zero or more event records, consisting of the EID,
timestamp, Record Identifier, action type, data model type, Software timestamp, Record Identifier, action type, data model type, Software
Identifier, and Software Locator of the affected software inventory Identifier, and Software Locator of the affected 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
skipping to change at page 60, line 37 skipping to change at page 59, line 31
contains a complete event set, the Last EID and Last Consulted EID contains a complete event set, the Last EID and Last 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
record might be reported 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.10. Software Inventory 5.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
skipping to change at page 61, line 24 skipping to change at page 60, line 24
| Last EID | | Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier | | Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type| | Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Locator Length | | Software Identifier Length | Software Locator Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length | | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|Source Id Num| Software Identifier (variable length) | | Source Id Num | Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator (Variable length) | | Software Locator (Variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (Variable length) | | Record (Variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Software Inventory Attribute Figure 9: Software Inventory Attribute
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Field | Description | | Field | Description |
skipping to change at page 61, line 50 skipping to change at page 60, line 50
| | be unset (0). | | | be unset (0). |
| | | | | |
| Flags: Bit 1-7 | Reserved for future use. This field MUST be set | | Flags: Bit 1-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. |
| | | | | |
| Record Count | The number of records that follow. This field is | | Record Count | The number of records that follow. This field is |
| | a 3-byte unsigned integer. The Record | | | a 3-byte unsigned integer. The Record |
| | Identifier, Data Model Type PEN, Data Model | | | Identifier, Data Model Type PEN, Data Model |
| | Type, Software Identifier Length, Software | | | Type, Software Identifier Length, Software |
| | Locator Length, Record Length, Source First Use | | | Locator Length, Record Length, Source |
| | Flag (F), Source Identification Number, Software | | | Identification Number, Software Identifier, |
| | Identifier, Software Locator, and Record fields | | | Software Locator, and Record fields are |
| | are repeated, in order, the number of times | | | repeated, in order, the number of times |
| | indicated in this field. This field value MAY be | | | indicated in this field. This field value MAY be |
| | 0 in which case there are no instances of these | | | 0 in which case there are no instances of these |
| | fields. | | | 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 | | | of an active subscription, this field MUST |
skipping to change at page 62, line 49 skipping to change at page 61, line 49
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Identifier | in bytes of the SW ID field. | | Identifier | in bytes of the SW ID field. |
| Length | | | Length | |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Locator Length | in bytes of the Software Locator field. | | Locator Length | in bytes of the Software Locator field. |
| | | | | |
| Record Length | This is a 4-byte unsigned integer indicating the | | Record Length | This is a 4-byte unsigned integer indicating the |
| | length of the Record field in bytes. | | | length of the Record field in bytes. |
| | | | | |
| Source First | If set, the following Source Identification |
| Use Flag (F) | Number is the first use of that number. If |
| | unset, the Source Identification Number has been |
| | associated with a source in a previous message. |
| | |
| Source | The Source Identification Number associated with | | Source | The Source Identification Number associated with |
| Identification | the source from which this software installation | | Identification | the source from which this software installation |
| Number | inventory instance was reported. | | Number | inventory instance was reported. |
| | | | | |
| Software | A string containing the Software Identifier | | Software | A string containing the Software Identifier |
| Identifier | value from a software inventory evidence record. | | Identifier | value from a software inventory evidence record. |
| | This field value MUST be normalized to Network | | | This field value MUST be normalized to Network |
| | Unicode format, as described in Section 4.5. | | | Unicode format, as described in Section 5.5. |
| | This string MUST NOT be NULL terminated. | | | This string MUST NOT be NULL terminated. |
| | | | | |
| Software | A string containing the Software Locator value. | | Software | A string containing the Software Locator value. |
| Locator | This is expressed as a URI. This field value | | Locator | This is expressed as a URI. This field value |
| | MUST be normalized to Network Unicode format as | | | MUST be normalized to Network Unicode format as |
| | described in Section 3.4.4. This string MUST NOT | | | described in Section 3.4.4. This string MUST NOT |
| | be NULL terminated. | | | be NULL terminated. |
| | | | | |
| Record | A software inventory evidence record as a | | Record | A software inventory evidence record as a |
| | string. The record MUST be converted and | | | string. The record MUST be converted and |
| | normalized to Network Unicode format, as | | | normalized to Network Unicode format, as |
| | described in Section 4.5. This string MUST NOT | | | described in Section 5.5. This string MUST NOT |
| | be NULL terminated. | | | be NULL terminated. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Table 7: Software Inventory Attribute Fields Table 6: 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 along with the core response attribute inventory evidence records along with the core response attribute
fields. Given that the size of records can vary considerably, the fields. Given that the size of records can vary considerably, the
length of this attribute is highly variable and, if transmitting a length of this attribute is highly variable and, if transmitting a
complete inventory, can be extremely large. Enterprises might wish complete inventory, can be extremely large. Enterprises might wish
to constrain the use of Software Inventory attributes to targeted to constrain the use of Software Inventory attributes to targeted
requests to avoid over-burdening the network 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.11. Software Events 5.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
that include software inventory evidence records. A SW-PV MUST NOT that include software inventory evidence records. A SW-PV MUST NOT
send this attribute. The SW-PC either sends this attribute in send this attribute. The SW-PC either sends this attribute in
fulfillment of an existing subscription where the establishing fulfillment of an existing subscription where the establishing
request has a Result Type of 0 and the Earliest EID is non-zero, or request has a Result Type of 0 and the Earliest EID is non-zero, or
in direct response to a SW Request attribute where the Result Type is in direct response to a SW Request attribute where the Result Type is
0 and the Earliest EID is non-zero. 0 and the Earliest EID is non-zero.
1 2 3 1 2 3
skipping to change at page 64, line 38 skipping to change at page 63, line 38
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier | | Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type| | Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Locator Length | | Software Identifier Length | Software Locator Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length | | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|Source Id Num| Action | Software Identifier (var len) | | Source Id Num | Action | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator (Variable Length) | | Software Locator (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (Variable Length) | | Record (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Software Events Attribute Figure 10: Software Events Attribute
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Field | Description | | Field | Description |
skipping to change at page 65, line 17 skipping to change at page 64, line 17
| | | | | |
| Flags: Bit 1-7 | Reserved for future use. This field MUST be set | | Flags: Bit 1-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. |
| | | | | |
| 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, Record Identifier, | | | integer. The EID, Timestamp, Record Identifier, |
| | Data Model Type PEN, Data Model Type, Software | | | Data Model Type PEN, Data Model Type, Software |
| | Identifier Length, Software Locator Length, | | | Identifier Length, Software Locator Length, |
| | Record Length, Source First Use Flag (F), Source | | | Record Length, Source Identification Number, |
| | Identification Number, Action, Software | | | Action, Software Identifier, Software Locator, |
| | Identifier, Software Locator, and Record fields | | | and Record fields are repeated, in order, the |
| | are repeated, in order, the number of times | | | number of times indicated in this field. This |
| | indicated in this field. This field value MAY | | | field value MAY be 0, in which case there are no |
| | be 0, in which case there are no instances of | | | instances of these fields. |
| | 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 | | | of an active subscription, this field MUST |
| | contain the Subscription ID of the subscription | | | contain the Subscription ID of the subscription |
| | being fulfilled by this attribute. | | | being fulfilled by this attribute. |
| | | | | |
skipping to change at page 66, line 47 skipping to change at page 65, line 46
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Identifier | in bytes of the Software Identifier field. | | Identifier | in bytes of the Software Identifier field. |
| Length | | | Length | |
| | | | | |
| Software | A 2-byte unsigned integer indicating the length | | Software | A 2-byte unsigned integer indicating the length |
| Locator Length | in bytes of the Software Locator field. | | Locator Length | in bytes of the Software Locator field. |
| | | | | |
| Record Length | This is a 4-byte unsigned integer indicating the | | Record Length | This is a 4-byte unsigned integer indicating the |
| | length of the Record field in bytes. | | | length of the Record field in bytes. |
| | | | | |
| Source First | If set, the following Source Identification |
| Use Flag (F) | Number is the first use of that number. If |
| | unset, the Source Identification Number has been |
| | associated with a source in a previous message. |
| | |
| Source | The Source Identification Number associated with | | Source | The Source Identification Number associated with |
| Identification | the source from which this software installation | | Identification | the source from which this software installation |
| Number | inventory instance was reported. | | Number | inventory instance was reported. |
| | | | | |
| 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 - | | | Inventory Evidence Collection; 2 = DELETION - |
| | the removal of a record from the endpoint's | | | the removal of a record from the endpoint's |
| | Software Inventory Evidence Collection; 3 = | | | Software Inventory Evidence Collection; 3 = |
skipping to change at page 67, line 27 skipping to change at page 66, line 21
| | reserved for future use and MUST NOT be used | | | reserved for future use and MUST NOT be used |
| | when sending attributes. In the case where a SW- | | | when sending attributes. In the case where a SW- |
| | PV receives an event record that uses an action | | | PV receives an event record that uses an action |
| | value other than the ones defined here, it MUST | | | value other than the ones defined here, it MUST |
| | ignore that event record but SHOULD process | | | ignore that event record but SHOULD process |
| | other event records in this attribute as normal. | | | other event records in this attribute as normal. |
| | | | | |
| Software | A string containing the Software Identifier | | Software | A string containing the Software Identifier |
| Identifier | value from a software inventory evidence record. | | Identifier | value from a software inventory evidence record. |
| | This field value MUST be normalized to Network | | | This field value MUST be normalized to Network |
| | Unicode format, as described in Section 4.5. | | | Unicode format, as described in Section 5.5. |
| | This string MUST NOT be NULL terminated. | | | This string MUST NOT be NULL terminated. |
| | | | | |
| Software | A string containing the Software Locator value. | | Software | A string containing the Software Locator value. |
| Locator | This is expressed as a URI. This field value | | Locator | This is expressed as a URI. This field value |
| | MUST be normalized to Network Unicode format as | | | MUST be normalized to Network Unicode format as |
| | described in Section 3.4.4. This string MUST NOT | | | described in Section 3.4.4. This string MUST NOT |
| | be NULL terminated. | | | be NULL terminated. |
| | | | | |
| Record | A software inventory evidence record as a | | Record | A software inventory evidence record as a |
| | string. The record MUST be converted and | | | string. The record MUST be converted and |
| | normalized to Network Unicode format, as | | | normalized to Network Unicode format, as |
| | described in Section 4.5. This string MUST NOT | | | described in Section 5.5. This string MUST NOT |
| | be NULL terminated. | | | be NULL terminated. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Table 8: Software Events Attribute Fields Table 7: 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.12. Subscription Status Request 5.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.13. Subscription Status Response 5.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 69, line 32 skipping to change at page 68, line 32
| 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 | | | Software | |
| Identifier | | | Identifier | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
Table 9: Subscription Status Response Fields Table 8: 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.8.2, the SW-PC MUST use the requester's As described in Section 3.8.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 70, line 29 skipping to change at page 69, line 29
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.14. PA-TNC Error as Used by Software Inventory Message and Attributes 5.14. Source Metadata Request
A SW-PV sends this attribute to a SW-PC to request metadata about
sources that the SW-PC is using to collect software inventory
information. A SW-PC MUST NOT send this attribute.
This attribute has no fields.
A SW-PC MUST respond to this attribute by sending a Sources Metadata
Response attribute (or a PA-TNC Error attribute if it is unable to
correctly provide a response).
5.15. Source Metadata Response
A SW-PC sends this attribute to a SW-PV to provide descriptive
metadata about the sources of software inventory information used by
the SW-PC. A SW-PV MUST NOT send this attribute.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Source Count | Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Length | Metadata (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Metadata Response Attribute
+----------+--------------------------------------------------------+
| Field | Description |
+----------+--------------------------------------------------------+
| Reserved | Reserved for future use. This field MUST be set to |
| | zero on transmission and ignored upon reception. |
| | |
| Source | The number of source records that follow. The Source |
| Count | ID, Metadata Size, and Metadata fields are repeated, |
| | in order, the number of times indicated by this field. |
| | This field MAY be 0, in which case no fields follow |
| | (but this would only be done to indicate that the SW- |
| | PC has no active sources, which would not be a usual |
| | situation). |
| | |
| Source | The Source ID number associated with the described |
| ID | source for any communications with the recipient SW- |
| | PV. |
| | |
| Metadata | A 2-byte unsigned integer indicating the length in |
| Length | bytes of the Metadata field. |
| | |
| Metadata | A string containing descriptive metadata about the |
| | indicated data source. This string MUST NOT be NULL |
| | terminated. |
+----------+--------------------------------------------------------+
Source Metadata Response Fields
A Source Metadata Response attribute contains 0 or more records, each
describing one of the data sources the SW-PC uses to collect software
inventory information. It SHOULD contain one metadata record for
each source that the SW-PC uses. (There might be reasons not to
inform certain SW-PVs of the presence of certain data sources.) The
attribute MUST contain a metadata record for each source that has
been identified in inventory or event messages to the given SW-PV.
A SW-PC MUST send a Source Metadata Response attribute in response to
a Source Metadata Request attribute. The only exception to this is
if the SW-PC experiences an error condition that prevents it from
correctly populating the Source Metadata Response attribute, in which
case it MUST respond with a PA-TNC Error attribute appropriate to the
type of error experienced.
The Source Count field indicates how many source metadata records are
included in the attribute. Each included record consists of a Source
Identifier, Metadata Length, and Metadata field.
The Source Identifier corresponds to the Source Identifier field in
inventory and event messages. In the case where the Source
Identifier value in a Source Metadata Response attribute matches a
Source Identifier associated with an event or inventory record and
both the Source Metadata Response and the inventory/event record were
sent to the same SW-PV, the source described in the Metadata field
MUST be the same source that provided the event or inventory record
associated with the Source Identifier. Recall that a SW-PC MAY use
different Source Identifier associations with different SW-PVs. When
sending to a giving SW-PV, the SW-PC MUST use the recipient SW-PVs
Source Identifier associations.
The Metadata Length indicates the length, in bytes, if the Metadata
field. The Metadata field contains information about the indicated
data source. This specification does not dictate a format for the
contents of the Metadata field. This field MAY include machine-
readable information. For broadest utility, the Metadata field
SHOULD include human-readable, descriptive information about the data
source.
5.16. PA-TNC Error as Used by Software Inventory Message and Attributes
for PA-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
Inventory Message and Attributes for PA-TNC exchange. The latter Inventory Message and Attributes for PA-TNC exchange. The latter
case utilizes error codes defined below. case utilizes error codes defined below.
A PA-TNC Error MUST be sent by a SW-PC in response to a SW Request in
the case where the SW-PC encounters a fatal error (i.e., an error
that prevents further processing of an exchange) relating to the
attribute exchange. A SW-PV MUST NOT send this attribute. In the
case where the SW-PV experiences a fatal error, it MUST handle the
error without sending a PA-TNC Error attribute. The SW-PV MAY take
other actions in response to the error, such as logging the cause of
the error, or even taking actions to isolate the endpoint.
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 10 lists the Error Code values for the PA-TNC Error attribute Table 9 lists the Error Code values for the PA-TNC Error attribute
specific to the Software Inventory Message and Attributes for PA-TNC specific to the Software Inventory Message and Attributes for PA-TNC
exchange. In all of these cases, the Error Code Vendor ID field MUST exchange. Error codes are shown in both hexadecimal and decimal
format. In all of these cases, the Error Code Vendor ID field MUST
be set to 0x000000, corresponding to the IETF SMI Private Enterprise be set to 0x000000, corresponding to the IETF SMI Private Enterprise
Number. The Error Information structures for each error type are Number. The Error Information structures for each error type are
described in the following subsections. described in the following subsections.
Note that a message with a Software Inventory Message and Attributes Note that a message with a Software Inventory Message and Attributes
for PA-TNC attribute might also result in an error condition covered for PA-TNC attribute might also result in an error condition covered
by the Standard PA-TNC Error Codes defined in PA-TNC. For example, a by the Standard PA-TNC Error Codes defined in PA-TNC. For example, a
SW Attribute might have an invalid parameter, leading to an error SW Attribute might have an invalid parameter, leading to an error
code 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 (32) | 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 |
| | described below but still specific to the | | | described below but still specific to the |
| | processing of SW Attributes. The | | | processing of SW Attributes. The |
| | Description field SHOULD contain | | | Description field SHOULD contain |
| | additional diagnostic information. | | | additional diagnostic information. |
| | | | | |
| 0x00000021 | SW_SUBSCRIPTION_DENIED_ERROR. This | | 0x00000021 (33) | SW_SUBSCRIPTION_DENIED_ERROR. This |
| | indicates that the SW-PC denied the SW- | | | indicates that the SW-PC denied the SW- |
| | 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 (34) | 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.14.2). The Description field | | | Section 5.16.2). The Description field |
| | SHOULD contain additional diagnostic | | | SHOULD contain additional diagnostic |
| | information. | | | information. |
| | | | | |
| 0x00000023 | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This | | 0x00000023 (35) | 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- |
| | PC experienced. The SW-PC and SW-PV MUST | | | PC experienced. The SW-PC and SW-PV MUST |
| | treat the identified subscription as | | | treat the identified subscription as |
| | cancelled. | | | cancelled. |
| | | | | |
| 0x00000024 | SW_SUBSCRIPTION_ID_REUSE_ERROR. This | | 0x00000024 (36) | SW_SUBSCRIPTION_ID_REUSE_ERROR. This |
| | 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 | | (37-47) | for use by future revisions of the |
| | Software Inventory Message and Attributes | | | Software Inventory Message and Attributes |
| | for PA-TNC specification. Any PA-TNC | | | for PA-TNC specification. Any PA-TNC |
| | Error attribute using one of these Error | | | Error attribute using one of these Error |
| | Codes MUST be treated as indicating a | | | Codes MUST be treated as indicating a |
| | fatal error on the sender without further | | | fatal error on the sender without further |
| | interpretation. | | | interpretation. |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
Table 10: PA-TNC Error Codes for Software Inventory Message and Table 9: PA-TNC Error Codes for Software Inventory Message and
Attributes for 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.14.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and 5.16.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 73, line 22 skipping to change at page 74, line 38
| | 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.14.3. | | | Section 5.16.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 11: SW Error, Subscription Error, and Subscription ID Reuse Table 10: 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.14.2. SW_RESPONSE_TOO_LARGE_ERROR Information 5.16.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 74, line 31 skipping to change at page 76, line 19
| 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.14.3. | | | as described in Section 5.16.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 12: SW Response Too Large Error Information Fields Table 11: 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.14.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information 5.16.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 76, line 32 skipping to change at page 77, line 48
| 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 13: SW Subscription Fulfillment Error Information Fields Table 12: 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 6. Supported Data Models
Software Inventory Message and Attributes for PA-TNC supports an Software Inventory Message and Attributes for PA-TNC supports an
extensible list of data models for representing and transmitting extensible list of data models for representing and transmitting
software inventory information. This list of data models appears in software inventory information. This list of data models appears in
the Software Data Model IANA table (see Section 9.4). This document the Software Data Model IANA registry (see Section 10.4). This
provides guidance for an initial set of data models. Other documents document provides guidance for an initial set of data models. Other
might provide guidance on the use of new data models by Software documents might provide guidance on the use of new data models by
Inventory Message and Attributes for PA-TNC, and will be referenced Software Inventory Message and Attributes for PA-TNC, and will be
by extensions to the Software Data Model IANA table. referenced by extensions to the Software Data Model IANA registry.
5.1. ISO 2015 SWID Tags using XML 6.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. [SWID15] Since that time, a revised version published in 2015. [SWID15] Since that time, a
growing number of vendors have integrated SWID tags into their growing number of vendors have integrated SWID tags into their
software products. Doing so significantly simplifies the task of software products. Doing so significantly simplifies the task of
identifying these pieces of software: instead of relying on discovery identifying these pieces of software: instead of relying on discovery
processes that look for clues as to software presence, such as the processes that look for clues as to software presence, such as the
presence of particular files or registry keys, a readily available presence of particular files or registry keys. A readily available
list of SWID tags provides simple and immediate evidence as to the list of SWID tags provides simple and immediate evidence as to the
presence of the given piece of software. presence of the given piece of software.
SWID Message and Attributes for PA-TNC has no reliance on the SWID Message and Attributes for PA-TNC has no reliance on the
presence or management of SWID tags on an endpoint as described in presence or management of SWID tags on an endpoint as described in
the ISO specification. However, the data model for describing the ISO specification. However, the data model for describing
software that is presented in the ISO specification provides a robust software that is presented in the ISO specification provides a robust
and comprehensive way of describing software and is adopted here as a and comprehensive way of describing software and is adopted here as a
means of representing and transmitting software information. It means of representing and transmitting software information. It
should be emphasized, the use of the ISO SWID tag data model makes no should be emphasized, the use of the ISO SWID tag data model makes no
assumption as to whether the source of the recorded information was, assumption as to whether the source of the recorded information was,
in fact, an ISO SWID tag harvested from the endpoint or whether the in fact, an ISO SWID tag harvested from the endpoint or whether the
information was created using some other source and normalized to the information was created using some other source and normalized to the
SWID format. SWID format.
5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags using 6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags using
XML XML
Any record associated with this Software Data Model Type MUST conform Any record associated with this Software Data Model Type MUST conform
to the ISO/IEC 19770-2-2015 [SWID15] specification. Any such tag to the ISO/IEC 19770-2-2015 [SWID15] specification. Any such tag
SHOULD use a UTF-8 encoding, but MUST NOT alter the existing encoding SHOULD use a UTF-8 encoding, but MUST NOT alter the existing encoding
if doing so would invalidate digital signatures included in the tag. if doing so would invalidate digital signatures included in the tag.
If generating a new ISO 2015 SWID tag, the software generating the If generating a new ISO 2015 SWID tag, the software generating the
tag MUST use either a Tag Creator RegID that is associated with the tag MUST use a Tag Creator RegID that is associated with the
generating software unless this is impossible, in which case it MUST generating software, unless this is impossible, in which case it MUST
use the Unknown Tag Creator RegID. Do not use a RegID associated use the "http://invalid.unavailable" Tag Creator RegID value. Do not
with any other party. In particular, it is incorrect to use a Tag use a RegID associated with any other party. In particular, it is
Creator RegID associated with the software being described by the incorrect to use a Tag Creator RegID associated with the software
tag, the enterprise that is using the software, or any other entity being described by the tag, the enterprise that is using the
except that of the party that built the tool that is generating the software, or any other entity except that of the party that built the
SWID tag. This reflects the requirement that the Tag Creator RegID tool that is generating the SWID tag. This reflects the requirement
identify the party that created the tag. that the Tag Creator RegID identify the party that created the tag.
5.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID 6.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID
Tags Tags
A Software Identifier generated from an ISO 2015 SWID tag is A Software Identifier generated from an ISO 2015 SWID tag is
expressed as a concatenation of the value of the Tag Creator RegID expressed as a concatenation of the value of the Tag Creator RegID
field and the Unique ID field. Specifically, it MUST be of the form: field and the Unique ID field. Specifically, it MUST be of the form:
NUMBER::TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length of NUMBER "::" TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length
TAG_CREATOR_REGID in bytes. The rest of the Software Identifier MUST of TAG_CREATOR_REGID in bytes. The rest of the Software Identifier
be the concatenation of the Tag Creator RegID and the Unique ID from MUST be the concatenation of the Tag Creator RegID and the Unique ID
the tag, without any connecting character or whitespace. from the tag, without any connecting character or whitespace.
5.2. ISO 2009 SWID Tags using XML 6.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
deployments. For this reason, ISO 2009 SWID tags are included in the deployments. For this reason, ISO 2009 SWID tags are included in the
Software Data Model IANA table. Software Data Model IANA table.
5.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID Tags using 6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID Tags using
XML XML
Any record associated with this Software Data Model Type MUST conform Any record associated with this Software Data Model Type MUST conform
to the ISO/IEC 19770-2-2009 [SWID09] specification. Any such tag to the ISO/IEC 19770-2-2009 [SWID09] specification. Any such tag
SHOULD use a UTF-8 encoding, but MUST NOT alter the existing encoding SHOULD use a UTF-8 encoding, but MUST NOT alter the existing encoding
if doing so would invalidate digital signatures included in the tag. if doing so would invalidate digital signatures included in the tag.
If generating a new ISO 2009 SWID tag, the software generating the If generating a new ISO 2009 SWID tag, the software generating the
tag MUST use either a Tag Creator RegID that is associated with the tag MUST use a Tag Creator RegID that is associated with the
generating software unless this is impossible, in which case it MUST generating software unless this is impossible, in which case it MUST
use the Unknown Tag Creator RegID. Do not use a RegID associated use "http://invalid.unavailable", which indicates the Tag Creator is
with any other party. In particular, it is incorrect to use a Tag unknown. Do not use a RegID associated with any other party. In
Creator RegID associated with the software being described by the particular, it is incorrect to use a Tag Creator RegID associated
tag, the enterprise that is using the software, or any other entity with the software being described by the tag, the enterprise that is
except that of the party that built the tool that is generating the using the software, or any other entity except that of the party that
SWID tag. This reflects the requirement that the Tag Creator RegID built the tool that is generating the SWID tag. This reflects the
identify the party that created the tag. requirement that the Tag Creator RegID identify the party that
created the tag.
5.2.2. Guidance on Creation of Software Identifiers from ISO 2009 SWID 6.2.2. Guidance on Creation of Software Identifiers from ISO 2009 SWID
Tags Tags
A Software Identifier generated from an ISO 2009 SWID tag is A Software Identifier generated from an ISO 2009 SWID tag is
expressed as a concatenation of the value of the Tag Creator RegID expressed as a concatenation of the value of the Tag Creator RegID
field and the Unique ID field. Specifically, it MUST be of the form: field and the Unique ID field. Specifically, it MUST be of the form:
NUMBER::TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length of NUMBER "::" TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length
TAG_CREATOR_REGID in bytes. The rest of the Software Identifier MUST of TAG_CREATOR_REGID in bytes. The rest of the Software Identifier
be the concatenation of the Tag Creator RegID and the Unique ID from MUST be the concatenation of the Tag Creator RegID and the Unique ID
the tag, without any connecting character or whitespace. from the tag, without any connecting character or whitespace.
6. Security Considerations 7. 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 Collectors and Posture Validators that implement the Software
Inventory Message and Attributes for PA-TNC protocol. This section Inventory Message and Attributes for PA-TNC protocol. This section
primarily notes potential issues for implementers to consider, primarily notes potential issues for implementers to consider,
although it does contain a handful of normative requirements to although it does contain a handful of normative requirements to
address certain security issues. Implementers need to make the final address certain security issues. The issues identified below focus
decision as to how their implementations address the given issues. on capabilities specific to this document. Implementers are advised
The issues identified below focus on capabilities specific to this to consult other relevant NEA specifications, particularly [RFC5209]
document. Implementers are advised to consult other relevant NEA (the NEA Architecture) and [RFC5792] (PA-TNC), for security issues
specifications for security issues that are applicable to such that are applicable to such components in general.
components in general.
Reading the Security Considerations section of any well-written
specification can be discouraging, as a long list of possible threats
is catalogued. Keep in mind that no security measure is absolute,
but each one can be beneficial. By understanding the weaknesses of
each security measure, we can put in place countermeasures to protect
against exploitation of these weaknesses.
6.1. Evidentiary Value of Software Inventory Evidence Records 7.1. Evidentiary Value of Software Inventory Evidence Records
It must be remembered that the accuracy of an endpoints Software The degree to which an endpoint's Software Inventory Evidence
Inventory Evidence Collection as an indicator of the endpoints Collection accurately reflects the endpoint's actual software load
software load and changes thereon is only as accurate as the tools and any changes made to this software load is dependent on the
that populate and manage the software inventory evidence records in accuracy of the tools used to populate and manage the software
this collection. Some tools might not be designed to update records inventory evidence records in this collection. Some tools might not
in the Software Inventory Evidence Collection in real time resulting be designed to update records in the Software Inventory Evidence
in a collection that is out-of-step with actual system state. Collection in real time, resulting in a collection that is out-of-
Moreover, tools might inaccurately characterize software, or fail to sync with actual system state. Moreover, tools might inaccurately
properly record its removal. Finally, it is likely that there will characterize software, or fail to properly record its removal.
be software on the endpoint that is not tracked by any source and Finally, it is likely that there will be software on the endpoint
thus is not reflected in the Software Inventory Evidence Collection. that is not tracked by any source and thus is not reflected in the
Users of collected software inventory evidence records need to Software Inventory Evidence Collection. Users of collected software
understand that the information provided by the Software Inventory inventory evidence records need to understand that the information
Message and Attributes for PA-TNC capability cannot be treated as provided by the Software Inventory Message and Attributes for PA-TNC
completely accurate. Nonetheless, having endpoints report this capability cannot be treated as completely accurate. Nonetheless,
information can still provide useful insights into the state of the having endpoints report this information can still provide useful
endpoint's software load, and can alert administrators and policy insights into the state of the endpoint's software load, and can
tools of situations that require remediation. alert administrators and policy tools of situations that require
remediation.
6.2. Sensitivity of Collected Records 7.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
that endpoint's records simply by inspecting other parts of the that endpoint's records simply by inspecting other parts of the
endpoint. endpoint.
skipping to change at page 81, line 11 skipping to change at page 82, line 28
attacker an indication of how quickly an organization distributes attacker an indication of how quickly an organization distributes
patches and updates, helping the attacker determine how long an patches and updates, helping the attacker determine how long an
attack window might remain open. attack window might remain open.
Any consolidated software inventory is a potential risk, because such Any consolidated software inventory is a potential risk, because such
an inventory can provide an adversary an insight into the an inventory can provide an adversary an insight into the
enterprise's configuration and management process. It is recommended enterprise's configuration and management process. It is recommended
that a centralized software inventory record collection be protected that a centralized software inventory record collection be protected
against unauthorized access. Mechanisms to accomplish this can against unauthorized access. Mechanisms to accomplish this can
include encrypting the data at rest, ensuring that access to the data include encrypting the data at rest, ensuring that access to the data
is limited only to necessary individuals and processes, and other is limited only to authorized individuals and processes, and other
basic security precautions. basic security precautions.
6.3. Integrity of Endpoint Records 7.3. Integrity of Endpoint Records
SW-PCs maintain records of detected changes to the endpoint's SW-PCs maintain records of detected changes to the endpoint's
Software Inventory Evidence Collection. These records are used to Software Inventory Evidence Collection. These records are used to
respond to a SW-PV's request for change events. The SW-PV might use respond to a SW-PV's request for change events. The SW-PV might use
a list of reported events to update its understanding of the a list of reported events to update its understanding of the
endpoint's Software Inventory Evidence Collection without needing to endpoint's Software Inventory Evidence Collection without needing to
receive a full inventory report from the SW-PC. For this reason, receive a full inventory report from the SW-PC. For this reason,
preserving the integrity of the SW-PC's record of events is extremely preserving the integrity of the SW-PC's record of events is extremely
important. If an attacker modifies the SW-PC's record of changes to important. If an attacker modifies the SW-PC's record of changes to
the endpoint's Software Inventory Evidence Collection, this might the endpoint's Software Inventory Evidence Collection, this might
skipping to change at page 81, line 45 skipping to change at page 83, line 13
able to modify or delete records of an established subscription by a able to modify or delete records of an established subscription by a
SW-PV, the SW-PC might fail to correctly fulfill this subscription. SW-PV, the SW-PC might fail to correctly fulfill this subscription.
The SW-PV would not be aware that its subscription was not being The SW-PV would not be aware that its subscription was not being
correctly fulfilled unless it received additional information that correctly fulfilled unless it received additional information that
indicated a discrepancy. For example, the SW-PV might collect a full indicated a discrepancy. For example, the SW-PV might collect a full
inventory and realize from this that certain events had not been inventory and realize from this that certain events had not been
correctly reported in accordance with an established subscription. correctly reported in accordance with an established subscription.
For this reason, the SW-PC MUST protect the integrity of subscription For this reason, the SW-PC MUST protect the integrity of subscription
records. records.
6.4. SW-PC Access Permissions 7.4. SW-PC Access Permissions
A SW-PC requires sufficient permissions to collect Software Inventory A SW-PC requires sufficient permissions to collect Software Inventory
Evidence Records from all of its supported sources, as well as Evidence Records from all of its supported sources, as well as
sufficient permissions to interact with the endpoint's Posture Broker sufficient permissions to interact with the endpoint's Posture Broker
Client. With regard to the former, this might require permissions to Client. With regard to the former, this might require permissions to
read the contents of directories throughout the file system. read the contents of directories throughout the file system.
Depending on the operating environment and other activities Depending on the operating environment and other activities
undertaken by a SW-PC (or software that incorporates a SW-PC as one undertaken by a SW-PC (or software that incorporates a SW-PC as one
of its capabilities) additional permissions might be required by the of its capabilities) additional permissions might be required by the
SW-PC software. The SW-PC SHOULD NOT be granted permissions beyond SW-PC software. The SW-PC SHOULD NOT be granted permissions beyond
what it needs in order to fulfill its duties. what it needs in order to fulfill its duties.
6.5. Sanitization of Record Fields 7.5. Sanitization of Record Fields
Not all sources of software inventory evidence are necessarily Not all sources of software inventory evidence are necessarily
tightly controlled. For example, consider a source that gathers tightly controlled. For example, consider a source that gathers
.swid files from the endpoint's file system. Any party could create .swid files from the endpoint's file system. Any party could create
a new .swid file that could be collected and turned into a Software a new .swid file that could be collected and turned into a Software
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 7.6. PA-TNC Security Threats
In addition to the aforementioned considerations the Software In addition to the aforementioned considerations the Software
Inventory Message and Attributes for PA-TNC protocol is subject to Inventory Message and Attributes for PA-TNC protocol is subject to
the same security threats as other PA-TNC transactions, as noted in the same security threats as other PA-TNC transactions, as noted in
Section 5.2 of PA-TNC [RFC5792]. These include, but are not limited Section 5.2 of PA-TNC [RFC5792]. These include, but are not limited
to, attribute theft, message fabrication, attribute modification, to, attribute theft, message fabrication, attribute modification,
attribute replay, attribute insertion, and denial of service. attribute replay, attribute insertion, and denial of service.
Implementers are advised to consult the PA-TNC specification to Implementers are advised to consult the PA-TNC specification to
better understand these security issues. better understand these security issues.
7. Privacy Considerations 8. Privacy Considerations
As noted in Section 6.2, if an adversary can gain an understanding of As noted in Section 7.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
that can be trusted to safeguard this information after collection. that can be trusted to safeguard this information after collection.
8. Relationship to Other Specifications 9. Relationship to Other Specifications
This specification makes frequent reference to and use of other This specification makes frequent reference to and use of other
specifications. This section describes these relationships. specifications. This section describes these relationships.
This specification is expected to participate in a standard NEA This specification is expected to participate in a standard NEA
architecture. As such, it is expected to be used in conjunction with architecture. As such, it is expected to be used in conjunction with
the other protocols used in a NEA exchange. In particular, SW the other protocols used in a NEA exchange. In particular, SW
Attributes are conveyed over PB-TNC [RFC5793], which is in turn Attributes are conveyed over PB-TNC [RFC5793], which is in turn
conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP
[RFC7171]). These protocols have an especially important role, as [RFC7171]). These protocols have an especially important role, as
skipping to change at page 83, line 25 skipping to change at page 84, line 44
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 Inventory Message and Attributes for PA-TNC specification is Software Inventory Message and Attributes for PA-TNC specification is
able to convey a broader query, resulting in a more comprehensive set able to convey a broader query, resulting in a more comprehensive set
of evidence regarding an endpoint's installed software. As such, of evidence regarding an endpoint's installed software. As such,
this specification provides important capabilities not present in the this specification provides important capabilities not present in the
PA-TNC specification. PA-TNC specification.
9. IANA Considerations 10. 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 10.1. PA Subtypes
Section 4.4 of this specification defines several new PA-TNC The following is an extension to the PA Subtype registry [1] defined
in section 7.2 of the PA-TNC specification [RFC5792].
+-----+---------+------------+--------------------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+------------+--------------------------------------+
| 0 | 9 | SW | Software Inventory Message and |
| | | Attributes | Attributes for PA-TNC |
+-----+---------+------------+--------------------------------------+
10.2. Registry for PA-TNC Attribute Types
Section 5.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 3 in Section 4.4 lists these attributes but uses a hexadecimal Table 2 in Section 5.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 3 includes an entry for PA-TNC Error attributes, but the IANA Table 2 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 Inventory Message | | 0 | 17 | SW Request | Software Inventory Message |
| | | | and Attributes for PA-TNC | | | | | and Attributes for PA-TNC |
| | | | | | | | | |
| 0 | 18 | Software | Software Inventory Message | | 0 | 18 | Software | Software Inventory Message |
skipping to change at page 84, line 37 skipping to change at page 86, line 37
| 0 | 23 | Subscription | Software Inventory Message | | 0 | 23 | Subscription | Software Inventory Message |
| | | Status Response | and Attributes for PA-TNC | | | | Status Response | and Attributes for PA-TNC |
| | | | | | | | | |
| 0 | 24 | Subscription | Software Inventory Message | | 0 | 24 | Subscription | Software Inventory Message |
| | | Status Response | and Attributes for PA-TNC | | | | Status Response | and Attributes for PA-TNC |
| | | | | | | | | |
| 0 | 25 - 31 | Reserved for | Software Inventory Message | | 0 | 25 - 31 | Reserved for | Software Inventory Message |
| | | future use | and Attributes for PA-TNC | | | | future use | and Attributes for PA-TNC |
+-----+---------+-------------------+-------------------------------+ +-----+---------+-------------------+-------------------------------+
9.2. Registry for PA-TNC Error Codes 10.3. Registry for PA-TNC Error Codes
Section 4.14 of this specification defines several new PA-TNC Error Section 5.16 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 10 Error Codes defined in the PA-TNC specification. Note that Table 9
in Section 4.14 lists these codes but uses a hexadecimal value to in Section 5.16 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 | | | | | Inventory |
| | | | Message and | | | | | Message and |
skipping to change at page 85, line 46 skipping to change at page 87, line 46
| | | | 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 | | | | | Inventory |
| | | | Message and | | | | | Message and |
| | | | Attributes | | | | | Attributes |
| | | | for PA-TNC | | | | | for PA-TNC |
+-----+---------+-----------------------------------+---------------+ +-----+---------+-----------------------------------+---------------+
9.3. Registry for PA Subtypes 10.4. Registry for Software Data Models
Section 4.1 of this specification defines one new PA Subtype. The
following value is added to the registry for PA Subtypes defined in
the PB-TNC specification.
+-----+---------+------------+--------------------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+------------+--------------------------------------+
| 0 | 9 | SW | Software Inventory Message and |
| | | Attributes | Attributes for PA-TNC |
+-----+---------+------------+--------------------------------------+
9.4. Registry for Software Data Models
The name for this registry is "Software Data Model Types". Each The name for this registry is "Software Data Model Types". Each
entry in this registry should include a human readable name, an SMI entry in this registry should include a human readable name, an SMI
Private Enterprise Number, a decimal integer value between 1 and Private Enterprise Number, a decimal integer value between 1 and
2^8-1 (inclusive), and a reference to the specification where the use 2^8-1 (inclusive), and a reference to the specification where the use
of this data model is defined. This specification needs to provide of this data model is defined. This specification needs to provide
both a description of the format used by the data model and the both a description of the format used by the data model and the
procedures by which Software Identifiers are derived from a record procedures by which Software Identifiers are derived from a record
expressed using this data model. Note that a specification that just expressed using this data model. Note that a specification that just
defines the data model structure and its use is generally not defines the data model structure and its use is generally not
skipping to change at page 86, line 48 skipping to change at page 88, line 33
| 0 | 1 | ISO 2015 SWID Tags using | **CURRENT | | 0 | 1 | ISO 2015 SWID Tags using | **CURRENT |
| | | XML | SPECIFICATION** | | | | XML | SPECIFICATION** |
| | | | | | | | | |
| 0 | 2 | ISO 2009 SWID Tags using | **CURRENT | | 0 | 2 | ISO 2009 SWID Tags using | **CURRENT |
| | | XML | SPECIFICATION** | | | | XML | SPECIFICATION** |
| | | | | | | | | |
| 0 | 192-255 | Reserved for local | N/A | | 0 | 192-255 | Reserved for local | N/A |
| | | enterprise use | | | | | enterprise use | |
+-----+---------+----------------------------+----------------------+ +-----+---------+----------------------------+----------------------+
10. References 11. References
10.1. Normative References
11.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>.
skipping to change at page 88, line 5 skipping to change at page 89, line 34
[SWID09] The International Organization for Standardization/ [SWID09] The International Organization for Standardization/
International Electrotechnical Commission, "Information International Electrotechnical Commission, "Information
Technology - Software Asset Management - Part 2: Software Technology - Software Asset Management - Part 2: Software
Identification Tag, ISO/IEC 19770-2", November 2009. Identification Tag, ISO/IEC 19770-2", November 2009.
[SWID15] The International Organization for Standardization/ [SWID15] The International Organization for Standardization/
International Electrotechnical Commission, "Information International Electrotechnical Commission, "Information
Technology - Software Asset Management - Part 2: Software Technology - Software Asset Management - Part 2: Software
Identification Tag, ISO/IEC 19770-2", October 2015. Identification Tag, ISO/IEC 19770-2", October 2015.
10.2. Informative References 11.2. Informative References
[NIST-SWID] [NIST-SWID]
The National Institute of Standards and Technology and The The National Institute of Standards and Technology and The
MITRE Corporation, "Guidelines for the Creation of MITRE Corporation, "Guidelines for the Creation of
Interoperable Software Identification (SWID) Tags", August Interoperable Software Identification (SWID) Tags", August
2013. 2013.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793,
skipping to change at page 88, line 28 skipping to change at page 90, line 10
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", RFC 6876, Transport Protocol over TLS (PT-TLS)", RFC 6876,
DOI 10.17487/RFC6876, February 2013, DOI 10.17487/RFC6876, February 2013,
<http://www.rfc-editor.org/info/rfc6876>. <http://www.rfc-editor.org/info/rfc6876>.
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
(PT) Protocol for Extensible Authentication Protocol (EAP) (PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014,
<http://www.rfc-editor.org/info/rfc7171>. <http://www.rfc-editor.org/info/rfc7171>.
11.3. URIs
[1] https://www.iana.org/assignments/pb-tnc-parameters/pb-tnc-
parameters.xhtml#pb-tnc-parameters-2
Authors' Addresses Authors' Addresses
Charles Schmidt Charles Schmidt
The MITRE Corporation The MITRE Corporation
202 Burlington Road 202 Burlington Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: cmschmidt@mitre.org Email: cmschmidt@mitre.org
skipping to change at page 89, line 4 skipping to change at page 90, line 32
Email: cmschmidt@mitre.org Email: cmschmidt@mitre.org
Daniel Haynes Daniel Haynes
The MITRE Corporation The MITRE Corporation
202 Burlington Road 202 Burlington Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: dhaynes@mitre.org Email: dhaynes@mitre.org
Chris Coffin Chris Coffin
The MITRE Corporation The MITRE Corporation
202 Burlington Road 202 Burlington Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: ccoffin@mitre.org Email: ccoffin@mitre.org
David Waltermire
National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, Maryland
USA
Email: david.waltermire@nist.gov
Jessica Fitzgerald-McKay Jessica Fitzgerald-McKay
Department of Defense Department of Defense
9800 Savage Road 9800 Savage Road
Ft. Meade, Maryland Ft. Meade, Maryland
USA USA
Email: jmfitz2@nsa.gov Email: jmfitz2@nsa.gov
 End of changes. 175 change blocks. 
837 lines changed or deleted 898 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/