--- 1/draft-coffin-sacm-nea-swid-patnc-00.txt 2016-06-08 16:16:03.623731772 -0700 +++ 2/draft-coffin-sacm-nea-swid-patnc-01.txt 2016-06-08 16:16:03.847737329 -0700 @@ -1,21 +1,21 @@ SACM C. Coffin Internet-Draft D. Haynes Intended status: Standards Track C. Schmidt -Expires: September 8, 2016 The MITRE Corporation +Expires: December 10, 2016 The MITRE Corporation J. Fitzgerald-McKay Department of Defense - March 7, 2016 + June 8, 2016 SWID Message and Attributes for PA-TNC - draft-coffin-sacm-nea-swid-patnc-00 + draft-coffin-sacm-nea-swid-patnc-01 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]. Status of This Memo @@ -26,21 +26,21 @@ 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 September 8, 2016. + This Internet-Draft will expire on December 10, 2016. 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 @@ -49,132 +49,131 @@ 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 - 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 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 . . . . . . . . . . . . 10 + Endpoint's Software Inventory . . . . . . . . . . . . 9 2.2.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10 - 2.3. Non-supported Use Cases . . . . . . . . . . . . . . . . . 11 - 2.4. Specification Requirements . . . . . . . . . . . . . . . 12 + 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 . . . . . . . . . . . . . . . . . . . . . 14 - 2.8. Caveat Regarding Persistent Connections . . . . . . . . . 14 - 2.9. SWID Message and Attributes for PA-TNC Diagram - Conventions . . . . . . . . . . . . . . . . . . . . . . . 15 - 3. SWID Message and Attributes for PA-TNC System Requirements . 15 - 3.1. SWID Tags as Inventory Evidence . . . . . . . . . . . . . 16 - 3.2. Basic SWID Tag Inventory Exchange . . . . . . . . . . . . 16 - 3.3. SWID Tag Identifiers . . . . . . . . . . . . . . . . . . 17 - 3.3.1. Tag Identifier Data . . . . . . . . . . . . . . . . . 18 - 3.3.2. Tag Identifier Instances . . . . . . . . . . . . . . 19 + 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 . . . . . . . . . . . . . . . . . . . . . . 20 + Instances . . . . . . . . . . . . . . . . . . . . . . 19 3.3.3.1. Matching Tag Identifiers Indicate the Same - Software Product . . . . . . . . . . . . . . . . 21 + Software Product . . . . . . . . . . . . . . . . 20 3.3.3.2. Matching Tag Identifiers DO NOT Necessarily - Indicate Identical Tag Files . . . . . . . . . . 21 + Indicate Identical Tag Files . . . . . . . . . . 20 3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate - Identical Tag Files . . . . . . . . . . . . . . . 22 + Identical Tag Files . . . . . . . . . . . . . . . 21 3.3.3.4. Differing Tag Identifiers DO NOT Necessarily - Indicate Different Software Products . . . . . . 22 - 3.3.4. Using Tag Identifiers in SWID Attributes . . . . . . 23 - 3.4. Targeted Requests . . . . . . . . . . . . . . . . . . . . 23 - 3.5. Monitoring Changes in an Endpoint's SWID Tag Collection . 24 - 3.6. Reporting Change Events . . . . . . . . . . . . . . . . . 26 - 3.6.1. Change Event Records . . . . . . . . . . . . . . . . 27 - 3.6.2. Updating Inventory Knowledge Based on Events . . . . 28 - 3.6.3. Using Event Records in SWID Attributes . . . . . . . 29 + 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 . . . . . . . . . . . . . . . . . . . . . 29 - 3.6.5. Synchronizing Event Identifiers and Epochs . . . . . 31 - 3.7. Supporting Multiple Instances of a Single Tag . . . . . . 33 + 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 . . . . . . . . . . . . . . . . . . 33 + Instantiated Tags . . . . . . . . . . . . . . . . . . 32 3.7.2. Event Reporting in the Presence of Multiply - Instantiated Tags . . . . . . . . . . . . . . . . . . 33 - 3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 34 - 3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 34 - 3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 35 - 3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 35 - 3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 36 - 3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 37 - 3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 39 - 3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 39 - 3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 40 - 3.8.5.4. No Subscription Consolidation . . . . . . . . . . 41 - 3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 41 - 3.9. Multiple Sources of SWID Tags . . . . . . . . . . . . . . 42 - 3.10. Error Handling . . . . . . . . . . . . . . . . . . . . . 43 - 4. SWID Message and Attributes for PA-TNC Protocol . . . . . . . 45 - 4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 45 - 4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 46 - 4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 46 - 4.4. SWID Attribute Overview . . . . . . . . . . . . . . . . . 47 - 4.5. SWID Attribute Exchanges . . . . . . . . . . . . . . . . 49 + 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 . . . . . . . . . . . . . . . . . . . . . . . 51 - 4.7. Normalization of Text Encoding . . . . . . . . . . . . . 52 - 4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 53 - 4.9. SWID Request . . . . . . . . . . . . . . . . . . . . . . 54 - 4.10. SWID Tag Identifier Inventory . . . . . . . . . . . . . . 58 - 4.11. SWID Tag Identifier Events . . . . . . . . . . . . . . . 61 - 4.12. SWID Tag Inventory . . . . . . . . . . . . . . . . . . . 66 - 4.13. SWID Tag Events . . . . . . . . . . . . . . . . . . . . . 68 - 4.14. Subscription Status Request . . . . . . . . . . . . . . . 72 - 4.15. Subscription Status Response . . . . . . . . . . . . . . 72 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 74 + PA-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR and SWID_SUBSCRIPTION_ID_REUSE_ERROR - Information . . . . . . . . . . . . . . . . . . . . 76 - 4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information . . . . . 77 - 4.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information . . 79 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 80 - 5.1. Evidentiary Value of SWID Tags . . . . . . . . . . . . . 81 - 5.2. Integrity of the SWID Tag Collection . . . . . . . . . . 81 - 5.3. Sensitivity of Collected Tags . . . . . . . . . . . . . . 82 - 5.4. Integrity of Endpoint Records . . . . . . . . . . . . . . 83 - 5.5. SWID-PC Access Permissions . . . . . . . . . . . . . . . 84 - 5.6. Sanitization of Tag Fields . . . . . . . . . . . . . . . 84 - 5.7. Tag Library Poisoning . . . . . . . . . . . . . . . . . . 85 - 5.8. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 85 - 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 85 - 7. Relationship to Other Specifications . . . . . . . . . . . . 86 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 - 8.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 87 - 8.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 87 - 8.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 88 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 89 - 9.2. Informative References . . . . . . . . . . . . . . . . . 89 - Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 90 - A.1. A Simple SWID Tag . . . . . . . . . . . . . . . . . . . . 90 - A.2. SWID Request Attributes . . . . . . . . . . . . . . . . . 92 - A.2.1. Simple Request . . . . . . . . . . . . . . . . . . . 92 - A.2.2. Subscription Request for Events . . . . . . . . . . . 93 - A.2.3. Targeted Request . . . . . . . . . . . . . . . . . . 93 - A.3. SWID Response Attributes . . . . . . . . . . . . . . . . 95 - A.3.1. SWID Tag Identifier Events Attribute . . . . . . . . 95 - A.3.2. SWID Tag Inventory Attribute . . . . . . . . . . . . 97 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 + 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 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 @@ -199,21 +198,21 @@ 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. +-------------+ +--------------+ | Posture | <--------PA--------> | Posture | | Collectors | | Validators | | (1 .. N) | | (1 .. N) | +-------------+ +--------------+ | | - | IF-IMC | IF-IMV + | | | | +-------------+ +--------------+ | Posture | | Posture | | Broker | <--------PB--------> | Broker | | Client | | Server | +-------------+ +--------------+ | | | | +-------------+ +--------------+ | Posture | | Posture | @@ -270,55 +269,36 @@ 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]. - In addition, this document relies upon features in the Trusted - Computing Group's Trusted Network Communications (TNC) IF-IMC 1.3 - [IF-IMC] and IF-IMV 1.4 [IF-IMV] specifications. These - specifications describe standard interfaces and requirements for the - interoperation between TNC IMCs and TNC Clients, and between TNC IMVs - and TNC Servers. The TNC and NEA architectures are interoperable and - the following components are equivalent: + 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 - As a result, the IF-IMC specification effectively standardizes an - interface between a Posture Collector and the Posture Broker Client, - while the IF-IMV specification effectively standardize an interface - between a Posture Validator and a Posture Broker Server. However, as - there is currently no NEA equivalent for IF-IMC or IF-IMV, the names - for these specifications as well as the names of functions and data - structures that appear in those specifications uses TNC rather than - NEA terminology. Readers should be aware of the functional - equivalence of the TNC and NEA terms. - - If the reader is building a posture collector that supports PA-TNC, - the reader is encouraged to read the TNC IF-IMC Specification prior - to reading this specification. If the reader is building a posture - validator that supports IF-IMV, the reader is encouraged to read the - TNC IF-IMV Specification prior to reading this specification. - 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. @@ -637,56 +618,21 @@ 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. -2.8. Caveat Regarding Persistent Connections - - One of the features defined in this specification describes the - ability for SWID-PCs to monitor the state of their endpoint's SWID - tag collection and, when changes are detected, to push updates to the - SWID-PV without the SWID-PV sending a request. (This feature is - described in more detail in Section 3.8.) This capability is tied to - the SWID-PC's ability to initiate an Integrity Check Handshake (as - described in section 2.10.1 of the IF-IMC 1.3 specification - [IF-IMC]), which in turn is only possible if there is an active - connection with a valid connection ID (as described in section 2.10.2 - of the IF-IMC 1.3 specification). - - The other specifications of the NEA architecture do not require - endpoints to maintain active connections outside of an Integrity - Check Handshake. While implementers are allowed to maintain - connections outside of an Integrity Check Handshake (and there are - advantages to doing so), maintaining open connections also consumes - resources on both the endpoint and the NEA Server, so some - implementers may choose to close connections as soon as a handshake - completes. Moreover, for devices with intermittent connectivity - (such as mobile phones), maintaining an active, ongoing connection - may be impractical. - - This specification requires that all SWID-PCs and SWID-PVs support - subscriptions. However, for the reasons noted above, subscriptions - may not be practical in all environments where SWID-PCs and SWID-PVs - are deployed. Parties deploying SWID-PCs and SWID-PVs as part of - their enterprise protection strategy are encouraged to understand the - limits of specific devices and their NEA architecture as a whole. In - some cases, while other features of the SWID Message and Attributes - for PA-TNC specification may be employed, the use of subscriptions - may be limited or impractical without additional infrastructure - changes. - -2.9. SWID Message and Attributes for PA-TNC Diagram Conventions +2.8. SWID Message and Attributes for PA-TNC Diagram Conventions This specification defines the syntax of the SWID 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 @@ -773,27 +719,24 @@ 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 3.3.2.2 of the IF-IMV r1.4 - specification. Exclusive delivery ensures that only the sender of - the SWID Request receives the resulting SWID Response. However, - exclusive delivery is not always possible (it requires the use of IF- - IMC 1.3 or later and IF-IMV 1.3 or later, and not all products - currently do this) or necessarily desirable in all cases. As such, - SWID Message and Attributes for PA-TNC does not require support for + 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 @@ -1617,48 +1562,32 @@ 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 subscriptions to multiple parties. 3.8.2. Managing Subscriptions The SWID-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. If the attribute is received by - the SWID-PC using the TNC_IMC_ReceiveMessage (section 3.8.4 of IF-IMC - 1.3 [IF-IMC]) function, then only the connection ID of the SWID-PV's - NEA Server is available to the SWID-PC. If the attribute is received - by the SWID-PC using the TNC_IMC_ReceiveMessageLong function (section - 3.8.6 of IF-IMC) then the SWID-PC has both the NEA Server's - connection ID and the Posture Validator ID of the sending SWID-PV. - SWID-PCs SHOULD support TNC_IMC_ReceiveMessageLong function calls. - SWID-PCs MUST record the connection ID of the SWID-PV's NEA Server - for each accepted subscription. SWID-PCs SHOULD record the SWID-PV's - Posture Validator ID for each accepted subscription if this - information is available. + 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 - they are the subscribing party along with its 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. As with the SWID-PC, the SWID-PV might only have - access to the connection ID of the SWID-PC's endpoint, or might have - both this connection ID and the SWID-PC's Posture Collector ID - depending on the supported IF-IMV functions [IF-IMV]. SWID-PVs - SHOULD support TNC_IMV_ReceiveMessageLong function calls so as to be - capable of receiving the SWID-PC's Posture Collector ID. SWID-PVs - MUST record the connection ID of the SWID-PC's endpoint for each - accepted subscription. The SWID-PV SHOULD record the SWID-PC's - Posture Collector ID for each accepted subscription if this - information is available. + 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. 3.8.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 @@ -1680,31 +1609,26 @@ unilaterally terminate a subscription. However, if the SWID-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 fulfillment led to the error MUST be treated as terminated by both the SWID-PC and the SWID-PV. Only the subscription experiencing the error is cancelled and other subscriptions are unaffected. See Section 3.10 for more on this error condition. Finally, a subscription is terminated if the connection between the - SWID-PC and SWID-PV is deleted, as indicated by the connection state - changing to DELETE. (Described in section 3.5.2.2 of IF-IMC [IF-IMC] - and section 3.5.2.2 of IF-IMV [IF-IMV].) Doing this renders the - SWID-PC incapable of pushing additional SWID Response attributes to - the subscribing party. Both the SWID-PC and SWID-PV MUST delete all - subscriptions for which the connection has been deleted. SWID-PCs - MUST support the TNC_IMC_NotifyConnectionChange function, as defined - in IF-IMC 1.3 section 3.8.2, so that the SWID-PC can be informed when - a connection's state changes to DELETE. Likewise, a SWID-PV MUST - support the TNC_IMV_NotifyConnectionChange function, as defined in - IF-IMV 1.4 section 3.8.2, for the same reason. + 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. 3.8.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 @@ -1731,33 +1655,32 @@ connection ID and that have no associated Posture Validator ID, and MUST include all such records. 3.8.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 in the case - that the SWID-PV's Posture Validator ID is known. (See section - 3.3.2.2 of IF-IMC 1.3 [IF-IMC] or section 3.3.2.2 of IF-IMV 1.4 - [IF-IMV] for more on exclusive delivery.) Such an attribute is said - to be sent "in fulfillment of" the given subscription and any such - attribute 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. + 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. +-------------+ +--------------+ | SWID-PC | | SWID-PV | Time +-------------+ +--------------+ | | | | |<----------SWID Request------------| | | | | |-----------SWID Response---------->| | | | | . . . @@ -2443,42 +2366,41 @@ sections. 4.8. Request IDs All SWID 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 (as described in section 3.5.2.2 of the IF-IMV - specification [IF-IMV]). 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. + 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. 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 @@ -3926,31 +3848,27 @@ authorized to receive this information and that can be trusted to safeguard this information after collection. 7. 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, the SWID- - PC communicates with the endpoint's Posture Broker Client using IF- - IMC [IF-IMC], while the SWID-PV communicates with the NEA Server's - Posture Broker Server using IF-IMV [IF-IMV]. - - In addition, SWID 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. + the other protocols used in a NEA exchange. In particular, SWID + 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 @@ -4087,26 +4005,20 @@ (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 - [IF-IMC] Trusted Computing Group, "TNC IF-IMC version 1.3", - February 2013. - - [IF-IMV] Trusted Computing Group, "TNC IF-IMV version 1.4", August - 2013. - [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, March 2010, .