--- 1/draft-ietf-sacm-nea-swid-patnc-00.txt 2017-03-13 14:14:22.098369990 -0700 +++ 2/draft-ietf-sacm-nea-swid-patnc-01.txt 2017-03-13 14:14:22.306374945 -0700 @@ -1,46 +1,47 @@ SACM C. Schmidt Internet-Draft D. Haynes 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 Department of Defense - January 5, 2017 + March 13, 2017 Software Inventory Message and Attributes (SWIMA) for PA-TNC - draft-ietf-sacm-nea-swid-patnc-00 + draft-ietf-sacm-nea-swid-patnc-01 Abstract - This document specifies the Software Inventory Message and Attributes - for PA-TNC. It extends the PA-TNC specification [RFC5792] by - providing specific attributes and message exchanges to allow - endpoints to report their installed software inventory information to - a NEA server (as described in [RFC5209]). + This document extends the PA-TNC specification [RFC5792] by providing + specific attributes and message exchanges to allow endpoints to + report their installed software inventory information to a NEA server + (as described in [RFC5209]). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 9, 2017. + This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -51,174 +52,175 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Network Endpoint Assessment (NEA) . . . . . . . . . . . . 5 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8 - 2.1.1. Use Software Inventory as a Factor in Determining - Endpoint Access . . . . . . . . . . . . . . . . . . . 8 - 2.1.2. Maintain a Central Repository Reflecting an - Endpoint's Software Inventory . . . . . . . . . . . . 9 - 2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10 - 2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 10 - 2.3. Specification Requirements . . . . . . . . . . . . . . . 11 + 2.1.1. Use Software Inventory as an Access Control Factor . 8 + 2.1.2. Central Stores of Up-to-Date Endpoint Software + Inventory Data . . . . . . . . . . . . . . . . . . . 9 + 2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 9 + 2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 9 + 2.3. Specification Requirements . . . . . . . . . . . . . . . 10 2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 12 2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12 - 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 13 - 2.7. Software Inventory Message and Attributes for PA-TNC - Diagram Conventions . . . . . . . . . . . . . . . . . . . 13 - 3. Software Inventory Message and Attributes for PA-TNC System - Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.1. Information Sources . . . . . . . . . . . . . . . . . . . 14 - 3.2. Data Models . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.3. Basic Attribute Exchange . . . . . . . . . . . . . . . . 16 - 3.4. Core Software Reporting Information . . . . . . . . . . . 17 - 3.4.1. Software Identifiers . . . . . . . . . . . . . . . . 17 - 3.4.2. Data Model Type . . . . . . . . . . . . . . . . . . . 18 - 3.4.3. Record Identifiers . . . . . . . . . . . . . . . . . 19 - 3.4.4. Software Locators . . . . . . . . . . . . . . . . . . 19 - 3.4.5. Source Identifiers . . . . . . . . . . . . . . . . . 20 + 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 12 + 3. System Requirements . . . . . . . . . . . . . . . . . . . . . 12 + 3.1. Data Sources . . . . . . . . . . . . . . . . . . . . . . 13 + 3.2. Data Models . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.3. Basic Attribute Exchange . . . . . . . . . . . . . . . . 15 + 3.4. Core Software Reporting Information . . . . . . . . . . . 16 + 3.4.1. Software Identifiers . . . . . . . . . . . . . . . . 16 + 3.4.2. Data Model Type . . . . . . . . . . . . . . . . . . . 17 + 3.4.3. Record Identifiers . . . . . . . . . . . . . . . . . 18 + 3.4.4. Software Locators . . . . . . . . . . . . . . . . . . 18 + 3.4.5. Source Identifiers . . . . . . . . . . . . . . . . . 19 3.4.6. Using Software and Record Identifiers in SW - Attributes . . . . . . . . . . . . . . . . . . . . . 21 + Attributes . . . . . . . . . . . . . . . . . . . . . 20 3.5. Targeted Requests . . . . . . . . . . . . . . . . . . . . 21 3.6. Monitoring Changes in an Endpoint's Software Inventory Evidence Collection . . . . . . . . . . . . . . . . . . . 22 - 3.7. Reporting Change Events . . . . . . . . . . . . . . . . . 25 + 3.7. Reporting Change Events . . . . . . . . . . . . . . . . . 24 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.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 Attributes . . . . . . . . . . . . . . . . . . . . . 28 3.7.6. Synchronizing Event Identifiers and Epochs . . . . . 30 - - 3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 32 - 3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 32 - 3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 33 - 3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 33 - 3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 34 + 3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 31 + 3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 31 + 3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 32 + 3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 32 + 3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 33 3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 34 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.4. No Subscription Consolidation . . . . . . . . . . 38 - 3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 38 - 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 39 - 4. Software Inventory Message and Attributes for PA-TNC Protocol 40 - 4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 40 - 4.2. SW Attribute Overview . . . . . . . . . . . . . . . . . . 41 - 4.3. SW Attribute Exchanges . . . . . . . . . . . . . . . . . 43 - 4.4. Software Inventory Message and Attributes for PA-TNC - Attribute Enumeration . . . . . . . . . . . . . . . . . . 45 - 4.5. Normalization of Text Encoding . . . . . . . . . . . . . 46 - 4.6. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 47 - 4.7. SW Request . . . . . . . . . . . . . . . . . . . . . . . 48 - 4.8. Software Identifier Inventory . . . . . . . . . . . . . . 51 - 4.9. Software Identifier Events . . . . . . . . . . . . . . . 55 - 4.10. Software Inventory . . . . . . . . . . . . . . . . . . . 60 - 4.11. Software Events . . . . . . . . . . . . . . . . . . . . . 63 - 4.12. Subscription Status Request . . . . . . . . . . . . . . . 68 - 4.13. Subscription Status Response . . . . . . . . . . . . . . 68 - 4.14. PA-TNC Error as Used by Software Inventory Message and - Attributes for PA-TNC . . . . . . . . . . . . . . . . . . 70 - 4.14.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and - SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 72 - 4.14.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 73 - 4.14.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 75 - 5. Supported Data Models . . . . . . . . . . . . . . . . . . . . 77 - 5.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 77 - 5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID - Tags using XML . . . . . . . . . . . . . . . . . . . 77 - 5.1.2. Guidance on Creation of Software Identifiers from ISO - 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 78 - 5.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 78 - 5.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID - Tags using XML . . . . . . . . . . . . . . . . . . . 78 - 5.2.2. Guidance on Creation of Software Identifiers from ISO - 2009 SWID Tags . . . . . . . . . . . . . . . . . . . 79 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 79 - 6.1. Evidentiary Value of Software Inventory Evidence Records 79 - 6.2. Sensitivity of Collected Records . . . . . . . . . . . . 80 - 6.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 81 - 6.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 81 - 6.5. Sanitization of Record Fields . . . . . . . . . . . . . . 82 - 6.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 82 - 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 82 - 8. Relationship to Other Specifications . . . . . . . . . . . . 82 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 - 9.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 83 - 9.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 84 - 9.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 85 - 9.4. Registry for Software Data Models . . . . . . . . . . . . 86 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 87 - 10.2. Informative References . . . . . . . . . . . . . . . . . 88 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 + 3.8.5.4. No Subscription Consolidation . . . . . . . . . . 37 + 3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 37 + 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 38 + 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 4.1. Direct Response to a SW Request . . . . . . . . . . . . . 40 + 4.2. Subscription-Based Response . . . . . . . . . . . . . . . 40 + 4.3. Required Exchanges . . . . . . . . . . . . . . . . . . . 41 + 5. Software Inventory Messages and Attributes . . . . . . . . . 41 + 5.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 42 + 5.2. SW Attribute Overview . . . . . . . . . . . . . . . . . . 42 + 5.3. Message Diagram Syntax . . . . . . . . . . . . . . . . . 44 + 5.4. Software Inventory Message and Attributes for PA-TNC + Attribute Enumeration . . . . . . . . . . . . . . . . . . 44 + 5.5. Normalization of Text Encoding . . . . . . . . . . . . . 45 + 5.6. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 46 + 5.7. SW Request . . . . . . . . . . . . . . . . . . . . . . . 47 + 5.8. Software Identifier Inventory . . . . . . . . . . . . . . 50 + 5.9. Software Identifier Events . . . . . . . . . . . . . . . 54 + 5.10. Software Inventory . . . . . . . . . . . . . . . . . . . 59 + 5.11. Software Events . . . . . . . . . . . . . . . . . . . . . 62 + 5.12. Subscription Status Request . . . . . . . . . . . . . . . 67 + 5.13. Subscription Status Response . . . . . . . . . . . . . . 67 + 5.14. Source Metadata Request . . . . . . . . . . . . . . . . . 69 + 5.15. Source Metadata Response . . . . . . . . . . . . . . . . 69 + 5.16. PA-TNC Error as Used by Software Inventory Message and + Attributes for PA-TNC . . . . . . . . . . . . . . . . . . 71 + 5.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and + SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 73 + 5.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 75 + 5.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 76 + 6. Supported Data Models . . . . . . . . . . . . . . . . . . . . 78 + 6.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 78 + 6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID + Tags using XML . . . . . . . . . . . . . . . . . . . 79 + 6.1.2. Guidance on Creation of Software Identifiers from ISO + 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 79 + 6.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 79 + 6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID + Tags using XML . . . . . . . . . . . . . . . . . . . 80 + 6.2.2. Guidance on Creation of Software Identifiers from ISO + 2009 SWID Tags . . . . . . . . . . . . . . . . . . . 80 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 80 + 7.1. Evidentiary Value of Software Inventory Evidence Records 81 + 7.2. Sensitivity of Collected Records . . . . . . . . . . . . 81 + 7.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 82 + 7.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 83 + 7.5. Sanitization of Record Fields . . . . . . . . . . . . . . 83 + 7.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 83 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 84 + 9. Relationship to Other Specifications . . . . . . . . . . . . 84 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 + 10.1. PA Subtypes . . . . . . . . . . . . . . . . . . . . . . 85 + 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 - Possession of a list of an endpoint's installed software is very - useful in understanding and maintaining the security state of an - enterprise. For example, if an enterprise policy requires the - presence of certain pieces of software and/or prohibits the presence - of other software, reported software installation inventory lists can - be used to indicate compliance or non-compliance with these - requirements. Software installation inventories and the patch level - of the identified software can be compared to vulnerability or threat - alerts to determine an endpoint's exposure to attack. All of these - uses make an understanding of an endpoint's installed software - inventory highly useful to NEA Servers and other enterprise security - applications. + Knowing the list of the software installed on endpoints is useful to + understand and maintain the security state of a network. For + example, if an enterprise policy requires the presence of certain + software and prohibits the presence of other software, reported + software installation information can be used to indicate compliance + and non-compliance with these requirements. When reported endpoint + software installation inventory lists, shortened to "software + inventories" for the remainder of this document, contain patch level + data for identified software, further comparison to vulnerability or + threat alerts can be used to determine an endpoint's exposure to + attack. These are some of the highly useful management use cases + supported by software inventory data provided by this specification. There is a need for a standardized method for exchanging software - inventory that carries a software identifier (a unique identifier - associated with a specific software product and version thereof). In - some cases, it may also be necessary to convey information that - characterizes this product (i.e., provides metadata about the product - beyond its identifier) as well as observable installation - information. These "Messages and Attributes" would enable software - identification, installation, and characterization information to be - provided for any software installed on any endpoint that supports - this specification. - - To that end, this specification defines a new set of PA-TNC - attributes, carried over PA-TNC messages, which are used to - communicate requests for software information and software events, - and for conveying that information back to a NEA Server. + inventory data that includes a unique software identifier associated + with a specific version of a software product. In some cases, it may + also be necessary to convey observable installation information and + characterization information for a software product including + metadata about the product beyond its identifier. These "Messages + and Attributes" enable software identification, installation, and + characterization information to be provided for any software + installed on any endpoint that supports this specification. Such + information can come from multiple sources, including tag files (such + as ISO SWID tags [SWID15]), reports from third party inventory tools, + output from package managers, and other sources. - 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 report information about what software is running on the endpoint. Likewise, it is not intended to report individual files, libraries, installation packages, or similar artifacts. While all of this information has its uses, this information requires different - metadata and different methods of monitoring the endpoint. As a - result, this specification focuses solely on installed software, - leaving reporting of other classes of endpoint information to other - specifications. + metadata and monitoring methods. As a result, this specification + focuses solely on software inventory information, leaving reporting + of other classes of endpoint information to other 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) The Network Endpoint Assessment (NEA) Working Group defines an open solution architecture that enables network operators to collect and utilize information about endpoint configuration and state. This information can be used to enforce policies, monitor endpoint health, and for many other activities. Information about the software present on an endpoint is an important consideration for such - activities. Such information can come from multiple sources, - including tag files (such as ISO SWID tags [SWID15], reports from - third party inventory tools, output from package managers, and other - sources. The attributes defined in this document are used to + activities. The attributes defined in this document are used to communicate software inventory evidence, collected from a range of possible sources, from the posture collector on the endpoint to the posture validator on a NEA Server using the PA-TNC interface, as shown in Figure 1 below. +-------------+ +--------------+ | Posture | <--------PA--------> | Posture | | Collectors | | Validators | | (1 .. N) | | (1 .. N) | +-------------+ +--------------+ @@ -235,25 +237,24 @@ +-------------+ +--------------+ | Posture | | Posture | | Transport | <--------PT--------> | Transport | | Client | | Server | | (1 .. N) | | (1 .. N) | +-------------+ +--------------+ NEA CLIENT NEA SERVER Figure 1: NEA Reference Model - Before reading this specification any further, the reader should - review and understand the NEA reference architecture as described in - the Network Endpoint Assessment (NEA): Overview and Requirements - [RFC5209]. The reader should also understand the capabilities and - requirements common to PA-TNC interfaces as defined in RFC 5792 + To better understand this specification, the reader should review the + NEA reference architecture as described in the Network Endpoint + Assessment (NEA): Overview and Requirements [RFC5209]. The reader + should also review the PA-TNC interfaces as defined in RFC 5792 [RFC5792]. This document is based on standards published by the Trusted Computing Group's Trusted Network Communications (TNC) workgroup. The TNC and NEA architectures are interoperable and the following components are equivalent: +---------------------------------------+-----------------------+ | TNC Component | NEA Component | +---------------------------------------+-----------------------+ @@ -277,27 +278,25 @@ informative comments and normative requirements. Therefore, for the sake of clarity, note that lower case instances of must, should, etc. do not indicate normative requirements. 1.3. Definitions This section defines terms with special meaning within this document. SW-PC - A Posture Collector (PC) that conforms to this specification. Note that such a posture collector might also support other PA-TNC - exchanges beyond Software Inventory Message and Attributes for PA- - TNC. + exchanges beyond those defined herein. SW-PV - A Posture Validator (PV) that conforms to this specification. Note that such a posture verifier might also support other PA-TNC - exchanges beyond Software Inventory Message and Attributes for PA- - TNC. + exchanges beyond those defined herein. SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792 [RFC5792] extension for conveying software inventory information. This specification defines several new attribute types. Endpoint's Software Inventory Evidence Collection - The set of information regarding the set of software installed on an endpoint. An endpoint's software inventory evidence collection might include information created by or derived from multiple sources, including but not limited to SWID tag files deposited on the file system during @@ -308,303 +307,253 @@ Software Inventory Evidence Record - The endpoint's Software Inventory Evidence Collection is composed of "records". Each record corresponds to one installed instance of a particular software product as reported by some data source. It is possible for a single installed instance to have multiple software inventory evidence records in an endpoint's Software Inventory Evidence Collection - this can happen if multiple sources all report the same software installation instance. Software Identifier - A string associated with a specific version of - a specific software product. Each supported Software Inventory - Message and Attributes for PA-TNC data model has its own rules for - how a Software Identifier (see Section 3.4.1) is derived from the - representation of the given software product using that data model, - and different sources for this information might populate relevant - information differently. As such, while each Software Identifier - uniquely identifies a specific software product, the same software - product might be associated with multiple Software Identifiers - reflecting differences between different information sources and + a specific software product. Each supported SWIMA data model has its + own rules for how a software identifier (see Section 3.4.1) is + derived from the representation of the given software product using + that data model, and different sources for this information might + populate relevant information differently. As such, while each + software identifier uniquely identifies a specific software product, + the same software product might be associated with multiple software + identifiers reflecting differences between different data sources and supported data models. 2. Background 2.1. Supported Use Cases - This section describes the Software Inventory Message and Attributes - for PA-TNC use cases supported by this specification. The primary - use of exchanging software inventory information over the PA-TNC - interface is to enable a challenger (e.g. NEA Server) to obtain - inventory evidence about some system in a way that conforms to NEA - procedures and expressed using a standard format. Collected software - information can support a range of security activities including - determining whether an endpoint is permitted to connect to the - enterprise, determining which endpoints contain software that + This section describes the use cases supported by this specification. + The primary use of exchanging software inventory information over the + PA-TNC interface is to enable a challenger (e.g. NEA Server) to + obtain inventory evidence about some system in a way that conforms to + NEA procedures and expressed using a standard format. Collected + software information can support a range of security activities + including determining whether an endpoint is permitted to connect to + the enterprise, determining which endpoints contain software that requires patching, and similar activities. -2.1.1. Use Software Inventory as a Factor in Determining Endpoint - Access +2.1.1. Use Software Inventory as an Access Control Factor Some enterprises might define security policies that require connected endpoints to have certain pieces of security software installed. By contrast, some security policies might prevent access - by endpoints that have certain prohibited pieces of software - installed, such as applications that pose known security risks. To - support such policies, the NEA Server needs to collect evidence - indicating the software inventory of an endpoint that is seeking to - initiate or continue connectivity to the enterprise. + to resources by endpoints that have certain prohibited pieces of + software installed, since such applications might pose a security + risk. To support such policies, the NEA Server needs to collect + software inventory evidence from an endpoint that is seeking to + initiate or continue connectivity to the enterprise resource. - Software Inventory Message and Attributes for PA-TNC facilitates - policy decisions that consider an endpoint's software inventory by - providing the NEA Server with software inventory information from the - endpoint. The SW-PC can provide a complete or partial inventory to - the SW-PV as required to determine policy compliance. The SW-PV can - then use this as evidence of compliance or non-compliance with - enterprise policy. + Based on this specification, the SW-PC can provide a complete or + partial inventory to the SW-PV as required to determine policy + compliance. The SW-PV can then use this as evidence of compliance or + non-compliance to make a policy-based access decision. -2.1.2. Maintain a Central Repository Reflecting an Endpoint's Software - Inventory +2.1.2. Central Stores of Up-to-Date Endpoint Software Inventory Data - Many tools can use information about an endpoint's software inventory - to monitor and enforce the security of an enterprise. For example, a - software patching service can use an endpoint's software inventory to - determine whether certain endpoints have software that requires - patching. A vulnerability management tool might identify endpoints - with known vulnerabilities (patched or otherwise) and use this to - gauge enterprise exposure to attack. A license management tool might - verify that all copies of a particular piece of software are - accounted for within the enterprise. The presence of a central - repository representing a real-time understanding of each endpoint's - software inventory facilitates all such activities. Using a central - repository that can ensure the freshness of its collected information - is generally more efficient than having each tool collect the same - inventory information from each endpoint individually and leads to a - more consistent understanding of enterprise state. + Many tools use information about an endpoint's software inventory to + monitor and enforce the security of a network. For example, a + software patching tool needs to determine if there is out-of-date + software installed that needs to be updated. A vulnerability + management tool needs to identify endpoints with known vulnerable + software installed (patched or otherwise) to gauge an endpoint's + relative exposure to attack. A license management tool needs to + verify that all installed software within the enterprise is accounted + for. A central repository representing an up-to-date understanding + of each endpoint's software inventory facilitates these activities. + Multiple tools can share such a repository ensuring that software + inventory information is collected more frequently and efficiently, + leading to a more complete and consistent understanding of installed + software state as compared to each tool collecting the same inventory + information from endpoints individually. - Software Inventory Message and Attributes for PA-TNC supports this - activity through a number of mechanisms. As noted above, it allows a - SW-PC to provide a complete list of software present in an endpoint's - Software Inventory Evidence Collection to the SW-PV, which can then - pass this information on to a central repository such as a - Configuration Management Database (CMDB) or similar application. In - addition, SW-PCs are required to be able to monitor for changes to an - endpoint's Software Inventory Evidence Collection in near real-time - and push reports of changes to the SW-PV as soon as those changes are - detected. Thus any central repository fed by a SW-PV receiving such - information can be updated soon after the change occurs. Keeping - such a central repository synchronized with the state of each - endpoint's Software Inventory Evidence Collection allows tools that - use this information for their own security activities to make - decisions in a consistent, efficient manner. + This specification supports these activities through a number of + mechanisms. As noted above, a SW-PC can provide a complete list of + software present in an endpoint's Software Inventory Evidence + Collection to the SW-PV, which can then pass this information on to a + central repository, such as a Configuration Management Database + (CMDB) or similar application. In addition, SW-PCs are required to + be able to monitor for changes to an endpoint's Software Inventory + Evidence Collection in near real-time and immediately push reports of + detected changes to the SW-PV. Thus any central repository fed by a + SW-PV receiving inventory information can be updated quickly after a + change occurs. Keeping a central repository synchronized with + current software inventory information in this way allows tools to + make efficient decisions based on up-to-date, consistent information. 2.1.3. PA-TNC Use Cases Software Inventory Message and Attributes for PA-TNC are intended to operate over the PA-TNC interface and, as such, are intended to meet the use cases set out in the PA-TNC specification. 2.2. Non-supported Use Cases - Some use cases not covered by this version of Software Inventory - Message and Attributes for PA-TNC include: + Some use cases not covered by this specification include: - o This specification does not address how the endpoint's Software - Inventory Evidence Collection is populated. In particular, NEA - components are not expected to perform software discovery - activities beyond compiling information in an endpoint's Software - Inventory Evidence Collection. This collection might potentially - come from multiple sources on the endpoint (e.g., information - generated dynamically by package management tools or discovery - tools, as well as SWID tag files discovered on the file system). - While an enterprise might make use of software discovery - procedures to identify installed software such procedures are - outside the scope of this specification. + o Addressing how the endpoint's Software Inventory Evidence + Collection is populated. In particular, NEA components are not + expected to perform software discovery activities beyond compiling + information in an endpoint's Software Inventory Evidence + Collection. This collection might come from multiple sources on + the endpoint (e.g., information generated dynamically by package + management tools or discovery tools, as well as SWID tag files + discovered on the file system). While an enterprise might make + use of software discovery capabilities to identify installed + software, such capabilities are outside the scope of this + specification. - o This specification does not address converting inventory - information expressed in a proprietary format into formats used in - the attributes described in this specification. Instead, it - focuses exclusively on defining interfaces for the transportation - of software information in the expectation that this is the format - around which reporting tools will converge. + o Converting inventory information expressed in a proprietary format + into formats used in the attributes described in this + specification. Instead, this specification focuses exclusively on + defining interfaces for the transportation of software information + expecting that reporting tools will converge around some set of + standardized formats for this information. - o This specification provides no mechanisms for a posture validator - to request a specific list of software information based on - arbitrary software properties. For example, requesting only - information about software from a particular vendor is not - supported. After the endpoint's software inventory evidence - collection has been copied to some central location, such as the - CMDB, processes there can perform queries based on any criteria - present in the collected information, but this specification does - not address using such queries to constrain the initial collection - of this information from the endpoint. + o Mechanisms for a posture validator to request a specific list of + software information based on arbitrary software properties. For + example, requesting only information about software from a + particular vendor is not supported. After the endpoint's Software + Inventory Evidence Collection has been copied to some central + location, such as the CMDB, processes there can perform queries + based on any criteria present in the collected information, but + this specification does not address using such queries to + constrain the initial collection of this information from the + endpoint. - o This specification does not address utilization of properties of - certain sources of software information that might facilitate - local tests (i.e., on the endpoint) of endpoint state. For - example, the optional package_footprint field of an ISO SWID tag - can contain a list of files and hash values associated with the - software indicated by the tag. Tools on the endpoint can use the - values in this field to test for the presence of the indicated - files. Successful evaluation of such tests leads to greater - assurance that the indicated software is present on the endpoint. - Currently, most SWID tag creators do not provide values for tag - fields that support local testing. For this reason, the added - complexity of supporting endpoint testing using these fields is - out of scope for this specification. Future versions of this - specification might add support for such testing. + o Use of properties of certain sources of software information that + might facilitate local tests (i.e., on the endpoint) of endpoint + state. For example, the optional package_footprint field of an + ISO SWID tag can contain a list of files and hash values + associated with the software indicated by the tag. Tools on the + endpoint can use the values in this field to test for the presence + of the indicated files. Successful evaluation of such tests leads + to greater assurance that the indicated software is present on the + endpoint. Currently, most SWID tag creators do not provide values + for tag fields that support local testing. For this reason, the + added complexity of supporting endpoint testing using these fields + is out of scope for this specification, but may be considered in a + future version. 2.3. Specification Requirements Below are the requirements that the Software Inventory Message and Attributes for PA-TNC specification is required to meet in order to successfully play its role in the NEA architecture. - o Efficient - - The NEA architecture enables delay of network access until the - endpoint is determined not to pose a security threat to the network - based on its asserted integrity information. To minimize user - frustration, the Software Inventory Message and Attributes for PA-TNC - ought to minimize overhead delays and make PA-TNC communications as - rapid and efficient as possible. + Efficient: The NEA architecture enables delay of network access + until the endpoint is determined not to pose a security threat to + the network based on its asserted integrity information. To + minimize user frustration, the Software Inventory Message and + Attributes for PA-TNC 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 + 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 - 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. + 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 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 - understanding of the state of endpoint in a network in a way that can - be used by other tools. One means of facilitating such an outcome is - for a Configuration Management Database (CMDB) to be able to contain - information about all endpoints connected to the enterprise for all - points in time between the endpoint's first connection and the - present. In such a scenario, it is necessary that any PC be able to - report any changes to its software inventory evidence collection in - near real-time while connected and, upon reconnection to the + Support precise and complete historical reporting: This + specification outlines capabilities that support real-time + understanding of the state of endpoint in a network in a way that + can be used by other tools. One means of facilitating such an + outcome is for a CMDB to be able to contain information about all + endpoints connected to the enterprise for all points in time + between the endpoint's first connection and the present. In such + a scenario, it is necessary that any PC be able to report any + changes to its software inventory evidence collection in near + real-time while connected and, upon reconnection to the enterprise, be able to update the NEA Server (and through it the CMDB) with regard to the state of its software inventory evidence - collection throughout the entire interval when it was not connected. + collection throughout the entire interval when it was not + connected. 2.4. Non-Requirements There are certain requirements that the Software Inventory Message and Attributes for PA-TNC specification explicitly is not required to meet. This list is not exhaustive. - o End to End Confidentiality - - This specification does not define mechanism for confidentiality, nor - is this property automatically provided by PA-TNC interface use. - Confidentiality is generally provided by the underlying transport - protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP Posture - Transport for Tunneled EAP Methods [RFC7171] - see Section 8 for more - information on related standards. Should users wish confidentiality - protection of assessment instructions or results, this needs to be - provided by parts of the NEA architecture other than this - specification. + End to End Confidentiality: This specification does not define a + mechanism for confidentiality, nor is this property automatically + provided by using the PA-TNC interface. In the NEA architecture, + confidentiality is generally provided by the underlying transport + protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP + Posture Transport for Tunneled EAP Methods [RFC7171] - see + Section 9 for more information on related standards. Should users + wish to protect the confidentiality of assessment instructions or + results, then an appropriate transport needs to be used. 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 - provide reliable delivery for PA-TNC messages and therefore the - Attributes sent between the SW PCs and the PVs. In the event that - reliable delivery cannot be provided, the Posture Collector or - Posture Validator is expected to terminate the connection. + provide reliable delivery for PA-TNC messages and attributes sent + between the SW-PCs and the SW-PVs. In the event that reliable + delivery cannot be provided, the Posture Collector or Posture + Validator is expected to terminate the connection. 2.6. Non-Assumptions - The Software Inventory Message and Attributes for PA-TNC - specification explicitly does not assume: - - 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 + This specification explicitly does not assume that software inventory + information exchanges reflect the software installation state of the + endpoint. This specification does not attempt to detect when the endpoint is providing false information, either through malice or error, but instead focuses on correctly and reliably providing the reported Software Inventory Evidence Collection to the NEA Server. - Similarly, this specification makes no assumption with regard to the + Similarly, this specification makes no assumption about the completeness of the Software Inventory Evidence Collection's coverage of the total set of software installed on the endpoint. It is possible, and even likely, that some installed software is not represented by a record in an endpoints Software Inventory Evidence - Collection. See Section 6 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). + Collection. See Section 7 for more on this security consideration. -3. Software Inventory Message and Attributes for PA-TNC System - Requirements +3. System Requirements The Software Inventory Message and Attributes for PA-TNC specification facilitates the exchange of software inventory and event information. Specifically, each application supporting Software Inventory Message and Attributes for PA-TNC includes a component known as the SW-PC that receives messages sent with the SW Attributes component type. The SW-PC is also responsible for sending appropriate SW Attributes back to the SW-PV in response. This section outlines what software inventories and events are and the requirements on SW-PCs and SW-PVs in order to support the stated use cases of this specification. -3.1. Information Sources +3.1. Data Sources The records in an endpoint's software inventory evidence collection come from one or more "sources". A source represents one collection of software inventory information about the endpoint. Examples of sources include, but are not limited to, ISO SWID tags deposited on the filesystem and collected therefrom, information derived from package managers (e.g., RPM or YUM), and the output of software inventory scanning tools. There is no expectation that any one source of inventory information @@ -618,25 +567,25 @@ other means. A SW-PC is not required to utilize every possible source of software information on its endpoint. Some SW-PCs might be explicitly tied only to one or a handful of software inventory sources, or it could be designed to dynamically accommodate new sources. For all software inventory evidence sources that a particular SW-PC supports, it MUST completely support all requirements of this specification with regard to those sources. A potential source that cannot support some set of 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 - be used as a source of endpoint software inventory information, even - if it could provide some information. In other words, a source - either supports full functionality as described in this - specification, or it cannot be used at all. + reports for change events, as discussed in Section 3.6) MUST NOT be + used as a source of endpoint software inventory information, even if + it could provide some information. In other words, a source either + supports full functionality as described in this specification, or it + cannot be used at all. When sending information about installed software the SW-PC MUST include the complete set of relevant data from all supported sources of software inventory evidence. In other words, sources need to be used consistently. This is because, if a particular source is included in an initial inventory, but excluded from a later inventory, the SW-PV receiving this information might reasonably conclude that the software reported by that source was no longer installed on the endpoint. As such, it is important that all supported sources be used every time the SW-PC provides information @@ -648,50 +597,60 @@ a single installation of a software product. When a SW-PC reports information or records events from multiple inventory evidence sources, it MUST use the information those sources provide, rather than attempting to perform some form of reduction. In other words, if multiple sources report records corresponding to a single 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 lead to multiple reporting, and the SW-PC is not to ignore some 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 Software Inventory Message and Attributes supports an open set of data models by which installed software instances can be described. This reflects the fact that, as of the writing of this specification, 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 information had very little impact on the behavior of the components defined in this specification. The SW-PV has no dependency on the 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 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 data model used to express software information, but any such dependency is beyond the scope of this specification and needs to be addressed outside the behaviors specified in this document. This specification is only concerned with collection and delivery of software inventory information; components that consume and use this information are a separate concern.) 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 - required to create a Software Identifier (described in Section 3.4.1) - based on each record it delivers. The SW-PC MUST be able to generate - a Software Identifier for each record it delivers, and if the SW-PC - cannot do so the record cannot be delivered by the SW-PC. All SW-PCs - MUST be able to generate Software Identifiers for the data model - types specified in Section 5 of this document. + required to deterministically create a Software Identifier (described + in Section 3.4.1) based on each record it delivers. The SW-PC MUST + be able to generate a Software Identifier for each record it + delivers, and if the SW-PC cannot do so the record cannot be + delivered by the SW-PC. All SW-PCs MUST at least be able to generate + 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 In the most basic exchange supported by this specification, a SW-PV sends a request to the SW-PC requesting some type of information about the endpoint's software inventory. This simple exchange is shown in Figure 2. +-------------+ +--------------+ | SW-PC | | SW-PV | Time @@ -749,21 +708,21 @@ following sections examine these three types of information in more detail. 3.4.1. Software Identifiers A Software Identifier uniquely identifies a specific version of a specific software product. The Software Inventory Message and Attributes for PA-TNC specification does not dictate the structure of a Software Identifier (beyond stating that it is a string) or define how it is created. Instead, each data model described in the - Software Data Model IANA table (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 Endpoint's Software Inventory Evidence Collection expressed in that data model. Other data models will have their own procedures for the creation of associated Software Identifiers. Within the Software Inventory Message and Attributes for PA-TNC specification, the Software Identifier is simply an opaque string and there is never any need to unpack any information that might be part of that identifier. A Software Identifier is a fraction of the size of the inventory record from which it is derived. For some combinations of data @@ -820,24 +779,24 @@ might be different. Clearly identifying the type of data model from with the Software Identifier was derived thus provides useful context for that value. The PEN (or Private Enterprise Number) identifies the organization that assigns meaning to the Data Model Type field value. PENs are managed by IANA in the Private Enterprise Numbers registry. PENs allow vendors to designate their own set of data models for software inventory description. IANA reserves the PEN of 0x000000. 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 - that this IANA table reserves all values greater than or equal to - 0xC0 (192) for enterprise use. This means that local enterprises can - use custom data formats and indicate them with the IANA PEN and a + Model IANA table, created in Section 10.4 of this specification. + Note that this IANA table reserves all values greater than or equal + to 0xC0 (192) for enterprise use. This means that local enterprises + can use custom data formats and indicate them with the IANA PEN and a Data Model Type value between 0xC0 and 0XFF, inclusive. Those enterprises are responsible for configuring their SW-PCs to correctly report those custom data models. 3.4.3. Record Identifiers 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 Software Inventory Evidence Collection. The SW-PC MUST assign a unique identifier to each record when it is added to the Endpoint's @@ -895,52 +854,73 @@ scheme and an empty path.) However, SW-PCs SHOULD only make such an assignment as a last resort. Even a probable location for a software product is preferable to using the unknown indicator. 3.4.5. Source Identifiers All SW-PCs MUST track the source of each piece of software 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- 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 - information. The first time a source is used, the Source - Identification Number is accompanied by setting the Source First Use - flag. This MUST be done on all records from that source sent in the - attribute that sends those records. From that point on, all - information that is provided by that source, MUST be delivered with - this same Source Identification Number. This MUST be done for each - source used. If the SW-PC ever is unclear as to whether a given - source is new or not, it MUST assume that this is a new source and - assign it a new Source Identification Number. Source Identification - Numbers can help with (although will not completely eliminate) the - challenges posed by multiple reporting of a single software instance: - since a single source would only report an instance or event once, if - multiple reports of a similar instance come from multiple sources, - this might be an instance of multiple reporting (although it still - might not be so). On the other hand, if multiple instances are - reported by a single source, this almost certainly means that there - are actually multiple instance that are being legitimately reported. + information. All information that is provided by that source, MUST + be delivered with this same Source Identification Number. This MUST + be done for each source used. If the SW-PC ever is unclear as to + whether a given source is new or not, it MUST assume that this is a + new source and assign it a new Source Identification Number. Source + Identification Numbers can help with (although will not completely + eliminate) the challenges posed by multiple reporting of a single + software instance: since a single source would only report an + instance or event once, if multiple reports of a similar instance + come from multiple sources, this might be an instance of multiple + reporting (although it still might not be so). On the other hand, if + multiple instances are reported by a single source, this almost + certainly means that there are actually multiple instance that are + being legitimately reported. + + The SW-PC is responsible for tracking associations between Source + 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 support recognition, rather than identification, of sources. That is to say, a Software Identification Number can tell a recipient that two events were reported by the same source, but will not necessarily help that recipient determine which source was used. Moreover, different SW-PCs will not necessarily use the same Source Identification Numbers for the same sources. SW-PCs MUST track the assignment of Source Identification Numbers to ensure consistent application thereof. SW-PCs MUST also track which Source Identification Numbers have been used with each SW-PV with which they - communicate. The "first use" of a source MUST correspond to the - first use as seen by each individual SW-PV. + communicate. 3.4.6. Using Software and Record Identifiers in SW Attributes A SW Attribute reporting an endpoint's Software Inventory Evidence Collection always contains the Software Identifiers associated with the identified software products. A SW Attribute might or might not also contain copies of software inventory evidence records. The attribute exchange is identical to the diagram shown in Figure 2 regardless of whether software inventory evidence records are included. The SW Request attribute indicates whether the response is @@ -1470,30 +1449,30 @@ attribute is otherwise identical to the SW Requests discussed in previous sections. Specifically, such a SW Request might or might not request inclusion of software inventory evidence records, might or might not be targeted, and might request change event records or endpoint inventory. Assuming no error is encountered, a SW-PC MUST send a SW Response attribute in direct response to this SW Request attribute, just as if the Subscription flag was not set. As such, the attribute exchange that establishes a new subscription in a SW-PC 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 - 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 established on the SW-PC. The SW Request attribute that establishes a new subscription is referred to as the "establishing request" for that subscription. When a subscription is established it is assigned a Subscription ID value. The Subscription ID is equal to the value of the Request ID of the establishing request. (For more about Request IDs, see - Section 4.6.) + Section 5.6.) A SW-PC MUST have the ability to record and support multiple simultaneous subscriptions from a single party and from multiple parties. A SW-PV MUST have the ability to record and support multiple simultaneous subscriptions to a single party and subscriptions to multiple parties. 3.8.2. Managing Subscriptions The SW-PC MUST record each accepted subscription along with the @@ -1508,21 +1487,21 @@ subscription. The SW-PV needs to retain this information in order to correctly interpret pushed SW Response attributes sent in fulfillment of the subscription. The identity of the SW-PC is given in the Posture Collector Identifier of the PB-PA message header in all messages from that SW-PC. 3.8.3. Terminating Subscriptions Subscriptions MAY be terminated at any time by the subscribing SW-PV 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 MUST only clear subscriptions that match both the NEA server connection ID and the SW-PV ID for this SW Request, and MUST clear all such subscriptions. This specification does not give the SW-PV the ability to terminate subscriptions individually - all subscriptions to the SW-PV are cleared when the Clear Subscriptions flag is set. This specification does not give the SW-PC the ability to @@ -1785,21 +1765,21 @@ unauthorized tampering. In other words, there needs to be some assurance that unauthorized individuals are not able to introduce long delays in subscription fulfillment. 3.9. Error Handling 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 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 - 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 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 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 a PA-TNC Error attribute, and possibly logging the error locally) rather than being partially executed. In the case where the SW-PC receives a valid SW Request attribute but experiences an error during the process of responding to that @@ -1845,160 +1825,31 @@ include, but are not limited to, detection of malformed SW Response attributes sent from a given SW-PC, as well as detection of error conditions when the SW-PV processes SW Responses. 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 the error, the time it was detected, and additional descriptive information to aid in understanding the nature and cause of the error. -4. Software Inventory Message and Attributes for PA-TNC 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. +4. Protocol - All SW-PVs MUST be capable of sending SW Requests 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 Requests 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. + The software inventory protocol supports two different types of + message exchanges which are described the following subsections, + along with implementation requirements for supporting these + exchanges. -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 - inventory or event collection from the queried endpoint. + The first type of exchange is used to provide the SW-PV with a + software inventory or event collection from the queried endpoint. +-------------+ +--------------+ | SW-PC | | SW-PV | Time +-------------+ +--------------+ | | | | |<------------SW Request--------------| | | | | | SW Response* | | |-----------------or----------------->| | | PA-TNC Error | | @@ -2012,184 +1863,309 @@ 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. events, full or targeted) and how it wishes the returned inventory to be expressed (with or without software inventory evidence records). The SW-PC responds with the requested information using the 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 request. - In addition, if there is an active subscription on the endpoint, the - SW-PC sends a SW Response to the SW-PV following a change event on - the endpoint in fulfillment of that subscription. Such an exchange - is shown in Figure 5. +4.2. Subscription-Based Response + + The second type of exchange allows change event-based reporting based + 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 Response(s)*------->| | | | | *SW Response is one of the following: Software Identifier Inventory, Software Identifier Events, Software Inventory, or Software Events. Figure 5: SW Attribute Exchange (In Fulfillment of an Active Subscription) Note that, unlike direct responses to a SW Request, a single change event can precipitate multiple SW Responses for a single subscription, but only if all but the last of those SW Responses - convey partial lists of event records, and the last of those SW - Responses conveys a complete list of event records. (That is, the - initial responses are partial lists and the last response is the + convey partial lists of event records. When providing multiple SW + Responses in this way, the initial responses contain partial lists of + event records and the last of those SW Responses conveys the remainder of the relevant event records, completing the delivery of - all relevant events at the time of the change event.) A single - Change Event MUST NOT otherwise be followed by multiple SW Response - or PA-TNC Error attributes in any combination. + all relevant events in response to the change event. A single Change + Event MUST NOT otherwise be followed by multiple SW Response or PA- + TNC Error attributes in any combination. + +4.3. Required Exchanges 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- PV immediately upon detection of a change to the endpoint's Software Inventory Evidence Collection in fulfillment of established SW-PV 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 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 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 | - | Name | | | | - +--------------+----------+------------+----------------------------+ - | SW Request | 0x000000 | 0x00000011 | Request from a SW-PV to a | - | | | | SW-PC for the SW-PC to | - | | | | provide a software | - | | | | inventory or event list | - | | | | | - | Software | 0x000000 | 0x00000012 | An inventory sent without | - | Identifier | | | software inventory | - | Inventory | | | evidence records sent from | - | | | | a SW-PC. | - | | | | | - | Software | 0x000000 | 0x00000013 | A collection of events | - | Identifier | | | impacting the endpoint's | - | Events | | | Software Inventory | - | | | | Evidence Collection, where | - | | | | events do not include | - | | | | software inventory | - | | | | evidence records. | - | | | | | - | Software | 0x000000 | 0x00000014 | An inventory including | - | Inventory | | | software inventory | - | | | | evidence records sent from | - | | | | a SW-PC. | - | | | | | - | Software | 0x000000 | 0x00000015 | A collection of events | - | Events | | | impacting the endpoint's | - | | | | Software Inventory | - | | | | Evidence Collection, where | - | | | | events include software | - | | | | inventory evidence | - | | | | records. | - | | | | | - | Subscription | 0x000000 | 0x00000016 | A request for a list of a | - | Status | | | SW-PV's active | - | Request | | | subscription. | - | | | | | - | Subscription | 0x000000 | 0x00000017 | A list of a SW-PV's active | - | Status | | | subscriptions. | - | Response | | | | - | | | | | - | Reserved | 0x000000 | 0x00000018 | These attribute types are | - | | | - | reserved for future use in | - | | | 0x0000001F | revisions to Software | - | | | | Inventory Message and | - | | | | Attributes for PA-TNC. | - | | | | | - | PA-TNC Error | 0x000000 | 0x00000008 | An error attribute as | - | | | | defined in the PA-TNC | - | | | | specification [RFC5792]. | - +--------------+----------+------------+----------------------------+ + +--------------+------------+---------------------------------------+ + | Attribute | Integer | Description | + | Name | | | + +--------------+------------+---------------------------------------+ + | SW Request | 0x00000011 | Request from a SW-PV to a SW-PC for | + | | (17) | the SW-PC to provide a software | + | | | inventory or event list | + | | | | + | Software | 0x00000012 | An inventory sent without software | + | Identifier | (18) | inventory evidence records sent from | + | Inventory | | a SW-PC. | + | | | | + | Software | 0x00000013 | A collection of events impacting the | + | Identifier | (19) | endpoint's Software Inventory | + | Events | | Evidence Collection, where events do | + | | | not include software inventory | + | | | evidence records. | + | | | | + | Software | 0x00000014 | An inventory including software | + | Inventory | (20) | inventory evidence records sent from | + | | | a SW-PC. | + | | | | + | Software | 0x00000015 | A collection of events impacting the | + | Events | (21) | endpoint's Software Inventory | + | | | Evidence Collection, where events | + | | | include software inventory evidence | + | | | records. | + | | | | + | Subscription | 0x00000016 | A request for a list of a SW-PV's | + | Status | (22) | active subscription on a SW-PC. | + | Request | | | + | | | | + | Subscription | 0x00000017 | A list of a SW-PV's active | + | Status | (23) | subscriptions on a SW-PC. | + | Response | | | + | | | | + | Source | 0x00000018 | A request for information about a SW- | + | Metadata | (24) | PC's data sources. | + | Request | | | + | | | | + | Subscription | 0x00000019 | Descriptive metadata about a SW-PC's | + | Status | (25) | data sources. | + | Response | | | + | | | | + | Reserved | 0x0000001A | These attribute types are reserved | + | | - | for future use in revisions to | + | | 0x0000001F | Software Inventory Message and | + | | (26 - 31) | Attributes for PA-TNC. | + | | | | + | PA-TNC Error | 0x00000008 | An error attribute as defined in the | + | | (8) | PA-TNC 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 require normalization of their format. When this is necessary, this is indicated in the field's description. In such cases, the field contents MUST be normalized to Network Unicode format as defined in RFC 5198 [RFC5198]. Network Unicode format defines a refinement of UTF-8 that ensures a normalized expression of characters. SW-PCs and SW-PVs MUST NOT perform conversion and normalization on any field values except those specifically identified as requiring normalization in the following sections. Note, however, that some data models require additional normalization before source information is added to an Endpoint's Inventory Evidence Collection 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 Request ID field provides a value that identifies a given request relative to other requests between a SW-PV and the receiving SW-PC. 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 network connection ID as assigned by the SW-PV's Posture Broker - Server. 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 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. + Server. In the case that a SW Request requests the establishment of a subscription and the receiving SW-PC agrees to that subscription, the Request ID of that SW Request (i.e., the establishing request of the subscription) becomes that subscription's Subscription ID. All attributes sent in fulfillment of this subscription include a flag indicating that the attribute fulfills a subscription and the 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 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- 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 Error attribute with an error code of SW_SUBSCRIPTION_ID_REUSE_ERROR. Note that this error does not cancel the indicated subscription. Subscription Status Requests and Subscription Status Responses do not 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 send software inventory information to the SW-PV. A SW-PC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Software Identifier Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -2265,24 +2241,25 @@ | | Identifier Inventory, or a PA-TNC Error | | | attribute. | | | | | Software | A 2-byte unsigned integer indicating the length | | Identifier | in bytes of the Software Identifier field. | | Length | | | | | | Software | A string containing the Software Identifier value | | Identifier | from a software inventory evidence record. This | | | 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. | +---------------+---------------------------------------------------+ - 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 indicated information. Note that between the Result Type flag and 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 response to the request. The Subscribe and Clear Subscription flags are used to manage subscriptions for the requesting SW-PV on the receiving SW-PC. Specifically, an attribute with the Subscribe flag set seeks to @@ -2294,75 +2271,75 @@ requester are deleted as described in Section 3.8.3. A newly established subscription has the parameters outlined in the Request attribute. Specifically, the Result Type flag indicates the type of result to send in fulfillment of the subscription, the value of the Earliest EID field indicates whether the fulfillment attributes list inventories or events, and the fields describing Software Identifiers (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 request to establish or clear subscriptions, the SW-PC MUST respond with a PA-TNC Error attribute with the SW_SUBSCRIPTION_DENIED_ERROR - error code. (Note that if the SW-PV requests that subscriptions be - cleared but has no existing subscriptions, this is not an error.) + error code. If the SW-PV requests that subscriptions be cleared but + has no existing subscriptions, this is not an error. An attribute requesting the establishment of a subscription is effectively doing double-duty, as it is a request for an immediate 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 send an appropriate response attribute to a request with the Subscribe flag set containing all requested information. The same is true of the Clear Subscription flag - assuming there is no error the SW-PC MUST generate a response attribute without regard to the presence of this flag in addition to clearing its subscription list. Both the Subscribe and Clear Subscription flags MAY be set in a single SW Request attribute. In the case where this request is 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 - new subscription in accordance with the request parameters. (In - other words, do not first create the new subscription and then clear - all the subscriptions including the one that was just created.) In - the case that the requested actions are successfully completed, the - SW-PC MUST respond with a SW Response attribute. (The specific type - of SW Response attribute depends on the Result Type and Earliest EID - fields, as described above.) In the case where there is a failure + new subscription in accordance with the request parameters. In other + words, do not first create the new subscription and then clear all + the subscriptions including the one that was just created. In the + case that the requested actions are successfully completed, the SW-PC + MUST respond with a SW Response attribute. The specific type of SW + Response attribute depends on the Result Type and Earliest EID + fields, as described above. In the case where there is a failure that prevents some part this request from completing, the SW-PC MUST 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 words, the SW-PC MUST NOT partially succeed at implementing such a request; either all actions succeed, or none succeed. - The Earliest EID field is used to indicate whether the SW-PV is - requesting an inventory or event list from the SW-PC. A value of 0 - (0x00000000) represents a request for inventory information. - Otherwise, the SW-PV is requesting event information. For Earliest - EID values other than 0, the SW-PC's response MUST respond with event - records, as described in Section 3.7. Note that the request does not - identify a particular EID Epoch, since responses can only include - events in the SW-PC's current EID Epoch. + The Earliest EID field is used to indicate if the SW-PV is requesting + an inventory or event list from the SW-PC. A value of 0 (0x00000000) + represents a request for inventory information. Otherwise, the SW-PV + is requesting event information. For Earliest EID values other than + 0, the SW-PC's response MUST respond with event records, as described + in Section 3.7. Note that the request does not identify a particular + EID Epoch, since responses can only include events in the SW-PC's + current EID Epoch. The Software Identifier Count indicates the number of Software Identifiers in the attribute. This number might be any value between 0 and 16,777,216, inclusive. A single Software Identifier is represented by the following fields: Software Identifier Length and Software Identifier. These fields are repeated a number of times - equal to the Software Identifier Count. Note that this could be 0 - times. The Software Identifier Length field indicates the number of - bytes allocated to the Software Identifier field. The Software - Identifier field contains a Software Identifier as describe in - Section 3.4.1. The presence of one or more Software Identifiers is - used by the SW-PV to indicate a targeted request, which seeks only - inventories of or events affecting software corresponding to the - given identifiers. The SW-PC MUST only report software that matched - the Software Identifiers provided in the SW-PVs SW Request attribute. + equal to the Software Identifier Count, which may be 0. The Software + Identifier Length field indicates the number of bytes allocated to + the Software Identifier field. The Software Identifier field + contains a Software Identifier as describe in Section 3.4.1. The + presence of one or more Software Identifiers is used by the SW-PV to + indicate a targeted request, which seeks only inventories of or + events affecting software corresponding to the given identifiers. + The SW-PC MUST only report software that matched the Software + 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 the endpoint's Software Inventory Evidence Collection without the inclusion of software inventory evidence records. This list might 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 send this attribute. The SW-PC either sends this attribute in fulfillment of an existing subscription where the establishing 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 @@ -2378,21 +2355,21 @@ | EID Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Model Type PEN |Data Model Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Software Identifier Inventory Attribute +----------------+--------------------------------------------------+ | Field | Description | +----------------+--------------------------------------------------+ | Flags: Bit 0 - | In the case that this attribute is sent in | @@ -2402,24 +2379,23 @@ | | be unset (0). | | | | | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | | - Reserved | to zero on transmission and ignored upon | | | reception. | | | | | Software | The number of Software Identifiers that follow. | | Identifier | This field is an unsigned integer. The Record | | Count | Identifier, Data Model Type PEN, Data Model | | | Type, Software Identifier Length, Software | - | | Locator Length, Source First Use Flag (F), | - | | Source Identification Number, Software | - | | Identifier, and Software Locator fields are | - | | repeated, in order, the number of times | + | | Locator Length, Source Identification Number, | + | | Software Identifier, and Software Locator fields | + | | are repeated, in order, the number of times | | | indicated in this field. This field value MAY be | | | 0, in which case there are no instances of these | | | fields. | | | | | Request ID | In the case where this attribute is in direct | | Copy / | response to a SW Request attribute from a SW-PV, | | Subscription | this field MUST contain an exact copy of the | | ID | Request ID field from that SW Request. In the | | | case where this attribute is sent in fulfillment | | | of an active subscription, this field MUST | @@ -2446,43 +2422,38 @@ | Type | identifier number that identifies the data model | | | of the reported record. | | | | | Software | A 2-byte unsigned integer indicating the length | | Identifier | in bytes of the SW ID field. | | Length | | | | | | Software | A 2-byte unsigned integer indicating the length | | 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 | | Identification | the source from which this software installation | | Number | inventory instance was reported. | | | | | Software | A string containing the Software Identifier | | Identifier | value from a software inventory evidence record. | | | 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. | | | | | Software | A string containing the Software Locator value. | | Locator | This is expressed as a URI. This field value | | | MUST be normalized to Network Unicode format as | | | described in Section 3.4.4. This string MUST NOT | | | 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 subscription, the Subscription Fulfillment bit MUST be set (1). In the case that this attribute is sent in direct response to a SW Request, the Subscription Fulfillment bit MUST be unset (0). Note that the SW Response attribute sent in direct response to a SW Request that establishes a subscription (i.e., a subscription's establishing request) MUST be treated as a direct response to that SW Request (and thus the Subscription Fulfillment bit is unset). SW Response attributes are only treated as being in fulfillment of a @@ -2510,30 +2481,24 @@ no recorded change events at the time that this inventory was collected, the Last EID field MUST contain 0. These fields can be interpreted to indicate that the provided inventory reflects the state of the endpoint after all changes up to and including this last event have been accounted for. The Data Model Type PEN and Data Model Type fields are used to identify the data model associated with the given software record. These fields are discussed more in Section 3.4.2. - The Source First Use flag and the Source Identification Number field - are used to identify the source that provided the given record, as - 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.) + The Source Identification Number field is used to identify the source + that provided the given record, as described in Section 3.1. -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 affected records are reported without software inventory evidence records. A SW-PV MUST NOT send this attribute. The SW-PC either sends this attribute in fulfillment of an existing subscription where 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 the Result Type is 1 and the Earliest EID is non-zero. 1 2 3 @@ -2560,21 +2525,21 @@ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Model Type PEN |Data Model Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Software Identifier Events Attribute +----------------+--------------------------------------------------+ | Field | Description | +----------------+--------------------------------------------------+ | Flags: Bit 0 - | In the case that this attribute is sent in | @@ -2585,26 +2550,26 @@ | | | | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | | - Reserved | to zero on transmission and ignored upon | | | reception. | | | | | Event Count | The number of events that are reported in this | | | attribute. This field is a 3-byte unsigned | | | integer. The EID, Timestamp, Record Identifier, | | | Data Model Type PEN, Data Model Type, Software | | | Identifier Length, Software Locator Length, | - | | Source First Use flag (F), Source Identification | - | | Number, Action, Software Identifier, and | - | | Software Locator fields are repeated, in order, | - | | the number of times indicated in this field. | - | | This field value MAY be 0, in which case there | - | | are no instances of these fields. | + | | Source Identification Number, Action, Software | + | | Identifier, and Software Locator fields are | + | | repeated, in order, the number of times | + | | indicated in this field. This field value MAY be | + | | 0, in which case there are no instances of these | + | | fields. | | | | | Request ID | In the case where this attribute is in direct | | Copy / | response to a SW Request attribute from a SW-PV, | | Subscription | this field MUST contain an exact copy of the | | ID | Request ID field from that SW Request. In the | | | case where this attribute is sent in fulfillment | | | of an active subscription, this field MUST | | | contain the Subscription ID of the subscription | | | being fulfilled by this attribute. | | | | @@ -2659,25 +2624,20 @@ | Type | identifier number that identifies the data model | | | of the reported record. | | | | | Software | A 2-byte unsigned integer indicating the length | | Identifier | in bytes of the SW ID field. | | Length | | | | | | Software | A 2-byte unsigned integer indicating the length | | 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 | | Identification | the source from which this software installation | | Number | inventory instance was reported. | | | | | Action | The type of event that is recorded in this event | | | record. Possible values are: 1 = CREATION - the | | | addition of a record to the endpoint's Software | | | Inventory Evidence Collection; 2 = DELETION - | | | the removal of a record from the endpoint's | | | Software Inventory Evidence Collection; 3 = | @@ -2687,31 +2647,31 @@ | | reserved for future use and MUST NOT be used | | | when sending attributes. In the case where a SW- | | | PV receives an event record that uses an action | | | value other than the ones defined here, it MUST | | | ignore that event record but SHOULD process | | | other event records in this attribute as normal. | | | | | Software | A string containing the Software Identifier | | Identifier | value from a software inventory evidence record. | | | 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. | | | | | Software | A string containing the Software Locator value. | | Locator | This is expressed as a URI. This field value | | | MUST be normalized to Network Unicode format as | | | described in Section 3.4.4. This string MUST NOT | | | 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 mirror those in the Software Identifier Inventory attribute. The primary difference is that, instead of conveying an inventory, the attribute conveys zero or more event records, consisting of the EID, timestamp, Record Identifier, action type, data model type, Software Identifier, and Software Locator of the affected software inventory evidence record. With regard to the Timestamp field, it is important to note that @@ -2753,21 +2712,21 @@ contains a complete event set, the Last EID and Last Consulted EID values are identical. If multiple events are sent in a Software Identifier Events attribute, the order in which they appear within the attribute is not significant. The EIDs associated with them are used for ordering the indicated events appropriately. Also note that a single software record might be reported multiple times in an attribute, such as if 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 records. A SW-PV MUST NOT send this attribute. The SW-PC either sends this attribute in fulfillment of an existing subscription where 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 Result Type is 0 and the Earliest EID is zero. 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 @@ -2781,21 +2740,21 @@ | Last EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Model Type PEN |Data Model Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Software Identifier Length | Software Locator Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |F|Source Id Num| Software Identifier (variable length) | + | Source Id Num | Software Identifier (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Software Locator (Variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record (Variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Software Inventory Attribute +----------------+--------------------------------------------------+ | Field | Description | @@ -2807,24 +2766,24 @@ | | be unset (0). | | | | | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | | - Reserved | to zero on transmission and ignored upon | | | reception. | | | | | Record Count | The number of records that follow. This field is | | | a 3-byte unsigned integer. The Record | | | Identifier, Data Model Type PEN, Data Model | | | Type, Software Identifier Length, Software | - | | Locator Length, Record Length, Source First Use | - | | Flag (F), Source Identification Number, Software | - | | Identifier, Software Locator, and Record fields | - | | are repeated, in order, the number of times | + | | Locator Length, Record Length, Source | + | | Identification Number, Software Identifier, | + | | Software Locator, and Record fields are | + | | repeated, in order, the number of times | | | indicated in this field. This field value MAY be | | | 0 in which case there are no instances of these | | | fields. | | | | | Request ID | In the case where this attribute is in direct | | Copy / | response to a SW Request attribute from a SW-PV, | | Subscription | this field MUST contain an exact copy of the | | ID | Request ID field from that SW Request. In the | | | case where this attribute is sent in fulfillment | | | of an active subscription, this field MUST | @@ -2854,63 +2813,58 @@ | Software | A 2-byte unsigned integer indicating the length | | Identifier | in bytes of the SW ID field. | | Length | | | | | | Software | A 2-byte unsigned integer indicating the length | | Locator Length | in bytes of the Software Locator field. | | | | | Record Length | This is a 4-byte unsigned integer indicating the | | | 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 | | Identification | the source from which this software installation | | Number | inventory instance was reported. | | | | | Software | A string containing the Software Identifier | | Identifier | value from a software inventory evidence record. | | | 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. | | | | | Software | A string containing the Software Locator value. | | Locator | This is expressed as a URI. This field value | | | MUST be normalized to Network Unicode format as | | | described in Section 3.4.4. This string MUST NOT | | | be NULL terminated. | | | | | Record | A software inventory evidence record as a | | | string. The record MUST be converted and | | | 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. | +----------------+--------------------------------------------------+ - Table 7: Software Inventory Attribute Fields + Table 6: Software Inventory Attribute Fields The Software Inventory attribute contains some number of software inventory evidence records along with the core response attribute fields. Given that the size of records can vary considerably, the length of this attribute is highly variable and, if transmitting a complete inventory, can be extremely large. Enterprises might wish to constrain the use of Software Inventory attributes to targeted requests to avoid over-burdening the network unnecessarily. When copying a software inventory evidence record into the Record field, the record MUST be converted and normalized to use Network 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 that include software inventory evidence records. A SW-PV MUST NOT send this attribute. The SW-PC either sends this attribute in fulfillment of an existing subscription where the establishing 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 0 and the Earliest EID is non-zero. 1 2 3 @@ -2939,21 +2893,21 @@ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Model Type PEN |Data Model Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Software Identifier Length | Software Locator Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |F|Source Id Num| Action | Software Identifier (var len) | + | Source Id Num | Action | Software Identifier (var len) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Software Locator (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Software Events Attribute +----------------+--------------------------------------------------+ | Field | Description | @@ -2966,27 +2920,26 @@ | | | | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | | - Reserved | to zero on transmission and ignored upon | | | reception. | | | | | Event Count | The number of events being reported in this | | | attribute. This field is a 3-byte unsigned | | | integer. The EID, Timestamp, Record Identifier, | | | Data Model Type PEN, Data Model Type, Software | | | Identifier Length, Software Locator Length, | - | | Record Length, Source First Use Flag (F), Source | - | | Identification Number, Action, Software | - | | Identifier, Software Locator, and Record fields | - | | are repeated, in order, the number of times | - | | indicated in this field. This field value MAY | - | | be 0, in which case there are no instances of | - | | these fields. | + | | Record Length, Source Identification Number, | + | | Action, Software Identifier, Software Locator, | + | | and Record fields are repeated, in order, the | + | | number of times indicated in this field. This | + | | field value MAY be 0, in which case there are no | + | | instances of these fields. | | | | | Request ID | In the case where this attribute is in direct | | Copy / | response to a SW Request attribute from a SW-PV, | | Subscription | this field MUST contain an exact copy of the | | ID | Request ID field from that SW Request. In the | | | case where this attribute is sent in fulfillment | | | of an active subscription, this field MUST | | | contain the Subscription ID of the subscription | | | being fulfilled by this attribute. | | | | @@ -3044,25 +2997,20 @@ | Software | A 2-byte unsigned integer indicating the length | | Identifier | in bytes of the Software Identifier field. | | Length | | | | | | Software | A 2-byte unsigned integer indicating the length | | Locator Length | in bytes of the Software Locator field. | | | | | Record Length | This is a 4-byte unsigned integer indicating the | | | 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 | | Identification | the source from which this software installation | | Number | inventory instance was reported. | | | | | Action | The type of event that is recorded in this event | | | record. Possible values are: 1 = CREATION - the | | | addition of a record to the endpoint's Software | | | Inventory Evidence Collection; 2 = DELETION - | | | the removal of a record from the endpoint's | | | Software Inventory Evidence Collection; 3 = | @@ -3072,68 +3020,68 @@ | | reserved for future use and MUST NOT be used | | | when sending attributes. In the case where a SW- | | | PV receives an event record that uses an action | | | value other than the ones defined here, it MUST | | | ignore that event record but SHOULD process | | | other event records in this attribute as normal. | | | | | Software | A string containing the Software Identifier | | Identifier | value from a software inventory evidence record. | | | 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. | | | | | Software | A string containing the Software Locator value. | | Locator | This is expressed as a URI. This field value | | | MUST be normalized to Network Unicode format as | | | described in Section 3.4.4. This string MUST NOT | | | be NULL terminated. | | | | | Record | A software inventory evidence record as a | | | string. The record MUST be converted and | | | 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. | +----------------+--------------------------------------------------+ - 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 corresponding fields of the previous attributes. As with the Software Inventory attribute, a Software Events attribute can be quite large if many events have occurred following the event indicated by a request's Earliest EID. As such, it is recommended that the SW Request attributes only request full records be sent (Result Type set to 0) in a targeted request, thus constraining the response just to records that match a given set of Software Identifiers. As with the Software Identifier Events Attribute, this attribute MUST only contain event records with EIDs coming from the current EID Epoch of the SW-PC. As with the Software Inventory Attribute, the SW-PC MUST perform 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 subscriptions for which the requesting SW-PV is the subscriber. A SW-PC MUST NOT send this attribute. This attribute has no fields. A SW-PC MUST respond to this attribute by sending a Subscription Status Response attribute (or a PA-TNC Error attribute if it is 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 subscriptions for which the receiving SW-PV is the subscriber. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Flags | Subscription Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -3168,21 +3116,21 @@ | Identifier | contain an exact copy of the fields with the | | Count, Request | same name as provided in the subscription's | | ID, Earliest | establishing request. | | EID, Software | | | Identifier | | | Length, and | | | Software | | | Identifier | | +-----------------+-------------------------------------------------+ - Table 9: Subscription Status Response Fields + Table 8: Subscription Status Response Fields A Subscription Status Response contains zero or more subscription records. Specifically, it MUST contain one subscription record for each active subscription associated with the party that sent the 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 Connection ID and its Posture Validator ID to determine which subscriptions are associated with the requester. A SW-PC MUST send a Subscription Status Response attribute in @@ -3213,115 +3161,220 @@ When a SW-PV compares the information received in a Subscription 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 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 the SW-PV recognizes. For this reason, SW-PVs SHOULD NOT automatically assume that extra subscriptions reported in a 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 The PA-TNC Error attribute is defined in the PA-TNC specification [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 also be sent in response to error conditions specific to the Software Inventory Message and Attributes for PA-TNC exchange. The latter 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 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 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 - 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 Number. The Error Information structures for each error type are described in the following subsections. Note that a message with a Software Inventory Message and Attributes 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 SW Attribute might have an invalid parameter, leading to an error 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 PA-TNC specification. +-----------------------+-------------------------------------------+ | 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 | | | creation of a suitable response | | | attribute) other than the errors | | | described below but still specific to the | | | processing of SW Attributes. The | | | Description field SHOULD contain | | | additional diagnostic information. | | | | - | 0x00000021 | SW_SUBSCRIPTION_DENIED_ERROR. This | + | 0x00000021 (33) | SW_SUBSCRIPTION_DENIED_ERROR. This | | | indicates that the SW-PC denied the SW- | | | PV's request to establish a subscription. | | | The Description field SHOULD contain | | | 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 | | | the SW-PV's request was too large to be | | | serviced. The error information structure | | | indicates the largest possible size of a | | | 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 | | | information. | | | | - | 0x00000023 | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This | + | 0x00000023 (35) | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This | | | indicates that the SW-PC experienced an | | | error fulfilling a given subscription. | | | The error information includes the | | | Subscription ID of the relevant | | | subscription, as well as a sub-error that | | | describes the nature of the error the SW- | | | PC experienced. The SW-PC and SW-PV MUST | | | treat the identified subscription as | | | cancelled. | | | | - | 0x00000024 | SW_SUBSCRIPTION_ID_REUSE_ERROR. This | + | 0x00000024 (36) | SW_SUBSCRIPTION_ID_REUSE_ERROR. This | | | indicates that the SW-PC received a SW | | | Request from a given SW-PV where the | | | Request ID of that SW Request is | | | currently used as the Subscription ID of | | | an active subscription with that SW-PV. | | | This error does not cancel the identified | | | subscription. | | | | | 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 | | | for PA-TNC specification. Any PA-TNC | | | Error attribute using one of these Error | | | Codes MUST be treated as indicating a | | | fatal error on the sender without further | | | 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 The following subsections describe the structures present in the 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 The SW_ERROR error code indicates that the sender (the SW-PC) has encountered an error related to the processing of a SW Request 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 establish a subscription or clear all subscriptions from the given 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 receives a SW Request whose Request ID duplicates a Subscription ID @@ -3349,42 +3402,42 @@ | | error. In the case that the attribute in question | | | is generated in fulfillment of an active | | | subscription, this field MUST contain the | | | Subscription ID of the subscription for which the | | | attribute was generated. (This is only possible | | | if the error code is SW_ERROR as the other errors | | | are not generated by subscription fulfillment.) | | | Note that, in this case, the indicated error | | | appears as a sub-error for a | | | SW_SUBSCRIPTION_FULFILLMENT_ERROR, as described in | - | | Section 4.14.3. | + | | Section 5.16.3. | | | | | Description | A UTF-8 string describing the condition that | | | caused this error. This field MAY be 0-length. | | | However, senders SHOULD include some description | | | in all PA-TNC Error attributes of these types. | | | 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 This error information structure is used with SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR, and SW_SUBSCRIPTION_ID_REUSE_ERROR status codes to identify the SW Request attribute that precipitated the error condition and to describe the error. The Description field contains text describing the error. The SW-PC MAY encode machine- interpretable information in this field, but SHOULD also include a human-readable description of the error, since the receiving SW-PV 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 generated by a SW-PC in response to a SW-PV's SW Request attribute was too large to send. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Copy of Request ID / Subscription I | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -3402,50 +3455,50 @@ | Request ID / | generated in direct response to a SW Request, this | | Subscription | field MUST contain an exact copy of the Request ID | | ID | field in the SW Request attribute that caused this | | | error. In the case that the attribute in question | | | is generated in fulfillment of an active | | | subscription, this field MUST contain the | | | Subscription ID of the subscription for which the | | | attribute was generated. Note that, in the latter | | | case, the SW_RESPONSE_TOO_LARGE_ERROR appears as a | | | 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 | | Allowed Size | indicating the largest permissible size, in bytes, | | | of SW Attribute that the SW-PC is currently | | | willing to send in response to a SW Request | | | attribute. | | | | | Description | A UTF-8 string describing the condition that | | | caused this error. This field MAY be 0-length. | | | However, senders SHOULD include some description | | | in all PA-TNC Error attributes of these types. | | | 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 status code to identify the SW Request attribute that precipitated the error condition and to describe the error. The Maximum Allowed Size field indicates the largest attribute the SW-PC is willing to send in response to a SW Request under the current circumstances. Note that under other circumstances, the SW-PC might be willing to return larger or smaller responses than indicated (such as if the endpoint connects to the NEA Server using a different network protocol). The other fields in this error information structure have the same meanings as corresponding fields in the SW_ERROR and 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 SW-PC encountered an error while fulfilling a subscription. The 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 nature of the encountered error. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -3480,187 +3533,181 @@ | Code | Code field of a PA-TNC Error attribute that | | | describes the error condition encountered during | | | subscription processing. | | | | | Sub Error | This field MUST contain the value of the Error | | Information | Information field of a PA-TNC Error attribute that | | | describes the error condition encountered during | | | 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 SW_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets of this error structure contain the Subscription ID of the subscription that was being fulfilled when the error occurred. The remaining 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 sub-error corresponds to the type of error that the SW-PC encountered while fulfilling the given subscription. The sub-error MUST NOT have an error code of SW_SUBSCRIPTION_FULFILLMENT_ERROR. 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 Subscription ID field as cancelled. All other subscriptions are unaffected. -5. Supported Data Models +6. Supported Data Models Software Inventory Message and Attributes for PA-TNC supports an extensible list of data models for representing and transmitting software inventory information. This list of data models appears in - the Software Data Model IANA table (see Section 9.4). This document - provides guidance for an initial set of data models. Other documents - might provide guidance on the use of new data models by Software - Inventory Message and Attributes for PA-TNC, and will be referenced - by extensions to the Software Data Model IANA table. + the Software Data Model IANA registry (see Section 10.4). This + document provides guidance for an initial set of data models. Other + documents might provide guidance on the use of new data models by + Software Inventory Message and Attributes for PA-TNC, and will be + 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 International Electrotechnical Commission (ISO/IEC) published the specification governing SWID tag construction and use in 2009 with a revised version published in 2015. [SWID15] Since that time, a growing number of vendors have integrated SWID tags into their software products. Doing so significantly simplifies the task of identifying these pieces of software: instead of relying on discovery 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 presence of the given piece of software. SWID Message and Attributes for PA-TNC has no reliance on the presence or management of SWID tags on an endpoint as described in the ISO specification. However, the data model for describing software that is presented in the ISO specification provides a robust and comprehensive way of describing software and is adopted here as a means of representing and transmitting software information. It 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, in fact, an ISO SWID tag harvested from the endpoint or whether the information was created using some other source and normalized to the 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 Any record associated with this Software Data Model Type MUST conform 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 if doing so would invalidate digital signatures included in the tag. 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 - generating software unless this is impossible, in which case it MUST - use the Unknown Tag Creator RegID. Do not use a RegID associated - with any other party. In particular, it is incorrect to use a Tag - Creator RegID associated with the software being described by the - tag, the enterprise that is using the software, or any other entity - except that of the party that built the tool that is generating the - SWID tag. This reflects the requirement that the Tag Creator RegID - identify the party that created the tag. + tag MUST use a Tag Creator RegID that is associated with the + generating software, unless this is impossible, in which case it MUST + use the "http://invalid.unavailable" Tag Creator RegID value. Do not + use a RegID associated with any other party. In particular, it is + incorrect to use a Tag Creator RegID associated with the software + being described by the tag, the enterprise that is using the + software, or any other entity except that of the party that built the + tool that is generating the SWID tag. This reflects the requirement + 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 A Software Identifier generated from an ISO 2015 SWID tag is 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: - NUMBER::TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length of - TAG_CREATOR_REGID in bytes. The rest of the Software Identifier MUST - be the concatenation of the Tag Creator RegID and the Unique ID from - the tag, without any connecting character or whitespace. + NUMBER "::" TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length + of TAG_CREATOR_REGID in bytes. The rest of the Software Identifier + MUST be the concatenation of the Tag Creator RegID and the Unique ID + 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 model for representation of software information. As of the writing of this specification, while the 2015 specification is considered more comprehensive and addresses some issues with the 2009 specification, 2009-format SWID tags remain far more common in deployments. For this reason, ISO 2009 SWID tags are included in the 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 Any record associated with this Software Data Model Type MUST conform 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 if doing so would invalidate digital signatures included in the tag. 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 - use the Unknown Tag Creator RegID. Do not use a RegID associated - with any other party. In particular, it is incorrect to use a Tag - Creator RegID associated with the software being described by the - tag, the enterprise that is using the software, or any other entity - except that of the party that built the tool that is generating the - SWID tag. This reflects the requirement that the Tag Creator RegID - identify the party that created the tag. + use "http://invalid.unavailable", which indicates the Tag Creator is + unknown. Do not use a RegID associated with any other party. In + particular, it is incorrect to use a Tag Creator RegID associated + with the software being described by the tag, the enterprise that is + using the software, or any other entity except that of the party that + built the tool that is generating the SWID tag. This reflects the + 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 A Software Identifier generated from an ISO 2009 SWID tag is 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: - NUMBER::TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length of - TAG_CREATOR_REGID in bytes. The rest of the Software Identifier MUST - be the concatenation of the Tag Creator RegID and the Unique ID from - the tag, without any connecting character or whitespace. + NUMBER "::" TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length + of TAG_CREATOR_REGID in bytes. The rest of the Software Identifier + MUST be the concatenation of the Tag Creator RegID and the Unique ID + 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 Collectors and Posture Validators that implement the Software Inventory Message and Attributes for PA-TNC protocol. This section primarily notes potential issues for implementers to consider, although it does contain a handful of normative requirements to - address certain security issues. Implementers need to make the final - decision as to how their implementations address the given issues. - The issues identified below focus on capabilities specific to this - document. Implementers are advised to consult other relevant NEA - specifications for security issues that are applicable to such - 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. + address certain security issues. The issues identified below focus + on capabilities specific to this document. Implementers are advised + to consult other relevant NEA specifications, particularly [RFC5209] + (the NEA Architecture) and [RFC5792] (PA-TNC), for security issues + that are applicable to such components in general. -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 - Inventory Evidence Collection as an indicator of the endpoints - software load and changes thereon is only as accurate as the tools - that populate and manage the software inventory evidence records in - this collection. Some tools might not be designed to update records - in the Software Inventory Evidence Collection in real time resulting - in a collection that is out-of-step with actual system state. - Moreover, tools might inaccurately characterize software, or fail to - properly record its removal. Finally, it is likely that there will - be software on the endpoint that is not tracked by any source and - thus is not reflected in the Software Inventory Evidence Collection. - Users of collected software inventory evidence records need to - understand that the information provided by the Software Inventory - Message and Attributes for PA-TNC capability cannot be treated as - completely accurate. Nonetheless, having endpoints report this - information can still provide useful insights into the state of the - endpoint's software load, and can alert administrators and policy - tools of situations that require remediation. + The degree to which an endpoint's Software Inventory Evidence + Collection accurately reflects the endpoint's actual software load + and any changes made to this software load is dependent on the + accuracy of the tools used to populate and manage the software + inventory evidence records in this collection. Some tools might not + be designed to update records in the Software Inventory Evidence + Collection in real time, resulting in a collection that is out-of- + sync with actual system state. Moreover, tools might inaccurately + characterize software, or fail to properly record its removal. + Finally, it is likely that there will be software on the endpoint + that is not tracked by any source and thus is not reflected in the + Software Inventory Evidence Collection. Users of collected software + inventory evidence records need to understand that the information + provided by the Software Inventory Message and Attributes for PA-TNC + capability cannot be treated as completely accurate. Nonetheless, + having endpoints report this information can still provide useful + insights into the state of the endpoint's software load, and can + 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 sensitive, although there can be exceptions to this generalization as noted in the section on Privacy Considerations. In general, an endpoint's Software Inventory Evidence Collection can be browsed and individual records read by any party with access to the endpoint. This is generally not considered to be problematic, as those with access to the endpoint can usually learn of everything disclosed by that endpoint's records simply by inspecting other parts of the endpoint. @@ -3696,24 +3743,24 @@ attacker an indication of how quickly an organization distributes patches and updates, helping the attacker determine how long an attack window might remain open. Any consolidated software inventory is a potential risk, because such an inventory can provide an adversary an insight into the enterprise's configuration and management process. It is recommended that a centralized software inventory record collection be protected against unauthorized access. Mechanisms to accomplish this can 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. -6.3. Integrity of Endpoint Records +7.3. Integrity of Endpoint Records SW-PCs maintain records of detected changes to the endpoint's Software Inventory Evidence Collection. These records are used to 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 endpoint's Software Inventory Evidence Collection without needing to 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 important. If an attacker modifies the SW-PC's record of changes to the endpoint's Software Inventory Evidence Collection, this might @@ -3730,70 +3777,70 @@ able to modify or delete records of an established subscription by a 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 correctly fulfilled unless it received additional information that indicated a discrepancy. For example, the SW-PV might collect a full inventory and realize from this that certain events had not been correctly reported in accordance with an established subscription. For this reason, the SW-PC MUST protect the integrity of subscription records. -6.4. SW-PC Access Permissions +7.4. SW-PC Access Permissions A SW-PC requires sufficient permissions to collect Software Inventory Evidence Records from all of its supported sources, as well as sufficient permissions to interact with the endpoint's Posture Broker Client. With regard to the former, this might require permissions to read the contents of directories throughout the file system. Depending on the operating environment and other activities undertaken by a SW-PC (or software that incorporates a SW-PC as one of its capabilities) additional permissions might be required by the SW-PC software. The SW-PC SHOULD NOT be granted permissions beyond 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 tightly controlled. For example, consider a source that gathers .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 Inventory Evidence Record. As a result, it is important that the contents of source information not be automatically trusted. In particular, tools that read source information and the Software Inventory Evidence Records derived therefrom, including SW-PCs, need to be careful to sanitize input to prevent buffer overflow attacks, encoding attacks, and other weaknesses that might be exploited by an 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 Inventory Message and Attributes for PA-TNC protocol is subject to 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 to, attribute theft, message fabrication, attribute modification, attribute replay, attribute insertion, and denial of service. Implementers are advised to consult the PA-TNC specification to 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 launch attacks and maintain footholds on this endpoint. For this reason, the NEA Server needs to ensure adequate safeguards are in place to prevent exposure of collected inventory records. For similar reasons, it is advisable that an endpoint only send records to a NEA Server that is authorized to receive this information and 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 specifications. This section describes these relationships. This specification is expected to participate in a standard NEA architecture. As such, it is expected to be used in conjunction with the other protocols used in a NEA exchange. In particular, SW Attributes are conveyed over PB-TNC [RFC5793], which is in turn conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP [RFC7171]). These protocols have an especially important role, as @@ -3807,40 +3854,52 @@ installed applications and the versions thereof. As such, there is some conceptual overlap between those attributes and the intent of this specification. However, PA-TNC was designed to respond to very specific queries about specific classes of products, while the Software Inventory Message and Attributes for PA-TNC specification is able to convey a broader query, resulting in a more comprehensive set of evidence regarding an endpoint's installed software. As such, this specification provides important capabilities not present in the PA-TNC specification. -9. IANA Considerations +10. IANA Considerations This section extends multiple existing IANA registries. Specifically, it extends the PA-TNC Attribute Types and PA-TNC Error Codes defined in the PA-TNC specification [RFC5792] and the PA- Subtypes registry defined in the PB-TNC specification [RFC5793] and extended in PA-TNC. This specification only adds values to these registries and does not alter how these registries work or are maintained. Consult the appropriate specifications for details on 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- 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 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 PA-TNC specification and is not reproduced here. +-----+---------+-------------------+-------------------------------+ | PEN | Integer | Name | Defining Specification | +-----+---------+-------------------+-------------------------------+ | 0 | 17 | SW Request | Software Inventory Message | | | | | and Attributes for PA-TNC | | | | | | | 0 | 18 | Software | Software Inventory Message | @@ -3862,26 +3921,26 @@ | 0 | 23 | Subscription | Software Inventory Message | | | | Status Response | and Attributes for PA-TNC | | | | | | | 0 | 24 | Subscription | Software Inventory Message | | | | Status Response | and Attributes for PA-TNC | | | | | | | 0 | 25 - 31 | Reserved for | Software Inventory Message | | | | future use | and Attributes for PA-TNC | +-----+---------+-------------------+-------------------------------+ -9.2. Registry for PA-TNC Error Codes +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 - Error Codes defined in the PA-TNC specification. Note that Table 10 - in Section 4.14 lists these codes but uses a hexadecimal value to + Error Codes defined in the PA-TNC specification. Note that Table 9 + in Section 5.16 lists these codes but uses a hexadecimal value to identify their associated integer. The integer values given in that table are identical to those provided here. +-----+---------+-----------------------------------+---------------+ | PEN | Integer | Name | Defining | | | | | Specification | +-----+---------+-----------------------------------+---------------+ | 0 | 32 | SW_ERROR | Software | | | | | Inventory | | | | | Message and | @@ -3912,34 +3971,21 @@ | | | | Attributes | | | | | for PA-TNC | | | | | | | 0 | 37-47 | Reserved for future use | Software | | | | | Inventory | | | | | Message and | | | | | Attributes | | | | | for PA-TNC | +-----+---------+-----------------------------------+---------------+ -9.3. Registry for PA Subtypes - - 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 +10.4. Registry for Software Data Models The name for this registry is "Software Data Model Types". Each entry in this registry should include a human readable name, an SMI Private Enterprise Number, a decimal integer value between 1 and 2^8-1 (inclusive), and a reference to the specification where the use of this data model is defined. This specification needs to provide both a description of the format used by the data model and the procedures by which Software Identifiers are derived from a record expressed using this data model. Note that a specification that just defines the data model structure and its use is generally not @@ -3961,22 +4007,23 @@ | 0 | 1 | ISO 2015 SWID Tags using | **CURRENT | | | | XML | SPECIFICATION** | | | | | | | 0 | 2 | ISO 2009 SWID Tags using | **CURRENT | | | | XML | SPECIFICATION** | | | | | | | 0 | 192-255 | Reserved for local | N/A | | | | enterprise use | | +-----+---------+----------------------------+----------------------+ -10. References -10.1. Normative References +11. References + +11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . @@ -4007,21 +4054,21 @@ [SWID09] The International Organization for Standardization/ International Electrotechnical Commission, "Information Technology - Software Asset Management - Part 2: Software Identification Tag, ISO/IEC 19770-2", November 2009. [SWID15] The International Organization for Standardization/ International Electrotechnical Commission, "Information Technology - Software Asset Management - Part 2: Software Identification Tag, ISO/IEC 19770-2", October 2015. -10.2. Informative References +11.2. Informative References [NIST-SWID] The National Institute of Standards and Technology and The MITRE Corporation, "Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", August 2013. [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, @@ -4030,20 +4077,25 @@ [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 10.17487/RFC6876, February 2013, . [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, . +11.3. URIs + + [1] https://www.iana.org/assignments/pb-tnc-parameters/pb-tnc- + parameters.xhtml#pb-tnc-parameters-2 + Authors' Addresses Charles Schmidt The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: cmschmidt@mitre.org @@ -4047,25 +4099,33 @@ Email: cmschmidt@mitre.org Daniel Haynes The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: dhaynes@mitre.org + Chris Coffin The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA 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 Department of Defense 9800 Savage Road Ft. Meade, Maryland USA Email: jmfitz2@nsa.gov