--- 1/draft-coffin-sacm-nea-swid-patnc-01.txt 2016-09-12 11:16:00.896401176 -0700 +++ 2/draft-coffin-sacm-nea-swid-patnc-02.txt 2016-09-12 11:16:01.084405931 -0700 @@ -1,210 +1,183 @@ SACM C. Coffin Internet-Draft D. Haynes Intended status: Standards Track C. Schmidt -Expires: December 10, 2016 The MITRE Corporation +Expires: March 16, 2017 The MITRE Corporation J. Fitzgerald-McKay Department of Defense - June 8, 2016 + September 12, 2016 - SWID Message and Attributes for PA-TNC - draft-coffin-sacm-nea-swid-patnc-01 + Software Message and Attributes for PA-TNC + draft-coffin-sacm-nea-swid-patnc-02 Abstract - This document specifies the SWID 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 - software inventory information to a NEA server (as described in - [RFC5209]) using SWID tags [SWID]. + This document specifies the Software 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 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 December 10, 2016. + This Internet-Draft will expire on March 16, 2017. Copyright Notice Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope and Audience . . . . . . . . . . . . . . . . . . . 4 - 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 - 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1. Role of SWID Message and Attributes for PA-TNC . . . . . 8 - 2.2. Supported Use Cases . . . . . . . . . . . . . . . . . . . 9 - 2.2.1. Use Software Inventory as a Factor in Determining - Endpoint Access . . . . . . . . . . . . . . . . . . . 9 - 2.2.2. Maintain a Central Repository Reflecting an - Endpoint's Software Inventory . . . . . . . . . . . . 9 - 2.2.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10 - 2.3. Non-supported Use Cases . . . . . . . . . . . . . . . . . 10 - 2.4. Specification Requirements . . . . . . . . . . . . . . . 11 - 2.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 13 - 2.6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 13 - 2.7. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 13 - 2.8. SWID Message and Attributes for PA-TNC Diagram - Conventions . . . . . . . . . . . . . . . . . . . . . . . 14 - 3. SWID Message and Attributes for PA-TNC System Requirements . 14 - 3.1. SWID Tags as Inventory Evidence . . . . . . . . . . . . . 15 - 3.2. Basic SWID Tag Inventory Exchange . . . . . . . . . . . . 15 - 3.3. SWID Tag Identifiers . . . . . . . . . . . . . . . . . . 16 - 3.3.1. Tag Identifier Data . . . . . . . . . . . . . . . . . 17 - 3.3.2. Tag Identifier Instances . . . . . . . . . . . . . . 18 - 3.3.3. Comparing Tag Identifiers and Tag Identifier - Instances . . . . . . . . . . . . . . . . . . . . . . 19 - 3.3.3.1. Matching Tag Identifiers Indicate the Same - Software Product . . . . . . . . . . . . . . . . 20 - 3.3.3.2. Matching Tag Identifiers DO NOT Necessarily - Indicate Identical Tag Files . . . . . . . . . . 20 - 3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate - Identical Tag Files . . . . . . . . . . . . . . . 21 - 3.3.3.4. Differing Tag Identifiers DO NOT Necessarily - Indicate Different Software Products . . . . . . 21 - 3.3.4. Using Tag Identifiers in SWID Attributes . . . . . . 22 - 3.4. Targeted Requests . . . . . . . . . . . . . . . . . . . . 22 - 3.5. Monitoring Changes in an Endpoint's SWID Tag Collection . 23 - 3.6. Reporting Change Events . . . . . . . . . . . . . . . . . 25 - 3.6.1. Change Event Records . . . . . . . . . . . . . . . . 25 - 3.6.2. Updating Inventory Knowledge Based on Events . . . . 27 - 3.6.3. Using Event Records in SWID Attributes . . . . . . . 28 - 3.6.4. Partial and Complete Lists of Event Records in SWID - Attributes . . . . . . . . . . . . . . . . . . . . . 28 - 3.6.5. Synchronizing Event Identifiers and Epochs . . . . . 30 - 3.7. Supporting Multiple Instances of a Single Tag . . . . . . 32 - 3.7.1. Inventory Reporting in the Presence of Multiply- - Instantiated Tags . . . . . . . . . . . . . . . . . . 32 - 3.7.2. Event Reporting in the Presence of Multiply - Instantiated Tags . . . . . . . . . . . . . . . . . . 32 - 3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 32 - 3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 33 - 3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 33 - 3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 34 - 3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 35 - 3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 35 - 3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 37 - 3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 37 - 3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 38 - 3.8.5.4. No Subscription Consolidation . . . . . . . . . . 39 - 3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 39 - 3.9. Multiple Sources of SWID Tags . . . . . . . . . . . . . . 40 - 3.10. Error Handling . . . . . . . . . . . . . . . . . . . . . 41 - 4. SWID Message and Attributes for PA-TNC Protocol . . . . . . . 43 - 4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 43 - 4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 44 - 4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 44 - 4.4. SWID Attribute Overview . . . . . . . . . . . . . . . . . 45 - 4.5. SWID Attribute Exchanges . . . . . . . . . . . . . . . . 47 - 4.6. SWID Message and Attributes for PA-TNC Attribute - Enumeration . . . . . . . . . . . . . . . . . . . . . . . 49 - 4.7. Normalization of Text Encoding . . . . . . . . . . . . . 50 - 4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 51 - 4.9. SWID Request . . . . . . . . . . . . . . . . . . . . . . 52 - 4.10. SWID Tag Identifier Inventory . . . . . . . . . . . . . . 56 - 4.11. SWID Tag Identifier Events . . . . . . . . . . . . . . . 59 - 4.12. SWID Tag Inventory . . . . . . . . . . . . . . . . . . . 64 - 4.13. SWID Tag Events . . . . . . . . . . . . . . . . . . . . . 66 - 4.14. Subscription Status Request . . . . . . . . . . . . . . . 70 - 4.15. Subscription Status Response . . . . . . . . . . . . . . 70 - 4.16. PA-TNC Error as Used by SWID Message and Attributes for - PA-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 72 - 4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR - and SWID_SUBSCRIPTION_ID_REUSE_ERROR - Information . . . . . . . . . . . . . . . . . . . . 74 - 4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information . . . . . 75 - 4.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information . . 77 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 78 - 5.1. Evidentiary Value of SWID Tags . . . . . . . . . . . . . 79 - 5.2. Integrity of the SWID Tag Collection . . . . . . . . . . 79 - 5.3. Sensitivity of Collected Tags . . . . . . . . . . . . . . 80 - 5.4. Integrity of Endpoint Records . . . . . . . . . . . . . . 81 - 5.5. SWID-PC Access Permissions . . . . . . . . . . . . . . . 82 - 5.6. Sanitization of Tag Fields . . . . . . . . . . . . . . . 82 - 5.7. Tag Library Poisoning . . . . . . . . . . . . . . . . . . 83 - 5.8. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 83 - 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 83 - 7. Relationship to Other Specifications . . . . . . . . . . . . 84 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 - 8.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 85 - 8.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 85 - 8.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 86 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 87 - 9.2. Informative References . . . . . . . . . . . . . . . . . 87 - Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 88 - A.1. A Simple SWID Tag . . . . . . . . . . . . . . . . . . . . 88 - A.2. SWID Request Attributes . . . . . . . . . . . . . . . . . 90 - A.2.1. Simple Request . . . . . . . . . . . . . . . . . . . 90 - A.2.2. Subscription Request for Events . . . . . . . . . . . 91 - A.2.3. Targeted Request . . . . . . . . . . . . . . . . . . 91 - A.3. SWID Response Attributes . . . . . . . . . . . . . . . . 93 - A.3.1. SWID Tag Identifier Events Attribute . . . . . . . . 93 - A.3.2. SWID Tag Inventory Attribute . . . . . . . . . . . . 95 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 + 2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 7 + 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 . . . . . . . . . . . . 8 + 2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 9 + 2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 9 + 2.3. Specification Requirements . . . . . . . . . . . . . . . 10 + 2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 11 + 2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 + 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 12 + 2.7. Software Message and Attributes for PA-TNC Diagram + Conventions . . . . . . . . . . . . . . . . . . . . . . . 12 + 3. Software Message and Attributes for PA-TNC System + Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.1. Basic Inventory Exchange . . . . . . . . . . . . . . . . 13 + 3.2. Software Identifiers . . . . . . . . . . . . . . . . . . 14 + 3.2.1. Record Identifiers . . . . . . . . . . . . . . . . . 15 + 3.2.2. Using Software and Record Identifiers in SW + Attributes . . . . . . . . . . . . . . . . . . . . . 16 + 3.3. Targeted Requests . . . . . . . . . . . . . . . . . . . . 16 + 3.4. Monitoring Changes in an Endpoint's Software Inventory + Evidence Collection . . . . . . . . . . . . . . . . . . . 17 + 3.5. Reporting Change Events . . . . . . . . . . . . . . . . . 19 + 3.5.1. Change Event Records . . . . . . . . . . . . . . . . 20 + 3.5.2. Updating Inventory Knowledge Based on Events . . . . 21 + 3.5.3. Using Event Records in SW Attributes . . . . . . . . 22 + 3.5.4. Partial and Complete Lists of Event Records in SW + Attributes . . . . . . . . . . . . . . . . . . . . . 22 + 3.5.5. Synchronizing Event Identifiers and Epochs . . . . . 24 + 3.6. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 26 + 3.6.1. Establishing Subscriptions . . . . . . . . . . . . . 26 + 3.6.2. Managing Subscriptions . . . . . . . . . . . . . . . 27 + 3.6.3. Terminating Subscriptions . . . . . . . . . . . . . . 27 + 3.6.4. Subscription Status . . . . . . . . . . . . . . . . . 28 + 3.6.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 28 + 3.6.5.1. Subscriptions Reporting Inventories . . . . . . . 30 + 3.6.5.2. Subscriptions Reporting Events . . . . . . . . . 30 + 3.6.5.3. Targeted Subscriptions . . . . . . . . . . . . . 31 + 3.6.5.4. No Subscription Consolidation . . . . . . . . . . 32 + 3.6.5.5. Delayed Subscription Fulfillment . . . . . . . . 32 + 3.7. Multiple Sources of Software Inventory Evidence Records . 33 + 3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 34 + 4. Software Message and Attributes for PA-TNC Protocol . . . . . 36 + 4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 36 + 4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 36 + 4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 37 + 4.4. SW Attribute Overview . . . . . . . . . . . . . . . . . . 38 + 4.5. SW Attribute Exchanges . . . . . . . . . . . . . . . . . 40 + 4.6. Software Message and Attributes for PA-TNC Attribute + Enumeration . . . . . . . . . . . . . . . . . . . . . . . 42 + 4.7. Normalization of Text Encoding . . . . . . . . . . . . . 43 + 4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 44 + 4.9. SW Request . . . . . . . . . . . . . . . . . . . . . . . 45 + 4.10. Software Identifier Inventory . . . . . . . . . . . . . . 48 + 4.11. Software Identifier Events . . . . . . . . . . . . . . . 51 + 4.12. Software Inventory . . . . . . . . . . . . . . . . . . . 56 + 4.13. Software Events . . . . . . . . . . . . . . . . . . . . . 58 + 4.14. Subscription Status Request . . . . . . . . . . . . . . . 62 + 4.15. Subscription Status Response . . . . . . . . . . . . . . 62 + 4.16. PA-TNC Error as Used by Software Message and Attributes + for PA-TNC . . . . . . . . . . . . . . . . . . . . . . . 64 + 4.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and + SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 66 + 4.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 68 + 4.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 69 + 5. Supported Data Models . . . . . . . . . . . . . . . . . . . . 71 + 5.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 71 + 5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID + Tags using XML . . . . . . . . . . . . . . . . . . . 72 + 5.1.2. Guidance on Creation of Software Identifiers from ISO + 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 72 + 5.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 72 + 5.2.1. Guidance on Normalizing Source Data to ISO 2015 SWID + Tags using XML . . . . . . . . . . . . . . . . . . . 72 + 5.2.2. Guidance on Creation of Software Identifiers from ISO + 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 73 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 73 + 6.1. Evidentiary Value of Software Inventory Evidence Records 73 + 6.2. Sensitivity of Collected Records . . . . . . . . . . . . 74 + 6.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 75 + 6.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 75 + 6.5. Sanitization of Record Fields . . . . . . . . . . . . . . 76 + 6.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 76 + 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 76 + 8. Relationship to Other Specifications . . . . . . . . . . . . 77 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 + 9.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 77 + 9.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 78 + 9.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 79 + 9.4. Registry for Software Data Models . . . . . . . . . . . . 80 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 80 + 10.2. Informative References . . . . . . . . . . . . . . . . . 80 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 1. Introduction 1.1. Scope and Audience 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. Software Identification tags (SWID tags) [SWID] are - formatted records (usually XML documents) that identify a specific - software product. In this case, a "software product" can be a - distinct release of some piece of software, such as an operating - system, web browser, etc.; a patch or plug-in for such an - application; or a suite of such applications. The SWID specification - describes the format of these documents as well as rules governing - their use on computer systems. In particular, software that supports - SWID tags is expected to deposit an identifying tag on the endpoint - when the software is installed, modify or replace the tag as the - software is updated, and delete the tag when the software is - uninstalled. SWID tags can also be created and managed by third- - party tools or by local enterprises, allowing for tags to indicate - the presence of software even when that software's manufacturer has - not included SWID support. As such, by collecting a list of tags on - an endpoint, one receives evidence as to the software present on that - endpoint. The attributes defined in this document are used to - communicate software inventory evidence, in the form of SWID tags, - between the posture collector and posture validator using the PA-TNC - interface, as shown in Figure 1 below. + activities. Such information can come from multiple sources, + including tag files (such as ISO SWID tags [SWID], reports from third + party inventory tools, output from package managers, and other + sources. The attributes defined in this document are used to + communicate software inventory evidence, collected from a range of + possible sources, from the posture collector on the endpoint to the + posture validator on a NEA Server using the PA-TNC interface, as + shown in Figure 1 below. +-------------+ +--------------+ | Posture | <--------PA--------> | Posture | | Collectors | | Validators | | (1 .. N) | | (1 .. N) | +-------------+ +--------------+ | | | | | | +-------------+ +--------------+ @@ -217,1872 +190,1537 @@ +-------------+ +--------------+ | Posture | | Posture | | Transport | <--------PT--------> | Transport | | Client | | Server | | (1 .. N) | | (1 .. N) | +-------------+ +--------------+ NEA CLIENT NEA SERVER Figure 1: NEA Reference Model - The use of standard protocols and formats for conveying evidence - about endpoint state (in this case, endpoint inventory information) - has a number of benefits. The use of standard protocols and formats - facilitates interoperability between products developed by different - vendors. This allows consumers to select the product that has - features that best fit with the needs of their environment, with the - expectation that it will be able to interoperate with other parts of - their infrastructure (at least with regard to the aforementioned - protocols and formats). In addition, because a standard is expected - to be implemented by multiple independent parties, this means that - the standard protocols and formats receive more review than might be - expected in a proprietary solution. When the standard is managed by - a group that is responsive to feedback from such implementers, as is - the case with the IETF, this can lead to improvements in efficiency - and security of those protocols and formats. For these reasons, a - standard means of conveying endpoint inventory information such as - the one described in this document provides significant value to - users. Vendors benefit from utilizing SWIDs to serve as evidence of - software inventory because it reduces their need to develop remote - software inventory tools for the increasing variety of endpoint - platforms. If those endpoints support SWID Message and Attributes - for PA-TNC, vendors can use these protocols to gather software - inventory information remotely. - This specification defines a new set of PA-TNC attributes, carried - over PA-TNC messages, which are used to communicate requests for SWID - tags and events surrounding those tags, and for conveying that + over PA-TNC messages, which are used to communicate requests for + software information and software events, and for conveying that information back to a NEA Server. - Possession of a list of an endpoint's SWID tags 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, - SWID tags can be used to indicate compliance or non-compliance with - these requirements. SWID tags indicating software presence and the - patch level of that software can be compared to vulnerability or - threat alerts to determine an endpoint's exposure to attack. SWID - tags provide a great deal of information about unfamiliar software - products, including the software author and potentially including - where the software is installed on the endpoint and what files on the - endpoint are associated with this installed software. All of these - uses make an understanding of an endpoint's SWID tag collection - highly useful to NEA Servers and other enterprise security - applications. + Possession of a list of an endpoint's installed software is very + useful in understanding and maintaining the security state of an + enterprise. For example, if an enterprise policy requires the + presence of certain pieces of software and/or prohibits the presence + of other software, reported software inventory lists can be used to + indicate compliance or non-compliance with these requirements. + Software presence and the patch level of that software can be + compared to vulnerability or threat alerts to determine an endpoint's + exposure to attack. All of these uses make an understanding of an + endpoint's software collection highly useful to NEA Servers and other + enterprise security applications. Before reading this specification any further, the reader should 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 [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 | +---------------------------------------+-----------------------+ | Integrity Measurement Verifier (IMV) | Posture Validator | + | | | | Integrity Measurement Collector (IMC) | Posture Collector | + | | | | TNC Server (TNCS) | Posture Broker Server | + | | | | TNC Client (TNCC) | Posture Broker Client | +---------------------------------------+-----------------------+ Table 1: Equivalent components in TNC and NEA architectures 1.2. Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC 2119 [RFC2119]. This specification does not distinguish blocks of informative comments and normative requirements. Therefore, for the sake of clarity, note that lower case instances of must, should, etc. do not indicate normative requirements. 1.3. Definitions This section defines terms with special meaning within this document. - SWID-PC - A Posture Collector (PC) that conforms to this - specification. Note that such a posture collector might also support - other PA-TNC exchanges beyond SWID Message and Attributes for PA-TNC. + SW-PC - A Posture Collector (PC) that conforms to this specification. + Note that such a posture collector might also support other PA-TNC + exchanges beyond Software Message and Attributes for PA-TNC. - SWID-PV - A Posture Validator (PV) that conforms to this - specification. Note that such a posture verifier might also support - other PA-TNC exchanges beyond SWID Message and Attributes for PA-TNC. + SW-PV - A Posture Validator (PV) that conforms to this specification. + Note that such a posture verifier might also support other PA-TNC + exchanges beyond Software Message and Attributes for PA-TNC. - Endpoint's SWID Tag Collection - The set of SWID tags installed and - managed on an endpoint for software installed on that endpoint. An - endpoint's SWID tag collection might include SWID tags from multiple + 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 + and expressed using one of the Software Message and Attributes data + models, as described in the Software Data Model IANA table (see + Section 9.4. An endpoint's software inventory evidence collection + might include information created by or derived from multiple sources, including but not limited to SWID tag files deposited on the - file system during software installation, SWID tags generated to - report output from software discovery tools, and SWID tags + file system during software installation, information generated to + report output from software discovery tools, and information dynamically generated by a software or package management system on an endpoint. -2. Background -2.1. Role of SWID Message and Attributes for PA-TNC - - The International Organization for Standardization and the - International Electrotechnical Commission (ISO/IEC) published the - specification governing SWID tag construction and use in 2009. - [SWID] 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 list of SWID tags provides simple and immediate - evidence as to the presence of the given piece of software. - - SWID tags can also be useful even when a piece of software does not - supply the tags itself. Discovery processes are permitted to express - their findings using SWID tags, place these in the endpoint's SWID - tag collection, and maintain them like vendor-created SWID tags. - This means that an endpoint's SWID tag collection is not necessarily - limited to containing SWID tags for software whose authors have taken - the time to integrate SWID maintenance into their installation and - update processes. Similarly, software and package managers on an - endpoint (such as RPM and YUM) keep records of installed software, - and these records can be exported as a series of SWID tags, allowing - these managers to expose their information about software inventories - in a standards-based manner. Finally, for organizations that - centrally manage the distribution of software, in-house-developed - SWID tags can be added to any software product that does not natively - support SWID tags allowing the organization to accurately identify - any software it has distributed. + 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. - The NEA Server needs access to this inventory evidence if it is to - use this information to assess endpoint compliance with policy. The - SWID Message and Attributes for PA-TNC specification has been created - for this purpose. Specifically, the attributes defined in this - specification allow a Posture Validator to request evidence of an - endpoint's inventory in the form of SWID tags and allow the Posture - Collector to respond with the appropriate information. + Software Identifier - A string associated with a specific version of + a specific software product. Each supported Software Message and + Attributes for PA-TNC data model has its own rules for how a Software + Identifier (see Section 3.2) is derived from the representation of + the given software product using that data model, and different + sources for this information might populate relevant information + differently. As such, while each Software Identifier uniquely + identifies a specific software product, the same software product + might be associated with multiple Software Identifiers reflecting + differences between different information sources and supported data + models. - It is not necessary to understand the details of SWID tag - construction and maintenance to understand the behaviors described in - the SWID Message and Attributes for PA-TNC specification, and it is - beyond the scope of this specification to discuss the details of the - SWID standard. Implementers, however, will likely need to be - familiar with the SWID tag format and how to locate tags on an - endpoint. The SWID specification is available from ISO/IEC at - http://www.iso.org/iso/catalogue_detail.htm?csnumber=53670. The XML - schema for a SWID tag file is available from ISO: - http://standards.iso.org/iso/19770/-2/2009/schema.xsd. The most - current working and production versions of the XML schema for SWID - tags can be found in the directory listing at - http://standards.iso.org/iso/19770/-2/. The US National Institute of - Standards and Technology (NIST) also has published guidelines for - SWID tag creation, which provide further guidance for those - interested in the use and best practices surrounding SWID tags. - [NIST-SWID] +2. Background -2.2. Supported Use Cases +2.1. Supported Use Cases - This section describes the SWID Message and Attributes for PA-TNC use - cases supported by this specification. The primary use of exchanging - SWID tag 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 while taking - advantage of the simplicity and precision of SWID tags. Collected - SWID tags can support a range of security activities including + This section describes the Software Message and Attributes for PA-TNC + use cases supported by this specification. The primary use of + exchanging software inventory information over the PA-TNC interface + is to enable a challenger (e.g. NEA Server) to obtain inventory + evidence about some system in a way that conforms to NEA procedures + and expressed using a standard format. Collected software + information can support a range of security activities including determining whether an endpoint is permitted to connect to the enterprise, determining which endpoints contain software that requires patching, and similar activities. -2.2.1. Use Software Inventory as a Factor in Determining Endpoint +2.1.1. Use Software Inventory as a Factor in Determining Endpoint Access 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. - SWID Message and Attributes for PA-TNC facilitates policy decisions - that consider an endpoint's software inventory by providing the NEA - Server with a list of the SWID tags in the endpoint's SWID tag - collection. The tags in this collection serve as evidence as to the - endpoint's installed software. The SWID-PC can provide a complete or - partial list of tags to the SWID-PV as required to determine policy - compliance. The SWID-PV can then use this as evidence of compliance - or non-compliance with enterprise policy. + Software Message and Attributes for PA-TNC facilitates policy + decisions that consider an endpoint's software inventory by providing + the NEA Server with software inventory information from the endpoint. + The SW-PC can provide a complete or partial inventory to the SW-PV as + required to determine policy compliance. The SW-PV can then use this + as evidence of compliance or non-compliance with enterprise policy. -2.2.2. Maintain a Central Repository Reflecting an Endpoint's Software +2.1.2. Maintain a Central Repository Reflecting an Endpoint's Software Inventory Many tools can use information about an endpoint's software inventory to monitor and enforce the security of an enterprise. For example, a 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. - SWID Message and Attributes for PA-TNC supports this activity through - a number of mechanisms. As noted above, it allows a SWID-PC to - provide a complete list of the tags present in an endpoint's SWID tag - collection to the SWID-PV, which can then pass this information on to - a central repository such as a Configuration Management Database - (CMDB) or similar application. In addition, SWID-PCs are required to - be able to monitor for changes to an endpoint's SWID tag collection - in near real-time and push reports of changes to the SWID-PV as soon - as those changes are detected. Thus any central repository fed by a - SWID-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 SWID tag collection allows tools that + Software Message and Attributes for PA-TNC supports this activity + through a number of mechanisms. As noted above, it allows a SW-PC to + provide a complete list of software present in an endpoint's Software + Inventory Evidence Collection to the SW-PV, which can then pass this + information on to a central repository such as a Configuration + Management Database (CMDB) or similar application. In addition, SW- + PCs are required to be able to monitor for changes to an endpoint's + Software Inventory Evidence Collection in near real-time and push + reports of changes to the SW-PV as soon as those changes are + detected. Thus any central repository fed by a SW-PV receiving such + information can be updated soon after the change occurs. Keeping + such a central repository synchronized with the state of each + endpoint's Software Inventory Evidence Collection allows tools that use this information for their own security activities to make decisions in a consistent, efficient manner. -2.2.3. PA-TNC Use Cases +2.1.3. PA-TNC Use Cases - SWID 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. + Software Message and Attributes for PA-TNC are intended to operate + over the PA-TNC interface and, as such, are intended to meet the use + cases set out in the PA-TNC specification. -2.3. Non-supported Use Cases +2.2. Non-supported Use Cases - Some use cases not covered by this version of SWID Message and + Some use cases not covered by this version of Software Message and Attributes for PA-TNC include: - o This specification does not address how the endpoint's SWID tag - collection is populated. In particular, NEA components are not - expected to perform software discovery activities beyond compiling - the tags in an endpoint's SWID tag collection. This collection - might potentially come from multiple sources on the endpoint - (e.g., SWID tags 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, especially - software that does not install or manage its own SWID tag, such - procedures are outside the scope of this specification. + 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 This specification does not address converting inventory - information expressed in a proprietary format into the SWID tag - format or converting a SWID tag into a proprietary format. + information expressed in a proprietary format into the standard + format used in the messages described in this specification. Instead, it focuses exclusively on defining interfaces for the - transportation of SWID tags in the expectation that this is the - format around which reporting tools will converge. + transportation of software information in the expectation that + this is the format around which reporting tools will converge. o This specification provides no mechanisms for a posture validator - to request a specific list of tags based on arbitrary tag - properties from the endpoint. For example, requesting only tags - representing software from a particular vendor is not supported. - After the endpoint's SWID tag 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 SWID tags, - but this specification does not address using such queries to - constrain the initial collection of this information from the - endpoint. + 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 certain SWID - tag fields designed to facilitate local tests (i.e., on the - endpoint) of endpoint state. For example, the optional - package_footprint field of a 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 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. -2.4. Specification Requirements +2.3. Specification Requirements - Below are the requirements that the SWID Message and Attributes for - PA-TNC specification is required to meet in order to successfully + Below are the requirements that the Software Message and Attributes + for PA-TNC specification is required to meet in order to successfully play its role in the NEA architecture. 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 SWID Message and Attributes for PA-TNC ought to + frustration, the Software Message and Attributes for PA-TNC ought to minimize overhead delays and make PA-TNC communications as rapid and efficient as possible. 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 Loosely Coupled to the SWID Specification - - Because the SWID specification is managed by ISO/IEC, the IETF has no - direct influence over this specification or any revisions made to it. - For this reason, the SWID Message and Attributes for PA-TNC - specification ought to minimize its requirements and assumptions with - regard to the structure and content of the SWID tags. While some - level of visibility into tag contents is required for certain - features of this specification, minimization of such dependencies is - necessary to improve compatibility with future revisions of the SWID - specification. - o Scalable - SWID Message and Attributes for PA-TNC needs to be usable in + Software Message and Attributes for PA-TNC needs to be usable in enterprises that contain tens of thousands of endpoints or more. As such, it needs to allow a security tools to make decisions based on up-to-date information about an endpoint's software inventory without creating an excessive burden on the enterprise's network. o Interoperable This specification defines the protocol for how PCs and PVs can - exchange and use SWID tags to provide a NEA Server with information - about an endpoint's software inventory. Therefore a key goal for - this specification is ensuring that all SWID PCs and PVs, regardless - of the vendor who created them, are able to interoperate in their - performance of these duties. + 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. o Support precise and complete historical reporting - This specification is expected to outline 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 SWID tag collection in + This specification outlines capabilities that support real-time + understanding of the state of endpoint in a network in a way that can + be used by other tools. One means of facilitating such an outcome is + for a Configuration Management Database (CMDB) to be able to contain + information about all endpoints connected to the enterprise for all + points in time between the endpoint's first connection and the + present. In such a scenario, it is necessary that any PC be able to + report any changes to its software inventory evidence collection in near real-time while connected and, upon reconnection to the enterprise, be able to update the NEA Server (and through it the - CMDB) with regard to the state of its SWID tag collection throughout - the entire interval when it was not connected. + CMDB) with regard to the state of its software inventory evidence + collection throughout the entire interval when it was not connected. -2.5. Non-Requirements +2.4. Non-Requirements - There are certain requirements that the SWID Message and Attributes - for PA-TNC specification explicitly is not required to meet. This - list is not exhaustive. + There are certain requirements that the Software Message and + Attributes for PA-TNC specification explicitly is not required to + meet. This list is not exhaustive. o End to End Confidentiality - SWID tags have no inherent mechanism for confidentiality, nor is this - property automatically provided by PA-TNC interface use. + 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 7 for more + 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. -2.6. Assumptions +2.5. Assumptions - Here are the assumptions that SWID Message and Attributes for PA-TNC - makes about other components in the NEA architecture. + Here are the assumptions that Software 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 SWID - Attributes sent between the SWID PCs and the PVs. In the event that + 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. -2.7. Non-Assumptions +2.6. Non-Assumptions - The SWID Message and Attributes for PA-TNC specification explicitly - does not assume: + The Software Message and Attributes for PA-TNC specification + explicitly does not assume: - o Authenticity and Accuracy of SWID tags with Regard to Endpoint - Inventory + o Authenticity and Accuracy of the Software Inventory Evidence + Collection with Regard to Endpoint Inventory - This specification makes no assumption as to whether the SWID tags - that it reports are authentic tags (rather than maliciously - generated) or that these tags correctly reflect software state on the - endpoint. This specification does not attempt to detect when the + This specification makes no assumption as to whether the software + information that it reports correctly reflect the software state on + the endpoint. This specification does not attempt to detect when the endpoint is providing false information, either through malice or error, but instead focuses on correctly and reliably providing the - existing SWID tags to the NEA Server. Similarly, this specification - makes no assumption with regard to the completeness of the SWID tag - 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 tag in an endpoints SWID tag - collection. See Section 5 for more on this security consideration. + reported Software Inventory Evidence Collection to the NEA Server. + Similarly, this specification makes no assumption with regard to the + completeness of the Software Inventory Evidence Collection's coverage + of the total set of software installed on the endpoint. It is + possible, and even likely, that some installed software is not + represented by a record in an endpoints Software Inventory Evidence + Collection. See Section 6 for more on this security consideration. -2.8. SWID Message and Attributes for PA-TNC Diagram Conventions +2.7. Software Message and Attributes for PA-TNC Diagram Conventions - This specification defines the syntax of the SWID Message and + This specification defines the syntax of the Software Message and Attributes for PA-TNC using diagrams. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits in each diagram as they are shown from left to right for each 32-bit quantity traversing the diagram from top to bottom. Multi- octet fields representing numeric values MUST be sent in network (big endian) byte order. Descriptions of bit fields (e.g. flags) values refer to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit. As such, an octet with only bit 0 set would have a value of 0x80 (1000 0000), an octet with only bit 1 set would have a value of 0x40 (0100 0000), and an octet with only bit 7 set would have a value of 0x01 (0000 0001). -3. SWID Message and Attributes for PA-TNC System Requirements - - The SWID Message and Attributes for PA-TNC specification facilitates - the exchange of SWID tag inventories and event information. - Specifically, each application supporting SWID Message and Attributes - for PA-TNC includes a component known as the SWID-PC that receives - messages sent with the SWID Attributes component type. The SWID-PC - is also responsible for sending appropriate SWID Attributes back to - the SWID-PV in response. Similarly, the SWID-PV exists on a NEA - Server and is responsible for interpreting responses, forwarding - information to a CMDB if desired, and making policy decisions based - upon the received information. This section outlines what a SWID tag - inventory is, important features of tags used by this specification, - and the requirements on SWID-PCs and SWID-PVs in order to support the - stated use cases of this specification. - -3.1. SWID Tags as Inventory Evidence - - As noted in Section 2.1, SWID tags are intended to be open, easily - accessible evidence indicating the presence of a particular piece of - software on an endpoint. A SWID tag contains multiple fields - intended to uniquely identify a single software product. Ideally, a - SWID tag is managed by the software that installs, modifies, - replaces, amends (e.g. patches, updates), and/or uninstalls the - product. Discovery processes, software package managers, and other - tools can also create and manage tags as a way to represent software - that they discover or manage on the endpoint. +3. Software Message and Attributes for PA-TNC System Requirements - It is important to note that, even in the ideal cases where a product - manages its own SWID tag, a tag is inherently distinct from the - product that it identifies. For this reason, a SWID tag needs to be - treated as evidence of software presence, but cannot be treated as - proof of software presence. That noted, a standardized - representation of evidence indicative of an endpoint's software - inventory is a powerful tool in managing software within an - enterprise. + The Software Message and Attributes for PA-TNC specification + facilitates the exchange of software inventory and event information. + Specifically, each application supporting Software Message and + Attributes for PA-TNC includes a component known as the SW-PC that + receives messages sent with the SW Attributes component type. The + SW-PC is also responsible for sending appropriate SW Attributes back + to the SW-PV in response. This section outlines what software + inventories and events are and the requirements on SW-PCs and SW-PVs + in order to support the stated use cases of this specification. -3.2. Basic SWID Tag Inventory Exchange +3.1. Basic Inventory Exchange - In the most basic exchange supported by this specification, a SWID-PV - sends a request to the SWID-PC requesting a copy of all the SWID tags - in the endpoint's SWID tag collection. This simple exchange is shown - in Figure 2. + In the most basic exchange supported by this specification, a SW-PV + sends a request to the SW-PC requesting all inventory information in + the endpoint's Software Inventory Evidence Collection. This simple + exchange is shown in Figure 2. +-------------+ +--------------+ - | SWID-PC | | SWID-PV | Time + | SW-PC | | SW-PV | Time +-------------+ +--------------+ | | | | - |<-------------SWID Request---------------| | + |<--------------SW Request----------------| | | | | - |--------------SWID Response------------->| | + |---------------SW Response-------------->| | | | V - Figure 2: Basic SWID Message Exchange + Figure 2: Basic SW Message Exchange - Upon receiving such a SWID Request from the SWID-PV, the SWID-PC is - expected to locate the endpoint's SWID tags and then create copies of - all identified SWID tags and place them within its response + Upon receiving such a SW Request from the SW-PV, the SW-PC is + expected to collect all inventory information from the endpoint's + software evidence collection and place it within its response attribute. - SWID-PVs MUST discard without error any SWID Response attributes that - they receive for which they do not know the SWID Request parameters - that led to this SWID Response. This is due to the fact that the - SWID Request includes parameters that control the nature of the - response (as will be described in the following sections) and without - knowing those parameters the SWID Response cannot be reliably - interpreted. Most often receiving an unsolicited SWID Response - attribute happens when a NEA Server has multiple SWID-PVs; one SWID- - PV sends a SWID Request but, unless exclusive delivery is used by the - SWID-PC in sending the response, both SWID-PVs receive copies of the - resulting SWID Response. In this case, the SWID-PV that didn't send - the SWID Request would lack the context necessary to correctly - interpret the SWID Response it received and would simply discard it. - Note, however, that proprietary measures might allow a SWID-PV to - discover the SWID Request parameters for a SWID Response even if that - SWID-PV did not send the given SWID Request. As such, there is no - blanket requirement for a SWID-PV to discard all SWID Responses to - SWID Request the SWID-PV did not generate itself, only that SWID-PVs - are required to discard SWID Responses for which they cannot get the - necessary context to interpret. - - In the case that it is possible to do so, the SWID-PC MAY send its - SWID Response attribute to the SWID-PV that requested it using - exclusive delivery as described in section 4.5 of RFC 5793 (PB-TNC) - [RFC5793]. Exclusive delivery ensures that only the sender of the - SWID Request receives the resulting SWID Response. However, SWID - Message and Attributes for PA-TNC does not require support for - exclusive delivery of attributes. - -3.3. SWID Tag Identifiers - - SWID tags can contain a great deal of information about a software - product. In addition to identifying name, manufacturer, and version - of a software product, SWID tags might contain references to related - products, associated files and libraries, dependencies on other - software, and many other details. Moreover, SWID tags might be - customized on the endpoint to indicate when the SWID tag was last - checked for accuracy relative to the endpoint's installed software - and other information about how the software was received. (This - document refers to this customized information as - "installationspecific" tag information.) For this reason, actual - possession of a SWID tag can be useful for reasoning about details of - an endpoint's software inventory. However, a SWID tag file that - contains all optional fields might be tens of KB in size. This means - that an endpoint's full SWID inventory, encompassing hundreds of - applications, can be quite large. - - If bandwidth is a concern within an enterprise, there is a way to - identify a SWID tag without needing the complete tag. All tags - contain specific fields that can be used to distinguish a tag for a - particular piece of software from tags for different pieces of - software. The Tag Creator RegID is a string that uniquely identifies - the creator of this SWID tag (who might or might not be the same as - the entity who created the described software) while the Unique ID is - a string that uniquely identifies the described piece of software - according to that tag creator. These two pieces of information - together create a "tag identifier". - -3.3.1. Tag Identifier Data - - Some attributes defined in this specification contain fields to hold - tag identifiers rather than whole tags. When populating these - fields, both the Tag Creator RegID and the Unique ID values MUST be - copies of the values of fields within the SWID tag that is being - identified. The specific fields of a SWID tag that correspond to the - Tag Creator RegID and Unique ID values vary between the different - releases of the ISO SWID tag specification. It is important to note - that, in all other parts of this specification, the terms Tag Creator - RegID and Unique ID refer to the general field values defined above - rather to any term used in any specific release of the ISO SWID tag - specification. - - To identify the SWID tag field corresponding to the Tag Creator - RegID, identify the field containing the regid value of the entity - that created the given SWID tag. Note that this might not be the - same entity that created the software. The Tag Creator RegID MUST be - the regid, rather than any prose name that might be associated with - the tag creator. The specific structure of a regid is defined in the - ISO/IEC SWID specification. - - To identify the SWID tag field corresponding to the Unique ID, find - the field that contains a string that uniquely identifies a specific - product, version, edition, revision, etc. of a piece of software. - Note that this is a single field within the SWID tag, rather than a - concatenation of multiple fields. In particular, SWID tags often - contain designated fields for just the product name, product version, - product edition, etc., but these fields are not used to populate the - Unique ID. Instead, look for a single field that is designed to - uniquely identify a specific software product, version, etc. (and - thus uniquely identifies a specific tag, at least according to the - tag's creator). - - Consult the ISO/IEC specification for the specific fields that - correspond to the requirements of the Tag Creator RegID and Unique - ID, as defined above. For example, in the 2009 version of the ISO/ - IEC SWID specification [SWID], the Tag Creator RegID corresponds to - the value of the software_identification_tag/software_id/ - tag_creator_regid field in a SWID tag. The Unique ID corresponds to - the value of the software_identification_tag/software_id/unique_id - field in a SWID tag. In subsequent releases of the ISO/IEC SWID - specification, different fields might be used to convey the same - information. - -3.3.2. Tag Identifier Instances - - A tag identifier (i.e., the combination of the Tag Creator RegID and - the Unique ID fields) uniquely identifies a particular SWID tag, - which corresponds to a single software product. Assuming that this - product manages its own SWID tag (i.e., creates the tag on - installation and deletes the tag when the product is uninstalled) - then every system with an instance of this software product installed - would also have a copy of this same SWID tag file with the same tag - identifier field values. (Presence of SWID tags managed by other - tools, such as discovery tools, would also depend on the presence of - those tools on the device.) In fact, if multiple instances of the - same software product are installed on a single device (i.e., it has - been installed twice in different locations) that device would have - two instances of the same SWID tag, one for each installation. Both - instances of the SWID tag would have the same tag identifier field - values. This is true even though the tags themselves might differ - with regard to their installation-specific tag fields. In many cases - it is important to distinguish between instances of a particular tag - on a particular endpoint. For example, if one is alerted to the - deletion of a particular SWID tag and there are multiple instances of - that SWID tag on the endpoint, one will likely wish to know which - instance was deleted. - - Individual instances of SWID tags are distinguished by providing an - "Instance ID" value along with the tag identifier. An Instance ID is - a string that is uniquely associated with a particular instance of a - SWID tag on a particular endpoint. The exact nature of the Instance - ID depends on the source of the SWID tag. If the SWID tag is - represented as a file on disk, the Instance ID might be the full path - of the SWID tag file, including the name of the SWID tag file itself. - (Note that the SWID tag filename MUST be included in the tag file - path because it is possible for two SWID tags, each for different - instances of the same software product, to co-exist in the same - directory under different file names.) In the case that the SWID tag - is dynamically generated upon request by some source, such as an RPM - or YUM package manager, the generation process MUST create an - Instance ID to distinguish instances of a particular tag. Inclusion - of this Instance ID ensures each tag is uniquely identified on a - given endpoint. - - To the extent that it is possible, the generation of Instance IDs - SHOULD be repeatable for a single installation of a single SWID tag. - - In the case where a product is installed once, and then SWID tags are - generated upon request, each time the SWID tag is generated the tag - identifier instance SHOULD all have the same Instance ID value. For - example, if a package manager generates a SWID tag in response to a - request based on some record it possesses, and then later generates - the SWID tag again based on the same record of package installation, - then the same Instance ID value SHOULD be created both times. This - is necessary to allow remote parties to understand whether a reported - SWID tag instance is for the same product installation they saw - reported earlier or if it represents a new installation of the same - product. Note, however, that some exceptional situations might - result in the changing of a product's Instance ID. For example, it - is not explicitly prohibited by the SWID specification for tags to - move after installation, and thus have their tag file path change. - If the file path was used as the tag's Instance ID, subsequent tag - identifier instances for that same product might appear to be - different. Implementers and users need to be aware of this - possibility. - - The combination of a tag identifier with an Instance ID is referred - to as a "tag identifier instance". A tag identifier instance - uniquely identifies a particular instance of a particular tag on a - given endpoint. Note that two endpoints might produce identical tag - identifier instances, but these do not mean that the tag files on the - two endpoints are identical - the tags in question indicate the same - software product on both endpoints (since the respective tag - identifiers are identical), but the tags might still differ in their - installation-specific fields. Therefore, it is important to remember - that tag identifier instances are only comparable in the scope of a - single endpoint; when comparing across different endpoints, only the - tag identifier fields (Tag Create RegID and Unique ID) can be - meaningfully compared - any Instance ID value will need to be - excluded from comparison. - -3.3.3. Comparing Tag Identifiers and Tag Identifier Instances + SW-PVs MUST discard without error any SW Response attributes that + they receive for which they do not know the SW Request parameters + that led to this SW Response. This is due to the fact that the SW + Request includes parameters that control the nature of the response + (as will be described in the following sections) and without knowing + those parameters the SW Response cannot be reliably interpreted. + Most often receiving an unsolicited SW Response attribute happens + when a NEA Server has multiple SW-PVs; one SW-PV sends a SW Request + but, unless exclusive delivery is used by the SW-PC in sending the + response, both SW-PVs receive copies of the resulting SW Response. + In this case, the SW-PV that didn't send the SW Request would lack + the context necessary to correctly interpret the SW Response it + received and would simply discard it. Note, however, that + proprietary measures might allow a SW-PV to discover the SW Request + parameters for a SW Response even if that SW-PV did not send the + given SW Request. As such, there is no blanket requirement for a SW- + PV to discard all SW Responses to SW Request the SW-PV did not + generate itself, only that SW-PVs are required to discard SW + Responses for which they cannot get the necessary context to + interpret. - Comparison of tag identifiers can be used to determine whether a - particular SWID tag is present in an endpoint's SWID tag collection. - A pair of SWID tag identifiers is said to "match" if their Tag - Creator RegID and Unique ID fields are identical. Similarly, a pair - of tag identifier instances is said to match if their Tag Creator - RegID, Unique ID, and Instance ID fields are identical. Fields in - SWID Message and Attributes for PA-TNC attributes that contain tag - identifiers or tag identifier instances MUST always be normalized to - Network Unicode, so comparison between values transported in - attributes can be a simple string comparison. When comparing tag - identifiers and tag identifier instances from attributes with the - corresponding values from other sources (such as when comparing them - to a full SWID tag file or similar record), the relevant fields from - the latter need to undergo normalization prior to comparison. See - Section 4.7 for more on normalization of the encoding for these - fields. Comparisons are case-sensitive. + In the case that it is possible to do so, the SW-PC SHOULD send its + SW Response attribute to the SW-PV that requested it using exclusive + delivery as described in section 4.5 of RFC 5793 (PB-TNC) [RFC5793]. + Exclusive delivery ensures that only the sender of the SW Request + receives the resulting SW Response. - Matching tag identifiers and tag identifier instances indicate very - specific things about the respective tags. The following sections - describe what one can and cannot deduce based on matching tag - identifiers. +3.2. Software Identifiers -3.3.3.1. Matching Tag Identifiers Indicate the Same Software Product + Software information records contain a large amount of descriptive + information about installed software products. However, in many + cases the complete level of detail in these records is not necessary. + For example, if one is simply tracking the installation or removal of + known software products, one only needs enough information to + recognize the software added or removed. To allow such uses to be + efficiently supported, Software Message and Attributes for PA-TNC + supports the use of Software Identifiers. - The Unique ID value of a tag identifier represents a value that the - given tag creator will only use to indicate a particular software - product (e.g., a particular release of a particular application). - The ISO SWID specification prohibits the tag creator from associating - a Unique ID value with multiple, different software products. At the - same time, the Tag Creator RegID element value uniquely identifies a - given tag creator. As such, even if two different tag creators were - to assign the same Unique ID value to two different software - products, the Tag Creator RegID values will be different, and - therefore the tag identifiers will be different. For these reasons, - the expectation is that if one sees two tags with the same tag - identifiers, these tags are both associated with the same software - product (assuming the tag's fields are correctly populated). + A Software Identifier uniquely identifies a specific version of a + specific software product. The Software Message and Attributes for + PA-TNC specification does not dictate the structure of a Software + Identifier (beyond stating that it is a string) or define how it is + created. Instead, each data model described in the Software Data + Model IANA table (Section 9.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. + Within the Software Message and Attributes for PA-TNC specification, + the Software Identifier is simply an opaque string. -3.3.3.2. Matching Tag Identifiers DO NOT Necessarily Indicate Identical - Tag Files + Software Identifiers allow SW Response messages to identify software + to a server at a fraction of the bandwidth that would be needed to + send the entire associated record. For some combinations of data + models and sources, the full record might never be necessary as the + identifier can be directly correlated to the contents of the full + record. This is possible with authoritative SWID tags, since these + tags always have the same contents and thus a Software Identifier + derived from these tags can be used as a lookup to a local copy of + the full tag. For other combinations of source and data model, a + server might not be able to determine the specific software product + and version associated with the identifier without requesting deliver + of the full record. In either case, however, a SW-PV can use + Software Identifiers to track the presence of specific software + products on an endpoint over time in a bandwidth-efficient manner. - Some optional fields in SWID tags can reflect installation-specific - information. As such, the SWID tags for a piece of software residing - on two different endpoints (or installed twice on a single endpoint) - will have the same tag identifier value (same tag creator with the - same Unique ID for the same software product) but might contain - different information in their installation-specific fields. For - this reason, one cannot assume that just because two endpoints - provide the same tag identifier value for their software inventories, - that the tags on those endpoints are identical in all their fields - (although one can deduce that the same software product was present - on both endpoints). + There are two important limitations of Software Identifiers to keep + in mind: - Informative note: Initial drafts of the revised ISO SWID - specification indicate that modification of SWID tags might no longer - be permitted by parties other than the original tag creator (usually - the vendor of the software identified by the tag). If this becomes - part of the revised SWID specification, then for SWID tags that - conform to this revised specification, this will mean that matching - tag identifiers do imply identical tag files. + The identifiers do not necessarily change when the associated + record changes. In some situations, a record in the endpoint's + Software Inventory Evidence Collection will change due to new + information becoming available or in order to correct prior errors + in that information. Such changes might or might not result in + changes to the Software Identifier, depending on the nature of the + changes and the rules governing how Software Identifiers are + derived from records of the appropriate data model. -3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate Identical Tag - Files + It is possible that a single software product is installed on a + single endpoint multiple times. If both of these installation + instances are reported by the same source using the same data + format, then this will result in identical Software Identifiers + for each installation instances. In other words, Software + Identifiers do not uniquely identify installation instances; they + just uniquely identify software products (which might have more + than one installation instance). Instead, to distinguish between + multiple instances of a single software product, one needs to make + use of Record Identifiers, described in the following section. - For a single endpoint, matching tag identifier instance values might - indicate identical tag files, at least within a narrow time window. - Tag identifier instance values are unique to a specific SWID tag - record on that particular endpoint at a particular point in time. - The Instance ID in the tag identifier instance information ought to - be unique relative to any other instances of the same SWID tag - currently also on that endpoint. However, tag identifier instances - are still not guaranteed to be unique to a single SWID tag file over - a long period of time. Consider a piece of software that is - installed (adding a SWID tag), uninstalled (removing the SWID tag), - and then reinstalled (adding that SWID tag back but with a different - installation-specific field values). It is possible that the two - SWID tag files, present at different points in time, might have - identical tag identifier instance values even though the tag files - themselves were different. +3.2.1. Record Identifiers - As noted above, SWID tag identifier instances are only comparable - within the context of a single endpoint. When SWID tag identifier - instances are collected from multiple endpoints and then compared, - the Instance ID MUST be ignored in any comparison of tag identifiers - from different endpoints. + A Record Identifier is a string generated by the SW-PC that is + uniquely associated with a specific record within the Endpoint's + Software Inventory Evidence Collection. The SW-PC MUST assign a + unique identifier to each record when it is added to the Endpoint's + Software Inventory Evidence Collection. The Record Identifier SHOULD + remain unchanged if that record is modified. The SWID-PC might wish + to assign Record Identifiers sequentially, but any scheme is + acceptable provided that no two records receive the same identifier. -3.3.3.4. Differing Tag Identifiers DO NOT Necessarily Indicate - Different Software Products + Servers can use Record Identifiers to distinguish between multiple + instances of a single software product installed on an endpoint. + Since each installation instance of a software product is associated + with a separate record, servers can use the record identifier to + distinguish between instances. For example, if an event is reported + (as described in Section 3.5), the record identifier will allow the + server to discern which instance of a software product is involved. - While a tag identifier uniquely identifies a software product (i.e., - that tag identifier cannot be associated with a different software - product), a single product might have more than one tag identifier. - This is because it is possible for more than one tag creator to - create a SWID tag for the same software product. Multiple tags for - the same software product but created by different tag creators will - have different Tag Creator RegID values and will also likely differ - in their Unique ID value. Thus, these two tags will have different - tag identifiers even though they were associated with the same - software product. In fact, in some circumstances, two parties might - create two different SWID tag records for a single instance of the - same software product. For example, when a product is installed, it - creates a SWID tag file on the file system, and a software discovery - tool also notes the installation of the product and generates its own - SWID tag record for the same installation. In this case, that single - installation is associated with two SWID tags with different SWID tag - identifiers. In short, identical tag identifiers always indicate the - same software product, but different tag identifiers do not - necessarily indicate different software products. +3.2.2. Using Software and Record Identifiers in SW Attributes -3.3.4. Using Tag Identifiers in SWID Attributes + A SW Attribute reporting an endpoint's Software Inventory Evidence + Collection can contain Software Identifiers instead of copies of + software inventory evidence records. The message exchange is + identical to the diagram shown in Figure 2, but the contents of the + SW Response are Software Identifiers instead of evidence records. + The SW Request attribute indicates whether the response is required + to use full records or Software Identifiers. Using Software + Identifiers can reduce the attribute size of the response by multiple + orders of magnitude when compared to sending the same inventory using + full records. A SW-PC responds to a SW Request attribute requesting + Software Identifiers the same way it responds to a request for full + software records, except that instead of copying each record entirely + into the attribute body of the response, it provides the specific + values that comprise a Software Identifier for each record. - A SWID attribute reporting an endpoint's SWID tag collection can - contain SWID tag identifier instances instead of copies of SWID tag - files. The message exchange is identical to the diagram shown in - Figure 2, but the contents of the SWID Response are SWID tag - identifier instances instead of tags. The SWID Request attribute - indicates whether the response is required to use full tags or tag - identifier instances. Using tag identifier instances can reduce the - attribute size of the response by multiple orders of magnitude when - compared to sending the same inventory using full tags. A SWID-PC - responds to a SWID Request attribute requesting SWID tag identifier - instances the same way it responds to a request for full SWID tags, - except that instead of copying each SWID tag entirely into the - attribute body of the response, it provides the specific values that - comprise a SWID tag identifier instance for each tag. + All SW Response attributes include Record Identifiers for each + reported record. This is true regardless of whether the record is + delivered in full or represented by a Software Identifier. -3.4. Targeted Requests +3.3. Targeted Requests - Sometimes a SWID-PV does not require information about every tag on - an endpoint but only needs to know about certain tags. For example, - an endpoint might be required to have a particular patch installed. - In determining compliance with this policy, the SWID-PV is only - interested in the specific SWID tag associated with this patch. - Instead of requesting a complete inventory just to see if the patch's - SWID tag is present, the SWID-PV can make a "targeted request" for - the tag in question. + Sometimes a SW-PV does not require information about every piece of + software on an endpoint but only needs to receive updates about + certain software instances. For example, enterprise endpoints might + be required to have certain software products installed and to keep + these updated. Instead of requesting a complete inventory just to + see if these products are present, the SW-PV can make a "targeted + request" for the software in question. Targeted requests follow the same message exchange described in - Figure 2. The SWID-PV targets its request by providing one or more - SWID tag identifiers in its SWID Request attribute. The SWID-PC MUST - then limit its response to contain only tags that match the indicated - tag identifier(s). This allows the network exchange to exclude - information that is not relevant to a given policy question, thus - reducing unnecessary bandwidth consumption. The SWID-PC's response - might consist of full tags or of tag identifier instances, depending - on the parameters of the SWID Request. - - Targeted requests cannot target specific SWID tag instances; the SWID - Request does not include fields for Instance IDs. As a result, when - responding to a targeted request, a SWID-PC MUST return applicable - results for every instance of the identified tags. + Figure 2. The SW-PV targets its request by providing one or more + Software Identifiers in its SW Request attribute. The SW-PC MUST + then limit its response to contain only records that match the + indicated Software Identifier(s). This allows the network exchange + to exclude information that is not relevant to a given policy + question, thus reducing unnecessary bandwidth consumption. The SW- + PC's response might consist of full records or of Software + Identifiers, depending on the parameters of the SW Request. - Note that targeted requests identify the SWID tags relevant to the - request only through SWID tag identifiers for those tags. This - specification does not support arbitrary, parameterized querying of - tags. For example, one cannot request all tags from a certain - software publisher, or all tags created by a particular tag creator. + Note that targeted requests identify the software relevant to the + request only through Software Identifiers. This specification does + not support arbitrary, parameterized querying of records. For + example, one cannot request all records from a certain software + publisher, or all records created by a particular record source. + Targeted requests only allow a requestor to request specific software + (as identified by their Software Identifiers) and receive a response + that is limited to the named software. - Targeted requests only allow a requestor to request specific tags (as - identified by their tag identifiers) and receive a response that is - limited to the named tags. There is also no assumption that a SWID- - PC will recognize "synonymous tags" - that is, tags by different tag - creators for the same software product. The SWID-PC returns only - tags that match the tag identifiers in the SWID Request, even if - there might be other SWID tags in the endpoint's SWID tag collection - for the same software product. + There is no assumption that a SW-PC will recognize "synonymous + records" - that is, records from different sources for the same + software. Recall that different sources and data models may use + different Software Identifier strings for the same software product. + The SW-PC returns only records that match the Software Identifiers in + the SW Request, even if there might be other records in the + endpoint's Software Inventory Evidence Collection for the same + software product. This is necessary because SW-PCs might not have + the ability to determine that two Software Identifiers refer to the + same product. - SWID-PCs MUST accept targeted requests and process them correctly as - described above. SWID-PVs MUST be capable of making targeted - requests and processing the responses thereto. + Targeted requests do not include Record Identifiers. The response to + a targeted request MUST include all records associated with the named + Software Identifiers, including the case where there are multiple + records associated with a single Software Identifier. -3.5. Monitoring Changes in an Endpoint's SWID Tag Collection + SW-PCs MUST accept targeted requests and process them correctly as + described above. SW-PVs MUST be capable of making targeted requests + and processing the responses thereto. - The SWID collection on an endpoint is not static. As software is - installed, uninstalled, patched, or updated, the SWID tag collection - is expected to change to reflect the new software state on the - endpoint. For tags managed by an application's installer, tag - changes usually occur at the time of installation or update. For - tags added by discovery tools, software and package managers, and - other sources, changes to the endpoint's SWID tag collection occur - when some process discovers the new or altered software product, - which typically lags behind the actual installation or update time. +3.4. Monitoring Changes in an Endpoint's Software Inventory Evidence + Collection - All SWID-PCs MUST be able to be able to detect changes to the SWID - tag repositories on their endpoint. Specifically, SWID-PCs MUST be - able to detect: + The software collection on an endpoint is not static. As software is + installed, uninstalled, patched, or updated, the Software Inventory + Evidence Collection is expected to change to reflect the new software + state on the endpoint. Different record sources might update the + evidence collection at different rates. For example, a package + manager might update its records in the Software Inventory Evidence + Collection immediately whenever it is used to add or remove a + software product. By contrast, sources that perform periodic + examination of the endpoint would likely only update their records in + the Software Inventory Evidence Collection after each examination. - o The creation of tags + All SW-PCs MUST be able to be able to detect changes to the Software + Inventory Evidence Collection. Specifically, SW-PCs MUST be able to + detect: - o The deletion of tags + o The creation of records - o The alteration of tags + o The deletion of records - An "alteration" is anything that modifies the contents of a SWID tag - file (or would modify it, if the tag file is dynamically generated on + o The alteration of records + An "alteration" is anything that modifies the contents of a record + (or would modify it, if the record is dynamically generated on demand) in any way, regardless of whether the change is functionally - meaningful. Changes MUST be monitored for all utilized sources of - SWID tags. This includes, but is not limited to, monitoring sources - that dynamically generate SWID tags. + meaningful. - SWID-PCs MUST detect such changes to the endpoint's SWID tag - collection in close to real-time (i.e., within seconds) when the - Posture Collector is operating. In addition, in the case where there - is a period during which the SWID-PC is not operating, the SWID-PC - MUST be able to determine the net change to the endpoint's SWID tag - collection over the period it was not operational. Specifically, the - "net change" represents the difference between the state of the - endpoint's SWID tag collection when the SWID-PC was last operational - and monitoring its state, and the state of the endpoint's SWID tag - collection when the SWID-PC resumed operation. Note that a net - change might not reflect the total number of change events over this - interval. For example, if a SWID tag file was altered three times - during a period when the SWID-PC was unable to monitor for changes, - the net change of this interval might only note that there was an - alteration to the file, but not how many individual alteration events - occurred. It is sufficient for a SWID-PC's determination of a net - change to note that there was a difference between the earlier and - current state rather than enumerating all the individual events that - allowed the current state to be reached. + SW-PCs MUST detect such changes to the endpoint's Software Inventory + Evidence Collection in close to real-time (i.e., within seconds) when + the Posture Collector is operating. In addition, in the case where + there is a period during which the SW-PC is not operating, the SW-PC + MUST be able to determine the net change to the endpoint's Software + Inventory Evidence Collection over the period it was not operational. + Specifically, the "net change" represents the difference between the + state of the endpoint's Software Inventory Evidence Collection when + the SW-PC was last operational and monitoring its state, and the + state of the endpoint's software inventory evidence collection when + the SW-PC resumed operation. Note that a net change might not + reflect the total number of change events over this interval. For + example, if a record was altered three times during a period when the + SW-PC was unable to monitor for changes, the net change of this + interval might only note that there was an alteration to the record, + but not how many individual alteration events occurred. It is + sufficient for a SW-PC's determination of a net change to note that + there was a difference between the earlier and current state rather + than enumerating all the individual events that allowed the current + state to be reached. - The SWID-PC MUST assign a time to each detected change in the - endpoint's SWID tag collection. These timestamps correspond to the - SWID-PC's best understanding as to when the detected change occurred. - These timestamps MUST be as accurate as possible. For changes to the - endpoint's SWID tag collection that occur while the SWID-PC is - operating, the SWID-PC ought to be able to assign a time to the event - that is accurate to within a few seconds. For changes to the - endpoint's SWID tag collection that occur while the SWID-PC is not - operational, upon becoming operational the SWID-PC needs to make a - best guess as to the time of the relevant events (possibly by looking - at timestamps on the files), but these values might be off. In the - case of dynamically generated SWID tags, the time of change is the - time at which the data from which the SWID tags are generate changes, - not the time at which a changed SWID tag is generated. For example, - if SWID tags are dynamically generated based on data in an RPM - database, the time of change would be when the RPM record was - changed. + The SW-PC MUST assign a time to each detected change in the + endpoint's Software Inventory Evidence Collection. These timestamps + correspond to the SW-PC's best understanding as to when the detected + change occurred. These timestamps MUST be as accurate as possible. + For changes to the endpoint's Software Inventory Evidence Collection + that occur while the SW-PC is operating, the SW-PC ought to be able + to assign a time to the event that is accurate to within a few + seconds. For changes to the endpoint's Software Inventory Evidence + Collection that occur while the SW-PC is not operational, upon + becoming operational the SW-PC needs to make a best guess as to the + time of the relevant events (possibly by looking at timestamps on + files), but these values might be off. In the case of dynamically + generated records, the time of change is the time at which the data + from which the records are generate changes, not the time at which a + changed record is generated. For example, if records are dynamically + generated based on data in an RPM database, the time of change would + be when the RPM record was changed. - With regard to deletions of SWID tags, the SWID-PC needs to detect - the deletion and MUST retain a copy of the full deleted tag so that - the tag itself can be provided to the SWID-PV upon request. This - copy of the SWID tag MUST be retained for a reasonable amount of - time. Vendors and administrators determine what "reasonable" means, - but a copy of the tag SHOULD be retained for as long as the event - recording the deletion of the tag remains in the SWID-PC's records. - This is recommended because, as long as the event is in the SWID-PC's - records, the SWID-PC might send an event attribute (described in - Section 3.6) that references this tag, and a copy of the tag is - needed if the SWID-PV wanted a full copy of the relevant tags. + With regard to deletions of records, the SW-PC needs to detect the + deletion and MUST retain a copy of the full deleted record along with + its Record Identifier so that the record itself can be provided to + the SW-PV upon request. This copy of the record MUST be retained for + a reasonable amount of time. Vendors and administrators determine + what "reasonable" means, but a copy of the record SHOULD be retained + for as long as the event recording the deletion of the record remains + in the SW-PC's event log (as described in Section 3.5). This is + recommended because, as long as the event is in the SW-PC's change + logs, the SW-PC might send an event attribute (described in + Section 3.5) that references this record, and a copy of the record is + needed if the SW-PV wanted a full copy of the relevant records. - With regard to alterations to a SWID tag file, SWID-PCs MUST detect - any alterations to the contents of a tag file. Alterations need to - be detected even if they have no functional impact on the tag file. - For example, the addition of whitespace between XML attributes does - not have any impact on the meaning of the SWID tag file, but still - needs to be detected as a tag file alteration by a SWID-PC. A good - guideline is that any alteration to a file that might change the - value of a hash taken on the file's contents needs to be detected by - the SWID-PC. A SWID-PC might be unable to distinguish modifications - to the content of a tag file from modifications to the metadata the - file system associates with the tag file. For example, a SWID-PC - might use the "last modification" timestamp as an indication of - alteration to a given tag file, but a file's last modification time - can change for reasons other than modifications to the file contents. - A SWID-PC is still considered compliant with this specification if it - also reports metadata change events that do not change the SWID tag - file itself as alterations to the SWID tag file. In other words, - while SWID-PC authors are encouraged to exclude modifications that do - not affect the bytes within the tag file when detecting alterations - to a SWID tag record, discriminating between modifications to file - contents and changes to file metadata can be difficult and time - consuming on some systems. As such, as long as the alterations - detected by a SWID-PC always cover all modifications to the contents - of tag files, the SWID-PC is considered compliant even if it also - registers alterations that do not modify the contents of a tag file - as well. When recording an alteration to a tag file, the SWID-PC is - only required to note that an alteration occurred. The SWID-PC is - not required to note or record how the tag file altered, nor is it - possible to include such details in SWID Attributes reporting the - change to a SWID-PV. + With regard to alterations to a record, SW-PCs MUST detect any + alterations to the contents of a record. Alterations need to be + detected even if they have no functional impact on the record. A + good guideline is that any alteration to a record that might change + the value of a hash taken on the record's contents needs to be + detected by the SW-PC. A SW-PC might be unable to distinguish + modifications to the content of a record from modifications to the + metadata the file system associates with the record. For example, a + SW-PC might use the "last modification" timestamp as an indication of + alteration to a given record, but a record's last modification time + can change for reasons other than modifications to the record + contents. A SW-PC is still considered compliant with this + specification if it also reports metadata change events that do not + change the record itself as alterations to the record. In other + words, while SW-PC authors are encouraged to exclude modifications + that do not affect the bytes within the record, discriminating + between modifications to file contents and changes to file metadata + can be difficult and time consuming on some systems. As such, as + long as the alterations detected by a SW-PC always cover all + modifications to the contents of record, the SW-PC is considered + compliant even if it also registers alterations that do not modify + the contents of a record as well. When recording an alteration to a + record, the SW-PC is only required to note that an alteration + occurred. The SW-PC is not required to note or record how the record + altered, nor is it possible to include such details in SW Attributes + reporting the change to a SW-PV. -3.6. Reporting Change Events +3.5. Reporting Change Events - As noted in the preceding section, SWID-PCs MUST be able to detect - changes to the SWID tag repositories (tag creation, tag removal, and - tag alteration) in near real-time while the SWID-PC is operational, - and MUST be able to account for any net change to the endpoint's SWID - tag collection that occurs when the SWID-PC is not operational. - However, to be of use to the enterprise, the NEA Server needs to be - able to receive these events and be able to understand how new - changes relate to earlier changes. In SWID Message and Attributes - for PA-TNC, this is facilitated by reporting change events. All - SWID-PCs MUST be capable of receiving requests for change events and - sending change event attributes. All SWID-PVs MUST be capable of - requesting and receiving change event attributes. + As noted in the preceding section, SW-PCs MUST be able to detect + changes to the endpoints software inventory evidence collection + (creation, deletion, and alteration) in near real-time while the SW- + PC is operational, and MUST be able to account for any net change to + the endpoint's Software Inventory Evidence Collection that occurs + when the SW-PC is not operational. However, to be of use to the + enterprise, the NEA Server needs to be able to receive these events + and be able to understand how new changes relate to earlier changes. + In Software Message and Attributes for PA-TNC, this is facilitated by + reporting change events. All SW-PCs MUST be capable of receiving + requests for change events and sending change event attributes. All + SW-PVs MUST be capable of requesting and receiving change event + attributes. -3.6.1. Change Event Records +3.5.1. Change Event Records - A change event record consists of either a complete SWID tag or SWID - tag identifier instance along with the following pieces of - information: + A change event record consists of either a complete record or + Software Identifier from the changed record along with the following + pieces of information: - o The nature of the change (i.e., tag creation, tag deletion, or tag - alteration) + o The nature of the change (i.e., creation, deletion, or lteration) o An Event Identifier (EID) value o An EID Epoch value - An EID is a 4-byte unsigned integer that the SWID-PC assigns + An EID is a 4-byte unsigned integer that the SW-PC assigns sequentially to each observed event (whether detected in real-time or - deduced by looking for net changes over a period of SWID-PC + deduced by looking for net changes over a period of SW-PC inactivity). All EIDs exist within the context of some "EID Epoch", which is also represented as a 4- byte unsigned integer. EID Epochs - are used to ensure synchronization between the SWID-PC and any SWID- - PVs with which it communicates. EID Epoch values SHOULD be generated + are used to ensure synchronization between the SW-PC and any SW-PVs + with which it communicates. EID Epoch values SHOULD be generated randomly and in such a way that it is unlikely that the same EID - Epoch is generated twice, even if the SWID-PC reverted to an earlier + Epoch is generated twice, even if the SW-PC reverted to an earlier state (e.g., resetting it to factory defaults). In the case where a - SWID-PC needs to reset its EID counter, either because it has - exhausted all available EID values or because the SWID-PC's event log - becomes corrupted, then a new EID Epoch MUST be selected. + SW-PC needs to reset its EID counter, either because it has exhausted + all available EID values or because the SW-PC's event log becomes + corrupted, then a new EID Epoch MUST be selected. Within an Epoch, EIDs MUST be assigned sequentially, so that if a particular event is assigned an EID of N, the next observed event is given an EID of N+1. In some cases, events might occur - simultaneously, or the SWID-PC might not otherwise be able to - determine an ordering for events. In these cases, the SWID-PC - creates an arbitrary ordering of the events and assigns EIDs - according to this ordering. Two change events MUST NOT ever be - assigned the same EID within the same EID Epoch. No meaningful - comparison can be made between EID values of different Epochs. + simultaneously, or the SW-PC might not otherwise be able to determine + an ordering for events. In these cases, the SW-PC creates an + arbitrary ordering of the events and assigns EIDs according to this + ordering. Two change events MUST NOT ever be assigned the same EID + within the same EID Epoch. No meaningful comparison can be made + between EID values of different Epochs. The EID value of 0 is reserved and MUST NOT be associated with any - event. Specifically, an EID of 0 in a SWID Request attribute - indicates that a SWID-PV wants an inventory response rather than an - event response, while an EID of 0 in a SWID Response is used to - indicate the initial state of the endpoint's SWID tag collection - prior to the observation of any events. Thus the very first recorded - event in a SWID-PC's records within an EID Epoch MUST be assigned a - value of 1 or greater. Note that EID and EID Epoch values are - assigned by the SWID-PC without regard to whether events are being - reported to one or more SWID-PVs. The SWID-PC records events and - assigns EIDs during its operation. Any and all SWID-PVs that request - event information from the SWID-PC will have those requests served - from the same records and thus will see the same EIDs and EID Epochs - for the same events. + event. Specifically, an EID of 0 in a SW Request attribute indicates + that a SW-PV wants an inventory response rather than an event + response, while an EID of 0 in a SW Response is used to indicate the + initial state of the endpoint's Software Inventory Evidence + Collection prior to the observation of any events. Thus the very + first recorded event in a SW-PC's records within an EID Epoch MUST be + assigned a value of 1 or greater. Note that EID and EID Epoch values + are assigned by the SW-PC without regard to whether events are being + reported to one or more SW-PVs. The SW-PC records events and assigns + EIDs during its operation. Any and all SW-PVs that request event + information from the SW-PC will have those requests served from the + same event records and thus will see the same EIDs and EID Epochs for + the same events. - The SWID-PC MUST ensure there is no coverage gap (i.e., change events - that are not recorded in the SWID-PC's records) in its records of - change events. This is necessary because a coverage gap might give a - SWID-PV a false impression of the endpoint's state. For example, if - a SWID-PV saw an event indicating that a particular SWID tag had been - installed, and saw no subsequent events indicating that tag had been - deleted, it might reasonably assume that this tag was still installed - (assuming the Epoch has not changed). If there is a coverage gap in - the SWID-PC's records, however, this assumption is false. For this - reason, the SWID-PC's event records MUST NOT contain gaps. In the - case where there are periods where it is possible that changes - occurred without the SWID-PC detecting or recording them, the SWID-PC - MUST either compute a net change and update its records - appropriately, or pick a new EID Epoch to indicate a discontinuity - with previous event records. + The SW-PC MUST ensure there is no coverage gap (i.e., change events + that are not recorded in the SW-PC's records) in its change event + records. This is necessary because a coverage gap might give a SW-PV + a false impression of the endpoint's state. For example, if a SW-PV + saw an event indicating that a particular record had been added to + the endpoint's software inventory evidence collection, and saw no + subsequent events indicating that record had been deleted, it might + reasonably assume that this record was still present and thus that + the indicated software was still installed (assuming the Epoch has + not changed). If there is a coverage gap in the SW-PC's event + records, however, this assumption is false. For this reason, the SW- + PC's event records MUST NOT contain gaps. In the case where there + are periods where it is possible that changes occurred without the + SW-PC detecting or recording them, the SW-PC MUST either compute a + net change and update its event records appropriately, or pick a new + EID Epoch to indicate a discontinuity with previous event records. Within a given Epoch, once a particular event has been assigned an EID, this association MUST NOT be changed. That is, within an Epoch, once an EID is assigned to an event, that EID cannot be reassigned to a different event, and the event cannot be assigned a different EID. - When the SWID-PC's Epoch changes, all of these associations between + When the SW-PC's Epoch changes, all of these associations between EIDs and events are cancelled, and EID values once again become free for assignment. -3.6.2. Updating Inventory Knowledge Based on Events +3.5.2. Updating Inventory Knowledge Based on Events Modern endpoints can have hundreds of software products installed, most of which are unlikely to change from one day to the next. As such, instead of exchanging a complete list of an endpoint's inventory on a regular basis, one might wish to only identify changes since some earlier known state of this inventory. This is readily facilitated by the use of EIDs to place change events in a context relative to earlier state. - Every inventory sent by a SWID-PC to a SWID-PV (as described in - Section 3.2 through Section 3.4) includes the EID Epoch and EID of + Every inventory sent by a SW-PC to a SW-PV (as described in + Section 3.1 through Section 3.3) includes the EID Epoch and EID of the last event recorded prior to that inventory being compiled. This - allows the SWID-PV to place all subsequently received event records - in context relative to this inventory (since the EIDs represent a - total ordering of all changes to the endpoint's SWID tag collection). - Specifically, a SWID-PV (or, more likely, a database that collects - and records its findings) can record an endpoint's full inventory and - also the EID and Epoch of the most recent event reflected in that - state. From that point on, if change events are observed, the - attribute describing these events indicates the nature of the change, - the affected SWID tags, and the order in which these events occurred - (as indicated by the sequential EIDs). Using this information, any - remote record of the endpoint's SWID tag collection can be updated - appropriately. + allows the SW-PV to place all subsequently received event records in + context relative to this inventory (since the EIDs represent a total + ordering of all changes to the endpoint's software inventory evidence + collection). Specifically, a SW-PV (or, more likely, a database that + collects and records its findings) can record an endpoint's full + inventory and also the EID and Epoch of the most recent event + reflected in that state. From that point on, if change events are + observed, the attribute describing these events indicates the nature + of the change, the affected records, and the order in which these + events occurred (as indicated by the sequential EIDs). Using this + information, any remote record of the endpoint's Software Inventory + Evidence Collection can be updated appropriately. -3.6.3. Using Event Records in SWID Attributes +3.5.3. Using Event Records in SW Attributes - A SWID-PV MUST be able to request a list of event records instead of - an inventory. The message flow in such an exchange looks the same as + A SW-PV MUST be able to request a list of event records instead of an + inventory. The message flow in such an exchange looks the same as the basic flow shown in Figure 2. The only difference is that, in - the SWID Request attribute, the SWID-PV provides an EID other than 0. - (A value of 0 in these fields represents a request for an inventory.) - When the SWID-PC receives such a request, instead of identifying SWID - tags in the endpoint's SWID tag collection, it consults its record of - detected changes. The SWID-PC MUST add an event record to the SWID - Response attribute for each recorded change event with an EID greater - than or equal to the EID in the SWID Request attribute (although - targeting of requests, as described in the next paragraph, may limit - this list). A list of event records MUST only contain events with - EIDs that all come from the current Epoch. + the SW Request attribute, the SW-PV provides an EID other than 0. (A + value of 0 in these fields represents a request for an inventory.) + When the SW-PC receives such a request, instead of identifying + records from the endpoint's Software Inventory Evidence Collection, + it consults its list of detected changes. The SW-PC MUST add an + event record to the SW Response attribute for each recorded change + event with an EID greater than or equal to the EID in the SW Request + attribute (although targeting of requests, as described in the next + paragraph, might limit this list). A list of event records MUST only + contain events with EIDs that all come from the current Epoch. - SWID-PVs can target requests for event records by including one or - more tag identifiers, as described in Section 3.4, in the SWID - Request that requests an event record list. A targeted request for - event records is used to indicate that only events affecting SWID - tags that match the provided SWID tag identifiers are to be returned. + SW-PVs can target requests for event records by including one or more + Software Identifiers, as described in Section 3.3, in the SW Request + that requests an event record list. A targeted request for event + records is used to indicate that only events affecting software that + match the provided Software Identifiers are to be returned. Specifically, in response to a targeted request for event records, - the SWID-PC MUST exclude any event records that are less than the + the SW-PC MUST exclude any event records that are less than the indicated EID (within the current EID Epoch) and exclude any event - records where the affected SWID tag does not match one of the - provided SWID tag identifiers. This might mean that the resulting + records where the affected software does not match one of the + provided Software Identifiers. This might mean that the resulting list of event records sent in the response attribute does not provide - a continuous sequence of EIDs. Both SWID-PCs and SWIC-PVs MUST - support targeted request for event records. + a continuous sequence of EIDs. Both SW-PCs and SWIC-PVs MUST support + targeted request for event records. -3.6.4. Partial and Complete Lists of Event Records in SWID Attributes +3.5.4. Partial and Complete Lists of Event Records in SW Attributes - Over time, a SWID-PC might record a large number of change events. - If a SWID-PV requests all change events covering a large period of - time, the resulting SWID Response attribute might be extremely large, - especially if the SWID-PV is requesting the use of full SWID tags - instead of the use of SWID Identifier instances (as described in - Section 3.3.4). In the case that the resulting attribute is too - large to send (either because it exceeds the 4GB attribute size limit - imposed by the PA-TNC specification, or because it exceeds some - smaller size limit imposed on the SWID-PC) the SWID-PC MAY send a - partial list of events back to the SWID-PV. + Over time, a SW-PC might record a large number of change events. If + a SW-PV requests all change events covering a large period of time, + the resulting SW Response attribute might be extremely large, + especially if the SW-PV is requesting the use of full records instead + of the use of Software Identifiers (as described in Section 3.2.2). + In the case that the resulting attribute is too large to send (either + because it exceeds the 4GB attribute size limit imposed by the PA-TNC + specification, or because it exceeds some smaller size limit imposed + on the SW-PC) the SW-PC MAY send a partial list of event records back + to the SW-PV. - Generation of a partial list of events in a SWID Response attribute - requires the SWID-PC to identify a "consulted range" of EIDs. A + Generation of a partial list of events in a SW Response attribute + requires the SW-PC to identify a "consulted range" of EIDs. A consulted range is the set of event records that are examined for - inclusion in the SWID Response attribute and that are included in - that attribute if applicable. Recall that, if a SWID Request is - targeted, only event records that involve the indicated SWID tags - would be applicable. (See Section 3.4 for more on Targeted Request.) - If a request is not targeted, all event records in the considered - range are applicable and included in the SWID Response attribute. + inclusion in the SW Response attribute and that are included in that + attribute if applicable. Recall that, if a SW Request is targeted, + only event records that involve the indicated software would be + applicable. (See Section 3.3 for more on Targeted Request.) If a + request is not targeted, all event records in the considered range + are applicable and included in the SW Response attribute. The lower bound of the consulted range MUST be the EID provided in - the SWID Request. (Recall that a SWID Request indicates a request - for event records by providing a non-0 EID value in the SWID Request. - See Section 3.6.3.) The upper bound of the consulted range is the - EID of the latest event record (as ordered by EID values) that is - included in the SWID Response attribute if it is applicable to the - request. The EID of this last event record is called the "Last - Consulted EID". The SWID-PC chooses this Last Consulted EID based on - the size of the event record list it is willing to provide to the - SWID-PV. + the SW Request. (Recall that a SW Request indicates a request for + event records by providing a non-0 EID value in the SW Request. See + Section 3.5.3.) The upper bound of the consulted range is the EID of + the latest event record (as ordered by EID values) that is included + in the SW Response attribute if it is applicable to the request. The + EID of this last event record is called the "Last Consulted EID". + The SW-PC chooses this Last Consulted EID based on the size of the + event record list it is willing to provide to the SW-PV. A partial result list MUST include all applicable event records within the consulted range. This means that for any applicable event - record whose EID is greater than or equal to the EID provided in the - SWID Request and whose EID is less than or equal to the Last - Consulted EID, that event record MUST be included in the SWID - Response conveying this partial list of event records. This ensures - that every partial list of event records is always complete within - its indicated range. + record (i.e., any event record in an un-targeted request, or an event + record associated with software matching a requested Software + Identifier in a targeted request) whose EID is greater than or equal + to the EID provided in the SW Request and whose EID is less than or + equal to the Last Consulted EID, that event record MUST be included + in the SW Response conveying this partial list of event records. + This ensures that every partial list of event records is always + complete within its indicated range. - All SWID Response attributes that convey event records (either using - full SWID tags or using SWID tag identifier instances) include an - Epoch, Last EID, and Last Consulted EID field. The Last EID contains - the EID of the last event record known to the SWID-PC at the time - that the SWID Response attribute was generated. The Last EID might - or might not be part of the consulted range. As noted above, the - Last Consulted EID field contains the EID of the last event record in - the consulted range. The Epoch field contains the EID Epoch - associated with the Last EID and Last Consulted EID fields as well as - all the EIDs in event records contained within the SWID Response - attribute. Note that, if responding to a targeted SWID Request, the - SWID Response attribute might not contain the event record whose EID - matches the Last Consulted EID value. For example, the last - consulted EID record might have been deemed inapplicable because it - did not match the specified list of SWID tag identifiers in the SWID - Request. + All SW Response attributes that convey event records (either using + full records or using Software Identifiers) include an Epoch, Last + EID, and Last Consulted EID field. The Last EID contains the EID of + the last event record known to the SW-PC at the time that the SW + Response attribute was generated. The Last EID might or might not be + part of the consulted range. As noted above, the Last Consulted EID + field contains the EID of the last event record in the consulted + range. The Epoch field contains the EID Epoch associated with the + Last EID and Last Consulted EID fields as well as all the EIDs in + event records contained within the SW Response attribute. Note that, + if responding to a targeted SW Request, the SW Response attribute + might not contain the event record whose EID matches the Last + Consulted EID value. For example, the last consulted EID record + might have been deemed inapplicable because it did not match the + specified list of Software Identifiers in the SW Request. - If a SWID-PV receives a SWID Response attribute where the Last EID - and Last Consulted EID fields are identical, the SWID-PV knows that - it has received a result list that is complete, given the parameters - of the request, up to the present time. On the other hand, if the - Last EID and Last Consulted EID values differ, the SWID-PV has - received a partial result list. In the latter case, if the SWID-PV - wishes to try to collect the rest of the partially delivered result - list it then sends a new SWID Request whose EID is one greater than - the Last Consulted EID in the preceding response. Doing this causes - the SWID-PC to generate another SWID Response attribute containing - event records where the earliest reported event record is the one - immediately after the event record with the Last Consulted EID (since - EIDs are assigned sequentially). By repeating this process until it - receives a SWID Response where the Last EID and Last Consulted EID - are equal, the SWID-PV is able to collect all event records over a - given range, even if the complete set of event records would be too - large to deliver via a single attribute. + If a SW-PV receives a SW Response attribute where the Last EID and + Last Consulted EID fields are identical, the SW-PV knows that it has + received a result list that is complete, given the parameters of the + request, up to the present time. On the other hand, if the Last EID + and Last Consulted EID values differ, the SW-PV has received a + partial result list. In the latter case, if the SW-PV wishes to try + to collect the rest of the partially delivered result list it then + sends a new SW Request whose EID is one greater than the Last + Consulted EID in the preceding response. Doing this causes the SW-PC + to generate another SW Response attribute containing event records + where the earliest reported event record is the one immediately after + the event record with the Last Consulted EID (since EIDs are assigned + sequentially). By repeating this process until it receives a SW + Response where the Last EID and Last Consulted EID are equal, the SW- + PV is able to collect all event records over a given range, even if + the complete set of event records would be too large to deliver via a + single attribute. - Implementers need to be aware that a SWID Request might specify an - EID that is greater than the EID of the last event recorded by a - SWID-PC. In accordance with the behaviors described in - Section 3.6.3, a SWID-PC MUST respond to such a request with a SWID - Response attribute of the appropriate type (using SWID tags or SWID - tag identifier instances as specified in the SWID Request) that - contains zero event records. This is because the SWID-PC has - recorded no event records with EIDs greater than or equal to the EID - in the SWID Request. In such a case, the Last Consulted EID field - MUST be set to the same value as the Last EID field in this SWID - response attribute. This case is called out because consulted range - on a SWID-PC in such a situation is a negative range, where the - "first" EID in the range (provided in the SWID Request) is greater - than the "last" EID in the range (this being the EID of the last - recorded event on the SWID-PC). Implementers need to ensure that - SWID-PCs do not experience problems in such a circumstance. + Implementers need to be aware that a SW Request might specify an EID + that is greater than the EID of the last event recorded by a SW-PC. + In accordance with the behaviors described in Section 3.5.3, a SW-PC + MUST respond to such a request with a SW Response attribute of the + appropriate type (using full records or Software Identifiers as + specified in the SW Request) that contains zero event records. This + is because the SW-PC has recorded no event records with EIDs greater + than or equal to the EID in the SW Request. In such a case, the Last + Consulted EID field MUST be set to the same value as the Last EID + field in this SW Response attribute. This case is called out because + the consulted range on a SW-PC in such a situation is a negative + range, where the "first" EID in the range (provided in the SW + Request) is greater than the "last" EID in the range (this being the + EID of the last recorded event on the SW-PC). Implementers need to + ensure that SW-PCs do not experience problems in such a circumstance. Note that this specification only supports the returning of partial results when returning event records. There is no way to return a partial inventory list under this specification. -3.6.5. Synchronizing Event Identifiers and Epochs +3.5.5. Synchronizing Event Identifiers and Epochs - Since EIDs are sequential within an Epoch, if a SWID-PV's list of - event records contains gaps in the EID values within a single Epoch, - the SWID-PV knows that there are events that have not been accounted - for. The SWID-PV can either request a new event list to collect the - missing events or request a full inventory to re-sync its - understanding of the state of the SWID tags on the endpoint. In - either case, after the SWID-PV's record of the endpoint's SWID tag - collection has been updated, the SWID-PV records the new latest EID - value and tracks events normally from that point on. + Since EIDs are sequential within an Epoch, if a SW-PV's list of event + records contains gaps in the EID values within a single Epoch, the + SW-PV knows that there are events that have not been accounted for. + The SW-PV can either request a new event list to collect the missing + events or request a full inventory to re-sync its understanding of + the state of the Endpoint's Software Inventory Evidence Collection. + In either case, after the SW-PV's record of the endpoint's Software + Inventory Evidence Collection has been updated, the SW-PV can record + the new latest EID value and track events normally from that point + on. - If the SWID-PV receives any attribute from a SWID-PC where the EID - Epoch differs from the EID Epoch that was used previously, then SWID- - PV or any entity using this information to track the endpoint's SWID - tag collection knows that there is a discontinuity in their - understanding of the endpoint's state. To move past this + If the SW-PV receives any attribute from a SW-PC where the EID Epoch + differs from the EID Epoch that was used previously, then SW-PV or + any entity using this information to track the endpoint's Software + Inventory Evidence Collection knows that there is a discontinuity in + their understanding of the endpoint's state. To move past this discontinuity and reestablish a current understanding of the state of - the endpoint's SWID tag collection, the SWID-PV needs to receive a - full inventory from the endpoint. This is because it is not possible - to account for all events on the SWID-PC over the interval since the - previous Epoch was used, because there is no way to query for EIDs - from a previous Epoch. Once the SWID-PV has received a full - inventory for the new Epoch, the SWID-PV records the latest EID - reported in this new Epoch and can track further events normally. + the endpoint's Software Inventory Evidence Collection, the SW-PV + needs to receive a full inventory from the endpoint. The SW-PV + cannot be brought in sync with the endpoint's state through the + collection of any set of event records in this situation. This is + because it is not possible to account for all events on the SW-PC + over the interval since the previous Epoch was used, because there is + no way to query for EIDs from a previous Epoch. Once the SW-PV has + received a full inventory for the new Epoch, the SW-PV records the + latest EID reported in this new Epoch and can track further events + normally. - A SWID-PC MUST NOT report events with EIDs from any Epoch other than - the current EID Epoch. The SWID-PC MAY choose to purge all event + A SW-PC MUST NOT report events with EIDs from any Epoch other than + the current EID Epoch. The SW-PC MAY choose to purge all event records from a previous Epoch from memory after an Epoch change. - Alternately, the SWID-PC MAY choose to retain some event records from - a previous EID Epoch and assign them new EIDs in the current Epoch. - However, in the case where a SWID-PC chooses the latter option it - MUST ensure that the order of events according to their EIDs is - unchanged and that there is no coverage gap between the first - retained event recorded during the previous Epoch (now reassigned - with an EID in the current Epoch) and the first event recorded during - the current Epoch. In particular, the SWID-PC MUST ensure that all - change events that occurred after the last recorded event from the - previous Epoch are known and recorded. (This might not be possible - if the Epoch change is due to state corruption on the SWID-PC.) A - SWID-PC might choose to reassign EIDs to records from a preceding - Epoch to create a "sliding window" of events, where each Epoch change - represents a shift in the window of available events. + Alternately, the SW-PC MAY choose to retain some event records from a + previous EID Epoch and assign them new EIDs in the current Epoch. + However, in the case where a SW-PC chooses the latter option it MUST + ensure that the order of events according to their EIDs is unchanged + and that there is no coverage gap between the first retained event + recorded during the previous Epoch (now reassigned with an EID in the + current Epoch) and the first event recorded during the current Epoch. + In particular, the SW-PC MUST ensure that all change events that + occurred after the last recorded event from the previous Epoch are + known and recorded. (This might not be possible if the Epoch change + is due to state corruption on the SW-PC.) A SW-PC might choose to + reassign EIDs to records from a preceding Epoch to create a "sliding + window" of events, where each Epoch change represents a shift in the + window of available events. - In the case where a SWID-PC suffers a crash and loses track of its + In the case where a SW-PC suffers a crash and loses track of its current EID Epoch or current EID, then it MUST generate a new EID Epoch value and begin assigning EIDs within that Epoch. In this - case, the SWID-PC MUST purge all event records from before the crash - as it cannot ensure that there is not a gap between the last of those + case, the SW-PC MUST purge all event records from before the crash as + it cannot ensure that there is not a gap between the last of those records and the next detected event. The process for generating a new EID Epoch MUST minimize the possibility that the newly generated EID Epoch is the same as a previously used EID Epoch. - The SWID-PV will normally never receive an attribute indicating that + The SW-PV will normally never receive an attribute indicating that the latest EID is less than the latest EID reported in a previous - attribute within the same EID Epoch. If this occurs, the SWID-PC has + attribute within the same EID Epoch. If this occurs, the SW-PC has suffered an error of some kind, possibly indicative of at least - partial corruption of its event log. In this case, the SWID-PV - SHOULD treat the situation as if there was a change in Epoch and - treat any local copy of the endpoint's SWID tag collection as out-of- - sync until a full inventory can be reported by the SWID-PC. In this - case, the SWID-PV SHOULD flag the event so it can be examined to - ensure it is now operating properly. - -3.7. Supporting Multiple Instances of a Single Tag - - One important consideration is that it is possible for multiple - instances of a SWID tag to be present on an endpoint. (I.e., - multiple SWID tag files whose tag identifiers are the same.) This - can happen if there are multiple instances of the indicated software - product installed on the endpoint. In order to account for the - possibility, all SWID-PCs MUST follow specific rules, outlined below. - -3.7.1. Inventory Reporting in the Presence of Multiply-Instantiated - Tags - - When sending an inventory, either full or based on a targeted - request, the SWID-PC MUST include one entry for each instance of a - relevant tag. (All tags are relevant in a full inventory. In a - targeted request for an inventory, only tags that match the tag - identifiers provided by the SWID-PV are considered relevant.) For - example, if a particular piece of software is installed twice on an - endpoint, and thus there are two instances of its SWID tag present in - the endpoint's SWID tag collection, an inventory for which this tag - is relevant will contain at least two records for this piece of - software, one for each tag instance. (It might contain more if - multiple tag creators each created tags for the same piece of - installed software.) In the case where the SWID-PC's response is - expressed using full tags, the response MUST contain one copy of each - instance of the given tag. In other words, the SWID-PC MUST send one - copy of each tag instance, rather than send multiple copies of one - tag instance. In the case where the SWID-PC's response is expressed - using tag identifiers, the response MUST include the tag identifier - instance for each instance of the given tag. - -3.7.2. Event Reporting in the Presence of Multiply Instantiated Tags - - When reporting events, the specific tags that were added, deleted, or - changed MUST be indicated. For example, in the case where tags A and - B are two instances of the same SWID tag, each for separate - installations of the same software product, and tag A changes in the - endpoint's SWID tag collection, the SWID-PC MUST report the event - using tag A (rather than reporting it using B). This means that the - report MUST contain the tag file or the tag identifier instance for - the affected tag. + partial corruption of its event log. In this case, the SW-PV SHOULD + treat the situation as if there was a change in Epoch and treat any + local copy of the endpoint's Software Inventory Evidence Collection + as out-of-sync until a full inventory can be reported by the SW-PC. + In this case, the SW-PV SHOULD flag the occurrence so the SW-PC can + be examined to ensure it is now operating properly. -3.8. Subscriptions +3.6. Subscriptions - Thus far, all message exchanges discussed assume that a SWID-PV sent - an SWID Request attribute and the SWID-PC is providing a direct - response to that request. The SWID Message and Attributes for PA-TNC - specification also supports the ability for a SWID-PC to send a - message with a SWID Attribute to the SWID-PV in response to observed - changes in the endpoint's SWID tag collection, instead of in direct - response to a SWID Request. An agreement by a SWID-PC to send - content when certain changes are detected to the endpoint's SWID tag - collection is referred to in this specification as a "subscription", - and the SWID-PV that receives this content is said to be "subscribed - to" the given SWID-PC. All SWID-PCs and SWID-PVs MUST support the - use of subscriptions. + Thus far, all message exchanges discussed assume that a SW-PV sent an + SW Request attribute and the SW-PC is providing a direct response to + that request. The Software Message and Attributes for PA-TNC + specification also supports the ability for a SW-PC to send a message + with a SW Attribute to the SW-PV in response to observed changes in + the endpoint's software inventory evidence collection, instead of in + direct response to a SW Request. An agreement by a SW-PC to send + content when certain changes are detected to the endpoint's Software + Inventory Evidence Collection is referred to in this specification as + a "subscription", and the SW-PV that receives this content is said to + be "subscribed to" the given SW-PC. All SW-PCs and SW-PVs MUST + support the use of subscriptions. -3.8.1. Establishing Subscriptions +3.6.1. Establishing Subscriptions - A SWID-PV establishes a subscription on a particular SWID-PC by - sending a SWID Request attribute with the Subscription flag set. The - SWID Request attribute is otherwise identical to the SWID Requests - discussed in previous sections. Specifically, such a SWID Request - might request full tags or tag identifier instances, might be - targeted, and might request change event records or endpoint - inventory. Assuming no error is encountered, a SWID-PC MUST send a - SWID Response attribute in direct response to this SWID Request - attribute, just as if the Subscription flag was not set. As such, - the message exchange that establishes a new subscription in a SWID-PC - has the same flow seen in the previous message exchanges, as depicted - in Figure 2. If the SWID-PV does not receive a PA-TNC Error - attribute (as described in Section 3.10 and Section 4.16) in response - to their subscription request, the subscription has been successfully - established on the SWID-PC. The SWID Request attribute that - establishes a new subscription is referred to as the "establishing - request" for that subscription. + A SW-PV establishes a subscription on a particular SW-PC by sending a + SW Request attribute with the Subscription flag set. The SW Request + attribute is otherwise identical to the SW Requests discussed in + previous sections. Specifically, such a SW Request might request + full records or Software Identifiers, might be targeted, and might + request change event records or endpoint inventory. Assuming no + error is encountered, a SW-PC MUST send a SW Response attribute in + direct response to this SW Request attribute, just as if the + Subscription flag was not set. As such, the message exchange that + establishes a new subscription in a SW-PC has the same flow seen in + the previous message exchanges, as depicted in Figure 2. If the SW- + PV does not receive a PA-TNC Error attribute (as described in + Section 3.8 and Section 4.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.8.) - A SWID-PC MUST have the ability to record and support multiple - simultaneous subscriptions from a single party and subscriptions from - multiple parties. A SWID-PV MUST have the ability to record and - support multiple simultaneous subscriptions to a single party and + 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 +3.6.2. Managing Subscriptions - The SWID-PC MUST record each accepted subscription along with the + The SW-PC MUST record each accepted subscription along with the identity of the party to whom attributes are to be pushed in compliance with the subscription. This identity includes both the NEA Server's connection ID and the Posture Validator Identifier from the PB-PA message that delivered the request. - Likewise, SWID-PVs MUST record each accepted subscription for which + Likewise, SW-PVs MUST record each accepted subscription for which they are the subscribing party along with the associated Subscription - ID and the identity of the SWID-PC that will be fulfilling the - subscription. The SWID-PV needs to retain this information in order - to correctly interpret pushed SWID Response attributes sent in - fulfillment of the subscription. The identity of the SWID-PC is - given in the Posture Collector Identifier of the PB-PA message header - in all messages from that SWID-PC. + ID and the identity of the SW-PC that will be fulfilling the + subscription. The SW-PV needs to retain this information in order to + correctly interpret pushed SW Response attributes sent in fulfillment + of the subscription. The identity of the SW-PC is given in the + Posture Collector Identifier of the PB-PA message header in all + messages from that SW-PC. -3.8.3. Terminating Subscriptions +3.6.3. Terminating Subscriptions - Subscriptions MAY be terminated at any time by the subscribing SWID- - PV by setting the Clear Subscriptions flag in a SWID Request. (See - Section 4.9 for more on using this flag.) In the case that the SWID- - PC receives both the connection ID and the Posture Validator ID of - the SWID-PV requesting that subscriptions be cleared (i.e., the clear - subscription request is received via a TNC_IMC_ReceiveMessageLong - function) and the SWID-PC has been recording PV IDs associated with - subscriptions when available, the SWID-PC MUST only clear - subscriptions that match both the connection ID and the PV ID, and - MUST clear all such subscriptions. In the case that the SWID-PC only - has the connection ID of the party requesting that subscriptions be - cleared or the SWID-PC has not been recording Posture Validator IDs - associated with subscriptions even when available, it MUST only clear - subscriptions that match the connection ID and that have no - associated Posture Validator ID, and MUST clear all such - 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.9 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 SWID-PV the ability to terminate - subscriptions individually - all subscriptions to the SWID-PV are + 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 SWID-PC the ability to - unilaterally terminate a subscription. However, if the SWID-PC + This specification does not give the SW-PC the ability to + unilaterally terminate a subscription. However, if the SW-PC experiences a fatal error fulfilling a subscription, resulting in sending a PA-TNC Error attribute of type - SWID_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose + SW_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose fulfillment led to the error MUST be treated as terminated by both - the SWID-PC and the SWID-PV. Only the subscription experiencing the + the SW-PC and the SW-PV. Only the subscription experiencing the error is cancelled and other subscriptions are unaffected. See - Section 3.10 for more on this error condition. + Section 3.8 for more on this error condition. Finally, a subscription is terminated if the connection between the - SWID-PC and SWID-PV is deleted. This occurs when the connection ID - used in the messages between the SWID-PC and the SWID-PV becomes - unbound. Loss of this connection ID would prevent the SWID-PC from - sending messages in fulfillment of this subscription. As such, loss - of the connection ID necessarily forces subscription termination - between the affected parties. + SW-PC and SW-PV is deleted. This occurs when the connection ID used + in the messages between the SW-PC and the SW-PV becomes unbound. + Loss of this connection ID would prevent the SW-PC from sending + messages in fulfillment of this subscription. As such, loss of the + connection ID necessarily forces subscription termination between the + affected parties. -3.8.4. Subscription Status +3.6.4. Subscription Status - A SWID-PV can request that a SWID-PC report the list of active - subscriptions where the SWID-PV is the subscriber. A SWID-PV can use - this to recover lost information about active subscriptions. A SWID- - PV can also use this capability to verify that a SWID-PC has not - forgotten any of its subscriptions. The latter is especially useful - where a SWID-PC does not send any attributes in fulfillment of a - given subscription for a long period of time. The SWID-PV can check - the list of active subscriptions on the SWID-PC and verify whether - the inactivity is due to a lack of reportable events, or due to the - SWID-PC forgetting its obligations to fulfill a given subscription. + A SW-PV can request that a SW-PC report the list of active + subscriptions where the SW-PV is the subscriber. A SW-PV can use + this to recover lost information about active subscriptions. A SW-PV + can also use this capability to verify that a SW-PC has not forgotten + any of its subscriptions. The latter is especially useful where a + SW-PC does not send any attributes in fulfillment of a given + subscription for a long period of time. The SW-PV can check the list + of active subscriptions on the SW-PC and verify whether the + inactivity is due to a lack of reportable events, or due to the SW-PC + forgetting its obligations to fulfill a given subscription. - A SWID-PV requests a list of its subscriptions on a given SWID-PC by - sending that SWID-PC a Subscription Status Request. The SWID-PC MUST + A SW-PV requests a list of its subscriptions on a given SW-PC by + sending that SW-PC a Subscription Status Request. The SW-PC MUST then respond with a Subscription Status Response (or a PA-TNC Error if an error condition is experienced). The Subscription Status - Response contains one subscription record for each of the active - subscriptions for which the SWID-PV is the subscribing party. - Specifically, in the case that the Subscription Status Request - arrives with both a connection ID and a Posture Validator ID and the - SWID-PC has been recording Posture Validator IDs associated with - subscriptions when available, the SWID-PC MUST include only - subscription records associated with both the given connection ID and - Posture Validator ID, and MUST include all such records. In the case - that the Subscription Status Request arrives with only a connection - ID or the SWID-PC has not been recording Posture Validator IDs - associated with subscriptions even when available, the SWID-PC MUST - include only subscription records associated with the given - connection ID and that have no associated Posture Validator ID, and - MUST include all such records. + Response MUST contain one subscription record for each of the active + subscriptions for which the SW-PV is the subscribing party. -3.8.5. Fulfilling Subscriptions +3.6.5. Fulfilling Subscriptions - As noted in Section 3.5 SWID-PCs MUST have the ability to - automatically detect changes to an endpoint's SWID tag collection in - near real-time. For every active subscription, the SWID-PC MUST send - an attribute to the subscribed SWID-PV whenever a change is detected - to relevant tags within the endpoint's SWID tag collection. The - SWID-PC MAY choose to exclusively deliver this attribute. (See - section 4.5 of RFC 5793 (PB-TNC) [RFC5793] for more on exclusive - delivery.) Such an attribute is said to be sent "in fulfillment of" - the given subscription and any such attribute MUST include that - subscription's Subscription ID. If the establishing request for that - subscription was a targeted request, then only tags that match the - SWID tag identifiers provided in that establishing request are - considered relevant. Otherwise, (i.e., for non-targeted requests) - any tag is considered relevant for this purpose. Figure 3 shows a - sample message exchange where a subscription is established and then - later messages are sent from the SWID-PC in fulfillment of the - established subscription. + As noted in Section 3.4 SW-PCs MUST have the ability to automatically + detect changes to an endpoint's Software Inventory Evidence + Collection in near real-time. For every active subscription, the SW- + PC MUST send an attribute to the subscribed SW-PV whenever a change + is detected to relevant records within the endpoint's Software + Inventory Evidence Collection. Such an attribute is said to be sent + "in fulfillment of" the given subscription and any such attribute + MUST include that subscription's Subscription ID. If the + establishing request for that subscription was a targeted request, + then only records that match the Software Identifiers provided in + that establishing request are considered relevant. Otherwise, (i.e., + for non-targeted requests) any record is considered relevant for this + purpose. Figure 3 shows a sample message exchange where a + subscription is established and then later messages are sent from the + SW-PC in fulfillment of the established subscription. +-------------+ +--------------+ - | SWID-PC | | SWID-PV | Time + | SW-PC | | SW-PV | Time +-------------+ +--------------+ | | | | - |<----------SWID Request------------| | + |<-----------SW Request-------------| | | | | - |-----------SWID Response---------->| | + |------------SW Response----------->| | | | | . . . . . . . . . | | | - |-----------SWID Response---------->| | + |------------SW Response----------->| | | | | . . . . . . . . . | | | - |-----------SWID Response---------->| | + |------------SW Response----------->| | | | V Figure 3: Subscription Establishment and Fulfillment The contents of an attribute sent in fulfillment of a subscription depend on the parameters provided in the establishing request for that subscription. Specifically, the contents of an attribute sent in fulfillment of a subscription have the same format as would a direct response to the establishing request. For example, if the establishing request stipulated a response that contained an event - record list wherein affected SWID tags were indicated using SWID tag - identifier instances, all attributes sent in fulfillment of this - subscription will also consist of event record lists expressed using - SWID tag identifier instances. As such, all SWID Responses displayed - in the exchange depicted in Figure 3 have the same format. A SWID - Response generated in fulfillment of an active subscription MUST be a - valid SWID Response attribute according to all the rules outlined in - the preceding sections. In other words, an attribute constructed in - fulfillment of a subscription will look the same as an attribute sent - in direct response to an explicit request from a SWID-PV that had the - same request parameters and which arrived immediately after the given + record list wherein affected software indicated using Software + Identifiers, all attributes sent in fulfillment of this subscription + will also consist of event record lists expressed using Software + Identifiers. As such, all SW Responses displayed in the exchange + depicted in Figure 3 have the same format. A SW Response generated + in fulfillment of an active subscription MUST be a valid SW Response + attribute according to all the rules outlined in the preceding + sections. In other words, an attribute constructed in fulfillment of + a subscription will look the same as an attribute sent in direct + response to an explicit request from a SW-PV that had the same + request parameters and which arrived immediately after the given change event. There are a few special rules that expand on this guideline: -3.8.5.1. Subscriptions Reporting Inventories +3.6.5.1. Subscriptions Reporting Inventories - In the case that a SWID-PV subscribes to a SWID-PC requesting an + In the case that a SW-PV subscribes to a SW-PC requesting an inventory attribute whenever changes are detected (i.e. the EID in - the establishing request is 0), then the SWID-PC MUST send the + the establishing request is 0), then the SW-PC MUST send the requested inventory whenever a relevant change is detected. (A "relevant change" is any change for untargeted requests, or a change - to an indicated SWID tag in a targeted request.) Upon detection of a - relevant change for an active subscription, the SWID-PC sends the + to an indicated record in a targeted request.) Upon detection of a + relevant change for an active subscription, the SW-PC sends the appropriate inventory information as if it had just received the establishing request. Attributes sent in fulfillment of this subscription will probably have a large amount of redundancy, as the - same tags are likely to be present in each of these SWID Attributes. - The role of an inventory subscription is not to report tags just for - the items that changed - that is the role of a subscription that - reports events (see Section 3.8.5.2). A SWID-PC MUST NOT exclude a - tag from an attribute sent in fulfillment of an inventory - subscription simply because that tag was not involved in the - triggering event (although the tag might be excluded for other + same records are likely to be present in each of these SW Attributes. + The role of an inventory subscription is not to report records just + for the items that changed - that is the role of a subscription that + reports events (see Section 3.6.5.2). A SW-PC MUST NOT exclude a + record from an attribute sent in fulfillment of an inventory + subscription simply because that record was not involved in the + triggering event (although a record might be excluded for other reasons, such as if the subscription is targeted - see - Section 3.8.5.3). + Section 3.6.5.3). -3.8.5.2. Subscriptions Reporting Events +3.6.5.2. Subscriptions Reporting Events - The way in which a SWID-PV indicates it wishes to establish a + The way in which a SW-PV indicates it wishes to establish a subscription requesting event records is by providing a non-zero EID - in the SWID Request establishing the subscription (see - Section 3.6.1). However, when the SWID-PC constructs an attribute in - fulfillment of the subscription (other than the direct response to - the establishing request), it MUST only include event records for the - detected change(s) that precipitated this response attribute. In - other words, it MUST NOT send a complete list of all changes starting - with the indicated EID, up through the latest change, every time a - new event is detected. In effect, the EID in the establishing - request is treated as being updated every time an attribute is sent - in fulfillment of this subscription, such that a single event is not + in the SW Request establishing the subscription (see Section 3.5.1). + However, when the SW-PC constructs an attribute in fulfillment of the + subscription (other than the direct response to the establishing + request), it MUST only include event records for the detected + change(s) that precipitated this response attribute. In other words, + it MUST NOT send a complete list of all changes starting with the + indicated EID, up through the latest change, every time a new event + is detected. In effect, the EID in the establishing request is + treated as being updated every time an attribute is sent in + fulfillment of this subscription, such that a single event is not reported twice in fulfillment of a single subscription. As such, - every SWID-PC MUST track the EID of the last event that triggered an + every SW-PC MUST track the EID of the last event that triggered an attribute for the given subscription. When the next event (or set of - events) is detected, the SWID-PC MUST only report events with later - EIDs. In the case that the EID Epoch of the SWID-PC changes, the - SWID-PC MUST treat EID values in the new Epoch as being after all - EIDs assigned in the previous Epoch regardless of the relative - numeric values of these EIDs. + events) is detected, the SW-PC MUST only report events with EIDs + after the last reported event. In the case that the EID Epoch of the + SW-PC changes, the SW-PC MUST treat EID values in the new Epoch as + being after all EIDs assigned in the previous Epoch regardless of the + relative numeric values of these EIDs. - Note that while a subscription is active, the subscribing SWID-PV MAY + Note that while a subscription is active, the subscribing SW-PV MAY make other requests for event records that overlap with events that - are reported due to a subscription. Such requests are unaffected by - the presence of the subscription, nor is the subscription affected by - such requests. In other words, a given request will get the same - results back whether or not there was a subscription. Likewise, an - attribute sent in fulfillment of a subscription will contain the same - information whether or not other requests had been received from the - SWID-PV. + are reported in fulfillment of a subscription. Such requests are + unaffected by the presence of the subscription, nor is the + subscription affected by such requests. In other words, a given + request will get the same results back whether or not there was a + subscription. Likewise, an attribute sent in fulfillment of a + subscription will contain the same information whether or not other + requests had been received from the SW-PV. - A SWID-PV needs to pay attention to the EID Epoch in these messages, - as changes in the Epoch might create discontinuities in the SWID-PV's - understanding of the endpoint's SWID tag collection state, as - discussed in Section 3.6.5. In particular, once the EID Epoch - changes, a SWID-PV is unable have confidence that it has a correct - understanding of the state of an endpoint's SWID tag collection until - after the SWID-PV collects a complete inventory. + A SW-PV needs to pay attention to the EID Epoch in these messages, as + changes in the Epoch might create discontinuities in the SW-PV's + understanding of the endpoint's Software Inventory Evidence + Collection state, as discussed in Section 3.5.5. In particular, once + the EID Epoch changes, a SW-PV is unable have confidence that it has + a correct understanding of the state of an endpoint's Software + Inventory Evidence Collection until after the SW-PV collects a + complete inventory. - SWID-PCs MAY send partial lists of event records in fulfillment of a - subscription. (See Section 3.6.4 for more on partial list of event - records.) In the case that a SWID-PC sends a partial list of event + SW-PCs MAY send partial lists of event records in fulfillment of a + subscription. (See Section 3.5.4 for more on partial list of event + records.) In the case that a SW-PC sends a partial list of event records, it MUST immediately send the next consecutive partial list, and continue doing so until it has sent the equivalent of the - complete list of event records. In other words, if the SWID-PC sends - a partial list it does not wait for another change event to send - another SWID Response, but continues sending SWID Responses until it - has sent all event records that would have been included in a - complete fulfillment of the subscription. + complete list of event records. In other words, if the SW-PC sends a + partial list it does not wait for another change event to send + another SW Response, but continues sending SW Responses until it has + sent all event records that would have been included in a complete + fulfillment of the subscription. -3.8.5.3. Targeted Subscriptions +3.6.5.3. Targeted Subscriptions - Subscriptions MAY be targeted to only apply to tags that match a - given set of tag identifiers. In the case where changes are detected - that affect multiple tags, some matching the establishing request's - tag identifiers and some not, the attribute sent in fulfillment of - the subscription MUST only include inventory or events (as - appropriate) for tags that match the establishing request's tag - identifiers. The SWID-PC MUST NOT include non-matching tags in the - attribute, even if those non-matching tags experienced change events - that were co-temporal with change events on the matching tags. + Subscriptions MAY be targeted to only apply to records that match a + given set of Software Identifiers. In the case where changes are + detected that affect multiple records, some matching the establishing + request's Software Identifiers and some not, the attribute sent in + fulfillment of the subscription MUST only include inventory or events + (as appropriate) for records that match the establishing request's + Software Identifiers. The SW-PC MUST NOT include non-matching + records in the attribute, even if those non-matching records + experienced change events that were co-temporal with change events on + the matching records. - In addition, a SWID-PC MUST send an attribute in fulfillment of a - targeted subscription only when changes to the endpoint's SWID tag - collection impact one or more tags matching the subscription's - establishing request's tag identifiers. A SWID-PC MUST NOT send any - attribute in fulfillment of a targeted subscription based on detected - change to the endpoint's SWID tag collection that did not involve any - of the tags targeted by that subscription. + In addition, a SW-PC MUST send an attribute in fulfillment of a + targeted subscription only when changes to the endpoint's Software + Inventory Evidence Collection impact one or more records matching the + subscription's establishing request's Software Identifiers. A SW-PC + MUST NOT send any attribute in fulfillment of a targeted subscription + based on detected change to the endpoint's Software Inventory + Evidence Collection that did not involve any of the records targeted + by that subscription. -3.8.5.4. No Subscription Consolidation +3.6.5.4. No Subscription Consolidation - A SWID-PV MAY establish multiple subscriptions to a given SWID-PC. - If this is the case, it is possible that a single change event on the + A SW-PV MAY establish multiple subscriptions to a given SW-PC. If + this is the case, it is possible that a single change event on the endpoint might require fulfillment by multiple subscriptions, and that the information included in attributes that fulfill each of - these subscriptions might overlap. The SWID-PC MUST send separate + these subscriptions might overlap. The SW-PC MUST send separate attributes for each established subscription that requires a response due to the given event. Each of these attributes MUST contain all information required to fulfill that individual subscription, even if that information is also sent in other attributes sent in fulfillment - of other subscriptions at the same time. In other words, SWID-PCs - MUST NOT attempt to combine information when fulfilling multiple + of other subscriptions at the same time. In other words, SW-PCs MUST + NOT attempt to combine information when fulfilling multiple subscriptions simultaneously, even if this results in some redundancy - in the attributes sent to the SWID-PV. + in the attributes sent to the SW-PV. -3.8.5.5. Delayed Subscription Fulfillment +3.6.5.5. Delayed Subscription Fulfillment - A SWID-PC MAY delay the fulfillment of a subscription following a + A SW-PC MAY delay the fulfillment of a subscription following a change event in the interest of waiting to see if additional change events are forthcoming and, if so, conveying the relevant records - back to the SWID-PV in a single SWID Response attribute. This can - help reduce network bandwidth consumption between the SWID-PC and the - SWID-PV. For example, consider a situation where 10 changes occur a - tenth of a second apart. If the SWID-PC does not delay in assembling - and sending SWID Response attributes, the SWID-PV will received 10 - separate SWID Response attributes over a period of 1 second. - However, if the SWID-PC waits half a second after the initial event - before assembling a SWID Response, the SWID-PV only receives two SWID - Response attributes over the same period of time. + back to the SW-PV in a single SW Response attribute. This can help + reduce network bandwidth consumption between the SW-PC and the SW-PV. + For example, consider a situation where 10 changes occur a tenth of a + second apart. If the SW-PC does not delay in assembling and sending + SW Response attributes, the SW-PV will receive 10 separate SW + Response attributes over a period of 1 second. However, if the SW-PC + waits half a second after the initial event before assembling a SW + Response, the SW-PV only receives two SW Response attributes over the + same period of time. Note that the ability to consolidate events for a single subscription over a given period of time does not contradict the rules in - Section 3.8.5.4 prohibiting consolidation across multiple - subscriptions. When delaying fulfillment of subscriptions, SWID-PCs + Section 3.6.5.4 prohibiting consolidation across multiple + subscriptions. When delaying fulfillment of subscriptions, SW-PCs are still required to fulfill each individual subscription separately. Moreover, in the case that change events within the - delay window cancel each other out (e.g., a SWID tag is deleted and - then re-added), the SWID-PC MUST still report each change event - rather than just reporting the net effect of changes over the delay - period. In other words, delayed fulfillment can decrease the number - of attributes send by the SWID-PC, but it does not reduce the total - number of change events reported. + delay window cancel each other out (e.g., a record is deleted and + then re-added), the SW-PC MUST still report each change event rather + than just reporting the net effect of changes over the delay period. + In other words, delayed fulfillment can decrease the number of + attributes send by the SW-PC, but it does not reduce the total number + of change events reported. - SWID-PCs are not required to support delayed fulfillment of - subscriptions. However, in the case that the SWID-PC does support + SW-PCs are not required to support delayed fulfillment of + subscriptions. However, in the case that the SW-PC does support delayed subscription fulfillment, it MUST be possible to configure - the SWID-PC to disable delayed fulfillment. In other words, parties - deploying SWID-PCs need to be allowed to disable delayed subscription - fulfillment in their SWID-PCs. The manner in which such - configuration occurs is left to the discretion of implementers, - although implementers MUST protect the configuration procedure from + the SW-PC to disable delayed fulfillment. In other words, parties + deploying SW-PCs need to be allowed to disable delayed subscription + fulfillment in their SW-PCs. The manner in which such configuration + occurs is left to the discretion of implementers, although + implementers MUST protect the configuration procedure from 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. Multiple Sources of SWID Tags +3.7. Multiple Sources of Software Inventory Evidence Records - As noted in Section 2.1, the SWID tags in an endpoint's SWID tag - collection might potentially come from multiple sources. For - example, SWID tags might be deposited on the file system and - collected therefrom. SWID tags might also be dynamically generated - by tools such as software and package managers (e.g., RPM or YUM) or - might be dynamically translated from software discovery reports - expressed in some non-SWID format. + The records in an endpoint's software inventory evidence collection + might potentially come from multiple sources. For example, records + might be derived from ISO SWID tags deposited on the file system and + collected therefrom. Records might also be generated by tools such + as software and package managers (e.g., RPM or YUM) or might be + translated from software discovery reports. - A SWID-PC is not required to identify every possible source of SWID - tags on its endpoint. Some SWID-PCs might be explicitly tied only to - one or a handful of SWID tag sources. SWID-PCs are not required to - be aware of SWID tags that come from sources other than those that - they specifically support. In particular, if an endpoint has 3 - sources of SWID tags, and a SWID-PC supports collecting SWID tags - from two of those sources, not only is that SWID-PC only responsible - for reporting tags that come from its two supported sources, but it - is also only responsible for monitoring for change events from those - two sources. This noted, for all of the SWID tag sources that a - particular SWID-PC supports, it MUST completely support all - requirements of this specification with regard to its supported - sources. In other words, for supported sources, the SWID-PC is - required to be capable of providing complete inventories of SWID - tags; monitoring for changes in the SWID collections reported by - those sources, correctly providing responses for both full and - targeted requests, and providing either complete SWID tag files or - SWID identifier instances as appropriate. The SWID-PC MUST NOT - provide any inventory or event information from SWID tag sources for - which it cannot provide this full support. + A SW-PC is not required to identify 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. 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. In other words, for supported sources, + the SW-PC is required to be capable of providing a complete set of + the provided software inventory evidence records; monitoring for + changes in the records reported by those sources, correctly providing + responses for both full and targeted requests that include records + from those sources, and providing either complete records or Software + Identifiers as appropriate. If the source's output is not in one of + the data models identified in the Software Data Model IANA table (see + Section 9.4), the SW-PC MUST be capable of converting that output + into one of the supported data models. In all cases, the SW-PC MUST + also be capable of deriving a Software Identifier from the resulting + record and also assigning that record a unique Record Identifier. + The SW-PC MUST NOT provide any inventory or event information from + software inventory sources for which it cannot provide this full + support. - The SWID Response attributes provide no way of distinguishing as to - which SWID tags, identifier instances, or event records are - associated with specific sources. The SWID-PC MUST include the - complete set of relevant data from all supported sources of SWID tags - in every SWID Response. In other words, a full inventory is required - to contain all the SWID tags from all supported sources, a targeted - inventory is required to contain all relevant tags from all sources, - and event tracking is required to cover all events from both sources. - With regard to events, a SWID-PC's assignment of EIDs MUST reflect - the presence and order of all events on the endpoint (at least for - supported sources) regardless of the source. This means that if - source A experiences an event, and then source B experiences two - events, and then source A experiences another two events, the SWID-PC - is required to capture five events with consecutive EID values + When providing a SW Response (either in direct response to a SW + Request or in fulfillment of a subscription) the SW-PC MUST include + the complete set of relevant data from all supported sources of + software inventory evidence. In other words, a full inventory is + required to contain all records from all supported sources, a + targeted inventory is required to contain all relevant records from + all sources, and event tracking is required to cover all events from + all sources. With regard to events, a SW-PC's assignment of EIDs + MUST reflect the presence and order of all events on the endpoint (at + least for supported sources) regardless of the source. This means + that if source A experiences an event, and then source B experiences + two events, and then source A experiences another two events, the SW- + PC is required to capture five events with consecutive EID values reflecting the order in which the events occur. - Note that, if a SWID-PC collects data from multiple sources, it is + Note that, if a SW-PC collects data from multiple sources, it is possible that some software products might be "double counted". This - can happen if both sources of SWID tags provide a SWID tag for a - single instance of a software product. Moreover, each of these - provided tags will probably have different SWID tag identifier - instances, since Instance IDs are managed by the process that - extracts the SWID tags from the individual sources, and such - processes are under no obligation to coordinate with each other as to - the Instance ID value. When a SWID-PC reports information or records - events from multiple SWID tag 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 a particular - SWID tag corresponding to a single installation of a software - product, all such tags from each source are required to be part of - the SWID-PC's processing even if this might lead to multiple - reporting, and the SWID-PC is not to ignore some tags to avoid such - multiple reporting. Similarly, in the case that multiple sources - report an event, the SWID-PC MUST create separate event records with - separate EIDs for each of these, even if there is the chance that - they represent the two sources reporting the same action on the - endpoint. Entities tracking SWID tags collected via SWID-PCs and - SWID-PVs need to be aware that such double-reporting might occur. - How (or if) such occurrences are detected and resolved is up to the - implementers of those entities. + can happen if both sources of inventory evidence provide a record for + a single installation of a software product. Moreover, each of these + provided records might have different Software Identifiers. 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. Similarly, in the case + that multiple sources report an event, the SW-PC MUST create separate + event records with separate EIDs for each of these, even if there is + the chance that they represent the two sources reporting the same + action on the endpoint. Entities tracking software inventory + information collected via SW-PCs and SW-PVs need to be aware that + such double-reporting might occur. How (or if) such occurrences are + detected and resolved is up to the implementers of those entities. -3.10. Error Handling +3.8. Error Handling - In the case where the SWID-PC detects an error in a SWID Request + In the case where the SW-PC detects an error in a SW Request attribute that it receives it MUST respond with a PA-TNC Error attribute 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.16 in this - specification for error codes specific to SWID attributes.) In the - cast that an error is detected in a SWID Request the SWID-PC MUST NOT - take any action requested by this SWID Request, even if some - requested action can be completed successfully despite the error in - the attribute. In other words, a SWID Request that contains an error - is ignored by the SWID-PC beyond sending a PA-TNC Error attribute, - and possibly logging the error locally. + 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 SWID-PC receives a valid SWID Request attribute - but experiences an error during the process of responding to that - attribute's instructions where that error prevents the SWID-PC from - properly or completely fulfilling that request, the SWID-PC MUST send - a PA-TNC Error attribute with an error code appropriate to the nature + In the case where the SW-PC receives a valid SW Request attribute but + experiences an error during the process of responding to that + attribute's instructions where that error prevents the SW-PC from + properly or completely fulfilling that request, the SW-PC MUST send a + PA-TNC Error attribute with an error code appropriate to the nature of the error. In the case where a PA-TNC Error attribute is sent, - the SWID-PC MUST NOT take any of the actions requested by the SWID + the SW-PC MUST NOT take any of the actions requested by the SW Request attribute which led to the detected error. This is the case - even if some actions can be completed successfully, and might even - require the SWID-PC to reverse some successful actions already taken - before the error condition was detected. In other words, either all - aspects of a SWID Request complete fully and successfully (in which - case the SWID-PC sends a SWID Response attribute), or no aspects of - the SWID Request occur (in which case the SWID-PC sends a PA-TNC - Error attribute). In the case that a SWID-PC sends a PA-TNC Error - attribute in response to a SWID Request then the SWID-PC MUST NOT - also send any SWID Response attribute in response to the same SWID - Request. For this reason, the sending of a SWID Response attribute - MUST be the last action taken by a SWID-PC in response to a SWID - Request to avoid the possibility of a processing error occurring - after that SWID Response attribute is sent. + even if some actions could have been completed successfully, and + might even require the SW-PC to reverse some successful actions + already taken before the error condition was detected. In other + words, either all aspects of a SW Request complete fully and + successfully (in which case the SW-PC sends a SW Response attribute), + or no aspects of the SW Request occur (in which case the SW-PC sends + a PA-TNC Error attribute). In the case that a SW-PC sends a PA-TNC + Error attribute in response to a SW Request then the SW-PC MUST NOT + also send any SW Response attribute in response to the same SW + Request. For this reason, the sending of a SW Response attribute + MUST be the last action taken by a SW-PC in response to a SW Request + to avoid the possibility of a processing error occurring after that + SW Response attribute is sent. - In the case that the SWID-PC detects an error that prevents it from + In the case that the SW-PC detects an error that prevents it from properly or completely fulfilling its obligations under an active - subscription, the SWID-PC MUST send a PA-TNC Error attribute of type - SWID_SUBSCRIPTION_FULFILLMENT_ERROR to the SWID-PV that established - this subscription. This type of PA-TNC Error attribute identifies - the specific subscription that cannot be adequately honored due to - the error condition as well as an error "sub-type". The error sub- - type is used to indicate the type of error condition the SWID-PC - experienced that prevented it from honoring the given subscription. - In the case that the error condition cannot be identified or does not - align with any of the defined error codes, the SWID_ERROR error code - SHOULD be used in the sub-type. In the case that a - SWID_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated - subscription MUST be treated as cancelled by both the SWID-PC and - SWID-PV. + subscription, the SW-PC MUST send a PA-TNC Error attribute of type + SW_SUBSCRIPTION_FULFILLMENT_ERROR to the SW-PV that established this + subscription. This type of PA-TNC Error attribute identifies the + specific subscription that cannot be adequately honored due to the + error condition as well as an error "sub-type". The error sub-type + is used to indicate the type of error condition the SW-PC experienced + that prevented it from honoring the given subscription. In the case + that the error condition cannot be identified or does not align with + any of the defined error codes, the SW_ERROR error code SHOULD be + used in the sub-type. In the case that a + SW_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated + subscription MUST be treated as cancelled by both the SW-PC and SW- + PV. - The SWID-PV MUST NOT send any PA-TNC Error attributes to SWID-PCs. - In the case that a SWID-PV detects an error condition, it SHOULD log - this error but does not inform any SWID-PC's of this event. Errors - might include, but are not limited to, detection of malformed SWID - Response attributes sent from a given SWID-PC, as well as detection - of error conditions when the SWID-PV processes SWID Responses. + The SW-PV MUST NOT send any PA-TNC Error attributes to SW-PCs. In + the case that a SW-PV detects an error condition, it SHOULD log this + error but does not inform any SW-PC's of this event. Errors might + include, but are not limited to, detection of malformed SW Response + attributes sent from a given SW-PC, as well as detection of error + conditions when the SW-PV processes SW Responses. - Both SWID-PCs and SWID-PVs SHOULD log errors so that administrators - can trace the causes of errors. Log messages SHOULD include the type - of the error, the time it was detected, and additional descriptive + Both SW-PCs and SW-PVs SHOULD log errors so that administrators can + trace the causes of errors. Log messages SHOULD include the type of + the error, the time it was detected, and additional descriptive information to aid in understanding the nature and cause of the error. -4. SWID Message and Attributes for PA-TNC Protocol +4. Software Message and Attributes for PA-TNC Protocol - This section describes the format and semantics of the SWID Message - and Attributes for PA-TNC protocol leveraging the existing SWID tag - format. SWID 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. + This section describes the format and semantics of the Software + Message and Attributes for PA-TNC protocol. Software 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. In order for the NEA protocols - to carry SWID tags, this specification adds the following enumeration - element to the table in section 7.2 of the PA-TNC specification - [RFC5792] using the IETF Standard name space (SMI Private Enterprise - Number 0x000000): + defined in the PA-TNC specification. This specification adds the + following enumeration element to the table 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 | SWID | SWID Message and Attributes for | + +-----+---------+-------------+-------------------------------------+ + | 0 | 9 | SW | Software Message and Attributes for | | | | Attributes | PA-TNC | - +-----+---------+----------------+----------------------------------+ + +-----+---------+-------------+-------------------------------------+ Table 2: PA Subtype Each PA-TNC attribute described in this specification is intended to - be sent between the SWID-PC and SWID-PV, so will be carried in a PB- - TNC message indicating a PA Subtype of SWID Attributes. Note that - although the PA-TNC Error attribute is defined in the PA-TNC - specification, when it is used in a SWID Attribute exchange, it uses - the SWID Attributes Component Definition Value, as described in - Section 4.2.8 of the PA-TNC specification [RFC5792]. PB-TNC messages - MUST always include the SWID Attributes Subtype defined in this - section when carrying SWID Attributes over PA-TNC. + be sent between the SW-PC and SW-PV, so will be carried in a PB-TNC + message indicating a PA Subtype of SW Attributes. Note that although + 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. 4.2. PB-TNC and PA-TNC Messages A PA-TNC message is wrapped within a PB-TNC message. A single PA-TNC message might contain one or more PA-TNC attributes. All of these attributes within a single PA-TNC message use the same PA Subtype - value. As such, SWID Attributes are never sent with attributes - defined in other PA-TNC binding specifications in a single PA-TNC - message. Note, however, that a single PB-TNC batch might contain - multiple PB-TNC and PA-TNC messages, and each of those messages might - use different PA Subtypes. + value. As such, SW Attributes are never sent in the same PA-TNC + message as attributes defined in other PA-TNC binding specifications. + + Note, however, that a single PB-TNC batch might contain multiple PB- + TNC and PA-TNC messages, and each of those messages might use + different PA Subtypes. For more information on PB-TNC and PA-TNC messages and message headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792] specifications, respectively. 4.3. PA-TNC Attribute Header - The SWID Message and Attributes for PA-TNC protocol described in this - specification is an extension of the PA-TNC protocol described in the - NEA Architecture. PA-TNC was designed to be very flexible in order - to carry many types of PA-TNC attributes that pertain to an + The Software Message and Attributes for PA-TNC protocol described in + this specification is an extension of the PA-TNC protocol described + in the NEA Architecture. PA-TNC was designed to be very flexible in + order to carry many types of PA-TNC attributes that pertain to an enumerated set of component types (e.g. Table 2). PA-TNC attributes might be carried from Posture Collector to Posture Validator or vice versa and might carry information about endpoint state or other information to be sent between a Posture Validator and a Posture - Collector. Therefore the SWID Message and Attributes for PA-TNC + Collector. Therefore, the Software Message and Attributes for PA-TNC specification defines a collection of PA-TNC attributes relevant to - the collection and transmission of SWID tag inventories. + the collection and transmission of software inventories and + associated events. Figure 4, reproduced from the PA-TNC specification, shows the format of a PA-TNC attribute. Multiple PA-TNC attributes can be sent in a single PB-TNC message, each housed within an attribute structure as described below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | PA-TNC Attribute Vendor ID | @@ -2093,664 +1731,646 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Value (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: PA-TNC Header and Attribute Format +-----------+-------------------------------------------------------+ | Field | Description | +-----------+-------------------------------------------------------+ | Flags | This field defines flags affecting the processing of | - | | the SWID Message and Attributes for PA-TNC. | + | | the Software Message and Attributes for PA-TNC. | | | Permissible flags are given in the PA-TNC | | | specification. [RFC5792] | + | | | | Attribute | This field indicates the owner of the name space | | Type | associated with the Attribute Type. Attributes | - | Vendor ID | defined in the SWID Message and Attributes for PA-TNC | - | | specification have a value corresponding to the IETF | - | | SMI Private Enterprise Number value (0x000000). The | - | | PA-TNC Error attribute is defined in the PA-TNC | - | | specification [RFC5792] and also uses the IETF SMI | - | | Private Enterprise Number Value (0x000000). See Table | - | | 4 for more information. | + | Vendor ID | defined in the Software Message and Attributes for | + | | PA-TNC specification have a value corresponding to | + | | the IETF SMI Private Enterprise Number value | + | | (0x000000). The PA-TNC Error attribute is defined in | + | | the PA-TNC specification [RFC5792] and also uses the | + | | IETF SMI Private Enterprise Number Value (0x000000). | + | | See Table 4 for more information. | + | | | | Attribute | This field defines the type of the Attribute. The | - | Type | values corresponding to SWID Attributes are given in | + | Type | values corresponding to SW Attributes are given in | | | Table 4. | + | | | | Attribute | This field contains the length in octets of the | | Length | entire Attribute, including the Attribute's header. | - | Attribute | This field contains the SWID Attribute. | + | | | + | Attribute | This field contains the SW Attribute. | | Value | | +-----------+-------------------------------------------------------+ Table 3: Fields of the PA-TNC Attribute Format -4.4. SWID Attribute Overview +4.4. 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 SWID Request - This attribute is used to request a SWID tag - inventory or SWID event list from an endpoint. This attribute - might also establish a subscription on the recipient SWID-PC. A - SWID-PC MUST NOT send this attribute. - - o SWID Tag Identifier Inventory - This attribute is used to convey - an inventory expressed using SWID tag identifier instances - (instead of full tags). When a SWID-PC receives a SWID Request - attribute requesting an inventory using SWID tag identifier - instances, the SWID-PC MUST send a SWID Tag Identifier Inventory - attribute (or a PA-TNC Error) in response. This attribute also - MAY be sent by the SWID-PC in fulfillment of an active - subscription. A SWID-PV MUST NOT send this attribute. + 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 SWID Tag Identifier Events - This attribute is used to convey a - list of events concerning changes to an endpoint's collection of - SWID tags. Affected SWID tags are indicated using SWID tag - identifier instances (instead of full tags). When a SWID-PC - receives a SWID Request attribute requesting an event collection - using with SWID tag identifier instances, the SWID-PC MUST send a - SWID Tag Identifier Events attribute (or a PA-TNC Error) in - response. This attribute also MAY be sent by the SWID-PC in - fulfillment of an active subscription. A SWID-PV MUST NOT send - this attribute. + o Software Identifier Inventory - This attribute is used to convey + an inventory expressed using Software Identifiers (instead of full + records). When a SW-PC receives a SW Request attribute requesting + an inventory using Software Identifiers, 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 SWID Tag Inventory - This attribute is used to convey an inventory - expressed using full SWID tags (instead of SWID tag identifier - instances). When a SWID-PC receives a SWID Request attribute - requesting an inventory using full SWID tags, the SWID-PC MUST - send a SWID Tag Inventory attribute (or a PA-TNC Error) in - response. This attribute also MAY be sent by the SWID-PC in - fulfillment of an active subscription. A SWID-PV MUST NOT send + o Software Identifier Events - This attribute is used to convey a + list of events concerning changes to an endpoint's Software + Inventory Evidence Collection. Affected software inventory + evidence records are indicated using Software Identifiers (instead + of full records). When a SW-PC receives a SW Request attribute + requesting an event collection using Software Identifiers, 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 SWID Tag Events - This attribute is used to convey a list of - events concerning changes to an endpoint's collection of SWID - tags. Affected SWID tags are indicated using full SWID tags - (instead of SWID tag identifier instances). When a SWID-PC - receives a SWID Request attribute requesting an event collection - using full SWID tags, the SWID-PC MUST send a SWID Tag Events + o Software Inventory - This attribute is used to convey an inventory + expressed using full software inventory evidence records (instead + of Software Identifiers). When a SW-PC receives a SW Request + attribute requesting an inventory using full 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 SWID-PC in fulfillment of an active - subscription. A SWID-PV MUST NOT send this attribute. + 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. Affected software inventory evidence records are + indicated using full records (instead of Software Identifiers). + When a SW-PC receives a SW Request attribute requesting an event + collection using full 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 - SWID-PC send a summary of all the active subscriptions it has - where the requesting party is the subscriber. The SWID-PC MUST - respond with a Subscription Status Response (or a PA-TNC Error). - A SWID-PC MUST NOT send this attribute. + 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 SWID-PC has for - a given subscriber. A SWID-PV MUST NOT send this attribute. + 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 SWID Attribute exchange. It MUST be sent - by a SWID-PC in response to a SWID Request in the case where the - SWID-PC encounters a fatal error (i.e., an error that prevents - further processing of an exchange) relating to the attribute - exchange. A SWID-PV MUST NOT send this attribute. The SWID-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 SWID-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 + 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 SWID Tag Identifier Inventory, SWID Tag Identifier - Events, SWID Tag Inventory, or SWID Tag Events attributes is expected - to be sent to a SWID-PV in direct response to a SWID Request - attribute or in fulfillment of an active subscription, those four - attribute types are frequently referred to collectively in this - document as "SWID Response" attributes. + Because one of the Software Identifier Inventory, Software Identifier + Events, Software Inventory, or Software Events attributes is expected + to be sent to a SW-PV in direct response to a SW Request attribute or + in fulfillment of an active subscription, those four attribute types + are referred to collectively in this document as "SW Response" + attributes. - All SWID-PVs MUST be capable of sending SWID Requests and be capable - of receiving and processing all SWID Response attributes as well as - PA-TNC Error attributes. All SWID-PCs MUST be capable of receiving - and processing SWID Requests and be capable of sending all types of - SWID Response attributes as well as PA-TNC Error attributes. In - other words, both SWID-PVs and SWID-PCs are required to support their - role in exchanges using any of the attribute types defined in this - section. SWID-PVs MUST ignore any SWID Request attributes that they - receive. SWID-PCs MUST ignore any SWID Response attributes or PA-TNC - Error attributes that they receive. + 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. -4.5. SWID Attribute Exchanges +4.5. SW Attribute Exchanges - A SWID Attribute Exchange is used to provide the SWID-PV with a SWID - tag inventory or event collection from the queried endpoint. + A SW Attribute Exchange is used to provide the SW-PV with a software + inventory or event collection from the queried endpoint. +-------------+ +--------------+ - | SWID-PC | | SWID-PV | Time + | SW-PC | | SW-PV | Time +-------------+ +--------------+ | | | | - |<-----------SWID Request-------------| | + |<------------SW Request--------------| | | | | - | SWID Response* | | + | SW Response* | | |-----------------or----------------->| | | PA-TNC Error | | | | V - *SWID Response is one of the following: SWID Tag Identifier - Inventory, SWID Tag Identifier Events, SWID Tag Inventory, - or SWID Tag Events. + *SW Response is one of the following: Software Identifier + Inventory, Software Identifier Events, Software Inventory, + or Software Events. - Figure 5: SWID Attribute Exchange (Direct Response to SWID Request) + Figure 5: SW Attribute Exchange (Direct Response to SW Request) - In this exchange, the SWID-PV indicates to the SWID-PC, via a SWID - 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 (full tags or tag identifier - instances). The SWID-PC responds with the requested information - using the appropriate attribute type. A single SWID Request MUST - only lead to a single SWID Response or PA-TNC Error that is in direct - response to that request. + In this exchange, the SW-PV indicates to the SW-PC, via a SW Request, + the nature of the information it wishes to receive (inventory vs. + events, full or targeted) and how it wishes the returned inventory to + be expressed (full records or Software Identifiers). 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 - SWID-PC sends a SWID Response to the SWID-PV following a change event - on the endpoint in fulfillment of that subscription. Such an - exchange is shown in Figure 6. + 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 6. +-------------+ +--------------+ - | SWID-PC | | SWID-PV | Time + | SW-PC | | SW-PV | Time +-------------+ +--------------+ | | | | | | | - |-------SWID Response(s)*------>| | + |--------SW Response(s)*------->| | | | | - *SWID Response is one of the following: SWID Tag Identifier - Inventory, SWID Tag Identifier Events, SWID Tag Inventory, - or SWID Tag Events. + *SW Response is one of the following: Software Identifier + Inventory, Software Identifier Events, Software Inventory, + or Software Events. - Figure 6: SWID Attribute Exchange (In Fulfillment of an Active + Figure 6: SW Attribute Exchange (In Fulfillment of an Active Subscription) - Note that, unlike direct responses to a SWID Request, a single change - event can precipitate multiple SWID Responses, but only if all but - the last of those SWID Responses convey partial lists of event - records, and the last of those SWID Responses conveys a complete list - of event records. (That is, the initial responses are partial lists - and the last response is 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 be followed by - multiple SWID Response or PA-TNC Error attributes in any combination - except as noted earlier in this paragraph. + 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 + 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 be followed by multiple SW Response or PA-TNC + Error attributes in any combination except as noted earlier in this + paragraph. - All SWID-PVs and SWID-PCs MUST support both exchanges. In - particular, SWID-PCs MUST be capable of pushing a SWID Response to a - SWID-PV immediately upon detection of a change to the endpoint's SWID - tag collection in fulfillment of established SWID-PV subscriptions, - as described in Section 3.8. + 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.6. -4.6. SWID Message and Attributes for PA-TNC Attribute Enumeration +4.6. Software Message and Attributes for PA-TNC Attribute Enumeration PA-TNC attribute types are identified in the PA-TNC Attribute Header (see Section 4.2) via the Attribute Type Vendor ID and Attribute Type fields. Table 4 identifies the appropriate values for these fields - for each attribute type used within the SWID Message and Attributes - for PA-TNC protocol. + for each attribute type used within the Software Message and + Attributes for PA-TNC protocol. +--------------+----------+------------+----------------------------+ | Attribute | PEN | Integer | Description | | Name | | | | +--------------+----------+------------+----------------------------+ - | SWID Request | 0x000000 | 0x00000011 | Request from a SWID-PV to | - | | | | a SWID-PC for the SWID-PC | - | | | | to provide a SWID tag | + | 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 | - | SWID Tag | 0x000000 | 0x00000012 | A collection of SWID tag | - | Identifier | | | identifier instances sent | - | Inventory | | | from a SWID-PC. | - | SWID Tag | 0x000000 | 0x00000013 | A collection of events | + | | | | | + | Software | 0x000000 | 0x00000012 | A collection of Software | + | Identifier | | | Identifiers sent from a | + | Inventory | | | SW-PC. | + | | | | | + | Software | 0x000000 | 0x00000013 | A collection of events | | Identifier | | | impacting the endpoint's | - | Events | | | SWID tag collection, where | - | | | | impacted SWID tags are | - | | | | indicated using SWID tag | - | | | | identifier instances. | - | SWID Tag | 0x000000 | 0x00000014 | A collection of SWID tags | - | Inventory | | | sent from a SWID-PC. | - | SWID Tag | 0x000000 | 0x00000015 | A collection of events | + | Events | | | Software Inventory | + | | | | Evidence Collection, where | + | | | | impacted software | + | | | | inventory evidence records | + | | | | are indicated using | + | | | | Software Identifiers. | + | | | | | + | Software | 0x000000 | 0x00000014 | A collection of software | + | Inventory | | | inventory evidence records | + | | | | sent from a SW-PC. | + | | | | | + | Software | 0x000000 | 0x00000015 | A collection of events | | Events | | | impacting the endpoint's | - | | | | SWID tag collection, where | - | | | | impacted SWID tags are | - | | | | indicated using full SWID | - | | | | tags. | + | | | | Software Inventory | + | | | | Evidence Collection, where | + | | | | impacted software | + | | | | inventory evidence records | + | | | | are indicated using full | + | | | | records. | + | | | | | | Subscription | 0x000000 | 0x00000016 | A request for a list of a | - | Status | | | SWID-PV's active | + | Status | | | SW-PV's active | | Request | | | subscription. | - | Subscription | 0x000000 | 0x00000017 | A list of a SWID-PV's | - | Status | | | active subscriptions. | + | | | | | + | 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 SWID Message | - | | | | and Attributes for PA-TNC. | + | | | 0x0000001F | revisions to Software | + | | | | Message and Attributes for | + | | | | PA-TNC. | + | | | | | | PA-TNC Error | 0x000000 | 0x00000008 | An error attribute as | | | | | defined in the PA-TNC | | | | | specification [RFC5792]. | +--------------+----------+------------+----------------------------+ - Table 4: SWID Attribute Enumeration + Table 4: SW Attribute Enumeration 4.7. Normalization of Text Encoding - SWID tags do not have a required encoding format. The 2009 ISO SWID - specification states that "For encoding purposes, the use of utf-8 is - the suggested methodology for software identification tags...", but - leaves implementers free to use different encodings if this makes - sense in their local environment. As such, implementers of the SWID - Message and Attributes for PA-TNC specification cannot assume any - specific encoding of SWID tag fields (although, in most current - examples of SWID tags, SWID tag creators have followed the suggestion - of using UTF-8 encodings). Similarly, sometimes the SWID Message and - Attributes for PA-TNC specification requires the use of data taken - from other sources, such a path from the endpoint's file system, and - different platforms might use different encodings for this - information. In order to ensure the ability to consistently and - reliably compare information sent using the SWID Message and - Attributes for PA-TNC exchange, certain field values (identified - explicitly in the attribute definitions in the following sections) - are required to undergo normalization prior to their inclusion in an - attribute. - In order to ensure consistency of transmitted attributes, a field - requiring normalization, as indicated in its description, and only - such fields 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. SWID- - PCs and SWID-PVs MUST NOT perform conversion and normalization on any - field values except those specifically identified in the following - sections. + requiring normalization, as indicated in its description, 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 Section 9.4 will + note where this is necessary. 4.8. Request IDs - All SWID Request attributes MUST include a Request ID value. The + All SW Request attributes MUST include a Request ID value. The Request ID field provides a value that identifies a given request - relative to other requests between a SWID-PV and the receiving SWID- - PC. Specifically, the SWID-PV assigns each SWID 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 SWID-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. For example, if a Request - ID of X was the first Request ID used within a particular network - connection and if the Request IDs are exhausted, X will be the first - reused Request ID. In other words, a SWID-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 SWID-PC SHOULD structure the reuse to - maximize the time between original and subsequent use. The Request - ID value is included in a response attribute directly responding to - this SWID Request to indicate which SWID 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. SWID-PCs are not required to check for duplicate Request - IDs. + 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. For example, if a Request ID of X was + the first Request ID used within a particular network connection and + if the Request IDs are exhausted, X will be the first reused Request + ID. In other words, a SW-PC SHOULD NOT use a given Request ID value + more than once within a persistent connection between a given Posture + Broker Client-Posture Broker Server pair, but, in the case where + reuse is necessary due to exhaustion of possible ID values, the SW-PC + SHOULD structure the reuse to maximize the time between original and + subsequent use. The Request ID value is included in a SW Response + attribute directly responding to this SW Request to indicate which SW + Request was received and caused the response. Request IDs can be + randomly generated or sequential, as long as values are not repeated + per the rules in this paragraph. SW-PCs are not required to check + for duplicate Request IDs. - In the case that a SWID Request requests the establishment of a - subscription and the receiving SWID-PC agrees to that subscription, - the Request ID of that SWID 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 SWID-PV MUST NOT reuse a Request - ID value in communicating to a given SWID-PC while that Request ID is - also serving as a Subscription ID for an active subscription with - that SWID-PC. In the case where a SWID-PC receives a SWID Request - from a given SWID-PV where that Request ID is also the Subscription - ID of an active subscription with that SWID-PV, the SWID-PC MUST - respond with a PA-TNC Error attribute with an error code of - SWID_SUBSCRIPTION_ID_REUSE_ERROR. Note that this error does not - cancel the indicated subscription. + 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.9. SWID Request +4.9. SW Request - A SWID-PV sends this attribute to a SWID-PC to request that the SWID- - PC send SWID tag-based information to the SWID-PV. A SWID-PC MUST - NOT send this attribute. + 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 | Tag ID Count | + | Flags | Software Identifier Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Earliest EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Tag Creator Length | Tag Creator (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Unique Software ID Length |Unique Software ID (var length)| + | Software Identifier Length | Software ID (var length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 7: SWID Request Attribute + Figure 7: SW Request Attribute +---------------+---------------------------------------------------+ | Field | Description | +---------------+---------------------------------------------------+ - | Flags: Bit 0 | If set (1), the SWID-PC MUST delete all | - | - Clear | subscriptions established by the requesting SWID- | - | Subscriptions | PV (barring any errors). | + | Flags: Bit 0 | If set (1), the SW-PC MUST delete all | + | - Clear | subscriptions established by the requesting SW-PV | + | Subscriptions | (barring any errors). | + | | | | Flags: Bit 1 | If set (1), in addition to responding to the | - | - Subscribe | request as described, the SWID-PC MUST establish | - | | a subscription with parameters matching those in | + | - Subscribe | request as described, the SW-PC MUST establish a | + | | subscription with parameters matching those in | | | the request attribute (barring any errors). | - | Flags: Bit 2 | If unset (0), the SWID-PC's response MUST consist | - | - Result Type | of complete SWID tags and thus the response MUST | - | | be a SWID Tag Inventory, a SWID Tag Events, or a | - | | PA-TNC Error attribute. If set (1), the response | - | | MUST consist of SWID tag identifier instances and | - | | thus the response MUST be a SWID Tag Identifier | - | | Inventory, a SWID Tag Identifier Events, or a PA- | - | | TNC Error attribute. | + | | | + | Flags: Bit 2 | If unset (0), the SW-PC's response MUST consist | + | - Result Type | of complete software inventory evidence records | + | | and thus the response MUST be a Software | + | | Inventory, a Software Events, or a PA-TNC Error | + | | attribute. If set (1), the response MUST consist | + | | of Software Identifiers and thus the response | + | | MUST be a Software Identifier Inventory, a | + | | Software Identifier Events, or a PA-TNC Error | + | | attribute. | + | | | | Flags: Bit | Reserved for future use. This field MUST be set | | 3-7 - | to zero on transmission and ignored upon | | Reserved | reception. | - | Tag ID Count | A 3-byte unsigned integer indicating the number | - | | of tag identifiers that follow. If this value is | - | | non-zero, this is a targeted request, as | - | | described in Section 3.4. This field is a 3-byte | - | | unsigned integer. The Tag Creator Length, Tag | - | | Creator, Unique Software ID Length, and Unique | - | | Software ID fields are repeated, in order, the | - | | number of times indicated in this field. In the | - | | case where tag identifiers are present, the SWID- | - | | PC MUST only respond with SWID tags or tag | - | | identifier instances that correspond to the | - | | identifiers the SWID-PV provided in this | - | | attribute (or with a PA-TNC Error attribute). | - | | This field value MAY be 0, in which case there | - | | are no instances of the Tag Creator Length, Tag | - | | Creator, Unique Software ID Length, and Unique | - | | Software ID fields. In this case, the SWID-PV is | - | | indicating an interest in all SWID tags on the | - | | endpoint (i.e., this is not a targeted request). | - | Request ID | A value that uniquely identifies this SWID | - | | Request from a particular SWID-PV. | - | Earliest EID | In the case where the SWID-PV is requesting SWID | - | | events, this field contains the EID value of the | - | | earliest event the SWID-PV wishes to have | - | | reported. (Note - the report will be inclusive of | - | | the event with this EID value.) In the case where | - | | the SWID-PV is requesting an inventory, then this | - | | field MUST be 0. (0x00000000) In the case where | - | | this field is non-zero, the SWID-PV is requesting | - | | events and the SWID-PC MUST respond using a SWID | - | | Tag Events, SWID Tag Identifier Events, or a PA- | - | | TNC Error attribute. In the case where this field | - | | is zero, the SWID-PV is requesting an inventory | - | | and the SWID-PC MUST respond using a SWID Tag | - | | Inventory, a SWID Tag Identifier Inventory, or a | - | | PA-TNC Error attribute. | - | Tag Creator | A 2-byte unsigned integer indicating the length | - | Length | in bytes of the Tag Creator field. | - | Tag Creator | A string containing the Tag Creator RegID value | - | | from within a SWID tag. This field value MUST be | - | | normalized to Network Unicode format, as | - | | described in Section 4.7. This string MUST NOT | - | | be NULL terminated. | - | Unique | A 2-byte unsigned integer indicating the length | - | Software ID | in bytes of the Unique Software ID field. | + | | | + | Software | A 3-byte unsigned integer indicating the number | + | Identifier | of Software Identifiers that follow. If this | + | Count | value is non-zero, this is a targeted request, as | + | | described in Section 3.3. The Software | + | | Identifier Length and Software ID fields are | + | | repeated, in order, the number of times indicated | + | | in this field. In the case where Software | + | | Identifiers are present, the SW-PC MUST only | + | | respond with software inventory evidence records | + | | or Software Identifiers that correspond to the | + | | identifiers the SW-PV provided in this attribute | + | | (or with a PA-TNC Error attribute). This field | + | | value MAY be 0, in which case there are no | + | | instances of the Software Identifier Length and | + | | Software ID fields. In this case, the SW-PV is | + | | indicating an interest in all software inventory | + | | evidence records on the endpoint (i.e., this is | + | | not a targeted request). | + | | | + | Request ID | A value that uniquely identifies this SW Request | + | | from a particular SW-PV. | + | | | + | Earliest EID | In the case where the SW-PV is requesting | + | | software events, this field contains the EID | + | | value of the earliest event the SW-PV wishes to | + | | have reported. (Note - the report will be | + | | inclusive of the event with this EID value.) In | + | | the case where the SW-PV is requesting an | + | | inventory, then this field MUST be 0. | + | | (0x00000000) In the case where this field is non- | + | | zero, the SW-PV is requesting events and the SW- | + | | PC MUST respond using a Software Events, Software | + | | Identifier Events, or a PA-TNC Error attribute. | + | | In the case where this field is zero, the SW-PV | + | | is requesting an inventory and the SW-PC MUST | + | | respond using a Software Inventory, a Software | + | | Identifier Inventory, or a PA-TNC Error | + | | attribute. | + | | | + | Software | A 2-byte unsigned integer indicating the length | + | Identifier | in bytes of the Software ID field. | | Length | | - | Unique | A string containing the Unique ID value from | - | Software ID | within a SWID tag. This field value MUST be | - | | normalized to Network Unicode format, as | - | | described in Section 4.7. This string MUST NOT be | - | | NULL terminated. | + | | | + | Software ID | A string containing the Software Identifier value | + | | from a software inventory evidence record. This | + | | field value MUST be normalized to Network Unicode | + | | format, as described in Section 4.7. This string | + | | MUST NOT be NULL terminated. | +---------------+---------------------------------------------------+ - Table 5: SWID Request Attribute Fields + Table 5: SW Request Attribute Fields - The SWID-PV sends the SWID Request attribute to a SWID-PC to request - the indicated information. Note that between the Result Type flag - and the Earliest EID field, the SWID-PC is constrained to a single - possible SWID Response attribute type (or a PA-TNC Error attribute) - in its response to the request. + 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 SWID-PV on the receiving SWID-PC. + subscriptions for the requesting SW-PV on the receiving SW-PC. Specifically, an attribute with the Subscribe flag set seeks to - establish a new subscription by the requesting SWID-PV to the given - SWID-PC, while an attribute with the Clear Subscription flag seeks to - delete all existing subscriptions by the requesting SWID-PV on the - given SWID-PC. Note that, in the latter case, only the subscriptions - associated with the Connection ID and, if available, the Posture - Validator ID of the 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 tag identifiers (if present) indicate if and how a - subscription is targeted. In the case that the SWID-PC is unable or - unwilling to comply with the SWID-PV's request to establish or clear - subscriptions, the SWID-PC MUST respond with a PA-TNC Error attribute - with the SWID_SUBSCRIPTION_DENIED_ERROR error code. (Note that if - the SWID-PV requests that subscriptions be cleared but has no - existing subscriptions, this is not an error.) + establish a new subscription by the requesting SW-PV to the given SW- + PC, while an attribute with the Clear Subscription flag seeks to + delete all existing subscriptions by the requesting SW-PV on the + given SW-PC. Note that, in the latter case, only the subscriptions + associated with the Connection ID and the Posture Validator ID of the + requester are deleted as described in Section 3.6.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.) An attribute requesting the establishment of a subscription is effectively doing double-duty, as it is a request for an immediate - response from the SWID-PC in addition to setting up the subscription. - A SWID-PC 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 - the SWID-PC MUST - generate a response attribute without regard to the presence of this - flag in addition to clearing its subscription list. + 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 SWID Request attribute. In the case where this request is - successful, the end result MUST be equivalent to the SWID-PC clearing - its subscription list for the given SWID-PV first and then creating 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 - SWID-PC MUST respond with a SWID Response attribute. (The specific - type of SWID 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 - SWID-PC MUST NOT add a new subscription, MUST NOT clear the old - subscriptions, and the SWID-PC MUST respond with a PA-TNC Error - attribute. In other words, the SWID-PC MUST NOT partially succeed at - implementing such a request; either both actions succeed, or neither - succeed. + 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 both actions succeed, or neither succeed. - The Earliest EID field is used to indicate whether the SWID-PV is - requesting an inventory or event list from the SWID-PC. A value of 0 + 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 SWID-PV is requesting event information. For Earliest - EID values other than 0, the SWID-PC's response MUST respond with - event records, as described in Section 3.6. Note that the request - does not identify a particular EID Epoch, since responses can only - include events in the SWID-PC's current EID Epoch. + 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.5. 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 Tag ID Count indicates the number of tag identifiers in the - attribute. This number might be any value between 0 and 16,777,216, - inclusive. A single tag identifier is represented by four fields: - Tag Creator Length, Tag Creator, Unique Software ID Length, and - Unique Software ID. The two length fields are used to indicate the - number of bytes allocated to their corresponding string field. The - two string fields, Tag Creator and Unique Software ID, contain copies - of the SWID tag's Tag Creator RegID and Unique ID values, - respectively, converted and normalized to Network Unicode format, as - described in Section 4.7. Note that there is no field to indicate a - particular Instance ID. Thus, targeted requests request all - instances of the indicated SWID tags. The presence of one or more - tag identifiers is used by the SWID-PV to indicate a targeted - request, which seeks only inventories of or events affecting SWID - tags corresponding to the given identifiers. The SWID-PC MUST only - respond with tags that match the tag identifier structures provided - in the SWID-PVs SWID Request attribute (as described in - Section 3.3.3) and MUST include all instances of matching tags in its - response. + 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 fields: Software Identifier Length and Software ID. + The Software Identifier Length field indicates the number of bytes + allocated to Software ID field. The Software Identifier field + contains a Software Identifier as describe in Section 3.2. 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 respond with records that match the Software + Identifiers provided in the SW-PVs SW Request attribute. -4.10. SWID Tag Identifier Inventory +4.10. Software Identifier Inventory - A SWID-PC sends this attribute to a SWID-PV to convey a list of the - endpoint's SWID tags expressed using SWID tag identifier instances. - This list might represent a complete inventory or a targeted list of - tags, depending on the parameters in the SWID-PV's request. A SWID- - PV MUST NOT send this attribute. The SWID-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 SWID Request attribute where the - Result Type is 1 and the Earliest EID is zero. + A SW-PC sends this attribute to a SW-PV to convey the inventory of + the endpoint's Software Inventory Evidence Collection expressed using + Software Identifiers. 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Tag ID Count | + | Flags | Software Identifier Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID Copy / Subscription ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Tag Creator Length | Tag Creator (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Unique Software ID Length |Unique Software ID (var length | + |Data Model Type| Software IdentifierLength |SW ID (var len)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID Length | Instance ID (var length) | + | Record ID Length | Record ID (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 8: SWID Tag Identifier Inventory Attribute + Figure 8: Software Identifier Inventory Attribute +--------------+----------------------------------------------------+ | Field | Description | +--------------+----------------------------------------------------+ | Flags: Bit 0 | In the case that this attribute is sent in | | - | fulfillment of a subscription this bit MUST be set | | Subscription | (1). In the case that this attribute is a direct | - | Fulfillment | response to a SWID Request, this bit MUST be unset | + | Fulfillment | response to a SW Request, this bit MUST be unset | | | (0). | + | | | | Flags: Bit | Reserved for future use. This field MUST be set to | | 1-7 - | zero on transmission and ignored upon reception. | | Reserved | | - | Tag ID Count | The number of tag identifier instances that | - | | follow. This field is an unsigned integer. The Tag | - | | Creator Length, Tag Creator, Unique Software ID | - | | Length, Unique Software ID, Instance ID Length, | - | | and Instance ID 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. | + | | | + | Software | The number of Software Identifiers that follow. | + | Identifier | This field is an unsigned integer. The Data Model | + | Count | Type, Software Identifier Length, SW ID, Record ID | + | | Length, and Record ID 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 SWID Request attribute from a SWID- | - | Subscription | PV, this field MUST contain an exact copy of the | - | ID | Request ID field from that SWID Request. In the | + | 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. | + | | | | EID Epoch | The EID Epoch of the Last EID value. This field is | | | an unsigned 4-byte integer. | - | Last EID | The EID of the last event recorded by the SWID-PC, | - | | or 0 if the SWID-PC has no recorded events. This | + | | | + | Last EID | The EID of the last event recorded by the SW-PC, | + | | or 0 if the SW-PC has no recorded events. This | | | field is an unsigned 4-byte integer. | - | Tag Creator | A 2-byte unsigned integer indicating the length in | - | Length | bytes of the Tag Creator field. | - | Tag Creator | A string containing the Tag Creator RegID value | - | | from within a SWID tag. This field value MUST be | - | | normalized to Network Unicode format, as described | - | | in Section 4.7. This string MUST NOT be NULL | - | | terminated. | - | Unique | A 2-byte unsigned integer indicating the length in | - | Software ID | bytes of the Unique Software ID field. | + | | | + | Data Model | A 1-byte unsigned integer containing an identifier | + | Type | number from the Software Data Model IANA table | + | | that identifies the data model of the reported | + | | record. | + | | | + | Software | A 2-byte unsigned integer indicating the length in | + | Identifier | bytes of the SW ID field. | | Length | | - | Unique | A string containing the Unique ID value from | - | Software ID | within a SWID tag. This field value MUST be | - | | normalized to Network Unicode format, as described | - | | in Section 4.7. This string MUST NOT be NULL | - | | terminated. | - | Instance ID | A 2-byte unsigned integer indicating the length in | - | Length | bytes of the Instance ID field. | - | Instance ID | A string containing the Instance ID of a given tag | - | | instance. The exact value of this field depends on | - | | the party that provides this SWID tag. This field | - | | value MUST be normalized to Network Unicode | + | | | + | SW ID | A string containing the Software Identifier value | + | | from a software inventory evidence record. This | + | | field value MUST be normalized to Network Unicode | + | | format, as described in Section 4.7. This string | + | | MUST NOT be NULL terminated. | + | | | + | Record ID | A 2-byte unsigned integer indicating the length in | + | Length | bytes of the Record ID field. | + | | | + | Record ID | A string containing the Record Identifier value | + | | from a software inventory evidence record. This | + | | field value MUST be normalized to Network Unicode | | | format, as described in Section 4.7. This string | | | MUST NOT be NULL terminated. | +--------------+----------------------------------------------------+ - Table 6: SWID Tag Identifier Inventory Attribute Fields + Table 6: 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 SWID + 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 SWID response attribute sent in direct response to a SWID + 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 - SWID Request (and thus the Subscription Fulfillment bit is unset). - SWID Response attributes are only treated as being in fulfillment of - a subscription (i.e., Subscription Fulfillment bit set) if they are + 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 + subscription (i.e., Subscription Fulfillment bit set) if they are sent following a change event, as shown in Figure 3. - The Tag ID Count field indicates the number of tag identifier - instances present in this inventory. Each tag identifier instance is - represented by a set of six fields: Tag Creator Length, Tag Creator, - Unique Software ID Length, Unique Software ID, Instance ID Length, - and Instance ID. These six fields, collectively referred to as the - "Tag ID Fields", will appear once for each reported tag instance. - Note that an endpoint's SWID tag collection might contain multiple - instances of a single tag (i.e., multiple tag files with the same tag - identifier value). When this occurs, in the case where that tag is - reported, then the response MUST contain a set of Tag ID Fields for - each instance of that tag. (The tag might not be reported if the - SWID-PV made a targeted request that does not match that tag's tag - identifier.) For example, if an endpoint has three copies of tag X, - and the SWID-PV requests a full inventory, then the response is - required to include three sets of Tag ID Fields corresponding to the - three instances of that tag. Only the Instance ID fields are - different between these three instances. + The Software Identifier Count field indicates the number of Software + Identifiers present in this inventory. Each Software Identifier is + represented by a set of five fields: Data Model Type, Software + Identifier Length, SW ID, Record ID Length, and Record ID. These + fields will appear once for each reported record. - When responding directly to a SWID Request attribute, the Request ID + When responding directly to a SW Request attribute, the Request ID Copy / Subscription ID field MUST contain an exact copy of the - Request ID field from that SWID Request. When this attribute is sent + Request ID field from that SW Request. When this attribute is sent in fulfillment of an existing subscription on this Posture Collector, then this field MUST contain the Subscription ID of the fulfilled subscription. The EID Epoch field indicates the EID Epoch of the Last EID value. The Last EID field MUST contain the EID of the last recorded change - event (see Section 3.6 for more about EIDs and recorded events) at + event (see Section 3.5 for more about EIDs and recorded events) at the time this inventory was collected. In the case where there are no recorded change events at the time that this inventory was collected, this field MUST contain 0. These fields can be interpreted to indicate that the provided inventory (be it full or targeted) reflects the record of events on the endpoint after all changes up to and including this last event have been accounted for. -4.11. SWID Tag Identifier Events +4.11. Software Identifier Events - A SWID-PC sends this attribute to a SWID-PV to convey events where - the affected SWID tags are expressed using SWID tag identifier - instances. A SWID-PV MUST NOT send this attribute. The SWID-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 SWID - Request attribute where the Result Type is 1 and the Earliest EID is - non-zero. + A SW-PC sends this attribute to a SW-PV to convey events where the + affected records are expressed using Software Identifiers. A SW-PV + 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Event Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID Copy / Subscription ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -2763,310 +2383,310 @@ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Action | Tag Creator Length |Tag Creator (v)| - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Unique Software ID Length |Unique Software ID (var length)| + | Action |Data Model Type| Software Identifier Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID Length | Instance ID (var length) | + |SW ID (var len)| Record ID Length |Record ID (var)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 9: SWID Tag Identifier Events Attribute + Figure 9: Software Identifier Events Attribute +--------------+----------------------------------------------------+ | Field | Description | +--------------+----------------------------------------------------+ | Flags: Bit 0 | In the case that this attribute is sent in | | - | fulfillment of a subscription this bit MUST be set | | Subscription | (1). In the case that this attribute is a direct | - | Fulfillment | response to a SWID Request, this bit MUST be unset | + | Fulfillment | response to a SW Request, this bit MUST be unset | | | (0). | + | | | | Flags: Bit | Reserved for future use. This field MUST be set to | | 1-7 - | zero on transmission and ignored upon reception. | | Reserved | | + | | | | Event Count | The number of events that are reported in this | | | attribute. This field is a 3-byte unsigned | - | | integer. The EID, Timestamp, Action, Tag Creator | - | | Length, Tag Creator, Unique Software ID Length, | - | | Unique Software ID, Instance ID Length, and | - | | Instance ID fields are repeated, in order, the | - | | number of times indicated in this field. (An | - | | instance of these nine fields is referred to as an | - | | "event record" in this attribute. Thus the Event | - | | Count field indicates the number of event | + | | integer. The EID, Timestamp, Action, Data Model | + | | Type, Software Identifier Length, SW ID, Record ID | + | | Length, and Record ID fields are repeated, in | + | | order, the number of times indicated in this | + | | field. (An instance of these fields is referred to | + | | as an "event record" in this attribute. Thus the | + | | Event Count field indicates the number of event | | | records.) This field value MAY be 0, in which case | | | there are no instances of these fields. | + | | | | Request ID | In the case where this attribute is in direct | - | Copy / | response to a SWID Request attribute from a SWID- | - | Subscription | PV, this field MUST contain an exact copy of the | - | ID | Request ID field from that SWID Request. In the | + | 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. | + | | | | EID Epoch | The EID Epoch of the Last EID value. This field is | | | an unsigned 4-byte integer. | - | Last EID | The EID of the last event recorded by the SWID-PC, | - | | or 0 if the SWID-PC has no recorded events. This | - | | field contains the EID of the SWID-PC's last | + | | | + | Last EID | The EID of the last event recorded by the SW-PC, | + | | or 0 if the SW-PC has no recorded events. This | + | | field contains the EID of the SW-PC's last | | | recorded change event (which might or might not be | | | included as an event record in this attribute). | + | | | | Last | The EID of the last event record that was | | Consulted | consulted when generating the event record list | | EID | included in this attribute. This is different from | | | the Last EID field value if and only if this | | | attribute is conveying a partial list of event | - | | records. See Section 3.6.4 for more on partial | + | | records. See Section 3.5.4 for more on partial | | | list of event records. | + | | | | EID | The EID of the event in this event record. | + | | | | Timestamp | The timestamp associated with the event in this | - | | event record. This timestamps is the SWID-PC's | - | | best understanding of when the given event | - | | occurred. Note that this timestamp might be an | - | | estimate. The Timestamp date and time MUST be | - | | represented as an RFC 3339 [5] compliant ASCII | - | | string in Coordinated Universal Time (UTC) time | - | | with the additional restrictions that the 'T' | - | | delimiter and the 'Z' suffix MUST be capitalized | - | | and fractional seconds (time-secfrac) MUST NOT be | - | | included. This field conforms to the date-time | - | | ABNF production from section 5.6 of RFC 3339 | - | | [RFC3339] with the above restrictions. Leap | - | | seconds are permitted and SWID-PVs MUST support | - | | them. The Timestamp string MUST NOT be NULL | - | | terminated or padded in any way. The length of | - | | this field is always 20 octets. | + | | event record. This timestamps is the SW-PC's best | + | | understanding of when the given event occurred. | + | | Note that this timestamp might be an estimate. | + | | The Timestamp date and time MUST be represented as | + | | an RFC 3339 [5] compliant ASCII string in | + | | Coordinated Universal Time (UTC) time with the | + | | additional restrictions that the 'T' delimiter and | + | | the 'Z' suffix MUST be capitalized and fractional | + | | seconds (time-secfrac) MUST NOT be included. This | + | | field conforms to the date-time ABNF production | + | | from section 5.6 of RFC 3339 [RFC3339] with the | + | | above restrictions. Leap seconds are permitted | + | | and SW-PVs MUST support them. The Timestamp | + | | string MUST NOT be NULL terminated or padded in | + | | any way. The length of this field is always 20 | + | | octets. | + | | | | Action | The type of event that is recorded in this event | | | record. Possible values are: 1 = CREATION - the | - | | addition of a tag to the endpoint's SWID tag | - | | collection; 2 = DELETION - the removal of a tag | - | | from the endpoint's SWID tag collection; 3 = | - | | ALTERATION - There was an alteration to a tag file | - | | within the endpoint's tag collection. All other | - | | values are reserved for future use and MUST NOT be | - | | used when sending attributes. In the case where a | - | | SWID-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. | - | Tag Creator | A 2-byte unsigned integer indicating the length in | - | Length | bytes of the Tag Creator field of the tag affected | - | | by the described event. | - | Tag Creator | A string containing the Tag Creator RegID value | - | | from within the SWID tag affected by the described | - | | event. This field value MUST be normalized to | - | | Network Unicode format, as described in Section | - | | 4.7. This string MUST NOT be NULL terminated. | - | Unique | A 2-byte unsigned integer indicating the length in | - | Software ID | bytes of the Unique Software ID field of the tag | - | Length | affected by the described event. | - | Unique | A string containing the Unique ID value from | - | Software ID | within the SWID tag affected by the described | - | | event. This field value MUST be normalized to | - | | Network Unicode format, as described in Section | - | | 4.7. This string MUST NOT be NULL terminated. | - | Instance ID | A 2-byte unsigned integer indicating the length in | - | Length | bytes of the Instance ID field. | - | Instance ID | A string containing the Instance ID of a given tag | - | | instance. The exact value of this field depends on | - | | the party that provides this SWID tag. This field | - | | value MUST be normalized to Network Unicode | + | | 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 = ALTERATION - | + | | There was an alteration to a record within the | + | | endpoint's Software Inventory Evidence Collection. | + | | All other values are 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. | + | | | + | Data Model | A 1-byte unsigned integer containing an identifier | + | Type | number from the Software Data Model IANA table | + | | that identifies the data model of the reported | + | | record. | + | | | + | Software | A 2-byte unsigned integer indicating the length in | + | Identifier | bytes of the SW ID field. | + | Length | | + | | | + | SW ID | A string containing the Software Identifier value | + | | from a software inventory evidence record. This | + | | field value MUST be normalized to Network Unicode | + | | format, as described in Section 4.7. This string | + | | MUST NOT be NULL terminated. | + | | | + | Record ID | A 2-byte unsigned integer indicating the length in | + | Length | bytes of the Record ID field. | + | | | + | Record ID | A string containing the Record Identifier value | + | | from a software inventory evidence record. This | + | | field value MUST be normalized to Network Unicode | | | format, as described in Section 4.7. This string | | | MUST NOT be NULL terminated. | +--------------+----------------------------------------------------+ + Table 7: Software Identifier Events Attribute Fields - Table 7: SWID Tag Identifier Events Attribute Fields - - The first few fields in the SWID Tag Identifier Events attribute - mirror those in the SWID Tag Identifier Inventory attribute. The + 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 using - tag identifier instances, the attribute conveys zero or more event - records, including the EID, timestamp, action type, and tag - identifier instance of the affected tag. + Software Identifiers, the attribute conveys zero or more event + records, consisting of the EID, timestamp, action type, data model + type, Software Identifier, and Record Identifier of the affected + software inventory evidence record. With regard to the Timestamp field, it is important to note that - clock skew between the SWID-PC and SWID-PV as well as between - different SWID-PCs within an enterprise might make correlation of - timestamp values difficult. This specification does not attempt to - resolve clock skew issues, although other mechanisms outside of this + clock skew between the SW-PC and SW-PV as well as between different + SW-PCs within an enterprise might make correlation of timestamp + values difficult. This specification does not attempt to resolve + clock skew issues, although other mechanisms outside of this specification do exist to reduce the impact of clock skew and make - the timestamp more useful for such correlation. Instead, SWID + the timestamp more useful for such correlation. Instead, Software Message and Attributes for PA-TNC uses Timestamp value primarily as a means to indicate the amount of time between two events on a single endpoint. For example, by taking the difference of the times for - when a SWID tag was removed and then subsequently re-added, one can - get an indication as to how long the system was without the given tag + when a record was removed and then subsequently re-added, one can get + an indication as to how long the system was without the given record (and, thus without the associated software). Since this will involve comparison of timestamp values all originating on the same system, - clock skew between the SWID-PC and SWID-PV is not an issue. However, - if the SWID-PC's clock was adjusted between two recorded events, it - is possible for such a calculation to lead to incorrect - understandings of the temporal distance between events. Users of - this field need to be aware of the possibility for such occurrences. - In the case where the Timestamp values of two events appear to - contradict the EID ordering of those events (i.e., the later EID has - an earlier timestamp) the recipient MUST treat the EID ordering as - correct. + clock skew between the SW-PC and SW-PV is not an issue. However, if + the SW-PC's clock was adjusted between two recorded events, it is + possible for such a calculation to lead to incorrect understandings + of the temporal distance between events. Users of this field need to + be aware of the possibility for such occurrences. In the case where + the Timestamp values of two events appear to contradict the EID + ordering of those events (i.e., the later EID has an earlier + timestamp) the recipient MUST treat the EID ordering as correct. - All event records in a Tag Identifier Events Attribute are required - to be part of the same EID Epoch. Specifically, all reported events - MUST have an EID from the same EID Epoch as each other, and which is - the same as the EID Epoch of the Last EID and Last Consulted EID - values. The SWID-PC MUST NOT report events with EIDs from different - EID Epochs. + All event records in a Software Identifier Events Attribute are + required to be part of the same EID Epoch. Specifically, all + reported events MUST have an EID from the same EID Epoch as each + other, and which is the same as the EID Epoch of the Last EID and + Last Consulted EID values. The SW-PC MUST NOT report events with + EIDs from different EID Epochs. The Last Consulted EID field contains the EID of the last event record considered for inclusion in this attribute. If this attribute - contains a partial event set (as described in Section 3.6.4) this + contains a partial event set (as described in Section 3.5.4) this field value will differ from that of the Last EID field; if this attribute contains a complete event set, the Last EID and Last Consulted EID values are identical. - If multiple events are sent in a SWID Tag Identifier Events + 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 tag - identifier instance might appear multiple times in an attribute, such - as if multiple events involving the associated tag were being - reported. + indicated events appropriately. Also note that a single Software + Identifier might appear multiple times in an attribute, such as if + multiple events involving the associated record were being reported. -4.12. SWID Tag Inventory +4.12. Software Inventory - A SWID-PC sends this attribute to a SWID-PV to convey a list of SWID - tags. A SWID-PV MUST NOT send this attribute. The SWID-PC either + 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 SWID Request attribute where the + is zero, or in direct response to a SW Request attribute where the Result Type is 0 and the Earliest EID is zero. 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 | Tag Count | + | Flags | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID Copy / Subscription ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID Length | Instance ID (var length) | + |Data Model Type| Record ID Length |Record ID (var)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Tag Length | + | Record Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Tag (Variable) | + | Record (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 10: SWID Tag Inventory Attribute + Figure 10: Software Inventory Attribute +--------------+----------------------------------------------------+ | Field | Description | +--------------+----------------------------------------------------+ | Flags: Bit 0 | In the case that this attribute is sent in | | - | fulfillment of a subscription this bit MUST be set | | Subscription | (1). In the case that this attribute is a direct | - | Fulfillment | response to a SWID Request, this bit MUST be unset | + | Fulfillment | response to a SW Request, this bit MUST be unset | | | (0). | + | | | | Flags: Bit | Reserved for future use. This field MUST be set to | | 1-7 - | zero on transmission and ignored upon reception. | | Reserved | | - | Tag ID Count | The number of tags that follow. This field is a | - | | 3-byte unsigned integer. The Instance ID Length, | - | | Instance ID, Tag Length, and Tag 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 Count | The number of records that follow. This field is a | + | | 3-byte unsigned integer. The Data Model Type, | + | | Record Identifier Length, Record ID, Record | + | | Length, 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 SWID Request attribute from a SWID- | - | Subscription | PV, this field MUST contain an exact copy of the | - | ID | Request ID field from that SWID Request. In the | + | 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. | + | | | | EID Epoch | The EID Epoch of the Last EID value. This field is | | | an unsigned 4-byte integer. | - | Last EID | The EID of the last event recorded by the SWID-PC, | - | | or 0 if the SWID-PC has no recorded events. This | + | | | + | Last EID | The EID of the last event recorded by the SW-PC, | + | | or 0 if the SW-PC has no recorded events. This | | | field is an unsigned 4-byte integer. | - | Instance ID | A 2-byte unsigned integer indicating the length in | - | Length | bytes of the Instance ID field. | - | Instance ID | A string containing the Instance ID of a given tag | - | | instance. The exact value of this field depends on | - | | the party that provides this SWID tag. This field | - | | value MUST be normalized to Network Unicode | + | | | + | Data Model | A 1-byte unsigned integer containing an identifier | + | Type | number from the Software Data Model IANA table | + | | that identifies the data model of the reported | + | | record. | + | | | + | Record ID | A 2-byte unsigned integer indicating the length in | + | Length | bytes of the Record ID field. | + | | | + | Record ID | A string containing the Record Identifier value | + | | from a software inventory evidence record. This | + | | field value MUST be normalized to Network Unicode | | | format, as described in Section 4.7. This string | | | MUST NOT be NULL terminated. | - | Tag Len | This is a 4-byte unsigned integer indicating the | - | | length of the following SWID tag in bytes. | - | Tag | A SWID tag as a string. In the case where the | - | | original SWID tag is not expressed using UTF-8 | - | | encoding, it MUST be converted and normalized to | + | | | + | Record Len | This is a 4-byte unsigned integer indicating the | + | | length of the following software inventory | + | | evidence record in bytes. | + | | | + | 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.7. However, in the case where the original SWID | - | | tag is expressed using UTF-8 encoding, the SWID | - | | tag MUST be copied to this field without | - | | modification, even if the original SWID tag does | - | | not conform fully to Network Unicode format. This | - | | string MUST NOT be NULL terminated. | + | | 4.7. This string MUST NOT be NULL terminated. | +--------------+----------------------------------------------------+ - Table 8: SWID Tag Inventory Attribute Fields + Table 8: Software Inventory Attribute Fields - The SWID Tag Inventory attribute contains some number of SWID tags. - Given that the size of tags 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 SWID Tag Inventory attributes to targeted - requests to avoid over-burdening the network unnecessarily. + The Software Inventory attribute contains some number of software + inventory evidence records. 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. - Note that the Instance ID is included in this attribute along with - the tag. This is because, unlike the Tag Creator RegID and Unique ID - fields that make up the tag identifier, the Instance ID cannot always - be extracted from fields within a SWID tag. As such, in order to be - able to associate a tag file with a given tag identifier instance, it - is necessary to include the Instance ID value in the attribute. + 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. - When copying a SWID tag into the Tag field, conversion and - normalization of the character encoding happens if and only if the - source SWID tag does not use UTF-8 encoding. In the case where the - source SWID tag is expressed using an encoding other than UTF-8, then - that tag MUST be converted and normalized to use Network Unicode - format prior to its inclusion in the tag field. However, in the case - where the source SWID tag is expressed in UTF-8, the source tag MUST - be copied to the Tag field without conversion or normalization. This - is true even if the source SWID tag uses UTF-8 but is not fully - conformant with Network Unicode format. This is done because any - conversion or normalization of a full SWID tag is likely to break any - cryptographic signatures included in the SWID tag. As such, - conversion only happens to ensure a SWID tag is readable for the - recipient (by ensuring it always uses UTF-8), but is otherwise - avoided if possible. Recipients of this attribute can always be - assured that the Tag field uses UTF-8 format, but cannot depend on - full Network Unicode format compliance. +4.13. Software Events -4.13. SWID Tag Events + A SW-PC sends this attribute to a SW-PV to convey a list of events + where the affected software inventory evidence records are expressed + using full 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. - A SWID-PC sends this attribute to a SWID-PV to convey a list of - events where the affected SWID tags are expressed using full tags. A - SWID-PV MUST NOT send this attribute. The SWID-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 SWID Request attribute where the - Result Type is 0 and the Earliest EID is non-zero. + Note that each record is reported along with its Record Identifier. + This can be used to link reported records to reported Software + Identifier + Record Identifier pairs. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Event Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID Copy / Subscription ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -3079,915 +2699,963 @@ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Action | Instance ID Length |Instance ID (v)| + | Action |Data Model Type| Record ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Tag Len | + | Record Identifier (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Tag (Variable) | + | Record Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Record (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 11: SWID Tag Events Attribute + Figure 11: Software Events Attribute +--------------+----------------------------------------------------+ | Field | Description | +--------------+----------------------------------------------------+ | Flags: Bit 0 | In the case that this attribute is sent in | | - | fulfillment of a subscription this bit MUST be set | | Subscription | (1). In the case that this attribute is a direct | - | Fulfillment | response to a SWID Request, this bit MUST be unset | + | Fulfillment | response to a SW Request, this bit MUST be unset | | | (0). | + | | | | Flags: Bit | Reserved for future use. This field MUST be set to | | 1-7 - | zero on transmission and ignored upon reception. | | Reserved | | + | | | | Event Count | The number of events being reported in this | | | attribute. This field is a 3-byte unsigned | - | | integer. The EID, Timestamp, Action, Instance ID | - | | Length, Instance ID, Tag Length, and Tag fields | - | | are repeated, in order, the number of times | - | | indicated in this field. (An instance of these | - | | five fields is referred to as an "event record" in | - | | this attribute. Thus the Event Count field | - | | indicates the number of event records.) This field | - | | value MAY be 0, in which case there are no | - | | instances of these fields. | + | | integer. The EID, Timestamp, Action, Data Model | + | | Type, Record Identifier Length, Record Identifier, | + | | Record Length, and Record fields are repeated, in | + | | order, the number of times indicated in this | + | | field. (An instance of these fields is referred to | + | | as an "event record" in this attribute. Thus the | + | | Event Count field indicates the number of event | + | | records.) This field value MAY be 0, in which case | + | | there are no instances of these fields. | + | | | | Request ID | In the case where this attribute is in direct | - | Copy / | response to a SWID Request attribute from a SWID- | - | Subscription | PV, this field MUST contain an exact copy of the | - | ID | Request ID field from that SWID Request. In the | + | 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. | + | | | | EID Epoch | The EID Epoch of the Last EID value. This field is | | | an unsigned 4-byte integer. | - | Last EID | The EID of the last event recorded by the SWID-PC, | - | | or 0 if the SWID-PC has no recorded events. This | - | | field contains the EID of the SWID-PC's last | + | | | + | Last EID | The EID of the last event recorded by the SW-PC, | + | | or 0 if the SW-PC has no recorded events. This | + | | field contains the EID of the SW-PC's last | | | recorded change event (which might or might not be | | | included as an event record in this attribute). | + | | | | Last | The EID of the last event record that was | | Consulted | consulted when generating the event record list | | EID | included in this attribute. This is different from | | | the Last EID field value if and only if this | | | attribute is conveying a partial list of event | - | | records. See Section 3.6.4 for more on partial | + | | records. See Section 3.5.4 for more on partial | | | list of event records. | + | | | | EID | The EID of the event in this event record. | + | | | | Timestamp | The timestamp associated with the event in this | - | | event record. This timestamps is the SWID-PC's | - | | best understanding of when the given event | - | | occurred. Note that this timestamp might be an | - | | estimate. The Timestamp date and time MUST be | - | | represented as an RFC 3339 [5] compliant ASCII | - | | string in Coordinated Universal Time (UTC) time | - | | with the additional restrictions that the 'T' | - | | delimiter and the 'Z' suffix MUST be capitalized | - | | and fractional seconds (time-secfrac) MUST NOT be | - | | included. This field conforms to the date-time | - | | ABNF production from section 5.6 of RFC 3339 | - | | [RFC3339] with the above restrictions. Leap | - | | seconds are permitted and SWID-PVs MUST support | - | | them. The Timestamp string MUST NOT be NULL | - | | terminated or padded in any way. The length of | - | | this field is always 20 octets. | + | | event record. This timestamp is the SW-PC's best | + | | understanding of when the given event occurred. | + | | Note that this timestamp might be an estimate. | + | | The Timestamp date and time MUST be represented as | + | | an RFC 3339 [5] compliant ASCII string in | + | | Coordinated Universal Time (UTC) time with the | + | | additional restrictions that the 'T' delimiter and | + | | the 'Z' suffix MUST be capitalized and fractional | + | | seconds (time-secfrac) MUST NOT be included. This | + | | field conforms to the date-time ABNF production | + | | from section 5.6 of RFC 3339 [RFC3339] with the | + | | above restrictions. Leap seconds are permitted | + | | and SW-PVs MUST support them. The Timestamp | + | | string MUST NOT be NULL terminated or padded in | + | | any way. The length of this field is always 20 | + | | octets. | + | | | | Action | The type of event that is recorded in this event | | | record. Possible values are: 1 = CREATION - the | - | | addition of a tag to the endpoint's SWID tag | - | | collection; 2 = DELETION - the removal of a tag | - | | from the endpoint's SWID tag collection; 3 = | - | | ALTERATION - There was an alteration to a tag file | - | | within the endpoint's tag collection. All other | - | | values are reserved for future use and MUST NOT be | - | | used when sending attributes. In the case where a | - | | SWID-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. | - | Instance ID | A 2-byte unsigned integer indicating the length in | - | Length | bytes of the Instance ID field. | - | Instance ID | A string containing the Instance ID of a given tag | - | | instance. The exact value of this field depends on | - | | the party that provides this SWID tag. This field | - | | value MUST be normalized to Network Unicode | + | | 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 = ALTERATION - | + | | There was an alteration to a record within the | + | | endpoint's Software Inventory Evidence Collection. | + | | All other values are 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. | + | | | + | Data Model | A 1-byte unsigned integer containing an identifier | + | Type | number from the Software Data Model IANA table | + | | that identifies the data model of the reported | + | | record. | + | | | + | Record ID | A 2-byte unsigned integer indicating the length in | + | Length | bytes of the Record ID field. | + | | | + | Record ID | A string containing the Record Identifier value | + | | from a software inventory evidence record. This | + | | field value MUST be normalized to Network Unicode | | | format, as described in Section 4.7. This string | | | MUST NOT be NULL terminated. | - | Tag Len | This is a 4-byte unsigned integer indicating the | - | | length of the following SWID tag in bytes. | - | Tag | A SWID tag as a string. In the case where the | - | | original SWID tag is not expressed using UTF-8 | - | | encoding, it MUST be converted and normalized to | + | | | + | Record Len | This is a 4-byte unsigned integer indicating the | + | | length of the following record in bytes. | + | | | + | 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.7. However, in the case where the original SWID | - | | tag is expressed using UTF-8 encoding, the SWID | - | | tag MUST be copied to this field without | - | | modification, even if the original SWID tag does | - | | not conform fully to Network Unicode format. This | - | | string MUST NOT be NULL terminated. | + | | 4.7. This string MUST NOT be NULL terminated. | +--------------+----------------------------------------------------+ - Table 9: SWID Tag Events Attribute Fields + Table 9: 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 SWID - Tag Inventory attribute, a SWID Tag 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 SWID - Request attributes only request full tags be sent (Result Type set to - 0) in a targeted request, thus constraining the response just to tags - that match a given set of tag identifiers. + 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 SWID Tag Identifier Events Attribute, this attribute MUST + As with the Software Identifier Events Attribute, this attribute MUST only contain event records with EIDs coming from the current EID - Epoch of the SWID-PC. + Epoch of the SW-PC. - As with the SWID Tag Inventory Attribute, the SWID-PC MUST perform - conversion and normalization of the SWID tag itself in the case where - the source SWID tag is expressed using an encoding other than UTF-8, - and MUST NOT perform conversion or normalization of the SWID tag - itself in the case where the source SWID tag is expressed using UTF- - 8. + As with the Software Inventory Attribute, the SW-PC MUST perform + conversion and normalization of the record. 4.14. Subscription Status Request - A SWID-PV sends this attribute to a SWID-PC to request a list of - active subscriptions for which the requesting SWID-PV is the - subscriber. A SWID-PC MUST NOT send this attribute. + 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 SWID-PC MUST respond to this attribute by sending a Subscription + A SW-PC MUST respond to this attribute by sending a Subscription Status Response attribute (or a PA-TNC Error attribute if it is unable to correctly provide a response). 4.15. Subscription Status Response - A SWID-PC sends this attribute to a SWID-P to report the list of - active subscriptions for which the receiving SWID-PV is the - subscriber. A SWID-PV MUST NOT send this attribute. + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Tag ID Count | + | Flags | Software Identifier Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Earliest EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Tag Creator Length | Tag Creator (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Unique Software ID Length |Unique Software ID (var length)| + | Software Identifier Length | Software ID (var length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Subscription Status Response Attribute - +------------------+------------------------------------------------+ + +-----------------+-------------------------------------------------+ | Field | Description | - +------------------+------------------------------------------------+ - | Flags: Bit 0-7 - | Reserved for future use. This field MUST be | - | Reserved | set to zero on transmission and ignored upon | + +-----------------+-------------------------------------------------+ + | Flags: Bit 0-7 | Reserved for future use. This field MUST be set | + | - Reserved | to zero on transmission and ignored upon | | | reception. | - | Subscription | The number of subscription records that | - | Record Count | follow. This field is a 3-byte unsigned | - | | integer. The Flags, Tag ID Count, Request ID, | - | | Earliest EID, Tag Creator Length, Tag Creator, | - | | Unique Software ID Length, and Unique Software | - | | ID 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 | + | | | + | Subscription | The number of subscription records that follow. | + | Record Count | This field is a 3-byte unsigned integer. The | + | | Flags, Software Identifier Count, Request ID, | + | | Earliest EID, Software Identifier Length, and | + | | Software ID 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. | - | Flags, Tag ID | For each active subscription, these fields | - | Count, Request | contain an exact copy of the fields with the | - | ID, Earliest | same name as provided in the subscription's | - | EID, Tag Creator | establishing request. | - | Length, Tag | | - | Creator, Unique | | - | Software ID | | + | | | + | Flags, Software | For each active subscription, these fields | + | 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 | | - | Unique Software | | - | ID | | - +------------------+------------------------------------------------+ + | Software ID | | + +-----------------+-------------------------------------------------+ Table 10: 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 SWID-PC MUST use the requester's - Connection ID and, if available, its Posture Validator ID to - determine which subscriptions are associated with the requester. + As described in Section 3.6.2, the SW-PC MUST use the requester's + Connection ID and its Posture Validator ID to determine which + subscriptions are associated with the requester. - A SWID-PC MUST send a Subscription Status Response attribute in + A SW-PC MUST send a Subscription Status Response attribute in response to a Subscription Status Request attribute. The only - exception to this is if the SWID-PC experiences an error condition - that prevents it from correctly populating the Subscription Status + exception to this is if the SW-PC experiences an error condition that + prevents it from correctly populating the Subscription Status Response attribute, in which case it MUST respond with a PA-TNC Error attribute appropriate to the type of error experienced. If there are no active subscriptions associated with the requesting party, the Subscription Status Response attribute will consist of its Status Flags field, a Subscription Record Count field with a value of 0, and no additional fields. Each subscription record included in a Subscription Status Response - attribute duplicates the fields of a SWID Request attribute that was + attribute duplicates the fields of a SW Request attribute that was the establishing request of a subscription. Note that the Request ID field in the record captures the Subscription ID associated with the given subscription record (since the Subscription ID is the same as the Request ID of the establishing request). Note also that if the - establishing request is targeted, then its Tag ID Count field will be - non-zero and, within that subscription record, the Tag Creator - Length, Tag Creator, Unique Software ID Length, and Unique Software - ID fields are repeated, in order, the number of times indicated in - the Tag ID Count field. As such, each subscription record can be - different sizes. Likewise, if the establishing request is not - targeted (Tag ID Count field is 0), the subscription record has no - Tag Creator Length, Tag Creator, Unique Software ID Length, or Unique - Software ID fields. + establishing request is targeted, then its Record Count field will be + non-zero and, within that subscription record, the Record Namespace + Length, Record Namespace, Record ID Length, and Record ID fields are + repeated, in order, the number of times indicated in the Record Count + field. As such, each subscription record can be different sizes. If + the establishing request is not targeted (Record Count field is 0), + the subscription record has no Record Namespace Length, Record + Namespace, Record ID Length, or Record ID fields. - When a SWID-PV compares the information received in a Subscription + When a SW-PV compares the information received in a Subscription Status Response to its own records of active subscriptions it should - be aware that the SWID-PC might be unable to distinguish this SWID-PV - from other SWID-PVs on the same NEA Server. As a result, it is - possible that the SWID-PC will report more subscription records than - the SWID-PV recognizes. For this reason, SWID-PVs SHOULD NOT + 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.16. PA-TNC Error as Used by SWID Message and Attributes for PA-TNC +4.16. PA-TNC Error as Used by Software 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 SWID + also be sent in response to error conditions specific to the Software Message and Attributes for PA-TNC exchange. The latter case utilizes error codes defined below. - A PA-TNC Error attribute is sent instead of a SWID Response attribute - due to factors that prevent the reliable creation of a SWID Response. - As such, a SWID-PC MUST NOT send both a PA-TNC Error attribute and a - SWID Response attribute in response to a single SWID Request - attribute. + A PA-TNC Error attribute is sent instead of a SW Response attribute + due to factors that prevent the reliable creation of a SW Response. + 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 11 lists the Error Code values for the PA-TNC Error attribute - specific to the SWID Message and Attributes for PA-TNC exchange. In - all of these cases, the Error Code Vendor ID field MUST be set to + specific to the Software Message and Attributes for PA-TNC exchange. + 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 SWID Message and Attributes for PA-TNC + Note that a message with a Software 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, the SWID + 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 SWID-PC MUST use the + 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 | SWID_ERROR. This indicates a fatal error | + | 0x00000020 | 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 SWID Attributes. The | + | | processing of SW Attributes. The | | | Description field SHOULD contain | | | additional diagnostic information. | - | 0x00000021 | SWID_SUBSCRIPTION_DENIED_ERROR. This | - | | indicates that the SWID-PC denied the | - | | SWID-PV's request to establish a | - | | subscription. The Description field | - | | SHOULD contain additional diagnostic | - | | information. | - | 0x00000022 | SWID_RESPONSE_TOO_LARGE_ERROR. This | - | | indicates that the SWID-PC's response to | - | | the SWID-PV's request was too large to be | + | | | + | 0x00000021 | 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 | + | | 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 SWID-PC (see | + | | response supported by the SW-PC (see | | | Section 4.16.2). The Description field | | | SHOULD contain additional diagnostic | | | information. | - | 0x00000023 | SWID_SUBSCRIPTION_FULFILLMENT_ERROR. This | - | | indicates that the SWID-PC experienced an | + | | | + | 0x00000023 | 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 | - | | SWID-PC experienced. The SWID-PC and | - | | SWID-PV MUST treat the identified | - | | subscription as cancelled. | - | 0x00000024 | SWID_SUBSCRIPTION_ID_REUSE_ERROR. This | - | | indicates that the SWID-PC received a | - | | SWID Request from a given SWID-PV where | - | | the Request ID of that SWID Request is | + | | 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 | + | | 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 SWID-PV. | + | | 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 SWID | - | | 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 | + | | for use by future revisions of the | + | | Software 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 11: PA-TNC Error Codes for SWID Message and Attributes for PA- - TNC + Table 11: PA-TNC Error Codes for Software Message and Attributes for + PA-TNC The following subsections describe the structures present in the Error Information fields. -4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR and - SWID_SUBSCRIPTION_ID_REUSE_ERROR Information +4.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and + SW_SUBSCRIPTION_ID_REUSE_ERROR Information - The SWID_ERROR error code indicates that the sender (the SWID-PC) has - encountered an error related to the processing of a SWID Request - attribute but which is not covered by more specific SWID error codes. - The SWID_SUBSCRIPTION_DENIED_ERROR is used when the SWID-PV requests - to establish a subscription or clear all subscriptions from the given - SWID-PV, but the SWID-PC is unable or unwilling to comply with this - request. The SWID_SUBSCRIPTION_ID_REUSE_ERROR is used when the SWID- - PC receives a SWID Request whose Request ID duplicates a Subscription - ID of an active subscription with the request's sender. All of these + 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 + of an active subscription with the request's sender. All of these error codes use the following error information structure. 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 ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Description (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 13: SWID Error, Subscription Error, and Subscription ID Reuse + Figure 13: SW Error, Subscription Error, and Subscription ID Reuse Information +--------------+----------------------------------------------------+ | Field | Description | +--------------+----------------------------------------------------+ | Copy of | In the case that this error condition is generated | - | Request ID / | in direct response to a SWID Request attribute, | - | Subscription | this field MUST contain an exact copy of the | - | ID | Request ID field in the SWID 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. (This is only | - | | possible if the error code is SWID_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 | - | | SWID_SUBSCRIPTION_FULFILLMENT_ERROR, as described | - | | in Section 4.16.3. | + | Request ID / | in direct response to a SW Request attribute, 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. (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.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 12: SWID Error, Subscription Error, and Subscription ID Reuse + Table 12: SW Error, Subscription Error, and Subscription ID Reuse Information Fields - This error information structure is used with SWID_ERROR, - SWID_SUBSCRIPTION_DENIED_ERROR, and SWID_SUBSCRIPTION_ID_REUSE_ERROR - status codes to identify the SWID Request attribute that precipitated + 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 SWID-PC MAY encode machine- + contains text describing the error. The SW-PC MAY encode machine- interpretable information in this field, but SHOULD also include a - human-readable description of the error, since the receiving SWID-PV - might not recognize the SWID-PC's encoded information. + human-readable description of the error, since the receiving SW-PV + might not recognize the SW-PC's encoded information. -4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information +4.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information - The SWID_RESPONSE_TOO_LARGE_ERROR error code indicates that a - response generated by a SWID-PC in response to a SWID-PV's SWID - Request attribute was too large to send. + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Allowed Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Description (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 14: SWID Response Too Large Error Information + Figure 14: SW Response Too Large Error Information +--------------+----------------------------------------------------+ | Field | Description | +--------------+----------------------------------------------------+ | Copy of | In the case that the attribute in question is | - | Request ID / | generated in direct response to a SWID Request, | - | Subscription | this field MUST contain an exact copy of the | - | ID | Request ID field in the SWID 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 this | - | | case, the SWID_RESPONSE_TOO_LARGE_ERROR appears as | - | | a sub-error for a | - | | SWID_SUBSCRIPTION_FULFILLMENT_ERROR, as described | - | | in Section 4.16.3. | + | 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.16.3. | + | | | | Maximum | This field MUST contain an unsigned integer | | Allowed Size | indicating the largest permissible size, in bytes, | - | | of SWID Attribute that the SWID-PC is currently | - | | willing to send in response to a SWID Request | + | | 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 13: SWID Response Too Large Error Information Fields + Table 13: SW Response Too Large Error Information Fields - This error structure is used with the SWID_RESPONSE_TOO_LARGE_ERROR - status code to identify the SWID Request attribute that precipitated + 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 SWID-PC is willing to - send in response to a SWID Request under the current circumstances. - - Note that under other circumstances, the SWID-PC might be willing to - return larger 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 SWID_ERROR and - SWID_SUBSCRIPTION_DENIED_ERROR information structure. + 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.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information +4.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information - The SWID_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the - SWID-PC encountered an error while fulfilling a subscription. The + 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subscription ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub Error Code Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub Error Information (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 15: SWID Subscription Fulfillment Error Information + Figure 15: SW Subscription Fulfillment Error Information +--------------+----------------------------------------------------+ | Field | Description | +--------------+----------------------------------------------------+ | Subscription | This field MUST contain the Subscription ID of the | | ID | subscription whose fulfillment caused this error. | + | | | | Reserved | This field MUST contain the value of the Reserved | | | 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 | | Code Vendor | Code Vendor ID field of a PA-TNC Error attribute | | ID | that describes the error condition encountered | | | during subscription processing. | + | | | | Sub Error | This field MUST contain the value of the Error | | 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 14: SWID Subscription Fulfillment Error Information Fields + Table 14: SW Subscription Fulfillment Error Information Fields This error structure is used with the - SWID_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 SWID- - PC encountered while fulfilling the given subscription. The sub- - error MUST NOT have an error code of - SWID_SUBSCRIPTION_FULFILLMENT_ERROR. + 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 SWID-PC sending a PA-TNC Error attribute with this error code, - and the SWID-PV receiving it, MUST treat the subscription identified - by the Subscription ID field as cancelled. All other subscriptions - are unaffected. + 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. Security Considerations +5. Supported Data Models + + Software 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 + Message and Attributes for PA-TNC, and will be referenced by + extensions to the Software Data Model IANA table. + +5.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. [SWID] 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 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 + XML + + TBD + + Don't violate the specification + + Use your own Tag Creator RegID or the Unknown Tag Creator RegID. Do + not use some other party's RegID, especially not the RegID of the + software author if you are not the author. + +5.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID + Tags + + TBD + + Use combination of Tag Creator RegID and Unique ID fields. + Specifically, format should be 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 concatination 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 + + 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 2015 SWID Tags using + XML + + TBD + + Don't violate the specification + + Use your own Tag Creator RegID or the Unknown Tag Creator RegID. Do + not use some other party's RegID, especially not the RegID of the + software author if you are not the author. + +5.2.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID + Tags + + TBD + + Use combination of Tag Creator RegID and Unique ID fields. + Specifically, format should be 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 concatination of the Tag + Creator RegID and the Unique ID from the tag, without any connecting + character or whitespace. + +6. Security Considerations This section discusses some of the security threats facing Posture - Collectors and Posture Validators that implement the SWID Message and - Attributes for PA-TNC protocol. This section primarily notes + Collectors and Posture Validators that implement the Software 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. -5.1. Evidentiary Value of SWID Tags - - A SWID tag is only indirect evidence as to the installation of a - piece of software on an endpoint. While the ideal is for the - presence of a tag to correspond to the presence of the corresponding - software, such a correlation hinges on software that accurately - manages individual tags as software is added and removed. - Utilization of the tests included in a tag's package_footprint and/or - validation elements can provide more direct evidence of software - presence, but this information might not be present in many tags and, - because of its limited support, this version of the SWID Message and - Attributes for PA-TNC specification does not support use of these - flags. Tags can include cryptographic signatures of some or all of - their fields, which can enable detection of field modification. This - is extremely useful in ensuring that sensitive fields are not - modified maliciously. However, the use of cryptographic signatures - is not required in SWID tags, and even when utilized, not all fields - will necessarily be protected by signatures. For these reasons, it - is important to treat SWID tags as evidence rather than proof of - software presence. - -5.2. Integrity of the SWID Tag Collection - - On a related note, while some systems might protect SWID tags against - modification, on others there might be very few restrictions on who - can add or delete tags on an endpoint. This can mean that a - malicious party has relatively free rein to add and remove tags with - the goal of obscuring the actual software inventory of the endpoint. - As noted above, signatures on tag files can keep tag modification - from going undetected, but an attacker can simply delete the signed - tag and replace it with a modified tag that lacks the associated - signature. In fact, even a signed tag can be added by an adversary - and go undetected if the tag does not include fields to verify - software presence, such as the package_footprint or validation - element +6.1. Evidentiary Value of Software Inventory Evidence Records - There is little a SWID-PC can do to prevent unauthorized - modifications of the endpoint's SWID tag from occurring if the local - system does not provide protections for tags. Instead, the SWID-PV - and NEA Server need to operate with an awareness that this type of - modification can occur. The use of mechanisms to corroborate - software inventories can help detect malicious modification of an - endpoint's SWID tag collection. Likewise, the SWID-PV can look for - odd behavior such as the deletion and rapid re-installation of a - particular tag, especially the replacement of a signed tag with an - unsigned one. Parties that use SWID tags as evidence of compliance - with security policies need to be aware of the possible risks of - corruption of an endpoint's SWID tag collection. + 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 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. -5.3. Sensitivity of Collected Tags +6.2. Sensitivity of Collected Records - Tags 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 - SWID tag collection can be browsed and individual tags 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 tags simply by - inspecting other parts of the endpoint. + 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. - The situation changes when an endpoint's SWID tags are collected and - stored off of the endpoint itself, such as on a NEA Server or CMDB. - Tags represent a wealth of information about the endpoint in question - and, for an adversary who does not already have access to the - endpoint, a collection of the endpoint's tags might provide many - details that are useful for mounting an attack. A list of the tags - associated with an endpoint reveals a list of software installed on - the endpoint. This list is very detailed, generally noting specific - versions and even patch levels, which an adversary can use to - identify vulnerable software and design efficacious attacks. + The situation changes when an endpoint's inventory records are + collected and stored off of the endpoint itself, such as on a NEA + Server or CMDB. Inventory records represent a wealth of information + about the endpoint in question and, for an adversary who does not + already have access to the endpoint, a collection of the endpoint's + inventory records might provide many details that are useful for + mounting an attack. A list of the inventory records associated with + an endpoint reveals a list of software installed on the endpoint. + This list can be very detailed, noting specific versions and even + patch levels, which an adversary can use to identify vulnerable + software and design efficacious attacks. In addition, other information might also be gleaned from a - collection of SWID tags: - - o A SWID tag might include information about where the product was - installed on a given endpoint. This can reveal details about the - file organization of that endpoint that an attacker can utilize. + collection of software inventory records: - o A SWID tag might include information about how the software was - provided to the endpoint, who in an organization signs off on the - package release, and who packaged the product for installation. + o An inventory record might include information about where the + product was installed on a given endpoint. This can reveal + details about the file organization of that endpoint that an + attacker can utilize. - This information might be used as a starting point for the - development of supply chain attacks. + o An inventory record might include information about how the + software was provided to the endpoint, who in an organization + signs off on the package release, and who packaged the product for + installation. This information might be used as a starting point + for the development of supply chain attacks. - o Events affecting SWID tags are reported with timestamps indicating - when each given event occurred. This can give the attacker an - indication of how quickly an organization distributes patches and - updates, helping the attacker determine how long an attack window - might remain open. + o Events affecting inventory records are reported with timestamps + indicating when each given event occurred. This can give the + 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 tag 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 basic security - precautions. - -5.4. Integrity of Endpoint Records + 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 + basic security precautions. - SWID-PCs maintain records of detected changes to the endpoint's SWID - tag collection. These records are used to respond to a SWID-PV's - request for change events. The SWID-PV might use a list of reported - events to update its understanding of the endpoint's SWID tag - collection without needing to receive a full inventory report from - the SWID-PC. For this reason, preserving the integrity of the SWID- - PC's record of events is extremely important. If an attacker - modifies the SWID-PC's record of changes to the endpoint's SWID tag - collection, this might cause the SWID-PV's understanding of the - endpoint's SWID tag collection to differ from its actual state. - Results might include leading the SWID-PV to believe that absent - software was present, that present software was absent, that patches - have been installed even if this is not the case, or to be unaware of - other changes to SWID tags. As such, the SWID-PC MUST take steps to - protect the integrity of its event record. +6.3. Integrity of Endpoint Records - In addition, sometimes a SWID-PC captures metadata about existing - tags or even creates copies of whole tags. Metadata might include - hash values of tag files or records of the last time a particular tag - file was modified, while whole tags might be preserved to record tags - that were deleted from the endpoint's SWID tag collection. If an - attacker is able to corrupt or modify this information, they might - cause a SWID-PC to fail to detect certain change events, incorrectly - report information, or otherwise fail to correctly fulfill SWID-PV - requests. As such, this additional information about SWID tags, if - collected, MUST be integrity protected. + 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 + cause the SW-PV's understanding of the endpoint's Software Inventory + Evidence Collection to differ from its actual state. Results might + include leading the SW-PV to believe that absent software was + present, that present software was absent, that patches have been + installed even if this is not the case, or to be unaware of other + changes to Software Inventory Evidence Records. As such, the SW-PC + MUST take steps to protect the integrity of its event records. - Finally, records of established SWID-PV subscriptions also require + In addition, records of established SW-PV subscriptions also require protection against manipulation or corruption. If an attacker is able to modify or delete records of an established subscription by a - SWID-PV, the SWID-PC might fail to correctly fulfill this - subscription. The SWID-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 SWID-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 SWID-PC MUST protect - the integrity of subscription records. - -5.5. SWID-PC Access Permissions - - A SWID-PC requires sufficient permissions to locate and read SWID - tags on the endpoint that constitute the endpoint's SWID tag - collection, and 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 SWID-PC (or software that - incorporates a SWID-PC as one of its capabilities) additional - permissions might be required by the SWID-PC software. The SWID-PC - SHOULD NOT be granted permissions beyond what it needs in order to - fulfill its duties. - -5.6. Sanitization of Tag Fields - - In most cases there is no constraint on an endpoint as to who can add - tags. This open model allows applications that run in user space to - register tags as easily as more privileged applications. However, - this also means that any tool reading an endpoint's tags needs to - treat these tags as un-vetted input and employ appropriate - safeguards. In particular, tools that read SWID tags, including - SWID-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 tag. + 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. - Fields of a SWID tag that change the SWID-PC's behavior, alter system - state, or execute code need to be handled with special care. In - particular, the validation element, which provides a command line - that can nominally be executed to validate the tag's correctness, can - be utilized by an attacker to point to a malicious executable. To - defend against this, SWID-PCs MUST NOT execute an application - indicated by a validation element unless the element is signed and - the SWID-PC has determined that the signature is intact and trusted. +6.4. SW-PC Access Permissions -5.7. Tag Library Poisoning + 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. - It can be useful for a SWID-PV to have access to a library of tags. - If the SWID-PV receives a list of tag identifier instances, it can - consult this library and collect full tags corresponding to those - identifiers. Assuming it does not need access to installation- - specific information, it can perform calculations on these full tags - as if it had received them from a SWID-PC. For example, it can use - this library to derive software names, publishers, and version by - finding the tag that corresponds to the given tag identifier value. +6.5. Sanitization of Record Fields - If the SWID-PV keeps a collection of full SWID tags for matching - against tag identifiers, there might be a temptation to add any - previously unknown tags that a SWID-PC might report to this library - automatically. In fact, this behavior can pose a security risk. If - the endpoint has been compromised and the tag manipulated on that - endpoint, the tag that it provides to the SWID-PV might be misleading - with regard to the software associated with this tag. If the SWID-PV - automatically adds this corrupted tag to its library, not only will - the computations with the compromised endpoint be affected, but - computations with other endpoints that provide tag identifier - instances that map to the corrupted tag will also be affected. - Instead, if the SWID-PV does make use of a tag library, it is - recommended to only populate that library with tags retrieved from a - trusted source, or at least to segregate collections of reported tags - by endpoint, so corrupted tags on one endpoint will not affect tag - computations involving other endpoints. In general, tags retrieved - from a trusted source and signed by a trusted authority are likely be - safe for inclusion in a tag library. + 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. -5.8. PA-TNC Security Threats +6.6. PA-TNC Security Threats - In addition to the aforementioned considerations the SWID Message and - Attributes for PA-TNC protocol is subject to the same security + In addition to the aforementioned considerations the Software 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. -6. Privacy Considerations +7. Privacy Considerations - As noted in Section 5.3, if an adversary can gain an understanding of + As noted in Section 6.2, if an adversary can gain an understanding of the software installed on an endpoint, they can utilize this to 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 tags. For similar reasons, it - is advisable that an endpoint only send tags to a NEA Server that is - authorized to receive this information and that can be trusted to - safeguard this information after collection. + 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. -7. Relationship to Other Specifications +8. 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, SWID + 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 they are responsible for ensuring that attributes defined under this specification are delivered reliably, securely, and to the appropriate party. It is important to note that the Product Information, Numeric Version, and String Version attributes defined in the PA-TNC specification [RFC5792] are also meant to convey information about 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 SWID - 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. Moreover, because this - specification makes use of the well-defined structures in SWID tags, - it is able to convey information that is more concise (by making use - of specific identifier fields instead of sending the whole SWID tag) - and/or more comprehensive (as the SWID structures contain many more - fields than expressible in PA-TNC). As such, this specification - provides important capabilities not present in the PA-TNC - specification. + specific queries about specific classes of products, while the + Software 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. -8. IANA Considerations +9. 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. -8.1. Registry for PA-TNC Attribute Types +9.1. Registry for PA-TNC Attribute Types Section 4.6 of this specification defines several new PA-TNC attributes. The following values are added to the registry for PA- TNC Attribute Types defined in the PA-TNC specification. Note that Table 4 in Section 4.6 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 4 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 | SWID Request | SWID Message and | + +-----+---------+---------------------+-----------------------------+ + | 0 | 17 | SW Request | Software Message and | | | | | Attributes for PA-TNC | - | 0 | 18 | SWID Tag Identifier | SWID Message and | + | | | | | + | 0 | 18 | Software Identifier | Software Message and | | | | Inventory | Attributes for PA-TNC | - | 0 | 19 | SWID Tag Identifier | SWID Message and | + | | | | | + | 0 | 19 | Software Identifier | Software Message and | | | | Events | Attributes for PA-TNC | - | 0 | 20 | SWID Tag Inventory | SWID Message and | + | | | | | + | 0 | 20 | Software Inventory | Software Message and | | | | | Attributes for PA-TNC | - | 0 | 21 | SWID Tag Events | SWID Message and | + | | | | | + | 0 | 21 | Software Events | Software Message and | | | | | Attributes for PA-TNC | - | 0 | 22 | Subscription Status | SWID Message and | + | | | | | + | 0 | 22 | Subscription Status | Software Message and | | | | Request | Attributes for PA-TNC | - | 0 | 23 | Subscription Status | SWID Message and | + | | | | | + | 0 | 23 | Subscription Status | Software Message and | | | | Response | Attributes for PA-TNC | - | 0 | 24 | Subscription Status | SWID Message and | + | | | | | + | 0 | 24 | Subscription Status | Software Message and | | | | Response | Attributes for PA-TNC | - | 0 | 25 - 31 | Reserved for future | SWID Message and | + | | | | | + | 0 | 25 - 31 | Reserved for future | Software Message and | | | | use | Attributes for PA-TNC | - +-----+---------+----------------------+----------------------------+ + +-----+---------+---------------------+-----------------------------+ -8.2. Registry for PA-TNC Error Codes +9.2. Registry for PA-TNC Error Codes Section 4.16 of this specification defines several new PA-TNC Error Codes. The following values are added to the registry for PA-TNC Error Codes defined in the PA-TNC specification. Note that Table 11 - in Section 4.16 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. + in Section 4.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. - +----+---------+------------------------------------+---------------+ - | PE | Integer | Name | Defining | - | N | | | Specification | - +----+---------+------------------------------------+---------------+ - | 0 | 32 | SWID_ERROR | SWID Message | - | | | | and | + +-----+---------+-----------------------------------+---------------+ + | PEN | Integer | Name | Defining | + | | | | Specification | + +-----+---------+-----------------------------------+---------------+ + | 0 | 32 | SW_ERROR | Software | + | | | | Message and | | | | | Attributes | | | | | for PA-TNC | - | 0 | 33 | SWID_SUBSCRIPTION_DENIED_ERROR | SWID Message | - | | | | and | + | | | | | + | 0 | 33 | SW_SUBSCRIPTION_DENIED_ERROR | Software | + | | | | Message and | | | | | Attributes | | | | | for PA-TNC | - | 0 | 34 | SWID_RESPONSE_TOO_LARGE_ERROR | SWID Message | - | | | | and | + | | | | | + | 0 | 34 | SW_RESPONSE_TOO_LARGE_ERROR | Software | + | | | | Message and | | | | | Attributes | | | | | for PA-TNC | - | 0 | 35 | SWID_SUBSCRIPTION_FULFILLMENT_ERRO | SWID Message | - | | | R | and | + | | | | | + | 0 | 35 | SW_SUBSCRIPTION_FULFILLMENT_ERROR | Software | + | | | | Message and | | | | | Attributes | | | | | for PA-TNC | - | 0 | 36 | SWID_SUBSCRIPTION_ID_REUSE_ERROR | SWID Message | - | | | | and | + | | | | | + | 0 | 36 | SW_SUBSCRIPTION_ID_REUSE_ERROR | Software | + | | | | Message and | | | | | Attributes | | | | | for PA-TNC | - | 0 | 37-47 | Reserved for future use | SWID Message | - | | | | and | + | | | | | + | 0 | 37-47 | Reserved for future use | Software | + | | | | Message and | | | | | Attributes | | | | | for PA-TNC | - +----+---------+------------------------------------+---------------+ + +-----+---------+-----------------------------------+---------------+ -8.3. Registry for PA Subtypes +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 | SWID | SWID Message and Attributes for | + +-----+---------+-------------+-------------------------------------+ + | 0 | 9 | SW | Software Message and Attributes for | | | | Attributes | PA-TNC | - +-----+---------+----------------+----------------------------------+ + +-----+---------+-------------+-------------------------------------+ -9. References -9.1. Normative References +9.4. Registry for Software Data Models + + TBD + +10. References + +10.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, . @@ -4003,21 +3671,21 @@ [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, . [SWID] The International Organization for Standardization/ International Electrotechnical Commission, "Information Technology - Software Asset Management - Part 2: Software Identification Tag, ISO/IEC 19770-2", November 2009. -9.2. Informative References +10.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, @@ -4026,410 +3694,22 @@ [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, . -Appendix A. Examples - - This appendix includes examples of a SWID tag file and SWID - attributes. All examples represent fictional content. Examples are - provided using the 2009 release of the ISO/IEC SWID specification. - -A.1. A Simple SWID Tag - - Figure 16 shows an example SWID tag for a fictional software product - called SomeApp created by Vendor Inc. This example includes only the - required SWID tag fields. This tag is for version 2.3, build 12 of - the product. - - 1] - 2] - 5] - 6] true - 7] - 8] SomeApp - 9] - 10] 2.3 r12 - 11] - 12] 2 - 13] 3 - 14] 12 - 15] 0 - 16] - 17] - 18] - 19] Vendor Inc. - 20] regid.2013-06.com.vendor - 21] - 22] - 23] Vendor Inc. - 24] regid.2013-06.com.vendor - 25] - 26] - 27] - 28] someapp-21ec2020-3aea-1069-a2dd-08002b30309d - 29] - 30] - 31] regid.2013-06.com.vendor - 32] - 33] - 34] - 35] Vendor Inc. - 36] regid.2013-06.com.vendor - 37] - 38] - - Figure 16: A Simple SWID Tag - - The SWID tag described in Figure 16 is limited to only the - information required by the SWID specification [SWID]. This - information includes the following: - - o Lines 5-7: Entitlement requirement indicator. This indicates - whether some sort of entitlement (e.g., a license) is required in - order to install and/or use the software. - - o Line 8: Prose name of the product - - o Lines 9-17: Product version. This includes both a prose - expression of the full product version and the version information - broken down into distinct fields. - - o Lines 18-21: Software creator identification. This identifies the - party that created the software. This includes both a prose name - of the software creator and their "regid" value. - - o Lines 22-25: Software licensor identification. This identifies - the party that holds the rights to license others to use the - software. - - o Lines 26-33: Software unique identifier. This structure contains - the regid for the party that created this tag and a value that - party uses to uniquely identify the named software product. The - SWID Message and Attributes for PA-TNC specification uses the - values of these fields when constructing a SWID tag identifier, as - described in Section 3.3. - - o Lines 34-37: Tag creator identification. This identifies the - party that created the tag. - - Assume the SWID tag file is installed on the file system in the - following location: - - C:\ProgramData\Vendor\regid.2013-06.com.vendor_someapp-21ec2020-3aea- - 1069.swidtag - -A.2. SWID Request Attributes - - Below are hexadecimal dumps of example SWID Request attributes. SWID - Request attributes are described in more detail in Section 4.7. - -A.2.1. Simple Request - - This is a basic SWID request for inventory information - the request - is not targeted nor does the request establish a subscription on the - endpoint. The SWID Request dictates that the response be expressed - using SWID tag identifier instances. - - +-------------+-----------------------------------------------------+ - | 20 00 00 00 | Clear Subscriptions = 0 (don't clear | - | | subscriptions), Subscribe = 0 (don't establish a | - | | new subscription), Result Type = 1 (respond using | - | | SWID tag identifier instances), Tag ID Count = 0 | - | | (non-targeted request) | - | ----------- | | - | 00 00 3a 76 | Request ID = 14966 | - | ----------- | | - | 00 00 00 00 | Earliest EID = 0 (respond with inventory rather | - | | than event records) | - +-------------+-----------------------------------------------------+ - - Note that this attribute does not contain any Tag Creator Length, Tag - Creator, Unique Software ID Length, or Unique Software ID fields - because the Tag ID Count field is 0. - -A.2.2. Subscription Request for Events - - This attribute establishes a request for a new subscription that will - report new SWID change events as they occur. - - +-------------+-----------------------------------------------------+ - | 60 00 00 00 | Clear Subscriptions = 0 (don't clear | - | | subscriptions), Subscribe = 1 (establish a new | - | | subscription), Result Type = 1 (respond using SWID | - | | tag identifier instances), Tag ID Count = 0 (non- | - | | targeted request) | - | ----------- | | - | 00 00 3a 76 | Request ID = 14967 | - | ----------- | | - | 00 02 cc 3a | Earliest EID = 183354 | - +-------------+-----------------------------------------------------+ - - As before, this attribute does not contain any Tag Creator Length, - Tag Creator, Unique Software ID Length, or Unique Software ID fields - because the Tag ID Count field is 0. The immediate response to this - message (assuming no errors are encountered) will be a list of events - with EIDs that are greater than or equal to 183354. Thereafter, if - any new events are recorded, those events (and only those events) - will be sent back to the SWID-PV in fulfillment of this subscription. - (See Section 3.8.2 for more on subscription fulfillment.) - -A.2.3. Targeted Request - - This example shows a targeted request. Specifically, the request - includes two SWID tag identifiers. The attribute requests that the - corresponding full SWID tags be returned. - - +-----------------+-------------------------------------------------+ - | 00 00 00 02 | Clear Subscriptions = 0 (don't clear | - | | subscriptions), Subscribe = 0 (don't establish | - | | a new subscription), Result Type = 0 (respond | - | | using full SWID tags), Tag ID Count = 2 | - | | (targeted request identifying two SWID tags) | - | ----------- | | - | 00 00 3a 76 | Request ID = 14968 | - | ----------- | | - | 00 00 00 00 | Earliest EID = 0 (respond with inventory rather | - | | than event records) | - | =========== | START TAG IDENTIFIER 1 | - | 00 18 | Tag Creator Length = 24 | - | ----------- | | - | 72 65 67 69 64 | Tag Creator = regid.2013-06.com.vendor | - | 2e 32 30 31 33 | | - | 2d 30 36 2e 63 | | - | 6f 6d 2e 76 65 | | - | 6e 64 6f 72 | | - | ----------- | | - | 00 2c | Unique Software ID Length = 44 | - | ----------- | | - | 73 6f 6d 65 61 | Unique Software ID = | - | 70 70 2d 32 31 | someapp-21ec2020-3aea-1069-a2dd-08002b30309d | - | 65 63 32 30 32 | | - | 30 2d 33 61 65 | | - | 61 2d 31 30 36 | | - | 39 2d 61 32 64 | | - | 64 2d 30 38 30 | | - | 30 32 62 33 30 | | - | 33 30 39 64 | | - | =========== | START TAG IDENTIFIER 2 | - | 00 18 | Tag Creator Length = 24 | - | ----------- | | - | 72 65 67 69 64 | Tag Creator = regid.2013-06.com.vendor | - | 2e 32 30 31 33 | | - | 2d 30 36 2e 63 | | - | 6f 6d 2e 76 65 | | - | 6e 64 6f 72 | | - | ----------- | | - | 00 2f | Unique Software ID Length = 47 | - | ----------- | | - | 61 6e 6f 74 68 | Unique Software ID = | - | 65 72 61 70 70 | anotherapp-23a52020-3aea-1069-a2dd-0800884d4e21 | - | 2d 32 33 61 35 | | - | 32 30 32 30 2d | | - | 33 61 65 61 2d | | - | 31 30 36 39 2d | | - | 61 32 64 64 2d | | - | 30 38 30 30 38 | | - | 38 34 64 34 65 | | - | 32 31 | | - +-----------------+-------------------------------------------------+ - - This message contains SWID tag identifiers for two SWID tags. The - first of these tags is the example SWID tag described in - Appendix A.1. The second tag is created by the same tag creator, but - indicates a different software product. - -A.3. SWID Response Attributes - - This section contains examples of SWID response attributes. - -A.3.1. SWID Tag Identifier Events Attribute - - This shows an example of a SWID Tag Identifier Events attribute. In - this case, this attribute is sent in fulfillment of an established - subscription rather than in direct response to a SWID Request - attribute. (This is indicated by setting the Subscription - Fulfillment flag.) The SWID Request attribute shown in - Appendix A.2.2 established this subscription (as indicated by the - Subscription ID field). - - This response contains two event records. - - +-------------------+-----------------------------------------------+ - | 80 00 00 02 | Subscription Fulfillment = 1, Event Count = 2 | - | ----------- | | - | 00 00 3a 76 | Subscription ID = 14968 | - | ----------- | | - | 7e 82 1c aa | EID Epoch = 2122456234 | - | ----------- | | - | 00 02 cc 84 | Last EID = 183428 | - | ----------- | | - | 00 02 cc 84 | Last Consulted EID = 183428 (Same as Last EID | - | | so this is a complete result) | - | =========== | START EVENT RECORD 1 | - | 00 02 cc 83 | EID = 183427 | - | ----------- | | - | 32 30 31 33 2d 30 | Timestamp = 2013-07-21T04:32:16Z | - | 37 2d 32 31 54 30 | | - | 34 3a 33 32 3a 31 | | - | 36 5a | | - | ----------- | | - | 01 | Action = 1 (CREATION) | - | ----------- | | - | 00 18 | Tag Creator Length = 24 | - | ----------- | | - | 72 65 67 69 64 2e | Tag Creator = regid.2013-06.com.vendor | - | 32 30 31 33 2d 30 | | - | 36 2e 63 6f 6d 2e | | - | 76 65 6e 64 6f 72 | | - | ----------- | | - | 00 2c | Unique Software ID Length = 44 | - | ----------- | | - | 73 6f 6d 65 61 70 | Unique Software ID = | - | 70 2d 32 31 65 63 | someapp-21ec2020-3aea-1069-a2dd-08002b30309d | - | 32 30 32 30 2d 33 | | - | 61 65 61 2d 31 30 | | - | 36 39 2d 61 32 64 | | - | 64 2d 30 38 30 30 | | - | 32 62 33 30 33 30 | | - | 39 64 | | - | ----------- | | - | 00 51 | Instance ID Length = 81 | - | ----------- | | - | 43 3a 5c 50 72 6f | Instance ID = | - | 67 72 61 6d 44 61 | C:\ProgramData\Vendor\regid.2013-06. | - | 74 61 5c 56 65 6e | com.vendor_someapp-21ec2020-3aea-1069.swidtag | - | 64 6f 72 5c 72 65 | | - | 67 69 64 2e 32 30 | | - | 31 33 2d 30 36 2e | | - | 63 6f 6d 2e 76 65 | | - | 6e 64 6f 72 5f 73 | | - | 6f 6d 65 61 70 70 | | - | 2d 32 31 65 63 32 | | - | 30 32 30 2d 33 61 | | - | 65 61 2d 31 30 36 | | - | 39 2e 73 77 69 64 | | - | 74 61 67 | | - | ============ | START EVENT RECORD 2 | - | 00 02 cc 84 | EID = 183428 | - | ----------- | | - | 32 30 31 33 2d 30 | Timestamp = 2013-07-21T04:32:22Z | - | 37 2d 32 31 54 30 | | - | 34 3a 33 32 3a 32 | | - | 32 5a | | - | ----------- | | - | 02 | Action = 2 (DELETED) | - | ----------- | | - | 00 18 | Tag Creator Length = 24 | - | ----------- | | - | 72 65 67 69 64 2e | Tag Creator = regid.2009-08.com.company | - | 32 30 30 39 2d 30 | | - | 38 2e 63 6f 6d 2e | | - | 63 6f 6d 70 61 6e | | - | 79 | | - | ----------- | | - | 00 24 | Unique Software ID Length = 36 | - | ----------- | | - | 32 34 38 35 34 39 | Unique Software ID = | - | 37 35 2d 31 32 35 | 24854975-125e-ee3e-98ac-45684248eefa | - | 65 2d 65 65 33 65 | | - | 2d 39 38 61 63 2d | | - | 34 35 36 38 34 32 | | - | 34 38 65 65 66 61 | | - | ----------- | | - | 00 47 | Instance ID Length = 71 | - | ----------- | | - | 43 3a 5c 50 72 6f | Instance ID = C:\Program | - | 67 72 61 6d 20 46 | Files\Company\OurProduct\ | - | 69 6c 65 73 5c 43 | OurProduct_8749-84789200-02.swidtag | - | 6f 6d 70 61 6e 79 | | - | 5c 4f 75 72 50 72 | | - | 6f 64 75 63 74 5c | | - | 4f 75 72 50 72 6f | | - | 64 75 63 74 5f 38 | | - | 37 34 39 2d 38 34 | | - | 37 38 39 32 30 30 | | - | 2d 30 32 2e 73 77 | | - | 69 64 74 61 67 | | - +-------------------+-----------------------------------------------+ - - This response contains two event records. Note that their timestamps - indicate that they occurred a few seconds apart - some SWID-PCs might - choose to wait a brief time before sending messages in fulfillment of - subscriptions so as to send multiple event records in a single - attribute. The first event record indicates the creation of the SWID - tag shown in Appendix A.1. The second event record indicates the - deletion of a different SWID tag. Finally, note that since the Last - EID field is equal to the EID of one of the reported event records, - this indicates that the SWID-PC has no later recorded events. - -A.3.2. SWID Tag Inventory Attribute - - This shows an example of a SWID Tag Inventory attribute. In this - case, this attribute is being sent in direct response to a SWID - Request attribute, as indicated by the Subscription Fulfillment flag - being unset. (Specifically, it is being sent in response to the SWID - Request shown in Appendix A.2.3, as can be shown by comparing the - Request ID and Request ID Copy fields.) The result includes a single - tag entry. - - +-----------------------+-------------------------------------------+ - | 00 00 00 01 | Subscription Fulfillment = 0, Tag Count = | - | | 1 | - | ----------- | | - | 00 00 3a 76 | Request ID Copy = 14968 | - | ----------- | | - | 7e 82 1c aa | EID Epoch = 2122456234 | - | ----------- | | - | 00 02 cc 84 | Last EID = 183428 | - | =========== | BEGIN TAG ENTRY | - | 00 51 | Instance ID Length = 81 | - | ----------- | | - | 43 3a 5c 50 72 6f 67 | Instance ID = | - | 72 61 6d 44 61 74 61 | C:\ProgramData\Vendor\regid.2013-06.com. | - | 5c 56 65 6e 64 6f 72 | vendor_someapp-21ec2020-3aea-1069.swidtag | - | 5c 72 65 67 69 64 2e | | - | 32 30 31 33 2d 30 36 | | - | 2e 63 6f 6d 2e 76 65 | | - | 6e 64 6f 72 5f 73 6f | | - | 6d 65 61 70 70 2d 32 | | - | 31 65 63 32 30 32 30 | | - | 2d 33 61 65 61 2d 31 | | - | 30 36 39 2e 73 77 69 | | - | 64 74 61 67 | | - | ----------- | | - | 05 ac | Tag Length = 1452 | - | ----------- | | - | 3c 3f 78 6d 6c 20 76 | The Tag field is equal to the SWID tag | - | ... 69 6f 6e 5f 74 | shown in Figure 16. Note that since the | - | 61 67 3e | original tag used UTF-8 encoding, the tag | - | | is copied without undergoing any | - | | conversion or normalization. | - +-----------------------+-------------------------------------------+ - - This attribute contains a single SWID tag. As a response to the - targeted SWID Request in Appendix A.2.3, this indicates a single - instance of the first requested SWID tag and no instances of the - second requested tag were present in the endpoint's SWID tag - collection. Moreover, if the same party receives both this attribute - and the attribute in Appendix A.3.1, one can tell that there have - been no change events recorded since the preceding message, because - the EID Epoch and Last EID values are unchanged. - Authors' Addresses + Chris Coffin The MITRE Corporation 202 Burlington Road Bedford, MA 01730 USA Email: ccoffin@mitre.org Daniel Haynes The MITRE Corporation