idnits 2.17.1 draft-ietf-sacm-nea-swima-patnc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5209], [RFC5792]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 22, 2017) is 2405 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 3005 -- Looks like a reference, but probably isn't: '1' on line 4135 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST8060' ** Downref: Normative reference to an Informational RFC: RFC 5209 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID09' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID15' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM C. Schmidt 3 Internet-Draft D. Haynes 4 Intended status: Standards Track C. Coffin 5 Expires: March 26, 2018 The MITRE Corporation 6 D. Waltermire 7 National Institute of Standards and Technology 8 J. Fitzgerald-McKay 9 Department of Defense 10 September 22, 2017 12 Software Inventory Message and Attributes (SWIMA) for PA-TNC 13 draft-ietf-sacm-nea-swima-patnc-01 15 Abstract 17 This document extends the PA-TNC specification [RFC5792] by providing 18 specific attributes and message exchanges to allow endpoints to 19 report their installed software inventory information to a NEA server 20 (as described in [RFC5209]). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 26, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Network Endpoint Assessment (NEA) . . . . . . . . . . . . 5 58 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 6 59 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8 62 2.1.1. Use Software Inventory as an Access Control Factor . 8 63 2.1.2. Central Stores of Up-to-Date Endpoint Software 64 Inventory Data . . . . . . . . . . . . . . . . . . . 8 65 2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 9 66 2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 9 67 2.3. Specification Requirements . . . . . . . . . . . . . . . 10 68 2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 11 69 2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 70 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 12 71 3. System Requirements . . . . . . . . . . . . . . . . . . . . . 12 72 3.1. Data Sources . . . . . . . . . . . . . . . . . . . . . . 12 73 3.2. Data Models . . . . . . . . . . . . . . . . . . . . . . . 14 74 3.3. Basic Attribute Exchange . . . . . . . . . . . . . . . . 15 75 3.4. Core Software Reporting Information . . . . . . . . . . . 16 76 3.4.1. Software Identifiers . . . . . . . . . . . . . . . . 16 77 3.4.2. Data Model Type . . . . . . . . . . . . . . . . . . . 17 78 3.4.3. Record Identifiers . . . . . . . . . . . . . . . . . 18 79 3.4.4. Software Locators . . . . . . . . . . . . . . . . . . 18 80 3.4.5. Source Identifiers . . . . . . . . . . . . . . . . . 19 81 3.4.6. Using Software and Record Identifiers in SWIMA 82 Attributes . . . . . . . . . . . . . . . . . . . . . 20 83 3.5. Targeted Requests . . . . . . . . . . . . . . . . . . . . 21 84 3.6. Monitoring Changes in an Endpoint's Software Inventory 85 Evidence Collection . . . . . . . . . . . . . . . . . . . 22 86 3.7. Reporting Change Events . . . . . . . . . . . . . . . . . 24 87 3.7.1. Event Identifiers . . . . . . . . . . . . . . . . . . 25 88 3.7.2. Core Event Tracking Information . . . . . . . . . . . 26 89 3.7.3. Updating Inventory Knowledge Based on Events . . . . 27 90 3.7.4. Using Event Records in SWIMA Attributes . . . . . . . 27 91 3.7.5. Partial and Complete Lists of Event Records in SWIMA 92 Attributes . . . . . . . . . . . . . . . . . . . . . 28 93 3.7.6. Synchronizing Event Identifiers and Epochs . . . . . 30 94 3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 31 95 3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 32 96 3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 32 97 3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 33 98 3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 33 99 3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 34 100 3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 36 101 3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 36 102 3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 37 103 3.8.5.4. No Subscription Consolidation . . . . . . . . . . 38 104 3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 38 105 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 39 106 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 40 107 4.1. Direct Response to a SWIMA Request . . . . . . . . . . . 41 108 4.2. Subscription-Based Response . . . . . . . . . . . . . . . 41 109 4.3. Required Exchanges . . . . . . . . . . . . . . . . . . . 42 110 5. Software Inventory Messages and Attributes . . . . . . . . . 42 111 5.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 42 112 5.2. SWIMA Attribute Overview . . . . . . . . . . . . . . . . 43 113 5.3. Message Diagram Syntax . . . . . . . . . . . . . . . . . 44 114 5.4. Software Inventory Message and Attributes for PA-TNC 115 Attribute Enumeration . . . . . . . . . . . . . . . . . . 45 116 5.5. Normalization of Text Encoding . . . . . . . . . . . . . 46 117 5.6. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 47 118 5.7. SWIMA Request . . . . . . . . . . . . . . . . . . . . . . 48 119 5.8. Software Identifier Inventory . . . . . . . . . . . . . . 51 120 5.9. Software Identifier Events . . . . . . . . . . . . . . . 55 121 5.10. Software Inventory . . . . . . . . . . . . . . . . . . . 60 122 5.11. Software Events . . . . . . . . . . . . . . . . . . . . . 63 123 5.12. Subscription Status Request . . . . . . . . . . . . . . . 68 124 5.13. Subscription Status Response . . . . . . . . . . . . . . 68 125 5.14. Source Metadata Request . . . . . . . . . . . . . . . . . 70 126 5.15. Source Metadata Response . . . . . . . . . . . . . . . . 70 127 5.16. PA-TNC Error as Used by Software Inventory Message and 128 Attributes for PA-TNC . . . . . . . . . . . . . . . . . . 72 129 5.16.1. SWIMA_ERROR, 130 SWIMA_SUBSCRIPTION_DENIED_ERROR and 131 SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information . . . 74 132 5.16.2. SWIMA_RESPONSE_TOO_LARGE_ERROR Information . . . . . 76 133 5.16.3. SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information . . 78 134 6. Supported Data Models . . . . . . . . . . . . . . . . . . . . 80 135 6.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 80 136 6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID 137 Tags using XML . . . . . . . . . . . . . . . . . . . 80 138 6.1.2. Guidance on Creation of Software Identifiers from ISO 139 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 81 140 6.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 81 141 6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID 142 Tags using XML . . . . . . . . . . . . . . . . . . . 81 143 6.2.2. Guidance on Creation of Software Identifiers from ISO 144 2009 SWID Tags . . . . . . . . . . . . . . . . . . . 82 146 7. Security Considerations . . . . . . . . . . . . . . . . . . . 82 147 7.1. Evidentiary Value of Software Inventory Evidence Records 82 148 7.2. Sensitivity of Collected Records . . . . . . . . . . . . 83 149 7.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 84 150 7.4. SWIMA-PC Access Permissions . . . . . . . . . . . . . . . 84 151 7.5. Sanitization of Record Fields . . . . . . . . . . . . . . 85 152 7.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 85 153 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 85 154 9. Relationship to Other Specifications . . . . . . . . . . . . 85 155 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 156 10.1. PA Subtypes . . . . . . . . . . . . . . . . . . . . . . 86 157 10.2. Registry for PA-TNC Attribute Types . . . . . . . . . . 86 158 10.3. Registry for PA-TNC Error Codes . . . . . . . . . . . . 87 159 10.4. Registry for Software Data Models . . . . . . . . . . . 89 160 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 89 161 11.1. Normative References . . . . . . . . . . . . . . . . . . 89 162 11.2. Informative References . . . . . . . . . . . . . . . . . 90 163 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 91 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 166 1. Introduction 168 Knowing the list of the software installed on endpoints is useful to 169 understand and maintain the security state of a network. For 170 example, if an enterprise policy requires the presence of certain 171 software and prohibits the presence of other software, reported 172 software installation information can be used to indicate compliance 173 and non-compliance with these requirements. Endpoint software 174 installation inventory lists (hereinafter "software inventories") can 175 further be used to determine an endpoint's exposure to attack based 176 on comparison to vulnerability or threat alerts against identified 177 software's patch level data. These are some of the highly useful 178 management use cases supported by software inventory data provided by 179 this Software Inventory Message and Attributes (SWIMA) for PA-TNC. 181 There is a need for a standardized method for exchanging software 182 inventory data that includes a unique software identifier associated 183 with a specific version of a software product. In some cases, it may 184 also be necessary to convey observable installation information and 185 characterization information for a software product including 186 metadata about the product beyond its identifier. These "Messages 187 and Attributes" enable software identification, installation, and 188 characterization information to be provided for any software 189 installed on any endpoint that supports this specification. Such 190 information can come from multiple sources, including tag files (such 191 as ISO SWID tags [SWID15]), reports from third party inventory tools, 192 output from package managers, and other sources. 194 This specification is designed to only report software that is 195 installed on a target endpoint. In particular, it does not monitor 196 or report information about what software is running on the endpoint. 197 Likewise, it is not intended to report individual files, libraries, 198 installation packages, or similar artifacts. While all of this 199 information has its uses, this information requires different 200 metadata and monitoring methods. As a result, this specification 201 focuses solely on software inventory information, leaving reporting 202 of other classes of endpoint information to other specifications. 204 This specification defines a new set of PA-TNC attributes, which are 205 used to communicate requests for software inventory information and 206 software installation change events. The exchange of these messages 207 allows software inventory information to be sent to a NEA Server, 208 which can make this information available to other applications. 210 1.1. Network Endpoint Assessment (NEA) 212 SWIMA defines a extensions to the PA-TNC specification, which is part 213 of the The Network Endpoint Assessment (NEA) architecture. The NEA 214 specifications define an open solution architecture that enables 215 network operators to collect and utilize information about endpoint 216 configuration and state. This information can be used to enforce 217 policies, monitor endpoint health, and for many other activities. 218 Information about the software present on an endpoint is an important 219 consideration for such activities. The new PA-TNC attributes defined 220 in this document are used to communicate software inventory evidence, 221 collected from a range of possible sources, from the posture 222 collector on the endpoint to the posture validator on a NEA Server 223 using the PA-TNC interface, as shown in Figure 1 below. 225 +-------------+ +--------------+ 226 | Posture | <--------PA--------> | Posture | 227 | Collectors | | Validators | 228 | (1 .. N) | | (1 .. N) | 229 +-------------+ +--------------+ 230 | | 231 | | 232 | | 233 +-------------+ +--------------+ 234 | Posture | | Posture | 235 | Broker | <--------PB--------> | Broker | 236 | Client | | Server | 237 +-------------+ +--------------+ 238 | | 239 | | 240 +-------------+ +--------------+ 241 | Posture | | Posture | 242 | Transport | <--------PT--------> | Transport | 243 | Client | | Server | 244 | (1 .. N) | | (1 .. N) | 245 +-------------+ +--------------+ 246 NEA CLIENT NEA SERVER 248 Figure 1: NEA Reference Model 250 To better understand this specification, the reader should review the 251 NEA reference architecture as described in the Network Endpoint 252 Assessment (NEA): Overview and Requirements [RFC5209]. The reader 253 should also review the PA-TNC interfaces as defined in RFC 5792 254 [RFC5792]. 256 This document is based on standards published by the Trusted 257 Computing Group's Trusted Network Communications (TNC) workgroup. 258 The TNC and NEA architectures are interoperable and many components 259 are equivalent. 261 1.2. Keywords 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 specification are to be interpreted as described in RFC 2119 266 [RFC2119]. This specification does not distinguish blocks of 267 informative comments and normative requirements. Therefore, for the 268 sake of clarity, note that lower case instances of must, should, etc. 269 do not indicate normative requirements. 271 1.3. Definitions 273 This section defines terms with special meaning within this document. 275 SWIMA-PC - A NEA Posture Collector (PC) that interprets SWIMA 276 Attributes sent by SWIMA-PVs and which conforms to this 277 specification. Note that such a posture collector might also support 278 other PA-TNC exchanges beyond those defined herein. 280 SWIMA-PV - A NEA Posture Validator (PV) that interprets SWIMA 281 Attributes sent by SWIMA-PCs and which conforms to this 282 specification. Note that such a posture verifier might also support 283 other PA-TNC exchanges beyond those defined herein. 285 SWIMA Attribute - This is a PA-TNC attribute (as defined in RFC 5792 286 [RFC5792] extension as defined in this specification. 288 Endpoint's Software Inventory Evidence Collection - The set of 289 information regarding the set of software installed on an endpoint. 290 An endpoint's software inventory evidence collection might include 291 information created by or derived from multiple sources, including 292 but not limited to SWID tag files deposited on the file system during 293 software installation, information generated to report output from 294 software discovery tools, and information dynamically generated by a 295 software or package management system on an endpoint. 297 Software Inventory Evidence Record - The endpoint's Software 298 Inventory Evidence Collection is composed of "records". Each record 299 corresponds to one installed instance of a particular software 300 product as reported by some data source. It is possible for a single 301 installed instance to have multiple software inventory evidence 302 records in an endpoint's Software Inventory Evidence Collection - 303 this can happen if multiple sources all report the same software 304 installation instance. 306 Software Identifier - A string associated with a specific version of 307 a specific software product. These identifiers are derived from the 308 records used to describe software products. SWIMA does not limit the 309 formats of these records, nor does it enforce that the same format be 310 populated the same way by all data sources. As such, while each 311 software identifier uniquely identifies a specific software product, 312 the same software product might be associated with multiple software 313 identifiers reflecting differences between different data sources and 314 supported record formats. 316 2. Background 318 2.1. Supported Use Cases 320 This section describes the use cases supported by this specification. 321 The primary use of exchanging software inventory information over the 322 PA-TNC interface is to enable a challenger (e.g. NEA Server) to 323 obtain inventory evidence about some system in a way that conforms to 324 NEA procedures and expressed using a standard format. Collected 325 software information can support a range of security activities 326 including determining whether an endpoint is permitted to connect to 327 the enterprise, determining which endpoints contain software that 328 requires patching, and similar activities. 330 2.1.1. Use Software Inventory as an Access Control Factor 332 Some enterprises might define security policies that require 333 connected endpoints to have certain pieces of security software 334 installed. By contrast, some security policies might prevent access 335 to resources by endpoints that have certain prohibited pieces of 336 software installed, since such applications might pose a security 337 risk. To support such policies, the NEA Server needs to collect 338 software inventory evidence from a target endpoint that is seeking to 339 initiate or continue connectivity to the enterprise resource. 341 Based on this specification, the SWIMA-PC can provide a complete or 342 partial inventory to the SWIMA-PV as required to determine policy 343 compliance. The SWIMA-PV can then use this as evidence of compliance 344 or non-compliance to make a policy-based access decision. 346 2.1.2. Central Stores of Up-to-Date Endpoint Software Inventory Data 348 Many tools use information about an endpoint's software inventory to 349 monitor and enforce the security of a network. For example, a 350 software patching tool needs to determine if there is out-of-date 351 software installed that needs to be updated. A vulnerability 352 management tool needs to identify endpoints with known vulnerable 353 software installed (patched or otherwise) to gauge an endpoint's 354 relative exposure to attack. A license management tool needs to 355 verify that all installed software within the enterprise is accounted 356 for. A central repository representing an up-to-date understanding 357 of each endpoint's software inventory facilitates these activities. 358 Multiple tools can share such a repository ensuring that software 359 inventory information is collected more frequently and efficiently, 360 leading to a more complete and consistent understanding of installed 361 software state as compared to each tool collecting the same inventory 362 information from endpoints individually. 364 This specification supports these activities through a number of 365 mechanisms. As noted above, a SWIMA-PC can provide a complete list 366 of software present in an endpoint's Software Inventory Evidence 367 Collection to the SWIMA-PV, which can then pass this information on 368 to a central repository, such as a Configuration Management Database 369 (CMDB) or similar application. In addition, SWIMA-PCs are required 370 to be able to monitor for changes to an endpoint's Software Inventory 371 Evidence Collection in near real-time and immediately push reports of 372 detected changes to the SWIMA-PV. Thus, any central repository fed 373 by a SWIMA-PV receiving inventory information can be updated quickly 374 after a change occurs. Keeping a central repository synchronized 375 with current software inventory information in this way allows tools 376 to make efficient decisions based on up-to-date, consistent 377 information. 379 2.1.3. PA-TNC Use Cases 381 Software Inventory Message and Attributes for PA-TNC are intended to 382 operate over the PA-TNC interface and, as such, are intended to meet 383 the use cases set out in the PA-TNC specification. 385 2.2. Non-supported Use Cases 387 Some use cases not covered by this specification include: 389 o Addressing how the endpoint's Software Inventory Evidence 390 Collection is populated. In particular, NEA components are not 391 expected to perform software discovery activities beyond compiling 392 information in an endpoint's Software Inventory Evidence 393 Collection. This collection might come from multiple sources on 394 the endpoint (e.g., information generated dynamically by package 395 management tools or discovery tools, as well as SWID tag files 396 discovered on the file system). While an enterprise might make 397 use of software discovery capabilities to identify installed 398 software, such capabilities are outside the scope of this 399 specification. 401 o Converting inventory information expressed in a proprietary format 402 into formats used in the attributes described in this 403 specification. Instead, this specification focuses exclusively on 404 defining interfaces for the transportation of software information 405 expecting that reporting tools will converge around some set of 406 standardized formats for this information. 408 o Mechanisms for a posture validator to request a specific list of 409 software information based on arbitrary software properties. For 410 example, requesting only information about software from a 411 particular vendor is not supported. After the endpoint's Software 412 Inventory Evidence Collection has been copied to some central 413 location, such as the CMDB, processes there can perform queries 414 based on any criteria present in the collected information, but 415 this specification does not address using such queries to 416 constrain the initial collection of this information from the 417 endpoint. 419 o Use of properties of certain sources of software information that 420 might facilitate local tests (i.e., on the endpoint) of endpoint 421 state. For example, the optional package_footprint field of an 422 ISO SWID tag can contain a list of files and hash values 423 associated with the software indicated by the tag. Tools on the 424 endpoint can use the values in this field to test for the presence 425 of the indicated files. Successful evaluation of such tests leads 426 to greater assurance that the indicated software is present on the 427 endpoint. Currently, most SWID tag creators do not provide values 428 for tag fields that support local testing. For this reason, the 429 added complexity of supporting endpoint testing using these fields 430 is out of scope for this specification, but may be considered in a 431 future version. 433 2.3. Specification Requirements 435 Below are the requirements that the Software Inventory Message and 436 Attributes for PA-TNC specification is required to meet in order to 437 successfully play its role in the NEA architecture. 439 Efficient: The NEA architecture enables delay of network access 440 until the endpoint is determined not to pose a security threat to 441 the network based on its asserted integrity information. To 442 minimize user frustration, the Software Inventory Message and 443 Attributes for PA-TNC ought to minimize overhead delays and make 444 PA-TNC communications as rapid and efficient as possible. 446 Efficiency is also important when one considers that some network 447 endpoints are small and low powered, some networks are low 448 bandwidth and/or high latency, and some transport protocols (such 449 as PT-EAP, Posture Transport (PT) Protocol for Extensible 450 Authentication Protocol (EAP) Tunnel Methods [RFC7171]) or their 451 underlying carrier protocol might allow only one packet in flight 452 at a time or only one roundtrip. However, when the underlying PT 453 protocol imposes fewer constraints on communications, this 454 protocol ought to be capable of taking advantage of more robust 455 communication channels (e.g. using larger messages or multiple 456 roundtrips). 458 Scalable: Software Inventory Message and Attributes for PA-TNC needs 459 to be usable in enterprises that contain tens of thousands of 460 endpoints or more. As such, it needs to allow a security tools to 461 make decisions based on up-to-date information about an endpoint's 462 software inventory without creating an excessive burden on the 463 enterprise's network. 465 Interoperable: This specification defines the protocol for how PCs 466 and PVs can exchange and use software information to provide a NEA 467 Server with information about an endpoint's software inventory. 468 Therefore, a key goal for this specification is ensuring that all 469 SWIMA PCs and PVs, regardless of the vendor who created them, are 470 able to interoperate in their performance of these duties. 472 Support precise and complete historical reporting: This 473 specification outlines capabilities that support real-time 474 understanding of the state of endpoint in a network in a way that 475 can be used by other tools. One means of facilitating such an 476 outcome is for a CMDB to be able to contain information about all 477 endpoints connected to the enterprise for all points in time 478 between the endpoint's first connection and the present. In such 479 a scenario, it is necessary that any PC be able to report any 480 changes to its software inventory evidence collection in near 481 real-time while connected and, upon reconnection to the 482 enterprise, be able to update the NEA Server (and through it the 483 CMDB) with regard to the state of its software inventory evidence 484 collection throughout the entire interval when it was not 485 connected. 487 2.4. Non-Requirements 489 There are certain requirements that the Software Inventory Message 490 and Attributes for PA-TNC specification explicitly is not required to 491 meet. This list is not exhaustive. 493 End to End Confidentiality: This specification does not define a 494 mechanism for confidentiality, nor is this property automatically 495 provided by using the PA-TNC interface. In the NEA architecture, 496 confidentiality is generally provided by the underlying transport 497 protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP 498 Posture Transport for Tunneled EAP Methods [RFC7171] - see 499 Section 9 for more information on related standards. Should users 500 wish to protect the confidentiality of assessment instructions or 501 results, then an appropriate transport needs to be used. 503 2.5. Assumptions 505 The Posture Broker Client and Posture Broker Server are assumed to 506 provide reliable delivery for PA-TNC messages and attributes sent 507 between the SWIMA-PCs and the SWIMA-PVs. Reliable delivery means 508 that either a message is delivered or the sender is made aware of the 509 delivery failure. In the event that reliable delivery cannot be 510 provided, the Posture Collector or Posture Validator is expected to 511 terminate the connection. 513 2.6. Non-Assumptions 515 This specification explicitly does not assume that software inventory 516 information exchanges reflect the software installation state of the 517 endpoint. This specification does not attempt to detect when the 518 endpoint is providing false information, either through malice or 519 error, but instead focuses on correctly and reliably providing the 520 reported Software Inventory Evidence Collection to the NEA Server. 521 Similarly, this specification makes no assumption about the 522 completeness of the Software Inventory Evidence Collection's coverage 523 of the total set of software installed on the endpoint. It is 524 possible, and even likely, that some installed software is not 525 represented by a record in an endpoints Software Inventory Evidence 526 Collection. See Section 7 for more on this security consideration. 528 3. System Requirements 530 The Software Inventory Message and Attributes for PA-TNC 531 specification facilitates the exchange of software inventory and 532 event information. Specifically, each application supporting 533 Software Inventory Message and Attributes for PA-TNC includes a 534 component known as the SWIMA-PC that receives messages sent with the 535 SWIMA Attributes component type. The SWIMA-PC is also responsible 536 for sending appropriate SWIMA Attributes back to the SWIMA-PV in 537 response. This section outlines what software inventories and events 538 are and the requirements on SWIMA-PCs and SWIMA-PVs in order to 539 support the stated use cases of this specification. 541 3.1. Data Sources 543 The records in an endpoint's software inventory evidence collection 544 come from one or more "sources". A source represents one collection 545 of software inventory information about the endpoint. Examples of 546 sources include, but are not limited to, ISO SWID tags deposited on 547 the filesystem and collected therefrom, information derived from 548 package managers (e.g., RPM or YUM), and the output of software 549 inventory scanning tools. 551 There is no expectation that any one source of inventory information 552 will have either perfect or complete software inventory information. 553 For this reason, this specification supports the simultaneous use of 554 multiple sources of software inventory information. Each source 555 might have its own "sphere of expertise" and report the software 556 within that sphere. For example, a package manager would have 557 excellent understanding of the software that it managed, but would 558 not necessarily have any information about software installed via 559 other means. 561 A SWIMA-PC is not required to utilize every possible source of 562 software information on its endpoint. Some SWIMA-PCs might be 563 explicitly tied only to one or a handful of software inventory 564 sources, or it could be designed to dynamically accommodate new 565 sources. For all software inventory evidence sources that a 566 particular SWIMA-PC supports, it MUST completely support all 567 requirements of this specification with regard to those sources. A 568 potential source that cannot support some set of required 569 functionality (e.g. it is unable to monitor the software it reports 570 for change events, as discussed in Section 3.6) MUST NOT be used as a 571 source of endpoint software inventory information, even if it could 572 provide some information. In other words, a source either supports 573 full functionality as described in this specification, or it cannot 574 be used at all. 576 When sending information about installed software the SWIMA-PC MUST 577 include the complete set of relevant data from all supported sources 578 of software inventory evidence. In other words, sources need to be 579 used consistently. This is because, if a particular source is 580 included in an initial inventory, but excluded from a later 581 inventory, the SWIMA-PV receiving this information might reasonably 582 conclude that the software reported by that source was no longer 583 installed on the endpoint. As such, it is important that all 584 supported sources be used every time the SWIMA-PC provides 585 information to a SWIMA-PV. 587 Note that, if a SWIMA-PC collects data from multiple sources, it is 588 possible that some software products might be "double counted". This 589 can happen if both sources of inventory evidence provide a record for 590 a single installation of a software product. When a SWIMA-PC reports 591 information or records events from multiple inventory evidence 592 sources, it MUST use the information those sources provide, rather 593 than attempting to perform some form of reduction. In other words, 594 if multiple sources report records corresponding to a single 595 installation of a software product, all such records from each source 596 are required to be part of the SWIMA-PC's processing even if this 597 might lead to multiple reporting, and the SWIMA-PC is not to ignore 598 some records to avoid such multiple reporting. 600 All inventory records reported by a SWIMA-PC include a Source 601 Identifier linking them to a particular source. Source Identifiers 602 are discussed more in Section 3.4.5. 604 3.2. Data Models 606 SWIMA conveys records about software presence from a SWIMA-PC to a 607 SWIMA-PV. SWIMA does not manage the actual generation or collection 608 of such records on the endpoint. As a result, information available 609 to SWIMA-PCs might come in a variety of formats, and a SWIMA-PC could 610 little control over the format of the data made available to it. 611 Because of this, SWIMA places no constraints on the format of these 612 generated records and supports an open set of record formats by which 613 installed software instances can be described. The following terms 614 are used in this document: 616 Data model - The format used to structure data within a given 617 records. SWIMA does not constrain the data models it conveys. 619 Record - A populated instance of some data model that describes a 620 software product. 622 Do not confuse the "data model" described here with the SWIMA 623 messages and attributes used to convey information between SWIMA-PVs 624 and PCs. The SWIMA specification dictates the structure of its 625 messages and attributes. Some attributes, however, have specific 626 fields used to convey inventory records, and those fields support an 627 extensible list of data models for their values. By contrast, a data 628 model refers only to the structure used to organize software 629 inventory record data. 631 The data model used to structure software inventory information has 632 very little impact on the behavior of the components defined in this 633 specification. The SWIMA-PV has no dependency on the data model of 634 records conveyed in SWIMA messages. For this reason, it MUST NOT 635 reject a message or respond with a PA-TNC Error due to the data model 636 used to structure records in attributes it receives. Similarly, it 637 MIST NOT reject a message or respond with a PA-TNC Error if a record 638 fails to comply with a stated format, unless that failure prevents 639 correct parsing of the attribute itself. In short, the record bodies 640 are effectively treated as "black boxes" by the SWIMA-PV. (Note that 641 the SWIMA-PV might serve as the front-end of other functionality that 642 does have a dependency on the data model used to structure software 643 information, but any such dependency is beyond the scope of this 644 specification and needs to be addressed outside the behaviors 645 specified in this document. This specification is only concerned 646 with collection and delivery of software inventory information; 647 components that consume and use this information are a separate 648 concern.) 650 The SWIMA-PC does have one functional dependency on the data models 651 used in the software records it delivers, but only insofar as it is 652 required to deterministically create a Software Identifier (described 653 in Section 3.4.1) based on each record it delivers. The SWIMA-PC 654 MUST be able to generate a Software Identifier for each record it 655 delivers, and if the SWIMA-PC cannot do so the record cannot be 656 delivered by the SWIMA-PC. All SWIMA-PCs MUST at least be able to 657 generate Software Identifiers for the data model types specified in 658 Section 6 of this document. A SWIMA-PC MAY include the ability to 659 generate Software Identifiers for other data model types, and thus be 660 able to support them as well. 662 3.3. Basic Attribute Exchange 664 In the most basic exchange supported by this specification, a SWIMA- 665 PV sends a request to the SWIMA-PC requesting some type of 666 information about the endpoint's software inventory. This simple 667 exchange is shown in Figure 2. 669 +-------------+ +--------------+ 670 | SWIMA-PC | | SWIMA-PV | Time 671 +-------------+ +--------------+ | 672 | | | 673 |<------------SWIMA Request---------------| | 674 | | | 675 |-------------SWIMA Response------------->| | 676 | | V 678 Figure 2: Basic SWIMA Attribute Exchange 680 Upon receiving such a SWIMA Request from the SWIMA-PV, the SWIMA-PC 681 is expected to collect all the relevant software inventory 682 information from the endpoint's software evidence collection and 683 place it within its response attribute. 685 SWIMA-PVs MUST discard without error any SWIMA Response attributes 686 that they receive for which they do not know the SWIMA Request 687 parameters that led to this SWIMA Response. This is due to the fact 688 that the SWIMA Request includes parameters that control the nature of 689 the response (as will be described in the following sections) and 690 without knowing those parameters the SWIMA Response cannot be 691 reliably interpreted. Most often receiving an unsolicited SWIMA 692 Response attribute happens when a NEA Server has multiple SWIMA-PVs; 693 one SWIMA-PV sends a SWIMA Request but, unless exclusive delivery is 694 used by the SWIMA-PC in sending the response, both SWIMA-PVs receive 695 copies of the resulting SWIMA Response. In this case, the SWIMA-PV 696 that didn't send the SWIMA Request would lack the context necessary 697 to correctly interpret the SWIMA Response it received and would 698 simply discard it. Note, however, that proprietary measures might 699 allow a SWIMA-PV to discover the SWIMA Request parameters for a SWIMA 700 Response even if that SWIMA-PV did not send the given SWIMA Request. 701 As such, there is no blanket requirement for a SWIMA-PV to discard 702 all SWIMA Responses to SWIMA Request the SWIMA-PV did not generate 703 itself, only that SWIMA-PVs are required to discard SWIMA Responses 704 for which they cannot get the necessary context to interpret. 706 In the case that it is possible to do so, the SWIMA-PC SHOULD send 707 its SWIMA Response attribute to the SWIMA-PV that requested it using 708 exclusive delivery as described in section 4.5 of RFC 5793 (PB-TNC) 709 [RFC5793]. Exclusive delivery ensures that only the sender of the 710 SWIMA Request receives the resulting SWIMA Response. 712 3.4. Core Software Reporting Information 714 Different parameters in the SWIMA Request can influence what 715 information is returned in the SWIMA Response. However, while each 716 SWIMA Response provides different additional information about this 717 installed software, they all share a common set of fields that 718 support reliable software identification on an endpoint. These 719 fields include: Software Identifiers, the Data Model Type, Record 720 Identifiers, Software Locators, and Source Identifiers. These fields 721 are present for each reported piece of software in each type of SWIMA 722 Response. The following sections examine these three types of 723 information in more detail. 725 3.4.1. Software Identifiers 727 A Software Identifier uniquely identifies a specific version of a 728 specific software product. The Software Inventory Message and 729 Attributes for PA-TNC specification does not dictate the structure of 730 a Software Identifier (beyond stating that it is a string) or define 731 how it is created. Instead, each data model described in the 732 Software Data Model IANA table (Section 10.4) includes its own rules 733 for how a Software Identifier is created based on a record in the 734 Endpoint's Software Inventory Evidence Collection expressed in that 735 data model. Other data models will have their own procedures for the 736 creation of associated Software Identifiers. Within the Software 737 Inventory Message and Attributes for PA-TNC specification, the 738 Software Identifier is simply an opaque string and there is never any 739 need to unpack any information that might be part of that identifier. 741 A Software Identifier is a fraction of the size of the inventory 742 record from which it is derived. For some combinations of data 743 models and sources, the full record might never be necessary as the 744 identifier can be directly correlated to the contents of the full 745 record. This is possible with authoritative SWID tags, since these 746 tags always have the same contents and thus a Software Identifier 747 derived from these tags can be used as a lookup to a local copy of 748 the full tag. For other combinations of source and data model, a 749 server might not be able to determine the specific software product 750 and version associated with the identifier without requesting 751 delivery of the full record. However, even in those cases, 752 downstream consumers of this information might never need the full 753 record as long as the Software Identifiers they receive can be 754 tracked reliably. A SWIMA-PV can use Software Identifiers to track 755 the presence of specific software products on an endpoint over time 756 in a bandwidth-efficient manner. 758 There are two important limitations of Software Identifiers to keep 759 in mind: 761 1. The identifiers do not necessarily change when the associated 762 record changes. In some situations, a record in the endpoint's 763 Software Inventory Evidence Collection will change due to new 764 information becoming available or in order to correct prior 765 errors in that information. Such changes might or might not 766 result in changes to the Software Identifier, depending on the 767 nature of the changes and the rules governing how Software 768 Identifiers are derived from records of the appropriate data 769 model. 771 2. It is possible that a single software product is installed on a 772 single endpoint multiple times. If both of these installation 773 instances are reported by the same source using the same data 774 format, then this can result in identical Software Identifiers 775 for each installation instances. In other words, Software 776 Identifiers might not uniquely identify installation instances; 777 they just are intended to uniquely identify software products 778 (which might have more than one installation instance). Instead, 779 to reliably distinguish between multiple instances of a single 780 software product, one needs to make use of Record Identifiers, 781 described in the following section. 783 3.4.2. Data Model Type 785 The Data Model Type consists of two fields: the Data Model Type PEN 786 and the Data Model Type. The combination of these fields is used to 787 identify the type of data model of the associated software inventory 788 record. The data model is significant not only because it informs 789 the recipient of the data model of the associated record, but because 790 the process for generation of the Software Identifier for the record 791 depends on the record's data model. Clearly identifying the type of 792 data model from with the Software Identifier was derived thus 793 provides useful context for that value. 795 The PEN (or Private Enterprise Number) identifies the organization 796 that assigns meaning to the Data Model Type field value. PENs are 797 managed by IANA in the Private Enterprise Numbers registry. PENs 798 allow vendors to designate their own set of data models for software 799 inventory description. IANA reserves the PEN of 0x000000. Data 800 Model Types associated with this PEN are defined in the Software Data 801 Model IANA table, created in Section 10.4 of this specification. 802 Note that this IANA table reserves all values greater than or equal 803 to 0xC0 (192) for enterprise use. This means that local enterprises 804 can use custom data formats and indicate them with the IANA PEN and a 805 Data Model Type value between 0xC0 and 0XFF, inclusive. Those 806 enterprises are responsible for configuring their SWIMA-PCs to 807 correctly report those custom data models. 809 3.4.3. Record Identifiers 811 A Record Identifier is a 4-byte integer generated by the SWIMA-PC 812 that is uniquely associated with a specific record within the 813 Endpoint's Software Inventory Evidence Collection. The SWIMA-PC MUST 814 assign a unique identifier to each record when it is added to the 815 Endpoint's Software Inventory Evidence Collection. The Record 816 Identifier SHOULD remain unchanged if that record is modified. The 817 SWIMA-PC might wish to assign Record Identifiers sequentially, but 818 any scheme is acceptable provided that no two records receive the 819 same identifier. 821 Servers can use Record Identifiers to distinguish between multiple 822 instances of a single software product installed on an endpoint. 823 Since each installation instance of a software product is associated 824 with a separate record, servers can use the record identifier to 825 distinguish between instances. For example, if an event is reported 826 (as described in Section 3.7), the record identifier will allow the 827 server to discern which instance of a software product is involved. 829 3.4.4. Software Locators 831 In addition to the need to identify software products, many use cases 832 of inventory information need to know where software is located on 833 the endpoint. This information might be needed to direct remediation 834 actions or similar processes. For this reason, every reported 835 software product also includes a Software Locator to identify where 836 the software is installed on the endpoint. 838 If the location is not provided directly by the record source the 839 SWIMA-PC is responsible for attempting to determine the location of 840 the software product. The "location" of a product SHOULD be the 841 directory in which the software products executables are kept. 842 However, if that directory is shared by other software products, the 843 "location" SHOULD be the location of the primary executable 844 associated with the software product. The source and/or SWIMA-PC 845 MUST be consistent in reporting the location of a software product 846 (i.e., it cannot use the executable location in one report and the 847 directory location in another). 849 The location is expressed as a URI string consisting of a scheme and 850 path. [RFC3986] The location URI does not include an authority part. 851 The URI schema describes the context of the described location. For 852 example, in most cases the location of the installed software product 853 will be expressed in terms of its path in the filesystem. For such 854 locations, the location URI scheme MUST be "file" or the URI MUST 855 appear without a scheme. (I.e., "file" is default scheme.) It is 856 possible that other schemes could be used to represent other location 857 contexts. Apart from reserving the "file" scheme, this specification 858 does not reserve schemes. When representing software products in 859 other location contexts, tools MUST be consistent in their use of 860 schemes, but the exact string used in those schemes is not 861 normatively defined here. 863 It is possible, that a SWIMA-PC is unable to determine the location 864 of a reported software product. In this case, the SWIMA-PC MUST 865 provide a zero-length Software Locator. However, SWIMA-PCs SHOULD 866 only make such an assignment as a last resort. Even a probable 867 location for a software product is preferable to using a zero-length 868 locator. 870 3.4.5. Source Identifiers 872 All SWIMA-PCs MUST track the source of each piece of software 873 information they report. Each time a SWIMA-PC gets information to 874 send to a given SWIMA-PV from a new source (from the perspective of 875 that SWIMA-PV), the SWIMA-PC MUST assign that source a Source 876 Identification Number, which is an 8-bit unsigned integer. Each item 877 reported includes the Source Identification Number that provided that 878 information. All information that is provided by that source, MUST 879 be delivered with this same Source Identification Number. This MUST 880 be done for each source used. If the SWIMA-PC ever is unclear as to 881 whether a given source is new or not, it MUST assume that this is a 882 new source and assign it a new Source Identification Number. Source 883 Identification Numbers can help with (although will not completely 884 eliminate) the challenges posed by multiple reporting of a single 885 software instance: since a single source would only report an 886 instance or event once, if multiple reports of a similar instance 887 come from multiple sources, this might be an instance of multiple 888 reporting (although it still might not be so). On the other hand, if 889 multiple instances are reported by a single source, this almost 890 certainly means that there are actually multiple instance that are 891 being legitimately reported. 893 The SWIMA-PC is responsible for tracking associations between Source 894 Identifiers and the given data source. This association MUST remain 895 consistent with regard to a given SWIMA-PV while there is an active 896 PB-TNC session with that SWIMA-PV. The SWIMA-PC MAY have a different 897 Source Identifier association for different SWIMA-PVs. Likewise, the 898 SWIMA-PC MAY change the Source Identifier association for a given 899 SWIMA-PV if the PB-TNC session terminates. However, implementers of 900 SWIMA-PCs will probably find it easier to manage associations by 901 maintaining the same association for all SWIMA-PVs and across 902 multiple sessions. 904 Of special note, events records reported from the SWIMA-PC's event 905 log (discussed in Section 3.7) also need to be sent with their 906 associated data source. The Source Identifier reported with events 907 MUST be the current (i.e., at the time the event is sent) Source 908 Identifier associated with the data source that produced the event, 909 regardless of how long ago that event occurred. Event logs are 910 likely to persist far longer than a single PB-TNC session. SWIMA-PCs 911 MUST ensure that each event can be linked to the appropriate data 912 source, even if the Source Identifiers used when the event was 913 created have since been reassigned. In other words, when sending an 914 event, it needs to be sent with the Source Identifier currently 915 linked to the data source that produced it, regardless of whether a 916 different Source Identifier would have been associated with the event 917 when the event was first created. 919 Note that the Source Identification Number is primarily used to 920 support recognition, rather than identification, of sources. That is 921 to say, a Software Identification Number can tell a recipient that 922 two events were reported by the same source, but will not necessarily 923 help that recipient determine which source was used. Moreover, 924 different SWIMA-PCs will not necessarily use the same Source 925 Identification Numbers for the same sources. SWIMA-PCs MUST track 926 the assignment of Source Identification Numbers to ensure consistent 927 application thereof. SWIMA-PCs MUST also track which Source 928 Identification Numbers have been used with each SWIMA-PV with which 929 they communicate. 931 3.4.6. Using Software and Record Identifiers in SWIMA Attributes 933 A SWIMA Attribute reporting an endpoint's Software Inventory Evidence 934 Collection always contains the Software Identifiers associated with 935 the identified software products. A SWIMA Attribute might or might 936 not also contain copies of software inventory evidence records. The 937 attribute exchange is identical to the diagram shown in Figure 2 938 regardless of whether software inventory evidence records are 939 included. The SWIMA Request attribute indicates whether the response 940 is required to include software inventory evidence records. 941 Excluding software inventory evidence records can reduce the 942 attribute size of the response by multiple orders of magnitude when 943 compared to sending the same inventory with full records. 945 3.5. Targeted Requests 947 Sometimes a SWIMA-PV does not require information about every piece 948 of software on an endpoint but only needs to receive updates about 949 certain software instances. For example, enterprise endpoints might 950 be required to have certain software products installed and to keep 951 these updated. Instead of requesting a complete inventory just to 952 see if these products are present, the SWIMA-PV can make a "targeted 953 request" for the software in question. 955 Targeted requests follow the same attribute exchange described in 956 Figure 2. The SWIMA-PV targets its request by providing one or more 957 Software Identifiers in its SWIMA Request attribute. The SWIMA-PC 958 MUST then limit its response to contain only records that match the 959 indicated Software Identifier(s). This allows the network exchange 960 to exclude information that is not relevant to a given policy 961 question, thus reducing unnecessary bandwidth consumption. The 962 SWIMA-PC's response might or might not include software inventory 963 evidence records, depending on the parameters of the SWIMA Request. 965 Note that targeted requests identify the software relevant to the 966 request only through Software Identifiers. This specification does 967 not support arbitrary, parameterized querying of records. For 968 example, one cannot request all records from a certain software 969 publisher, or all records created by a particular record source. 970 Targeted requests only allow a requestor to request specific software 971 (as identified by their Software Identifiers) and receive a response 972 that is limited to the named software. 974 There is no assumption that a SWIMA-PC will recognize "synonymous 975 records" - that is, records from different sources for the same 976 software. Recall that different sources and data models may use 977 different Software Identifier strings for the same software product. 978 The SWIMA-PC returns only records that match the Software Identifiers 979 in the SWIMA Request, even if there might be other records in the 980 endpoint's Software Inventory Evidence Collection for the same 981 software product. This is necessary because SWIMA-PCs might not have 982 the ability to determine that two Software Identifiers refer to the 983 same product. 985 Targeted requests do not include Record Identifiers or Software 986 Locators. The response to a targeted request MUST include all 987 records associated with the named Software Identifiers, including the 988 case where there are multiple records associated with a single 989 Software Identifier. 991 SWIMA-PCs MUST accept targeted requests and process them correctly as 992 described above. SWIMA-PVs MUST be capable of making targeted 993 requests and processing the responses thereto. 995 3.6. Monitoring Changes in an Endpoint's Software Inventory Evidence 996 Collection 998 The software collection on an endpoint is not static. As software is 999 installed, uninstalled, patched, or updated, the Software Inventory 1000 Evidence Collection is expected to change to reflect the new software 1001 state on the endpoint. Different record sources might update the 1002 evidence collection at different rates. For example, a package 1003 manager might update its records in the Software Inventory Evidence 1004 Collection immediately whenever it is used to add or remove a 1005 software product. By contrast, sources that perform periodic 1006 examination of the endpoint would likely only update their records in 1007 the Software Inventory Evidence Collection after each examination. 1009 All SWIMA-PCs MUST be able to be able to detect changes to the 1010 Software Inventory Evidence Collection. Specifically, SWIMA-PCs MUST 1011 be able to detect: 1013 o The creation of records 1015 o The deletion of records 1017 o The alteration of records 1019 An "alteration" is anything that modifies the contents of a record 1020 (or would modify it, if the record is dynamically generated on 1021 demand) in any way, regardless of whether the change is functionally 1022 meaningful. 1024 SWIMA-PCs MUST detect such changes to the endpoint's Software 1025 Inventory Evidence Collection in close to real-time (i.e., within 1026 seconds) when the Posture Collector is operating. In addition, in 1027 the case where there is a period during which the SWIMA-PC is not 1028 operating, the SWIMA-PC MUST be able to determine the net change to 1029 the endpoint's Software Inventory Evidence Collection over the period 1030 it was not operational. Specifically, the "net change" represents 1031 the difference between the state of the endpoint's Software Inventory 1032 Evidence Collection when the SWIMA-PC was last operational and 1033 monitoring its state, and the state of the endpoint's software 1034 inventory evidence collection when the SWIMA-PC resumed operation. 1035 Note that a net change might not reflect the total number of change 1036 events over this interval. For example, if a record was altered 1037 three times during a period when the SWIMA-PC was unable to monitor 1038 for changes, the net change of this interval might only note that 1039 there was an alteration to the record, but not how many individual 1040 alteration events occurred. It is sufficient for a SWIMA-PC's 1041 determination of a net change to note that there was a difference 1042 between the earlier and current state rather than enumerating all the 1043 individual events that allowed the current state to be reached. 1045 The SWIMA-PC MUST assign a time to each detected change in the 1046 endpoint's Software Inventory Evidence Collection. These timestamps 1047 correspond to the SWIMA-PC's best understanding as to when the 1048 detected change occurred. For changes to the endpoint's Software 1049 Inventory Evidence Collection that occur while the SWIMA-PC is 1050 operating, the SWIMA-PC ought to be able to assign a time to the 1051 event that is accurate to within a few seconds. For changes to the 1052 endpoint's Software Inventory Evidence Collection that occur while 1053 the SWIMA-PC is not operational, upon becoming operational the SWIMA- 1054 PC needs to make a best guess as to the time of the relevant events 1055 (possibly by looking at timestamps on files), but these values might 1056 be off. In the case of dynamically generated records, the time of 1057 change is the time at which the data from which the records are 1058 generate changes, not the time at which a changed record is 1059 generated. For example, if records are dynamically generated based 1060 on data in an RPM database, the time of change would be when the RPM 1061 database changed. 1063 With regard to deletions of records, the SWIMA-PC needs to detect the 1064 deletion and MUST retain a copy of the full deleted record along with 1065 the associated Record Identifier and Software Locator so that the 1066 record and associated information can be provided to the SWIMA-PV 1067 upon request. This copy of the record MUST be retained for a 1068 reasonable amount of time. Vendors and administrators determine what 1069 "reasonable" means, but a copy of the record SHOULD be retained for 1070 as long as the event recording the deletion of the record remains in 1071 the SWIMA-PC's event log (as described in Section 3.7). This is 1072 recommended because, as long as the event is in the SWIMA-PC's change 1073 logs, the SWIMA-PC might send an event attribute (described in 1074 Section 3.7) that references this record, and a copy of the record is 1075 needed if the SWIMA-PV wanted a full copy of the relevant records. 1076 In the case that there a SWIMA-PC is called upon to report a deleted 1077 record that is no longer available, the SWIMA-PC SHOULD return a 1078 0-length record. 1080 With regard to alterations to a record, SWIMA-PCs MUST detect any 1081 alterations to the contents of a record. Alterations need to be 1082 detected even if they have no functional impact on the record. A 1083 good guideline is that any alteration to a record that might change 1084 the value of a hash taken on the record's contents needs to be 1085 detected by the SWIMA-PC. A SWIMA-PC might be unable to distinguish 1086 modifications to the content of a record from modifications to the 1087 metadata the file system associates with the record. For example, a 1088 SWIMA-PC might use the "last modification" timestamp as an indication 1089 of alteration to a given record, but a record's last modification 1090 time can change for reasons other than modifications to the record 1091 contents. A SWIMA-PC is still considered compliant with this 1092 specification if it also reports metadata change events that do not 1093 change the record itself as alterations to the record. In other 1094 words, while SWIMA-PC authors are encouraged to exclude modifications 1095 that do not affect the bytes within the record, discriminating 1096 between modifications to file contents and changes to file metadata 1097 can be difficult and time consuming on some systems. As such, as 1098 long as the alterations detected by a SWIMA-PC always cover all 1099 modifications to the contents of record, the SWIMA-PC is considered 1100 compliant even if it also registers alterations that do not modify 1101 the contents of a record as well. When recording an alteration to a 1102 record, the SWIMA-PC is only required to note that an alteration 1103 occurred. The SWIMA-PC is not required to note or record how the 1104 record altered, nor is it possible to include such details in SWIMA 1105 Attributes reporting the change to a SWIMA-PV. There is no need to 1106 retain a copy of the original record. 1108 When a record changes it SHOULD retain the same Record Identifier. 1109 The Software Locator might or might not change, depending on whether 1110 the software changed locations during the changes that led to the 1111 record change. A record change MUST retain the same Software 1112 Identifier. This means that any action that changes a software 1113 product (e.g., application of a patch that results in a change to the 1114 product's version) MUST NOT be reflected by a record change but 1115 instead MUST result in the deletion of the old record and the 1116 creation of a new record. This reflects the requirement that a 1117 record in the endpoint's Software Inventory Evidence Collection 1118 correspond directly with an instance of a specific software product. 1120 3.7. Reporting Change Events 1122 As noted in the preceding section, SWIMA-PCs MUST be able to detect 1123 changes to the endpoints Software Inventory Evidence Collection 1124 (creation, deletion, and alteration) in near real-time while the 1125 SWIMA-PC is operational, and MUST be able to account for any net 1126 change to the endpoint's Software Inventory Evidence Collection that 1127 occurs when the SWIMA-PC is not operational. However, to be of use 1128 to the enterprise, the NEA Server needs to be able to receive these 1129 events and be able to understand how new changes relate to earlier 1130 changes. In Software Inventory Message and Attributes for PA-TNC, 1131 this is facilitated by reporting change events. All SWIMA-PCs MUST 1132 be capable of receiving requests for change events and sending change 1133 event attributes. All SWIMA-PVs MUST be capable of requesting and 1134 receiving change event attributes. 1136 3.7.1. Event Identifiers 1138 To be useful, change events need to be correctly ordered. Ordering 1139 of events is facilitated by two pieces of information: an Event 1140 Identifier (EID) value and an EID Epoch value. 1142 An EID is a 4-byte unsigned integer that the SWIMA-PC assigns 1143 sequentially to each observed event (whether detected in real-time or 1144 deduced by looking for net changes over a period of SWIMA-PC 1145 inactivity). All EIDs exist within the context of some "EID Epoch", 1146 which is also represented as a 4-byte unsigned integer. EID Epochs 1147 are used to ensure synchronization between the SWIMA-PC and any 1148 SWIMA-PVs with which it communicates. EID Epoch values MUST be 1149 generated in such a way as to minimize the chance that an EID Epoch 1150 will be reused, even in the case where the SWIMA-PC reverts to an 1151 earlier state. For this reason, sequential EID Epochs are 1152 discouraged, since loss of state could result in value reuse. In the 1153 case where a SWIMA-PC needs to reset its EID counter, either because 1154 it has exhausted all available EID values or because the SWIMA-PC's 1155 event log becomes corrupted, then a new EID Epoch MUST be selected. 1157 Within an Epoch, EIDs MUST be assigned sequentially, so that if a 1158 particular event is assigned an EID of N, the next observed event is 1159 given an EID of N+1. In some cases, events might occur 1160 simultaneously, or the SWIMA-PC might not otherwise be able to 1161 determine an ordering for events. In these cases, the SWIMA-PC 1162 creates an arbitrary ordering of the events and assigns EIDs 1163 according to this ordering. Two change events MUST NOT ever be 1164 assigned the same EID within the same EID Epoch. No meaningful 1165 comparison can be made between EID values of different Epochs. 1167 The EID value of 0 is reserved and MUST NOT be associated with any 1168 event. Specifically, an EID of 0 in a SWIMA Request attribute 1169 indicates that a SWIMA-PV wants an inventory response rather than an 1170 event response, while an EID of 0 in a SWIMA Response is used to 1171 indicate the initial state of the endpoint's Software Inventory 1172 Evidence Collection prior to the observation of any events. Thus the 1173 very first recorded event in a SWIMA-PC's records within an EID Epoch 1174 MUST be assigned a value of 1 or greater. Note that EID and EID 1175 Epoch values are assigned by the SWIMA-PC without regard to whether 1176 events are being reported to one or more SWIMA-PVs. The SWIMA-PC 1177 records events and assigns EIDs during its operation. Any and all 1178 SWIMA-PVs that request event information from the SWIMA-PC will have 1179 those requests served from the same event records and thus will see 1180 the same EIDs and EID Epochs for the same events. 1182 If a SWIMA-PC uses multiple sources, a SWIMA-PC's assignment of EIDs 1183 MUST reflect the presence and order of all events on the endpoint (at 1184 least for supported sources) regardless of the source. This means 1185 that if source A experiences an event, and then source B experiences 1186 two events, and then source A experiences another two events, the 1187 SWIMA-PC is required to capture five events with consecutive EID 1188 values reflecting the order in which the events occur. 1190 The SWIMA-PC MUST ensure there is no coverage gap (i.e., change 1191 events that are not recorded in the SWIMA-PC's records) in its change 1192 event records. This is necessary because a coverage gap might give a 1193 SWIMA-PV a false impression of the endpoint's state. For example, if 1194 a SWIMA-PV saw an event indicating that a particular record had been 1195 added to the endpoint's software inventory evidence collection, and 1196 saw no subsequent events indicating that record had been deleted, it 1197 might reasonably assume that this record was still present and thus 1198 that the indicated software was still installed (assuming the Epoch 1199 has not changed). If there is a coverage gap in the SWIMA-PC's event 1200 records, however, this assumption could be false. For this reason, 1201 the SWIMA-PC's event records MUST NOT contain gaps. In the case 1202 where there are periods where it is possible that changes occurred 1203 without the SWIMA-PC detecting or recording them, the SWIMA-PC MUST 1204 either compute a net change and update its event records 1205 appropriately, or pick a new EID Epoch to indicate a discontinuity 1206 with previous event records. 1208 Within a given Epoch, once a particular event has been assigned an 1209 EID, this association MUST NOT be changed. That is, within an Epoch, 1210 once an EID is assigned to an event, that EID cannot be reassigned to 1211 a different event, and the event cannot be assigned a different EID. 1212 When the SWIMA-PC's Epoch changes, all of these associations between 1213 EIDs and events are cancelled, and EID values once again become free 1214 for assignment. 1216 3.7.2. Core Event Tracking Information 1218 Whether reporting events or full inventories it is important to know 1219 how the reported information fits into the overall timeline of change 1220 events. This is why all SWIMA Response attributes include fields to 1221 place that response within the sequence of detected events. 1222 Specifically, all SWIMA Responses include a Last EID and EID Epoch 1223 field. The EID Epoch field identifies the EID Epoch in which the 1224 SWIMA Response was sent. If the SWIMA Response is reporting events, 1225 all reported events occurred within the named EID Epoch. The Last 1226 EID (which is also always from the named EID Epoch) indicates the EID 1227 of the last recorded change event at the time that the SWIMA Response 1228 was sent. These two fields allow any response to be placed in the 1229 context of the complete set of detected change events within a given 1230 EID Epoch. 1232 3.7.3. Updating Inventory Knowledge Based on Events 1234 Modern endpoints can have hundreds of software products installed, 1235 most of which are unlikely to change from one day to the next. As 1236 such, instead of exchanging a complete list of an endpoint's 1237 inventory on a regular basis, one might wish to only identify changes 1238 since some earlier known state of this inventory. This is readily 1239 facilitated by the use of EIDs to place change events in a context 1240 relative to earlier state. 1242 As noted above, every SWIMA Response sent by a SWIMA-PC to a SWIMA-PV 1243 (as described in Section 3.3 through Section 3.5) includes the EID 1244 Epoch and EID of the last event recorded prior to that response being 1245 compiled. This allows the SWIMA-PV to place all subsequently 1246 received event records in context relative to this SWIMA Response 1247 attribute (since the EIDs represent a total ordering of all changes 1248 to the endpoint's software inventory evidence collection). 1249 Specifically, a SWIMA-PV (or, more likely, a database that collects 1250 and records its findings) can record an endpoint's full inventory and 1251 also the EID and Epoch of the most recent event reflected at the time 1252 of that inventory. From that point on, if change events are 1253 observed, the attribute describing these events indicates the nature 1254 of the change, the affected records, and the order in which these 1255 events occurred (as indicated by the sequential EIDs). Using this 1256 information, any remote record of the endpoint's Software Inventory 1257 Evidence Collection can be updated appropriately. 1259 3.7.4. Using Event Records in SWIMA Attributes 1261 A SWIMA-PV MUST be able to request a list of event records instead of 1262 an inventory. The attribute flow in such an exchange looks the same 1263 as the basic flow shown in Figure 2. The only difference is that, in 1264 the SWIMA Request attribute, the SWIMA-PV provides an EID other than 1265 0. (A value of 0 in these fields represents a request for an 1266 inventory.) When the SWIMA-PC receives such a request, instead of 1267 identifying records from the endpoint's Software Inventory Evidence 1268 Collection, it consults its list of detected changes. The SWIMA-PC 1269 MUST add an event record to the SWIMA Response attribute for each 1270 recorded change event with an EID greater than or equal to the EID in 1271 the SWIMA Request attribute (although targeting of requests, as 1272 described in the next paragraph, might limit this list). A list of 1273 event records MUST only contain events with EIDs that all come from 1274 the current Epoch. 1276 SWIMA-PVs can target requests for event records by including one or 1277 more Software Identifiers, as described in Section 3.5, in the SWIMA 1278 Request that requests an event record list. A targeted request for 1279 event records is used to indicate that only events affecting software 1280 that matches one of the provided Software Identifiers are to be 1281 returned. Specifically, in response to a targeted request for event 1282 records, the SWIMA-PC MUST exclude any event records that are less 1283 than the indicated EID (within the current EID Epoch) and exclude any 1284 event records where the affected software does not match one of the 1285 provided Software Identifiers. This might mean that the resulting 1286 list of event records sent in the response attribute does not provide 1287 a continuous sequence of EIDs. Both SWIMA-PCs and SWIMA-PVs MUST 1288 support targeted request for event records. 1290 3.7.5. Partial and Complete Lists of Event Records in SWIMA Attributes 1292 Over time, a SWIMA-PC might record a large number of change events. 1293 If a SWIMA-PV requests all change events covering a large period of 1294 time, the resulting SWIMA Response attribute might be extremely 1295 large, especially if the SWIMA-PV requests inclusion of software 1296 inventory evidence records in the response. In the case that the 1297 resulting attribute is too large to send (either because it exceeds 1298 the 4GB attribute size limit imposed by the PA-TNC specification, or 1299 because it exceeds some smaller size limit imposed on the SWIMA-PC) 1300 the SWIMA-PC MAY send a partial list of event records back to the 1301 SWIMA-PV. 1303 Generation of a partial list of events in a SWIMA Response attribute 1304 requires the SWIMA-PC to identify a "consulted range" of EIDs. A 1305 consulted range is the set of event records that are examined for 1306 inclusion in the SWIMA Response attribute and that are included in 1307 that attribute if applicable. Recall that, if a SWIMA Request is 1308 targeted, only event records that involve the indicated software 1309 would be applicable. (See Section 3.5 for more on Targeted Request.) 1310 If a request is not targeted, all event records in the considered 1311 range are applicable and included in the SWIMA Response attribute. 1313 The lower bound of the consulted range MUST be the EID provided in 1314 the SWIMA Request. (Recall that a SWIMA Request indicates a request 1315 for event records by providing a non-0 EID value in the SWIMA 1316 Request. See Section 3.7.4.) The upper bound of the consulted range 1317 is the EID of the latest event record (as ordered by EID values) that 1318 is included in the SWIMA Response attribute if it is applicable to 1319 the request. The EID of this last event record is called the "Last 1320 Consulted EID". The SWIMA-PC chooses this Last Consulted EID based 1321 on the size of the event record list it is willing to provide to the 1322 SWIMA-PV. 1324 A partial result list MUST include all applicable event records 1325 within the consulted range. This means that for any applicable event 1326 record (i.e., any event record in an un-targeted request, or any 1327 event record associated with software matching a requested Software 1328 Identifier in a targeted request) whose EID is greater than or equal 1329 to the EID provided in the SWIMA Request and whose EID is less than 1330 or equal to the Last Consulted EID, that event record MUST be 1331 included in the SWIMA Response conveying this partial list of event 1332 records. This ensures that every partial list of event records is 1333 always complete within its indicated range. 1335 All SWIMA Response attributes that convey event records include a 1336 Last Consulted EID field. This is in addition to the EID Epoch and 1337 Last EID fields that are present in all SWIMA Responses. Note that, 1338 if responding to a targeted SWIMA Request, the SWIMA Response 1339 attribute might not contain the event record whose EID matches the 1340 Last Consulted EID value. For example, the last consulted EID record 1341 might have been deemed inapplicable because it did not match the 1342 specified list of Software Identifiers in the SWIMA Request. 1344 If a SWIMA-PV receives a SWIMA Response attribute where the Last EID 1345 and Last Consulted EID fields are identical, the SWIMA-PV knows that 1346 it has received a result list that is complete, given the parameters 1347 of the request, up to the present time. 1349 On the other hand, if the Last EID is greater than the Last Consulted 1350 EID, the SWIMA-PV has received a partial result list. (The Last 1351 Consulted EID MUST NOT exceed the Last EID.) In this case, if the 1352 SWIMA-PV wishes to try to collect the rest of the partially delivered 1353 result list it then sends a new SWIMA Request whose EID is one 1354 greater than the Last Consulted EID in the preceding response. Doing 1355 this causes the SWIMA-PC to generate another SWIMA Response attribute 1356 containing event records where the earliest reported event record is 1357 the one immediately after the event record with the Last Consulted 1358 EID (since EIDs are assigned sequentially). By repeating this 1359 process until it receives a SWIMA Response where the Last EID and 1360 Last Consulted EID are equal, the SWIMA-PV is able to collect all 1361 event records over a given range, even if the complete set of event 1362 records would be too large to deliver via a single attribute. 1364 Implementers need to be aware that a SWIMA Request might specify an 1365 EID that is greater than the EID of the last event recorded by a 1366 SWIMA-PC. In accordance with the behaviors described in 1367 Section 3.7.4, a SWIMA-PC MUST respond to such a request with a SWIMA 1368 Response attribute that contains zero event records. This is because 1369 the SWIMA-PC has recorded no event records with EIDs greater than or 1370 equal to the EID in the SWIMA Request. In such a case, the Last 1371 Consulted EID field MUST be set to the same value as the Last EID 1372 field in this SWIMA Response attribute. This case is called out 1373 because the consulted range on a SWIMA-PC in such a situation is a 1374 negative range, where the "first" EID in the range (provided in the 1375 SWIMA Request) is greater than the "last" EID in the range (this 1376 being the EID of the last recorded event on the SWIMA-PC). 1377 Implementers need to ensure that SWIMA-PCs do not experience problems 1378 in such a circumstance. 1380 Note that this specification only supports the returning of partial 1381 results when returning event records. There is no way to return a 1382 partial inventory list under this specification. 1384 3.7.6. Synchronizing Event Identifiers and Epochs 1386 Since EIDs are sequential within an Epoch, if a SWIMA-PV's list of 1387 event records contains gaps in the EID values within a single Epoch, 1388 the SWIMA-PV knows that there are events that have not been accounted 1389 for. The SWIMA-PV can either request a new event list to collect the 1390 missing events or request a full inventory to re-sync its 1391 understanding of the state of the endpoint's Software Inventory 1392 Evidence Collection. In either case, after the SWIMA-PV's record of 1393 the endpoint's Software Inventory Evidence Collection has been 1394 updated, the SWIMA-PV can record the new latest EID value and track 1395 events normally from that point on. 1397 If the SWIMA-PV receives any attribute from a SWIMA-PC where the EID 1398 Epoch differs from the EID Epoch that was used previously, then 1399 SWIMA-PV or any entity using this information to track the endpoint's 1400 Software Inventory Evidence Collection knows that there is a 1401 discontinuity in their understanding of the endpoint's state. To 1402 move past this discontinuity and reestablish a current understanding 1403 of the state of the endpoint's Software Inventory Evidence 1404 Collection, the SWIMA-PV needs to receive a full inventory from the 1405 endpoint. The SWIMA-PV cannot be brought in sync with the endpoint's 1406 state through the collection of any set of event records in this 1407 situation. This is because it is not possible to account for all 1408 events on the SWIMA-PC since the previous Epoch was used, because 1409 there is no way to query for EIDs from a previous Epoch. Once the 1410 SWIMA-PV has received a full inventory for the new Epoch, the SWIMA- 1411 PV records the latest EID reported in this new Epoch and can track 1412 further events normally. 1414 A SWIMA-PC MUST NOT report events with EIDs from any Epoch other than 1415 the current EID Epoch. The SWIMA-PC MAY choose to purge all event 1416 records from a previous Epoch from memory after an Epoch change. 1417 Alternately, the SWIMA-PC MAY choose to retain some event records 1418 from a previous EID Epoch and assign them new EIDs in the current 1419 Epoch. However, in the case where a SWIMA-PC chooses the latter 1420 option it MUST ensure that the order of events according to their 1421 EIDs is unchanged and that there is no coverage gap between the first 1422 retained event recorded during the previous Epoch (now reassigned 1423 with an EID in the current Epoch) and the first event recorded during 1424 the current Epoch. In particular, the SWIMA-PC MUST ensure that all 1425 change events that occurred after the last recorded event from the 1426 previous Epoch are known and recorded. (This might not be possible 1427 if the Epoch change is due to state corruption on the SWIMA-PC.) A 1428 SWIMA-PC might choose to reassign EIDs to records from a preceding 1429 Epoch to create a "sliding window" of events, where each Epoch change 1430 represents a shift in the window of available events. 1432 In the case where a SWIMA-PC suffers a crash and loses track of its 1433 current EID Epoch or current EID, then it MUST generate a new EID 1434 Epoch value and begin assigning EIDs within that Epoch. In this 1435 case, the SWIMA-PC MUST purge all event records from before the crash 1436 as it cannot ensure that there is not a gap between the last of those 1437 records and the next detected event. The process for generating a 1438 new EID Epoch MUST minimize the possibility that the newly generated 1439 EID Epoch is the same as a previously used EID Epoch. 1441 The SWIMA-PV will normally never receive an attribute indicating that 1442 the latest EID is less than the latest EID reported in a previous 1443 attribute within the same EID Epoch. If this occurs, the SWIMA-PC 1444 has suffered an error of some kind, possibly indicative of at least 1445 partial corruption of its event log. In this case, the SWIMA-PV MUST 1446 treat the situation as if there was a change in Epoch and treat any 1447 local copy of the endpoint's Software Inventory Evidence Collection 1448 as out-of-sync until a full inventory can be reported by the SWIMA- 1449 PC. In this case, the SWIMA-PV SHOULD log the occurrence so the 1450 SWIMA-PC can be examined to ensure it is now operating properly. 1452 3.8. Subscriptions 1454 Thus far, all attribute exchanges discussed assume that a SWIMA-PV 1455 sent an SWIMA Request attribute and the SWIMA-PC is providing a 1456 direct response to that request. The Software Inventory Message and 1457 Attributes for PA-TNC specification also supports the ability for a 1458 SWIMA-PC to send a SWIMA Response to the SWIMA-PV in response to 1459 observed changes in the endpoint's software inventory evidence 1460 collection, instead of in direct response to a SWIMA Request. An 1461 agreement by a SWIMA-PC to send content when certain changes are 1462 detected to the endpoint's Software Inventory Evidence Collection is 1463 referred to in this specification as a "subscription", and the SWIMA- 1464 PV that receives this content is said to be "subscribed to" the given 1465 SWIMA-PC. All SWIMA-PCs and SWIMA-PVs MUST support the use of 1466 subscriptions. 1468 3.8.1. Establishing Subscriptions 1470 A SWIMA-PV establishes a subscription on a particular SWIMA-PC by 1471 sending a SWIMA Request attribute with the Subscription flag set. 1472 The SWIMA Request attribute is otherwise identical to the SWIMA 1473 Requests discussed in previous sections. Specifically, such a SWIMA 1474 Request might or might not request inclusion of software inventory 1475 evidence records, might or might not be targeted, and might request 1476 change event records or endpoint inventory. Assuming no error is 1477 encountered, a SWIMA-PC MUST send a SWIMA Response attribute in 1478 direct response to this SWIMA Request attribute, just as if the 1479 Subscription flag was not set. As such, the attribute exchange that 1480 establishes a new subscription in a SWIMA-PC has the same flow seen 1481 in the previous attribute exchanges, as depicted in Figure 2. If the 1482 SWIMA-PV does not receive a PA-TNC Error attribute (as described in 1483 Section 3.9 and Section 5.16) in response to their subscription 1484 request, the subscription has been successfully established on the 1485 SWIMA-PC. The SWIMA Request attribute that establishes a new 1486 subscription is referred to as the "establishing request" for that 1487 subscription. 1489 When a subscription is established it is assigned a Subscription ID 1490 value. The Subscription ID is equal to the value of the Request ID 1491 of the establishing request. (For more about Request IDs, see 1492 Section 5.6.) 1494 A SWIMA-PC MUST have the ability to record and support multiple 1495 simultaneous subscriptions from a single party and from multiple 1496 parties. A SWIMA-PV MUST have the ability to record and support 1497 multiple simultaneous subscriptions to a single party and 1498 subscriptions to multiple parties. 1500 3.8.2. Managing Subscriptions 1502 The SWIMA-PC MUST record each accepted subscription along with the 1503 identity of the party to whom attributes are to be pushed in 1504 compliance with the subscription. This identity includes both the 1505 NEA Server's connection ID and the Posture Validator Identifier from 1506 the PB-PA message that delivered the request. 1508 Likewise, SWIMA-PVs MUST record each accepted subscription for which 1509 they are the subscribing party along with the associated Subscription 1510 ID and the identity of the SWIMA-PC that will be fulfilling the 1511 subscription. The SWIMA-PV needs to retain this information in order 1512 to correctly interpret pushed SWIMA Response attributes sent in 1513 fulfillment of the subscription. The identity of the SWIMA-PC is 1514 given in the Posture Collector Identifier of the PB-PA message header 1515 in all messages from that SWIMA-PC. 1517 3.8.3. Terminating Subscriptions 1519 Subscriptions MAY be terminated at any time by the subscribing SWIMA- 1520 PV by setting the Clear Subscriptions flag in a SWIMA Request. (See 1521 Section 5.7 for more on using this flag.) In the case that a SWIMA 1522 Request with the Clear Subscriptions flag set is received the SWIMA- 1523 PC MUST only clear subscriptions that match both the NEA server 1524 connection ID and the SWIMA-PV ID for this SWIMA Request, and MUST 1525 clear all such subscriptions. 1527 This specification does not give the SWIMA-PV the ability to 1528 terminate subscriptions individually - all subscriptions to the 1529 SWIMA-PV are cleared when the Clear Subscriptions flag is set. 1531 This specification does not give the SWIMA-PC the ability to 1532 unilaterally terminate a subscription. However, if the SWIMA-PC 1533 experiences a fatal error fulfilling a subscription, resulting in 1534 sending a PA-TNC Error attribute of type 1535 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose 1536 fulfillment led to the error MUST be treated as terminated by both 1537 the SWIMA-PC and the SWIMA-PV. Only the subscription experiencing 1538 the error is cancelled and other subscriptions are unaffected. See 1539 Section 3.9 for more on this error condition. 1541 Finally, a subscription is terminated if the connection between the 1542 SWIMA-PC and SWIMA-PV is deleted. This occurs when the connection ID 1543 used in the messages between the SWIMA-PC and the SWIMA-PV becomes 1544 unbound. Loss of this connection ID would prevent the SWIMA-PC from 1545 sending messages in fulfillment of this subscription. As such, loss 1546 of the connection ID necessarily forces subscription termination 1547 between the affected parties. 1549 3.8.4. Subscription Status 1551 A SWIMA-PV can request that a SWIMA-PC report the list of active 1552 subscriptions for which the SWIMA-PV is the subscriber. A SWIMA-PV 1553 can use this to recover lost information about active subscriptions. 1554 A SWIMA-PV can also use this capability to verify that a SWIMA-PC has 1555 not forgotten any of its subscriptions. The latter is especially 1556 useful where a SWIMA-PC does not send any attributes in fulfillment 1557 of a given subscription for a long period of time. The SWIMA-PV can 1558 check the list of active subscriptions on the SWIMA-PC and verify 1559 whether the inactivity is due to a lack of reportable events or due 1560 to the SWIMA-PC forgetting its obligations to fulfill a given 1561 subscription. 1563 A SWIMA-PV requests a list of its subscriptions on a given SWIMA-PC 1564 by sending that SWIMA-PC a Subscription Status Request. The SWIMA-PC 1565 MUST then respond with a Subscription Status Response (or a PA-TNC 1566 Error if an error condition is experienced). The Subscription Status 1567 Response MUST contain one subscription record for each of the active 1568 subscriptions for which the SWIMA-PV is the subscribing party. 1570 3.8.5. Fulfilling Subscriptions 1572 As noted in Section 3.6 SWIMA-PCs MUST have the ability to 1573 automatically detect changes to an endpoint's Software Inventory 1574 Evidence Collection in near real-time. For every active 1575 subscription, the SWIMA-PC MUST send an attribute to the subscribed 1576 SWIMA-PV whenever a change is detected to relevant records within the 1577 endpoint's Software Inventory Evidence Collection. Such an attribute 1578 is said to be sent "in fulfillment of" the given subscription and any 1579 such attribute MUST include that subscription's Subscription ID. If 1580 the establishing request for that subscription was a targeted 1581 request, then only records that match the Software Identifiers 1582 provided in that establishing request are considered relevant. 1583 Otherwise, (i.e., for non-targeted requests) any record is considered 1584 relevant for this purpose. Figure 3 shows a sample attribute 1585 exchange where a subscription is established and then later 1586 attributes are sent from the SWIMA-PC in fulfillment of the 1587 established subscription. 1589 +-------------+ +--------------+ 1590 | SWIMA-PC | | SWIMA-PV | Time 1591 +-------------+ +--------------+ | 1592 | | | 1593 |<----------SWIMA Request-----------| | 1594 | | | 1595 |-----------SWIMA Response--------->| | 1596 | | | 1597 . . . 1598 . . . 1599 . . . 1600 | | | 1601 |----------SWIMA Response---------->| | 1602 | | | 1603 . . . 1604 . . . 1605 . . . 1606 | | | 1607 |----------SWIMA Response---------->| | 1608 | | V 1610 Figure 3: Subscription Establishment and Fulfillment 1612 The contents of an attribute sent in fulfillment of a subscription 1613 depend on the parameters provided in the establishing request for 1614 that subscription. Specifically, the contents of an attribute sent 1615 in fulfillment of a subscription have the same format as would a 1616 direct response to the establishing request. For example, if the 1617 establishing request stipulated a response that contained an event 1618 record list that included software inventory evidence records, all 1619 attributes sent in fulfillment of this subscription will also consist 1620 of event record lists with software inventory evidence records. As 1621 such, all SWIMA Responses displayed in the exchange depicted in 1622 Figure 3 have the same format. A SWIMA Response generated in 1623 fulfillment of an active subscription MUST be a valid SWIMA Response 1624 attribute according to all the rules outlined in the preceding 1625 sections. In other words, an attribute constructed in fulfillment of 1626 a subscription will look the same as an attribute sent in direct 1627 response to an explicit request from a SWIMA-PV that had the same 1628 request parameters and which arrived immediately after the given 1629 change event. There are a few special rules that expand on this 1630 guideline: 1632 3.8.5.1. Subscriptions Reporting Inventories 1634 In the case that a SWIMA-PV subscribes to a SWIMA-PC requesting an 1635 inventory attribute whenever changes are detected (i.e. the EID in 1636 the establishing request is 0), then the SWIMA-PC MUST send the 1637 requested inventory whenever a relevant change is detected. (A 1638 "relevant change" is any change for untargeted requests, or a change 1639 to an indicated record in a targeted request.) Upon detection of a 1640 relevant change for an active subscription, the SWIMA-PC sends the 1641 appropriate inventory information as if it had just received the 1642 establishing request. Attributes sent in fulfillment of this 1643 subscription will probably have a large amount of redundancy, as the 1644 same records are likely to be present in each of these SWIMA 1645 Attributes. The role of an inventory subscription is not to report 1646 records just for the items that changed - that is the role of a 1647 subscription that reports events (see Section 3.8.5.2). A SWIMA-PC 1648 MUST NOT exclude a record from an attribute sent in fulfillment of an 1649 inventory subscription simply because that record was not involved in 1650 the triggering event (although a record might be excluded for other 1651 reasons, such as if the subscription is targeted - see 1652 Section 3.8.5.3). 1654 3.8.5.2. Subscriptions Reporting Events 1656 The way in which a SWIMA-PV indicates it wishes to establish a 1657 subscription requesting event records is by providing a non-zero EID 1658 in the SWIMA Request establishing the subscription (see 1659 Section 3.7.1). However, when the SWIMA-PC constructs an attribute 1660 in fulfillment of the subscription (other than the direct response to 1661 the establishing request), it MUST only include event records for the 1662 detected change(s) that precipitated this response attribute. In 1663 other words, it MUST NOT send a complete list of all changes starting 1664 with the indicated EID, up through the latest change, every time a 1665 new event is detected. In effect, the EID in the establishing 1666 request is treated as being updated every time an attribute is sent 1667 in fulfillment of this subscription, such that a single event is not 1668 reported twice in fulfillment of a single subscription. As such, 1669 every SWIMA-PC MUST track the EID of the last event that triggered an 1670 attribute for the given subscription. When the next event (or set of 1671 events) is detected, the SWIMA-PC MUST only report events with EIDs 1672 after the last reported event. In the case that the EID Epoch of the 1673 SWIMA-PC changes, the SWIMA-PC MUST treat EID values in the new Epoch 1674 as being after all EIDs assigned in the previous Epoch regardless of 1675 the relative numeric values of these EIDs. 1677 Note that while a subscription is active, the subscribing SWIMA-PV 1678 MAY make other requests for event records that overlap with events 1679 that are reported in fulfillment of a subscription. Such requests 1680 are unaffected by the presence of the subscription, nor is the 1681 subscription affected by such requests. In other words, a given 1682 request will get the same results back whether or not there was a 1683 subscription. Likewise, an attribute sent in fulfillment of a 1684 subscription will contain the same information whether or not other 1685 requests had been received from the SWIMA-PV. 1687 A SWIMA-PV needs to pay attention to the EID Epoch in these 1688 attributes, as changes in the Epoch might create discontinuities in 1689 the SWIMA-PV's understanding of the endpoint's Software Inventory 1690 Evidence Collection state, as discussed in Section 3.7.6. In 1691 particular, once the EID Epoch changes, a SWIMA-PV is unable have 1692 confidence that it has a correct understanding of the state of an 1693 endpoint's Software Inventory Evidence Collection until after the 1694 SWIMA-PV collects a complete inventory. 1696 SWIMA-PCs MAY send partial lists of event records in fulfillment of a 1697 subscription. (See Section 3.7.5 for more on partial list of event 1698 records.) In the case that a SWIMA-PC sends a partial list of event 1699 records in fulfillment of a subscription, it MUST immediately send 1700 the next consecutive partial list, and continue doing so until it has 1701 sent the equivalent of the complete list of event records. In other 1702 words, if the SWIMA-PC sends a partial list it does not wait for 1703 another change event to send another SWIMA Response, but continues 1704 sending SWIMA Responses until it has sent all event records that 1705 would have been included in a complete fulfillment of the 1706 subscription. Note that the direct response to the establishing 1707 request is not considered to be sent in fulfillment of a 1708 subscription. However, in this case the SWIMA-PC MUST treat the 1709 presence of unreported events as a triggering event for pushing 1710 additional messages in fulfillment of the newly established 1711 subscription. As such, the net effect is that, if the direct 1712 response to the establishing request (i.e., the Subscription 1713 Fulfillment flag is unset) is partial, the SWIMA-PC will immediately 1714 follow this with additional attributes (with the Subscription 1715 Fulfillment flag set) until the complete set of events has been sent 1716 to the SWIMA-PV. 1718 3.8.5.3. Targeted Subscriptions 1720 Subscriptions MAY be targeted to only apply to records that match a 1721 given set of Software Identifiers. In the case where changes are 1722 detected that affect multiple records, some matching the establishing 1723 request's Software Identifiers and some not, the attribute sent in 1724 fulfillment of the subscription MUST only include inventory or events 1725 (as appropriate) for records that match the establishing request's 1726 Software Identifiers. The SWIMA-PC MUST NOT include non-matching 1727 records in the attribute, even if those non-matching records 1728 experienced change events that were co-temporal with change events on 1729 the matching records. 1731 In addition, a SWIMA-PC MUST send an attribute in fulfillment of a 1732 targeted subscription only when changes to the endpoint's Software 1733 Inventory Evidence Collection impact one or more records matching the 1734 subscription's establishing request's Software Identifiers. A SWIMA- 1735 PC MUST NOT send any attribute in fulfillment of a targeted 1736 subscription based on detected change to the endpoint's Software 1737 Inventory Evidence Collection that did not involve any of the records 1738 targeted by that subscription. 1740 3.8.5.4. No Subscription Consolidation 1742 A SWIMA-PV MAY establish multiple subscriptions to a given SWIMA-PC. 1743 If this is the case, it is possible that a single change event on the 1744 endpoint might require fulfillment by multiple subscriptions, and 1745 that the information included in attributes that fulfill each of 1746 these subscriptions might overlap. The SWIMA-PC MUST send separate 1747 attributes for each established subscription that requires a response 1748 due to the given event. Each of these attributes MUST contain all 1749 information required to fulfill that individual subscription, even if 1750 that information is also sent in other attributes sent in fulfillment 1751 of other subscriptions at the same time. In other words, SWIMA-PCs 1752 MUST NOT attempt to combine information when fulfilling multiple 1753 subscriptions simultaneously, even if this results in some redundancy 1754 in the attributes sent to the SWIMA-PV. 1756 3.8.5.5. Delayed Subscription Fulfillment 1758 A SWIMA-PC MAY delay the fulfillment of a subscription following a 1759 change event in the interest of waiting to see if additional change 1760 events are forthcoming and, if so, conveying the relevant records 1761 back to the SWIMA-PV in a single SWIMA Response attribute. This can 1762 help reduce network bandwidth consumption between the SWIMA-PC and 1763 the SWIMA-PV. For example, consider a situation where 10 changes 1764 occur a tenth of a second apart. If the SWIMA-PC does not delay in 1765 assembling and sending SWIMA Response attributes, the SWIMA-PV will 1766 receive 10 separate SWIMA Response attributes over a period of 1 1767 second. However, if the SWIMA-PC waits half a second after the 1768 initial event before assembling a SWIMA Response, the SWIMA-PV only 1769 receives two SWIMA Response attributes over the same period of time. 1771 Note that the ability to consolidate events for a single subscription 1772 over a given period of time does not contradict the rules in 1773 Section 3.8.5.4 prohibiting consolidation across multiple 1774 subscriptions. When delaying fulfillment of subscriptions, SWIMA-PCs 1775 are still required to fulfill each individual subscription 1776 separately. Moreover, in the case that change events within the 1777 delay window cancel each other out (e.g., a record is deleted and 1778 then re-added), the SWIMA-PC MUST still report each change event 1779 rather than just reporting the net effect of changes over the delay 1780 period. In other words, delayed fulfillment can decrease the number 1781 of attributes send by the SWIMA-PC, but it does not reduce the total 1782 number of change events reported. 1784 SWIMA-PCs are not required to support delayed fulfillment of 1785 subscriptions. However, in the case that the SWIMA-PC does support 1786 delayed subscription fulfillment, it MUST be possible to configure 1787 the SWIMA-PC to disable delayed fulfillment. In other words, parties 1788 deploying SWIMA-PCs need to be allowed to disable delayed 1789 subscription fulfillment in their SWIMA-PCs. The manner in which 1790 such configuration occurs is left to the discretion of implementers, 1791 although implementers MUST protect the configuration procedure from 1792 unauthorized tampering. In other words, there needs to be some 1793 assurance that unauthorized individuals are not able to introduce 1794 long delays in subscription fulfillment. 1796 3.9. Error Handling 1798 In the case where the SWIMA-PC detects an error in a SWIMA Request 1799 attribute that it receives it MUST respond with a PA-TNC Error 1800 attribute with an error code appropriate to the nature of the error. 1801 (See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC 1802 Error attributes and error codes as well as Section 5.16 in this 1803 specification for error codes specific to SWIMA Attributes.) In the 1804 case that an error is detected in a SWIMA Request the SWIMA-PC MUST 1805 NOT take any action requested by this SWIMA Request, even if partial 1806 completion of the request is possible. In other words, a SWIMA 1807 Request that contains an error is completely ignored by the SWIMA-PC 1808 (beyond sending a PA-TNC Error attribute, and possibly logging the 1809 error locally) rather than being partially executed. 1811 In the case where the SWIMA-PC receives a valid SWIMA Request 1812 attribute but experiences an error during the process of responding 1813 to that attribute's instructions where that error prevents the SWIMA- 1814 PC from properly or completely fulfilling that request, the SWIMA-PC 1815 MUST send a PA-TNC Error attribute with an error code appropriate to 1816 the nature of the error. In the case where a PA-TNC Error attribute 1817 is sent, the SWIMA-PC MUST NOT take any of the actions requested by 1818 the SWIMA Request attribute which led to the detected error. This is 1819 the case even if some actions could have been completed successfully, 1820 and might even require the SWIMA-PC to reverse some successful 1821 actions already taken before the error condition was detected. In 1822 other words, either all aspects of a SWIMA Request complete fully and 1823 successfully (in which case the SWIMA-PC sends a SWIMA Response 1824 attribute), or no aspects of the SWIMA Request occur (in which case 1825 the SWIMA-PC sends a PA-TNC Error attribute). In the case that a 1826 SWIMA-PC sends a PA-TNC Error attribute in response to a SWIMA 1827 Request then the SWIMA-PC MUST NOT also send any SWIMA Response 1828 attribute in response to the same SWIMA Request. For this reason, 1829 the sending of a SWIMA Response attribute MUST be the last action 1830 taken by a SWIMA-PC in response to a SWIMA Request to avoid the 1831 possibility of a processing error occurring after that SWIMA Response 1832 attribute is sent. 1834 In the case that the SWIMA-PC detects an error that prevents it from 1835 properly or completely fulfilling its obligations under an active 1836 subscription, the SWIMA-PC MUST send a PA-TNC Error attribute of type 1837 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR to the SWIMA-PV that established 1838 this subscription. This type of PA-TNC Error attribute identifies 1839 the specific subscription that cannot be adequately honored due to 1840 the error condition as well as an error "sub-type". The error sub- 1841 type is used to indicate the type of error condition the SWIMA-PC 1842 experienced that prevented it from honoring the given subscription. 1843 In the case that the error condition cannot be identified or does not 1844 align with any of the defined error codes, the SWIMA_ERROR error code 1845 SHOULD be used in the sub-type. In the case that a 1846 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated 1847 subscription MUST be treated as cancelled by both the SWIMA-PC and 1848 SWIMA-PV. 1850 The SWIMA-PV MUST NOT send any PA-TNC Error attributes to SWIMA-PCs. 1851 In the case that a SWIMA-PV detects an error condition, it SHOULD log 1852 this error but does not inform any SWIMA-PC's of this event. Errors 1853 might include, but are not limited to, detection of malformed SWIMA 1854 Response attributes sent from a given SWIMA-PC, as well as detection 1855 of error conditions when the SWIMA-PV processes SWIMA Responses. 1857 Both SWIMA-PCs and SWIMA-PVs SHOULD log errors so that administrators 1858 can trace the causes of errors. Log entries SHOULD include the type 1859 of the error, the time it was detected, and additional descriptive 1860 information to aid in understanding the nature and cause of the 1861 error. Logs are an important debugging tool and implementers are 1862 strongly advised to include comprehensive logging capabilities in 1863 their products. 1865 4. Protocol 1867 The software inventory protocol supports two different types of 1868 message exchanges which are described the following subsections, 1869 along with implementation requirements for supporting these 1870 exchanges. 1872 4.1. Direct Response to a SWIMA Request 1874 The first type of exchange is used to provide the SWIMA-PV with a 1875 software inventory or event collection from the queried endpoint. 1877 +-------------+ +--------------+ 1878 | SWIMA-PC | | SWIMA-PV | Time 1879 +-------------+ +--------------+ | 1880 | | | 1881 |<-----------SWIMA Request------------| | 1882 | | | 1883 | SWIMA Response* | | 1884 |-----------------or----------------->| | 1885 | PA-TNC Error | | 1886 | | V 1888 *SWIMA Response is one of the following: Software Identifier 1889 Inventory, Software Identifier Events, Software Inventory, 1890 or Software Events. 1892 Figure 4: SWIMA Attribute Exchange (Direct Response to SWIMA Request) 1894 In this exchange, the SWIMA-PV indicates to the SWIMA-PC, via a SWIMA 1895 Request, the nature of the information it wishes to receive 1896 (inventory vs. events, full or targeted) and how it wishes the 1897 returned inventory to be expressed (with or without software 1898 inventory evidence records). The SWIMA-PC responds with the 1899 requested information using the appropriate attribute type. A single 1900 SWIMA Request MUST only lead to a single SWIMA Response or PA-TNC 1901 Error that is in direct response to that request. 1903 4.2. Subscription-Based Response 1905 The second type of exchange allows change event-based reporting based 1906 on a subscription. If there is an active subscription on the 1907 endpoint, the SWIMA-PC sends a SWIMA Response to the SWIMA-PV 1908 following a change event on the endpoint in fulfillment of that 1909 subscription. Such an exchange is shown in Figure 5. 1911 +-------------+ +--------------+ 1912 | SWIMA-PC | | SWIMA-PV | Time 1913 +-------------+ +--------------+ | 1914 | | | 1915 | | | 1916 |------SWIMA Response(s)*------>| | 1917 | | | 1919 *SWIMA Response is one of the following: Software Identifier 1920 Inventory, Software Identifier Events, Software Inventory, 1921 or Software Events. 1923 Figure 5: SWIMA Attribute Exchange (In Fulfillment of an Active 1924 Subscription) 1926 Note that, unlike direct responses to a SWIMA Request, a single 1927 change event can precipitate multiple SWIMA Responses for a single 1928 subscription, but only if all but the last of those SWIMA Responses 1929 convey partial lists of event records. When providing multiple SWIMA 1930 Responses in this way, the initial responses contain partial lists of 1931 event records and the last of those SWIMA Responses conveys the 1932 remainder of the relevant event records, completing the delivery of 1933 all relevant events in response to the change event. A single Change 1934 Event MUST NOT otherwise be followed by multiple SWIMA Response or 1935 PA-TNC Error attributes in any combination. 1937 4.3. Required Exchanges 1939 All SWIMA-PVs and SWIMA-PCs MUST support both types of exchanges. In 1940 particular, SWIMA-PCs MUST be capable of pushing a SWIMA Response to 1941 a SWIMA-PV immediately upon detection of a change to the endpoint's 1942 Software Inventory Evidence Collection in fulfillment of established 1943 SWIMA-PV subscriptions, as described in Section 3.8. 1945 5. Software Inventory Messages and Attributes 1947 This section describes the format and semantics of the Software 1948 Inventory Message and Attributes for PA-TNC protocol. This protocol 1949 uses the PA-TNC message header format [RFC5792]. 1951 5.1. PA Subtype (AKA PA-TNC Component Type) 1953 The NEA PB-TNC interface provides a general message-batching protocol 1954 capable of carrying one or more PA-TNC messages between the Posture 1955 Broker Client and Posture Broker Server. When PB-TNC is carrying a 1956 PA-TNC message, the PB-TNC message headers contain a 32 bit 1957 identifier called the PA Subtype. The PA Subtype field indicates the 1958 type of component associated with all of the PA-TNC attributes 1959 carried by the PB-TNC message. The core set of PA Subtypes is 1960 defined in the PA-TNC specification. This specification defines a 1961 new "SWIMA Attributes" PA Subtype, which is registered in 1962 Section 10.1 of this document, which is used as a namespace for the 1963 collection of SWIMA Attributes defined in this document. 1965 For more information on PB-TNC and PA-TNC messages and message 1966 headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792] 1967 specifications, respectively. 1969 5.2. SWIMA Attribute Overview 1971 Each PA-TNC attribute described in this specification is intended to 1972 be sent between the SWIMA-PC and SWIMA-PV, so will be carried in a 1973 PB-TNC message indicating a PA Subtype of "SWIMA Attributes". PB-TNC 1974 messages MUST always include the SWIMA Attributes Subtype defined in 1975 Section 5.1 when carrying SWIMA Attributes over PA-TNC. The 1976 attributes defined in this specification appear below along with a 1977 short summary of their purposes. Each attribute is described in 1978 greater detail in subsequent sections. 1980 SWIMA Request: This attribute is used to request a software 1981 inventory or software event list from an endpoint. This attribute 1982 might also establish a subscription on the recipient SWIMA-PC. See 1983 Section 5.7 for more information. 1985 Software Identifier Inventory: This attribute is used to convey an 1986 inventory without the inclusion of software inventory evidence 1987 records. See Section 5.8 for more information. 1989 Software Identifier Events: This attribute is used to convey a list 1990 of events concerning changes to an endpoint's Software Inventory 1991 Evidence Collection. Reported events do not include software 1992 inventory evidence records. See Section 5.9 for more information. 1994 Software Inventory: This attribute is used to convey an inventory 1995 expressed including software inventory evidence records. See 1996 Section 5.10 for more information. 1998 Software Events: This attribute is used to convey a list of events 1999 concerning changes to an endpoint's inventory evidence collection. 2000 Reported events include software inventory evidence records. See 2001 Section 5.11 for more information. 2003 Subscription Status Request: This attribute is used to request a 2004 SWIMA-PC send a summary of all the active subscriptions it has 2005 where the requesting party is the subscriber. See Section 5.12 for 2006 more information. 2008 Subscription Status Response: This attribute is used to convey 2009 information about the active subscriptions that a SWIMA-PC has for 2010 a given subscriber. See Section 5.13 for more information. 2012 Source Metadata Request: This attribute is used to request a SWIMA- 2013 PC send metadata about the sources is uses to collect software 2014 inventory information. See Section 5.14 for more information. 2016 Source Metadata Response: This attribute is used to convey 2017 descriptive metadata about the sources a SWIMA-PC uses to collect 2018 software inventory information. See Section 5.15 for more 2019 information. 2021 PA-TNC Error: This is the standard PA-TNC Error attribute as defined 2022 in PA-TNC [RFC5792] and is used to indicate that an error was 2023 encountered during a software inventory exchange. Use of the PA- 2024 TNC attribute by Software Inventory Message and Attributes for PA- 2025 TNC is described in Section 5.16. 2027 Because one of the Software Identifier Inventory, Software Identifier 2028 Events, Software Inventory, or Software Events attributes are 2029 expected to be sent to a SWIMA-PV in direct response to a SWIMA 2030 Request attribute or in fulfillment of an active subscription, those 2031 four attribute types are referred to collectively in this document as 2032 "SWIMA Response attributes". 2034 All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and 2035 be capable of receiving and processing all SWIMA Response attributes 2036 as well as PA-TNC Error attributes. All SWIMA-PCs MUST be capable of 2037 receiving and processing SWIMA Request attributes and be capable of 2038 sending all types of SWIMA Response attributes as well as PA-TNC 2039 Error attributes. In other words, both SWIMA-PVs and SWIMA-PCs are 2040 required to support their role in exchanges using any of the 2041 attribute types defined in this section. SWIMA-PVs MUST ignore any 2042 SWIMA Request attributes that they receive. SWIMA-PCs MUST ignore 2043 any SWIMA Response attributes or PA-TNC Error attributes that they 2044 receive. 2046 5.3. Message Diagram Syntax 2048 This specification defines the syntax of new PA-TNC messages and 2049 attributes using diagrams. Each diagram depicts the format and size 2050 of each field in bits. Implementations MUST send the bits in each 2051 diagram as they are shown from left to right for each 32-bit quantity 2052 traversing the diagram from top to bottom. Multi-octet fields 2053 representing numeric values MUST be sent in network (big endian) byte 2054 order. 2056 Descriptions of bit fields (e.g. flags) values refer to the position 2057 of the bit within the field. These bit positions are numbered from 2058 the most significant bit through the least significant bit. As such, 2059 an octet with only bit 0 set would have a value of 0x80 (1000 0000), 2060 an octet with only bit 1 set would have a value of 0x40 (0100 0000), 2061 and an octet with only bit 7 set would have a value of 0x01 (0000 2062 0001). 2064 5.4. Software Inventory Message and Attributes for PA-TNC Attribute 2065 Enumeration 2067 PA-TNC attribute types are identified in the PA-TNC Attribute Header 2068 via the Attribute Type Vendor ID and Attribute Type fields. Table 1 2069 identifies the appropriate values for these fields for each attribute 2070 type used within the Software Inventory Message and Attributes for 2071 PA-TNC protocol. The following is a summary of the registered 2072 attributes. All attributes have a PEN value of 0x000000. For the 2073 Integer value field, both the hexadecimal and decimal values are 2074 provided. 2076 +--------------+------------+---------------------------------------+ 2077 | Attribute | Integer | Description | 2078 | Name | | | 2079 +--------------+------------+---------------------------------------+ 2080 | SWIMA | 0x00000011 | Request from a SWIMA-PV to a SWIMA-PC | 2081 | Request | (17) | for the SWIMA-PC to provide a | 2082 | | | software inventory or event list | 2083 | | | | 2084 | Software | 0x00000012 | An inventory sent without software | 2085 | Identifier | (18) | inventory evidence records sent from | 2086 | Inventory | | a SWIMA-PC. | 2087 | | | | 2088 | Software | 0x00000013 | A collection of events impacting the | 2089 | Identifier | (19) | endpoint's Software Inventory | 2090 | Events | | Evidence Collection, where events do | 2091 | | | not include software inventory | 2092 | | | evidence records. | 2093 | | | | 2094 | Software | 0x00000014 | An inventory including software | 2095 | Inventory | (20) | inventory evidence records sent from | 2096 | | | a SWIMA-PC. | 2097 | | | | 2098 | Software | 0x00000015 | A collection of events impacting the | 2099 | Events | (21) | endpoint's Software Inventory | 2100 | | | Evidence Collection, where events | 2101 | | | include software inventory evidence | 2102 | | | records. | 2103 | | | | 2104 | Subscription | 0x00000016 | A request for a list of a SWIMA-PV's | 2105 | Status | (22) | active subscription on a SWIMA-PC. | 2106 | Request | | | 2107 | | | | 2108 | Subscription | 0x00000017 | A list of a SWIMA-PV's active | 2109 | Status | (23) | subscriptions on a SWIMA-PC. | 2110 | Response | | | 2111 | | | | 2112 | Source | 0x00000018 | A request for information about a | 2113 | Metadata | (24) | SWIMA-PC's data sources. | 2114 | Request | | | 2115 | | | | 2116 | Subscription | 0x00000019 | Descriptive metadata about a SWIMA- | 2117 | Metadata | (25) | PC's data sources. | 2118 | Response | | | 2119 | | | | 2120 | Reserved | 0x0000001A | These attribute types are reserved | 2121 | | - | for future use in revisions to | 2122 | | 0x0000001F | Software Inventory Message and | 2123 | | (26 - 31) | Attributes for PA-TNC. | 2124 | | | | 2125 | PA-TNC Error | 0x00000008 | An error attribute as defined in the | 2126 | | (8) | PA-TNC specification [RFC5792]. | 2127 +--------------+------------+---------------------------------------+ 2129 Table 1: SWIMA Attribute Enumeration 2131 5.5. Normalization of Text Encoding 2133 In order to ensure consistency of transmitted attributes some fields 2134 require normalization of their format. When this is necessary, this 2135 is indicated in the field's description. In such cases, the field 2136 contents MUST be normalized to Network Unicode format as defined in 2137 RFC 5198 [RFC5198]. Network Unicode format defines a refinement of 2138 UTF-8 that ensures a normalized expression of characters. SWIMA-PCs 2139 and SWIMA-PVs MUST NOT perform conversion and normalization on any 2140 field values except those specifically identified as requiring 2141 normalization in the following sections. Note, however, that some 2142 data models require additional normalization before source 2143 information is added to an Endpoint's Inventory Evidence Collection 2144 as a record. The references from the Software Data Model IANA table 2145 (see Section 10.4) will note where this is necessary. 2147 5.6. Request IDs 2149 All SWIMA Request attributes MUST include a Request ID value. The 2150 Request ID field provides a value that identifies a given request 2151 relative to other requests between a SWIMA-PV and the receiving 2152 SWIMA-PC. Specifically, the SWIMA-PV assigns each SWIMA Request 2153 attribute a Request ID value that is intended to be unique within the 2154 lifetime of a given network connection ID as assigned by the SWIMA- 2155 PV's Posture Broker Server. 2157 In the case that a SWIMA Request requests the establishment of a 2158 subscription and the receiving SWIMA-PC agrees to that subscription, 2159 the Request ID of that SWIMA Request (i.e., the establishing request 2160 of the subscription) becomes that subscription's Subscription ID. 2161 All attributes sent in fulfillment of this subscription include a 2162 flag indicating that the attribute fulfills a subscription and the 2163 subscription's Subscription ID. A SWIMA-PV MUST NOT reuse a Request 2164 ID value in communicating to a given SWIMA-PC while that Request ID 2165 is also serving as a Subscription ID for an active subscription with 2166 that SWIMA-PC. In the case where a SWIMA-PC receives a SWIMA Request 2167 from a given SWIMA-PV where that Request ID is also the Subscription 2168 ID of an active subscription with that SWIMA-PV, the SWIMA-PC MUST 2169 respond with a PA-TNC Error attribute with an error code of 2170 SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. Note that this error does not 2171 cancel the indicated subscription. 2173 Subscription Status Requests and Subscription Status Responses do not 2174 include Request IDs. 2176 In the case where all possible Request ID values have been exhausted 2177 within the lifetime of a single network connection ID, the sender MAY 2178 reuse previously used Request IDs within the same network connection 2179 if the ID is not being used as a Subscription ID. In such a case of 2180 Request ID reuse, Request IDs SHOULD be reused in the order of their 2181 original use. In other words, a SWIMA-PC SHOULD NOT use a given 2182 Request ID value more than once within a persistent connection 2183 between a given Posture Broker Client-Posture Broker Server pair. In 2184 the case where reuse is necessary due to exhaustion of possible ID 2185 values, the SWIMA-PC SHOULD structure the reuse to maximize the time 2186 between original and subsequent use. The Request ID value is 2187 included in a SWIMA Response attribute directly responding to this 2188 SWIMA Request to indicate which SWIMA Request was received and caused 2189 the response. Request IDs can be randomly generated or sequential, 2190 as long as values are not repeated per the rules in this paragraph. 2191 SWIMA-PCs are not required to check for duplicate Request IDs. 2193 5.7. SWIMA Request 2195 A SWIMA-PV sends this attribute to a SWIMA-PC to request that the 2196 SWIMA-PC send software inventory information to the SWIMA-PV. A 2197 SWIMA-PC MUST NOT send this attribute. 2199 1 2 3 2200 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 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | Flags | Software Identifier Count | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | Request ID | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | Earliest EID | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | Software Identifier Length | Software Identifier (var len) | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 Figure 6: SWIMA Request Attribute 2213 +---------------+---------------------------------------------------+ 2214 | Field | Description | 2215 +---------------+---------------------------------------------------+ 2216 | Flags: Bit 0 | If set (1), the SWIMA-PC MUST delete all | 2217 | - Clear | subscriptions established by the requesting | 2218 | Subscriptions | SWIMA-PV (barring any errors). | 2219 | | | 2220 | Flags: Bit 1 | If set (1), in addition to responding to the | 2221 | - Subscribe | request as described, the SWIMA-PC MUST establish | 2222 | | a subscription with parameters matching those in | 2223 | | the request attribute (barring any errors). | 2224 | | | 2225 | Flags: Bit 2 | If unset (0), the SWIMA-PC's response MUST | 2226 | - Result Type | include software inventory evidence records and | 2227 | | thus the response MUST be a Software Inventory, a | 2228 | | Software Events, or a PA-TNC Error attribute. If | 2229 | | set (1), the response MUST NOT include software | 2230 | | inventory evidence records and thus the response | 2231 | | MUST be a Software Identifier Inventory, a | 2232 | | Software Identifier Events, or a PA-TNC Error | 2233 | | attribute. | 2234 | | | 2235 | Flags: Bit | Reserved for future use. This field MUST be set | 2236 | 3-7 - | to zero on transmission and ignored upon | 2237 | Reserved | reception. | 2238 | | | 2239 | Software | A 3-byte unsigned integer indicating the number | 2240 | Identifier | of Software Identifiers that follow. If this | 2241 | Count | value is non-zero, this is a targeted request, as | 2242 | | described in Section 3.5. The Software | 2243 | | Identifier Length and Software Identifier fields | 2244 | | are repeated, in order, the number of times | 2245 | | indicated in this field. In the case where | 2246 | | Software Identifiers are present, the SWIMA-PC | 2247 | | MUST only report software that corresponds to the | 2248 | | identifiers the SWIMA-PV provided in this | 2249 | | attribute (or with a PA-TNC Error attribute). | 2250 | | This field value MAY be 0, in which case there | 2251 | | are no instances of the Software Identifier | 2252 | | Length and Software Identifier fields. In this | 2253 | | case, the SWIMA-PV is indicating an interest in | 2254 | | all software inventory evidence records on the | 2255 | | endpoint (i.e., this is not a targeted request). | 2256 | | | 2257 | Request ID | A value that uniquely identifies this SWIMA | 2258 | | Request from a particular SWIMA-PV. | 2259 | | | 2260 | Earliest EID | In the case where the SWIMA-PV is requesting | 2261 | | software events, this field contains the EID | 2262 | | value of the earliest event the SWIMA-PV wishes | 2263 | | to have reported. (Note - the report will be | 2264 | | inclusive of the event with this EID value.) In | 2265 | | the case where the SWIMA-PV is requesting an | 2266 | | inventory, then this field MUST be 0. | 2267 | | (0x00000000) In the case where this field is non- | 2268 | | zero, the SWIMA-PV is requesting events and the | 2269 | | SWIMA-PC MUST respond using a Software Events, | 2270 | | Software Identifier Events, or a PA-TNC Error | 2271 | | attribute. In the case where this field is zero, | 2272 | | the SWIMA-PV is requesting an inventory and the | 2273 | | SWIMA-PC MUST respond using a Software Inventory, | 2274 | | a Software Identifier Inventory, or a PA-TNC | 2275 | | Error attribute. | 2276 | | | 2277 | Software | A 2-byte unsigned integer indicating the length | 2278 | Identifier | in bytes of the Software Identifier field. | 2279 | Length | | 2280 | | | 2281 | Software | A string containing the Software Identifier value | 2282 | Identifier | from a software inventory evidence record. This | 2283 | | field value MUST be normalized to Network Unicode | 2284 | | format, as described in Section 5.5. This string | 2285 | | MUST NOT be NULL terminated. | 2286 +---------------+---------------------------------------------------+ 2288 Table 2: SWIMA Request Attribute Fields 2290 The SWIMA-PV sends the SWIMA Request attribute to a SWIMA-PC to 2291 request the indicated information. Note that between the Result Type 2292 flag and the Earliest EID field, the SWIMA-PC is constrained to a 2293 single possible SWIMA Response attribute type (or a PA-TNC Error 2294 attribute) in its response to the request. 2296 The Subscribe and Clear Subscription flags are used to manage 2297 subscriptions for the requesting SWIMA-PV on the receiving SWIMA-PC. 2298 Specifically, an attribute with the Subscribe flag set seeks to 2299 establish a new subscription by the requesting SWIMA-PV to the given 2300 SWIMA-PC, while an attribute with the Clear Subscription flag seeks 2301 to delete all existing subscriptions by the requesting SWIMA-PV on 2302 the given SWIMA-PC. Note that, in the latter case, only the 2303 subscriptions associated with the Connection ID and the Posture 2304 Validator ID of the requester are deleted as described in 2305 Section 3.8.3. A newly established subscription has the parameters 2306 outlined in the Request attribute. Specifically, the Result Type 2307 flag indicates the type of result to send in fulfillment of the 2308 subscription, the value of the Earliest EID field indicates whether 2309 the fulfillment attributes list inventories or events, and the fields 2310 describing Software Identifiers (if present) indicate if and how a 2311 subscription is targeted. In the case that the SWIMA-PC is unable or 2312 unwilling to comply with the SWIMA-PV's request to establish or clear 2313 subscriptions, the SWIMA-PC MUST respond with a PA-TNC Error 2314 attribute with the SWIMA_SUBSCRIPTION_DENIED_ERROR error code. If 2315 the SWIMA-PV requests that subscriptions be cleared but has no 2316 existing subscriptions, this is not an error. 2318 An attribute requesting the establishment of a subscription is 2319 effectively doing double-duty, as it is a request for an immediate 2320 response from the SWIMA-PC in addition to setting up the 2321 subscription. Assuming the SWIMA-PC is willing to comply with the 2322 subscription it MUST send an appropriate response attribute to a 2323 request with the Subscribe flag set containing all requested 2324 information. The same is true of the Clear Subscription flag - 2325 assuming there is no error the SWIMA-PC MUST generate a response 2326 attribute without regard to the presence of this flag in addition to 2327 clearing its subscription list. 2329 Both the Subscribe and Clear Subscription flags MAY be set in a 2330 single SWIMA Request attribute. In the case where this request is 2331 successful, the end result MUST be equivalent to the SWIMA-PC 2332 clearing its subscription list for the given SWIMA-PV first and then 2333 creating a new subscription in accordance with the request 2334 parameters. In other words, do not first create the new subscription 2335 and then clear all the subscriptions including the one that was just 2336 created. In the case that the requested actions are successfully 2337 completed, the SWIMA-PC MUST respond with a SWIMA Response attribute. 2338 The specific type of SWIMA Response attribute depends on the Result 2339 Type and Earliest EID fields, as described above. In the case where 2340 there is a failure that prevents some part this request from 2341 completing, the SWIMA-PC MUST NOT add a new subscription, MUST NOT 2342 clear the old subscriptions, and the SWIMA-PC MUST respond with a PA- 2343 TNC Error attribute. In other words, the SWIMA-PC MUST NOT partially 2344 succeed at implementing such a request; either all actions succeed, 2345 or none succeed. 2347 The Earliest EID field is used to indicate if the SWIMA-PV is 2348 requesting an inventory or event list from the SWIMA-PC. A value of 2349 0 (0x00000000) represents a request for inventory information. 2350 Otherwise, the SWIMA-PV is requesting event information. For 2351 Earliest EID values other than 0, the SWIMA-PC's response MUST 2352 respond with event records, as described in Section 3.7. Note that 2353 the request does not identify a particular EID Epoch, since responses 2354 can only include events in the SWIMA-PC's current EID Epoch. 2356 The Software Identifier Count indicates the number of Software 2357 Identifiers in the attribute. This number might be any value between 2358 0 and 16,777,216, inclusive. A single Software Identifier is 2359 represented by the following fields: Software Identifier Length and 2360 Software Identifier. These fields are repeated a number of times 2361 equal to the Software Identifier Count, which may be 0. The Software 2362 Identifier Length field indicates the number of bytes allocated to 2363 the Software Identifier field. The Software Identifier field 2364 contains a Software Identifier as describe in Section 3.4.1. The 2365 presence of one or more Software Identifiers is used by the SWIMA-PV 2366 to indicate a targeted request, which seeks only inventories of or 2367 events affecting software corresponding to the given identifiers. 2368 The SWIMA-PC MUST only report software that matched the Software 2369 Identifiers provided in the SWIMA-PVs SWIMA Request attribute. 2371 5.8. Software Identifier Inventory 2373 A SWIMA-PC sends this attribute to a SWIMA-PV to convey the inventory 2374 of the endpoint's Software Inventory Evidence Collection without the 2375 inclusion of software inventory evidence records. This list might 2376 represent a complete inventory or a targeted list of records, 2377 depending on the parameters in the SWIMA-PV's request. A SWIMA-PV 2378 MUST NOT send this attribute. The SWIMA-PC either sends this 2379 attribute in fulfillment of an existing subscription where the 2380 establishing request has a Result Type of 1 and the Earliest EID is 2381 zero, or in direct response to a SWIMA Request attribute where the 2382 Result Type is 1 and the Earliest EID is zero. 2384 1 2 3 2385 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 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | Flags | Software Identifier Count | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | Request ID Copy / Subscription ID | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | EID Epoch | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | Last EID | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Record Identifier | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | Data Model Type PEN |Data Model Type| 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Source Id Num | Software Identifier Length |Software Id (v)| 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Software Locator Length |Software Locator (variable len)| 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 Figure 7: Software Identifier Inventory Attribute 2406 +----------------+--------------------------------------------------+ 2407 | Field | Description | 2408 +----------------+--------------------------------------------------+ 2409 | Flags: Bit 0 - | In the case that this attribute is sent in | 2410 | Subscription | fulfillment of a subscription this bit MUST be | 2411 | Fulfillment | set (1). In the case that this attribute is a | 2412 | | direct response to a SWIMA Request, this bit | 2413 | | MUST be unset (0). | 2414 | | | 2415 | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | 2416 | - Reserved | to zero on transmission and ignored upon | 2417 | | reception. | 2418 | | | 2419 | Software | The number of Software Identifiers that follow. | 2420 | Identifier | This field is an unsigned integer. The Record | 2421 | Count | Identifier, Data Model Type PEN, Data Model | 2422 | | Type, Source Identification Number, Software | 2423 | | Identifier Length, Software Identifier, Software | 2424 | | Locator Length, and Software Locator fields are | 2425 | | repeated, in order, the number of times | 2426 | | indicated in this field. This field value MAY be | 2427 | | 0, in which case there are no instances of these | 2428 | | fields. | 2429 | | | 2430 | Request ID | In the case where this attribute is in direct | 2431 | Copy / | response to a SWIMA Request attribute from a | 2432 | Subscription | SWIMA-PV, this field MUST contain an exact copy | 2433 | ID | of the Request ID field from that SWIMA Request. | 2434 | | In the case where this attribute is sent in | 2435 | | fulfillment of an active subscription, this | 2436 | | field MUST contain the Subscription ID of the | 2437 | | subscription being fulfilled by this attribute. | 2438 | | | 2439 | EID Epoch | The EID Epoch of the Last EID value. This field | 2440 | | is an unsigned 4-byte integer. | 2441 | | | 2442 | Last EID | The EID of the last event recorded by the SWIMA- | 2443 | | PC, or 0 if the SWIMA-PC has no recorded events. | 2444 | | This field is an unsigned 4-byte integer. | 2445 | | | 2446 | Record | A 4-byte, unsigned integer containing the Record | 2447 | Identifier | Identifier value from a software inventory | 2448 | | evidence record. | 2449 | | | 2450 | Data Model | A 3-byte unsigned integer containing the Private | 2451 | Type PEN | Enterprise Number (PEN) of the organization that | 2452 | | assigned the meaning of the Data Model Type | 2453 | | value. | 2454 | | | 2455 | Data Model | A 1-byte unsigned integer containing an | 2456 | Type | identifier number that identifies the data model | 2457 | | of the reported record. | 2458 | | | 2459 | Source | The Source Identification Number associated with | 2460 | Identification | the source from which this software installation | 2461 | Number | inventory instance was reported. | 2462 | | | 2463 | Software | A 2-byte unsigned integer indicating the length | 2464 | Identifier | in bytes of the SW ID field. | 2465 | Length | | 2466 | | | 2467 | Software | A string containing the Software Identifier | 2468 | Identifier | value from a software inventory evidence record. | 2469 | | This field value MUST be normalized to Network | 2470 | | Unicode format, as described in Section 5.5. | 2471 | | This string MUST NOT be NULL terminated. | 2472 | | | 2473 | Software | A 2-byte unsigned integer indicating the length | 2474 | Locator Length | in bytes of the Software Locator field. | 2475 | | | 2476 | Software | A string containing the Software Locator value. | 2477 | Locator | This is expressed as a URI. This field value | 2478 | | MUST be normalized to Network Unicode format as | 2479 | | described in Section 3.4.4. This string MUST NOT | 2480 | | be NULL terminated. | 2481 +----------------+--------------------------------------------------+ 2483 Table 3: Software Identifier Inventory Attribute Fields 2485 In the case that this attribute is sent in fulfillment of a 2486 subscription, the Subscription Fulfillment bit MUST be set (1). In 2487 the case that this attribute is sent in direct response to a SWIMA 2488 Request, the Subscription Fulfillment bit MUST be unset (0). Note 2489 that the SWIMA Response attribute sent in direct response to a SWIMA 2490 Request that establishes a subscription (i.e., a subscription's 2491 establishing request) MUST be treated as a direct response to that 2492 SWIMA Request (and thus the Subscription Fulfillment bit is unset). 2493 SWIMA Response attributes are only treated as being in fulfillment of 2494 a subscription (i.e., Subscription Fulfillment bit set) if they are 2495 sent following a change event, as shown in Figure 3. 2497 The Software Identifier Count field indicates the number of Software 2498 Identifiers present in this inventory. Each Software Identifier is 2499 represented by the following set of fields: Record Identifier, Data 2500 Model Type, Software Identifier Length, Software Identifier, Software 2501 Locator Length, and Software Locator. These fields will appear once 2502 for each reported record. 2504 When responding directly to a SWIMA Request attribute, the Request ID 2505 Copy / Subscription ID field MUST contain an exact copy of the 2506 Request ID field from that SWIMA Request. When this attribute is 2507 sent in fulfillment of an existing subscription on this Posture 2508 Collector, then this field MUST contain the Subscription ID of the 2509 fulfilled subscription. 2511 The EID Epoch field indicates the EID Epoch of the Last EID value. 2512 The Last EID field MUST contain the EID of the last recorded change 2513 event (see Section 3.7 for more about EIDs and recorded events) at 2514 the time this inventory was collected. In the case where there are 2515 no recorded change events at the time that this inventory was 2516 collected, the Last EID field MUST contain 0. These fields can be 2517 interpreted to indicate that the provided inventory reflects the 2518 state of the endpoint after all changes up to and including this last 2519 event have been accounted for. 2521 The Data Model Type PEN and Data Model Type fields are used to 2522 identify the data model associated with the given software record. 2523 These fields are discussed more in Section 3.4.2. 2525 The Source Identification Number field is used to identify the source 2526 that provided the given record, as described in Section 3.1. 2528 5.9. Software Identifier Events 2530 A SWIMA-PC sends this attribute to a SWIMA-PV to convey events where 2531 the affected records are reported without software inventory evidence 2532 records. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC 2533 either sends this attribute in fulfillment of an existing 2534 subscription where the establishing request has a Result Type is 1 2535 and the Earliest EID is non-zero, or in direct response to a SWIMA 2536 Request attribute where the Result Type is 1 and the Earliest EID is 2537 non-zero. 2539 1 2 3 2540 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 2541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 | Flags | Event Count | 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 | Request ID Copy / Subscription ID | 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | EID Epoch | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 | Last EID | 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 | Last Consulted EID | 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 | EID | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | Timestamp | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | Timestamp | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Timestamp | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | Timestamp | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | Timestamp | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | Record Identifier | 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | Data Model Type PEN |Data Model Type| 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | Source Id Num | Action | Software Identifier Length | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 | Software Identifier (variable length) | 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 | Software Locator Length |Software Locator (variable len)| 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 Figure 8: Software Identifier Events Attribute 2577 +----------------+--------------------------------------------------+ 2578 | Field | Description | 2579 +----------------+--------------------------------------------------+ 2580 | Flags: Bit 0 - | In the case that this attribute is sent in | 2581 | Subscription | fulfillment of a subscription this bit MUST be | 2582 | Fulfillment | set (1). In the case that this attribute is a | 2583 | | direct response to a SWIMA Request, this bit | 2584 | | MUST be unset (0). | 2585 | | | 2586 | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | 2587 | - Reserved | to zero on transmission and ignored upon | 2588 | | reception. | 2589 | | | 2590 | Event Count | The number of events that are reported in this | 2591 | | attribute. This field is a 3-byte unsigned | 2592 | | integer. The EID, Timestamp, Record Identifier, | 2593 | | Data Model Type PEN, Data Model Type, Source | 2594 | | Identification Number, Action, Software | 2595 | | Identifier Length, Software Identifier, Software | 2596 | | Locator Length, and Software Locator fields are | 2597 | | repeated, in order, the number of times | 2598 | | indicated in this field. This field value MAY be | 2599 | | 0, in which case there are no instances of these | 2600 | | fields. | 2601 | | | 2602 | Request ID | In the case where this attribute is in direct | 2603 | Copy / | response to a SWIMA Request attribute from a | 2604 | Subscription | SWIMA-PV, this field MUST contain an exact copy | 2605 | ID | of the Request ID field from that SWIMA Request. | 2606 | | In the case where this attribute is sent in | 2607 | | fulfillment of an active subscription, this | 2608 | | field MUST contain the Subscription ID of the | 2609 | | subscription being fulfilled by this attribute. | 2610 | | | 2611 | EID Epoch | The EID Epoch of the Last EID value. This field | 2612 | | is an unsigned 4-byte integer. | 2613 | | | 2614 | Last EID | The EID of the last event recorded by the SWIMA- | 2615 | | PC, or 0 if the SWIMA-PC has no recorded events. | 2616 | | This field contains the EID of the SWIMA-PC's | 2617 | | last recorded change event (which might or might | 2618 | | not be included as an event record in this | 2619 | | attribute). | 2620 | | | 2621 | Last Consulted | The EID of the last event record that was | 2622 | EID | consulted when generating the event record list | 2623 | | included in this attribute. This is different | 2624 | | from the Last EID field value if and only if | 2625 | | this attribute is conveying a partial list of | 2626 | | event records. See Section 3.7.5 for more on | 2627 | | partial list of event records. | 2628 | | | 2629 | EID | The EID of the event in this event record. | 2630 | | | 2631 | Timestamp | The timestamp associated with the event in this | 2632 | | event record. This timestamps is the SWIMA-PC's | 2633 | | best understanding of when the given event | 2634 | | occurred. Note that this timestamp might be an | 2635 | | estimate. The Timestamp date and time MUST be | 2636 | | represented as an RFC 3339 [5] compliant ASCII | 2637 | | string in Coordinated Universal Time (UTC) time | 2638 | | with the additional restrictions that the 'T' | 2639 | | delimiter and the 'Z' suffix MUST be capitalized | 2640 | | and fractional seconds (time-secfrac) MUST NOT | 2641 | | be included. This field conforms to the date- | 2642 | | time ABNF production from section 5.6 of RFC | 2643 | | 3339 [RFC3339] with the above restrictions. | 2644 | | Leap seconds are permitted and SWIMA-PVs MUST | 2645 | | support them. The Timestamp string MUST NOT be | 2646 | | NULL terminated or padded in any way. The length | 2647 | | of this field is always 20 octets. | 2648 | | | 2649 | Record | A 4-byte, unsigned integer containing the Record | 2650 | Identifier | Identifier value from a software inventory | 2651 | | evidence record. | 2652 | | | 2653 | Data Model | A 3-byte unsigned integer containing the Private | 2654 | Type PEN | Enterprise Number (PEN) of the organization that | 2655 | | assigned the meaning of the Data Model Type | 2656 | | value. | 2657 | | | 2658 | Data Model | A 1-byte unsigned integer containing an | 2659 | Type | identifier number that identifies the data model | 2660 | | of the reported record. | 2661 | | | 2662 | Source | The Source Identification Number associated with | 2663 | Identification | the source from which this software installation | 2664 | Number | inventory instance was reported. | 2665 | | | 2666 | Action | The type of event that is recorded in this event | 2667 | | record. Possible values are: 1 = CREATION - the | 2668 | | addition of a record to the endpoint's Software | 2669 | | Inventory Evidence Collection; 2 = DELETION - | 2670 | | the removal of a record from the endpoint's | 2671 | | Software Inventory Evidence Collection; 3 = | 2672 | | ALTERATION - There was an alteration to a record | 2673 | | within the endpoint's Software Inventory | 2674 | | Evidence Collection. All other values are | 2675 | | reserved for future use and MUST NOT be used | 2676 | | when sending attributes. In the case where a | 2677 | | SWIMA-PV receives an event record that uses an | 2678 | | action value other than the ones defined here, | 2679 | | it MUST ignore that event record but SHOULD | 2680 | | process other event records in this attribute as | 2681 | | normal. | 2682 | | | 2683 | Software | A 2-byte unsigned integer indicating the length | 2684 | Identifier | in bytes of the SW ID field. | 2685 | Length | | 2686 | | | 2687 | Software | A string containing the Software Identifier | 2688 | Identifier | value from a software inventory evidence record. | 2689 | | This field value MUST be normalized to Network | 2690 | | Unicode format, as described in Section 5.5. | 2691 | | This string MUST NOT be NULL terminated. | 2692 | | | 2693 | Software | A 2-byte unsigned integer indicating the length | 2694 | Locator Length | in bytes of the Software Locator field. | 2695 | | | 2696 | Software | A string containing the Software Locator value. | 2697 | Locator | This is expressed as a URI. This field value | 2698 | | MUST be normalized to Network Unicode format as | 2699 | | described in Section 3.4.4. This string MUST NOT | 2700 | | be NULL terminated. | 2701 +----------------+--------------------------------------------------+ 2703 Table 4: Software Identifier Events Attribute Fields 2705 The first few fields in the Software Identifier Events attribute 2706 mirror those in the Software Identifier Inventory attribute. The 2707 primary difference is that, instead of conveying an inventory, the 2708 attribute conveys zero or more event records, consisting of the EID, 2709 timestamp, Record Identifier, action type, data model type, Software 2710 Identifier, and Software Locator of the affected software inventory 2711 evidence record. 2713 With regard to the Timestamp field, it is important to note that 2714 clock skew between the SWIMA-PC and SWIMA-PV as well as between 2715 different SWIMA-PCs within an enterprise might make correlation of 2716 timestamp values difficult. This specification does not attempt to 2717 resolve clock skew issues, although other mechanisms outside of this 2718 specification do exist to reduce the impact of clock skew and make 2719 the timestamp more useful for such correlation. Instead, Software 2720 Inventory Message and Attributes for PA-TNC uses Timestamp value 2721 primarily as a means to indicate the amount of time between two 2722 events on a single endpoint. For example, by taking the difference 2723 of the times for when a record was removed and then subsequently re- 2724 added, one can get an indication as to how long the system was 2725 without the given record (and, thus without the associated software). 2726 Since this will involve comparison of timestamp values all 2727 originating on the same system, clock skew between the SWIMA-PC and 2728 SWIMA-PV is not an issue. However, if the SWIMA-PC's clock was 2729 adjusted between two recorded events, it is possible for such a 2730 calculation to lead to incorrect understandings of the temporal 2731 distance between events. Users of this field need to be aware of the 2732 possibility for such occurrences. In the case where the Timestamp 2733 values of two events appear to contradict the EID ordering of those 2734 events (i.e., the later EID has an earlier timestamp) the recipient 2735 MUST treat the EID ordering as correct. 2737 All events recorded in a Software Identifier Events Attribute are 2738 required to be part of the same EID Epoch. Specifically, all 2739 reported events MUST have an EID from the same EID Epoch as each 2740 other, and which is the same as the EID Epoch of the Last EID and 2741 Last Consulted EID values. The SWIMA-PC MUST NOT report events with 2742 EIDs from different EID Epochs. 2744 The Last Consulted EID field contains the EID of the last event 2745 record considered for inclusion in this attribute. If this attribute 2746 contains a partial event set (as described in Section 3.7.5) this 2747 field value will be less than the Last EID value; if this attribute 2748 contains a complete event set, the Last EID and Last Consulted EID 2749 values are identical. 2751 If multiple events are sent in a Software Identifier Events 2752 attribute, the order in which they appear within the attribute is not 2753 significant. The EIDs associated with them are used for ordering the 2754 indicated events appropriately. Also note that a single software 2755 record might be reported multiple times in an attribute, such as if 2756 multiple events involving the associated record were being reported. 2758 5.10. Software Inventory 2760 A SWIMA-PC sends this attribute to a SWIMA-PV to convey a list of 2761 inventory records. A SWIMA-PV MUST NOT send this attribute. The 2762 SWIMA-PC either sends this attribute in fulfillment of an existing 2763 subscription where the establishing request had a Result Type of 0 2764 and the Earliest EID is zero, or in direct response to a SWIMA 2765 Request attribute where the Result Type is 0 and the Earliest EID is 2766 zero. 2768 1 2 3 2769 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 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | Flags | Record Count | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 | Request ID Copy / Subscription ID | 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | EID Epoch | 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | Last EID | 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | Record Identifier | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | Data Model Type PEN |Data Model Type| 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | Source Id Num | Software Identifier Length |Software Id (v)| 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | Software Locator Length |Software Locator (variable len)| 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 | Record Length | 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | Record (variable length) | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 Figure 9: Software Inventory Attribute 2794 +----------------+--------------------------------------------------+ 2795 | Field | Description | 2796 +----------------+--------------------------------------------------+ 2797 | Flags: Bit 0 - | In the case that this attribute is sent in | 2798 | Subscription | fulfillment of a subscription this bit MUST be | 2799 | Fulfillment | set (1). In the case that this attribute is a | 2800 | | direct response to a SWIMA Request, this bit | 2801 | | MUST be unset (0). | 2802 | | | 2803 | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | 2804 | - Reserved | to zero on transmission and ignored upon | 2805 | | reception. | 2806 | | | 2807 | Record Count | The number of records that follow. This field is | 2808 | | a 3-byte unsigned integer. The Record | 2809 | | Identifier, Data Model Type PEN, Data Model | 2810 | | Type, Source Identification Number, Software | 2811 | | Identifier Length, Software Identifier, Software | 2812 | | Locator Length, Software Locator, Record Length, | 2813 | | and Record fields are repeated, in order, the | 2814 | | number of times indicated in this field. This | 2815 | | field value MAY be 0 in which case there are no | 2816 | | instances of these fields. | 2817 | | | 2818 | Request ID | In the case where this attribute is in direct | 2819 | Copy / | response to a SWIMA Request attribute from a | 2820 | Subscription | SWIMA-PV, this field MUST contain an exact copy | 2821 | ID | of the Request ID field from that SWIMA Request. | 2822 | | In the case where this attribute is sent in | 2823 | | fulfillment of an active subscription, this | 2824 | | field MUST contain the Subscription ID of the | 2825 | | subscription being fulfilled by this attribute. | 2826 | | | 2827 | EID Epoch | The EID Epoch of the Last EID value. This field | 2828 | | is an unsigned 4-byte integer. | 2829 | | | 2830 | Last EID | The EID of the last event recorded by the SWIMA- | 2831 | | PC, or 0 if the SWIMA-PC has no recorded events. | 2832 | | This field is an unsigned 4-byte integer. | 2833 | | | 2834 | Record | A 4-byte, unsigned integer containing the Record | 2835 | Identifier | Identifier value from a software inventory | 2836 | | evidence record. | 2837 | | | 2838 | Data Model | A 3-byte unsigned integer containing the Private | 2839 | Type PEN | Enterprise Number (PEN) of the organization that | 2840 | | assigned the meaning of the Data Model Type | 2841 | | value. | 2842 | | | 2843 | Data Model | A 1-byte unsigned integer containing an | 2844 | Type | identifier number that identifies the data model | 2845 | | of the reported record. | 2846 | | | 2847 | Source | The Source Identification Number associated with | 2848 | Identification | the source from which this software installation | 2849 | Number | inventory instance was reported. | 2850 | | | 2851 | Software | A 2-byte unsigned integer indicating the length | 2852 | Identifier | in bytes of the SW ID field. | 2853 | Length | | 2854 | | | 2855 | Software | A string containing the Software Identifier | 2856 | Identifier | value from a software inventory evidence record. | 2857 | | This field value MUST be normalized to Network | 2858 | | Unicode format, as described in Section 5.5. | 2859 | | This string MUST NOT be NULL terminated. | 2860 | | | 2861 | Software | A 2-byte unsigned integer indicating the length | 2862 | Locator Length | in bytes of the Software Locator field. | 2863 | | | 2864 | Software | A string containing the Software Locator value. | 2865 | Locator | This is expressed as a URI. This field value | 2866 | | MUST be normalized to Network Unicode format as | 2867 | | described in Section 3.4.4. This string MUST NOT | 2868 | | be NULL terminated. | 2869 | | | 2870 | Record Length | This is a 4-byte unsigned integer indicating the | 2871 | | length of the Record field in bytes. | 2872 | | | 2873 | Record | A software inventory evidence record as a | 2874 | | string. The record MUST be converted and | 2875 | | normalized to Network Unicode format, as | 2876 | | described in Section 5.5. This string MUST NOT | 2877 | | be NULL terminated. | 2878 +----------------+--------------------------------------------------+ 2880 Table 5: Software Inventory Attribute Fields 2882 The Software Inventory attribute contains some number of software 2883 inventory evidence records along with the core response attribute 2884 fields. Given that the size of records can vary considerably, the 2885 length of this attribute is highly variable and, if transmitting a 2886 complete inventory, can be extremely large. Enterprises might wish 2887 to constrain the use of Software Inventory attributes to targeted 2888 requests to avoid over-burdening the network unnecessarily. 2890 When copying a software inventory evidence record into the Record 2891 field, the record MUST be converted and normalized to use Network 2892 Unicode format prior to its inclusion in the record field. 2894 5.11. Software Events 2896 A SWIMA-PC sends this attribute to a SWIMA-PV to convey a list of 2897 events that include software inventory evidence records. A SWIMA-PV 2898 MUST NOT send this attribute. The SWIMA-PC either sends this 2899 attribute in fulfillment of an existing subscription where the 2900 establishing request has a Result Type of 0 and the Earliest EID is 2901 non-zero, or in direct response to a SWIMA Request attribute where 2902 the Result Type is 0 and the Earliest EID is non-zero. 2904 1 2 3 2905 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 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 | Flags | Event Count | 2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2909 | Request ID Copy / Subscription ID | 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2911 | EID Epoch | 2912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2913 | Last EID | 2914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2915 | Last Consulted EID | 2916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2917 | EID | 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 | Timestamp | 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 | Timestamp | 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 | Timestamp | 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 | Timestamp | 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 | Timestamp | 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | Record Identifier | 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 | Data Model Type PEN |Data Model Type| 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 | Source Id Num | Action | Software Identifier Length | 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 | Software Identifier (variable length) | 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 | Software Locator Length |Software Locator (variable len)| 2938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2939 | Record Length | 2940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 | Record (variable Length) | 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2944 Figure 10: Software Events Attribute 2946 +----------------+--------------------------------------------------+ 2947 | Field | Description | 2948 +----------------+--------------------------------------------------+ 2949 | Flags: Bit 0 - | In the case that this attribute is sent in | 2950 | Subscription | fulfillment of a subscription this bit MUST be | 2951 | Fulfillment | set (1). In the case that this attribute is a | 2952 | | direct response to a SWIMA Request, this bit | 2953 | | MUST be unset (0). | 2954 | | | 2955 | Flags: Bit 1-7 | Reserved for future use. This field MUST be set | 2956 | - Reserved | to zero on transmission and ignored upon | 2957 | | reception. | 2958 | | | 2959 | Event Count | The number of events being reported in this | 2960 | | attribute. This field is a 3-byte unsigned | 2961 | | integer. The EID, Timestamp, Record Identifier, | 2962 | | Data Model Type PEN, Data Model Type, Source | 2963 | | Identification Number, Action, Software | 2964 | | Identifier Length, Software Identifier, Software | 2965 | | Locator Length, Software Locator, Record Length, | 2966 | | and Record fields are repeated, in order, the | 2967 | | number of times indicated in this field. This | 2968 | | field value MAY be 0, in which case there are no | 2969 | | instances of these fields. | 2970 | | | 2971 | Request ID | In the case where this attribute is in direct | 2972 | Copy / | response to a SWIMA Request attribute from a | 2973 | Subscription | SWIMA-PV, this field MUST contain an exact copy | 2974 | ID | of the Request ID field from that SWIMA Request. | 2975 | | In the case where this attribute is sent in | 2976 | | fulfillment of an active subscription, this | 2977 | | field MUST contain the Subscription ID of the | 2978 | | subscription being fulfilled by this attribute. | 2979 | | | 2980 | EID Epoch | The EID Epoch of the Last EID value. This field | 2981 | | is an unsigned 4-byte integer. | 2982 | | | 2983 | Last EID | The EID of the last event recorded by the SWIMA- | 2984 | | PC, or 0 if the SWIMA-PC has no recorded events. | 2985 | | This field contains the EID of the SWIMA-PC's | 2986 | | last recorded change event (which might or might | 2987 | | not be included as an event record in this | 2988 | | attribute). | 2989 | | | 2990 | Last Consulted | The EID of the last event record that was | 2991 | EID | consulted when generating the event record list | 2992 | | included in this attribute. This is different | 2993 | | from the Last EID field value if and only if | 2994 | | this attribute is conveying a partial list of | 2995 | | event records. See Section 3.7.5 for more on | 2996 | | partial list of event records. | 2997 | | | 2998 | EID | The EID of the event in this event record. | 2999 | | | 3000 | Timestamp | The timestamp associated with the event in this | 3001 | | event record. This timestamp is the SWIMA-PC's | 3002 | | best understanding of when the given event | 3003 | | occurred. Note that this timestamp might be an | 3004 | | estimate. The Timestamp date and time MUST be | 3005 | | represented as an RFC 3339 [5] compliant ASCII | 3006 | | string in Coordinated Universal Time (UTC) time | 3007 | | with the additional restrictions that the 'T' | 3008 | | delimiter and the 'Z' suffix MUST be capitalized | 3009 | | and fractional seconds (time-secfrac) MUST NOT | 3010 | | be included. This field conforms to the date- | 3011 | | time ABNF production from section 5.6 of RFC | 3012 | | 3339 [RFC3339] with the above restrictions. | 3013 | | Leap seconds are permitted and SWIMA-PVs MUST | 3014 | | support them. The Timestamp string MUST NOT be | 3015 | | NULL terminated or padded in any way. The length | 3016 | | of this field is always 20 octets. | 3017 | | | 3018 | Record | A 4-byte, unsigned integer containing the Record | 3019 | Identifier | Identifier value from a software inventory | 3020 | | evidence record. | 3021 | | | 3022 | Data Model | A 3-byte unsigned integer containing the Private | 3023 | Type PEN | Enterprise Number (PEN) of the organization that | 3024 | | assigned the meaning of the Data Model Type | 3025 | | value. | 3026 | | | 3027 | Data Model | A 1-byte unsigned integer containing an | 3028 | Type | identifier number that identifies the data model | 3029 | | of the reported record. | 3030 | | | 3031 | Source | The Source Identification Number associated with | 3032 | Identification | the source from which this software installation | 3033 | Number | inventory instance was reported. | 3034 | | | 3035 | Action | The type of event that is recorded in this event | 3036 | | record. Possible values are: 1 = CREATION - the | 3037 | | addition of a record to the endpoint's Software | 3038 | | Inventory Evidence Collection; 2 = DELETION - | 3039 | | the removal of a record from the endpoint's | 3040 | | Software Inventory Evidence Collection; 3 = | 3041 | | ALTERATION - There was an alteration to a record | 3042 | | within the endpoint's Software Inventory | 3043 | | Evidence Collection. All other values are | 3044 | | reserved for future use and MUST NOT be used | 3045 | | when sending attributes. In the case where a | 3046 | | SWIMA-PV receives an event record that uses an | 3047 | | action value other than the ones defined here, | 3048 | | it MUST ignore that event record but SHOULD | 3049 | | process other event records in this attribute as | 3050 | | normal. | 3051 | | | 3052 | Software | A 2-byte unsigned integer indicating the length | 3053 | Identifier | in bytes of the Software Identifier field. | 3054 | Length | | 3055 | | | 3056 | Software | A string containing the Software Identifier | 3057 | Identifier | value from a software inventory evidence record. | 3058 | | This field value MUST be normalized to Network | 3059 | | Unicode format, as described in Section 5.5. | 3060 | | This string MUST NOT be NULL terminated. | 3061 | | | 3062 | Software | A 2-byte unsigned integer indicating the length | 3063 | Locator Length | in bytes of the Software Locator field. | 3064 | | | 3065 | Software | A string containing the Software Locator value. | 3066 | Locator | This is expressed as a URI. This field value | 3067 | | MUST be normalized to Network Unicode format as | 3068 | | described in Section 3.4.4. This string MUST NOT | 3069 | | be NULL terminated. | 3070 | | | 3071 | Record Length | This is a 4-byte unsigned integer indicating the | 3072 | | length of the Record field in bytes. | 3073 | | | 3074 | Record | A software inventory evidence record as a | 3075 | | string. The record MUST be converted and | 3076 | | normalized to Network Unicode format, as | 3077 | | described in Section 5.5. This string MUST NOT | 3078 | | be NULL terminated. | 3079 +----------------+--------------------------------------------------+ 3081 Table 6: Software Events Attribute Fields 3083 The fields of this attribute are used in the same way as the 3084 corresponding fields of the previous attributes. As with the 3085 Software Inventory attribute, a Software Events attribute can be 3086 quite large if many events have occurred following the event 3087 indicated by a request's Earliest EID. As such, it is recommended 3088 that the SWIMA Request attributes only request full records be sent 3089 (Result Type set to 0) in a targeted request, thus constraining the 3090 response just to records that match a given set of Software 3091 Identifiers. 3093 As with the Software Identifier Events Attribute, this attribute MUST 3094 only contain event records with EIDs coming from the current EID 3095 Epoch of the SWIMA-PC. 3097 As with the Software Inventory Attribute, the SWIMA-PC MUST perform 3098 conversion and normalization of the record. 3100 5.12. Subscription Status Request 3102 A SWIMA-PV sends this attribute to a SWIMA-PC to request a list of 3103 active subscriptions for which the requesting SWIMA-PV is the 3104 subscriber. A SWIMA-PC MUST NOT send this attribute. 3106 This attribute has no fields. 3108 A SWIMA-PC MUST respond to this attribute by sending a Subscription 3109 Status Response attribute (or a PA-TNC Error attribute if it is 3110 unable to correctly provide a response). 3112 5.13. Subscription Status Response 3114 A SWIMA-PC sends this attribute to a SWIMA-PV to report the list of 3115 active subscriptions for which the receiving SWIMA-PV is the 3116 subscriber. A SWIMA-PV MUST NOT send this attribute. 3118 1 2 3 3119 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 3120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3121 | Status Flags | Subscription Record Count | 3122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3123 | Flags | Software Identifier Count | 3124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3125 | Request ID | 3126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3127 | Earliest EID | 3128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3129 | Software Identifier Length | Software Identifier (var len) | 3130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3132 Figure 11: Subscription Status Response Attribute 3134 +-----------------+-------------------------------------------------+ 3135 | Field | Description | 3136 +-----------------+-------------------------------------------------+ 3137 | Flags: Bit 0-7 | Reserved for future use. This field MUST be set | 3138 | - Reserved | to zero on transmission and ignored upon | 3139 | | reception. | 3140 | | | 3141 | Subscription | The number of subscription records that follow. | 3142 | Record Count | This field is a 3-byte unsigned integer. The | 3143 | | Flags, Software Identifier Count, Request ID, | 3144 | | Earliest EID, Software Identifier Length, and | 3145 | | Software Identifier fields are repeated, in | 3146 | | order, the number of times indicated in this | 3147 | | field. This field value MAY be 0 in which case | 3148 | | there are no instances of these fields. | 3149 | | | 3150 | Flags, Software | For each active subscription, these fields | 3151 | Identifier | contain an exact copy of the fields with the | 3152 | Count, Request | same name as provided in the subscription's | 3153 | ID, Earliest | establishing request. | 3154 | EID, Software | | 3155 | Identifier | | 3156 | Length, and | | 3157 | Software | | 3158 | Identifier | | 3159 +-----------------+-------------------------------------------------+ 3161 Table 7: Subscription Status Response Fields 3163 A Subscription Status Response contains zero or more subscription 3164 records. Specifically, it MUST contain one subscription record for 3165 each active subscription associated with the party that sent the 3166 Subscription Status Request to which this attribute is a response. 3167 As described in Section 3.8.2, the SWIMA-PC MUST use the requester's 3168 Connection ID and its Posture Validator ID to determine which 3169 subscriptions are associated with the requester. 3171 A SWIMA-PC MUST send a Subscription Status Response attribute in 3172 response to a Subscription Status Request attribute. The only 3173 exception to this is if the SWIMA-PC experiences an error condition 3174 that prevents it from correctly populating the Subscription Status 3175 Response attribute, in which case it MUST respond with a PA-TNC Error 3176 attribute appropriate to the type of error experienced. If there are 3177 no active subscriptions associated with the requesting party, the 3178 Subscription Status Response attribute will consist of its Status 3179 Flags field, a Subscription Record Count field with a value of 0, and 3180 no additional fields. 3182 Each subscription record included in a Subscription Status Response 3183 attribute duplicates the fields of a SWIMA Request attribute that was 3184 the establishing request of a subscription. Note that the Request ID 3185 field in the record captures the Subscription ID associated with the 3186 given subscription record (since the Subscription ID is the same as 3187 the Request ID of the establishing request). Note also that if the 3188 establishing request is targeted, then its Record Count field will be 3189 non-zero and, within that subscription record, the Software 3190 Identifier Length and Software Identifier fields are repeated, in 3191 order, the number of times indicated in the Record Count field. As 3192 such, each subscription record can be different sizes. If the 3193 establishing request is not targeted (Record Count field is 0), the 3194 subscription record has no Software Identifier Length or Software 3195 Identifier fields. 3197 When a SWIMA-PV compares the information received in a Subscription 3198 Status Response to its own records of active subscriptions it should 3199 be aware that the SWIMA-PC might be unable to distinguish this SWIMA- 3200 PV from other SWIMA-PVs on the same NEA Server. As a result, it is 3201 possible that the SWIMA-PC will report more subscription records than 3202 the SWIMA-PV recognizes. For this reason, SWIMA-PVs SHOULD NOT 3203 automatically assume that extra subscriptions reported in a 3204 Subscription Status Response indicate a problem. 3206 5.14. Source Metadata Request 3208 A SWIMA-PV sends this attribute to a SWIMA-PC to request metadata 3209 about sources that the SWIMA-PC is using to collect software 3210 inventory information. A SWIMA-PC MUST NOT send this attribute. 3212 This attribute has no fields. 3214 A SWIMA-PC MUST respond to this attribute by sending a Sources 3215 Metadata Response attribute (or a PA-TNC Error attribute if it is 3216 unable to correctly provide a response). 3218 5.15. Source Metadata Response 3220 A SWIMA-PC sends this attribute to a SWIMA-PV to provide descriptive 3221 metadata about the sources of software inventory information used by 3222 the SWIMA-PC. A SWIMA-PV MUST NOT send this attribute. 3224 1 2 3 3225 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 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 | Reserved | Source Count | Source ID | 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | Metadata Length | Metadata (variable length) | 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3232 Source Metadata Response Attribute 3234 +----------+--------------------------------------------------------+ 3235 | Field | Description | 3236 +----------+--------------------------------------------------------+ 3237 | Reserved | Reserved for future use. This field MUST be set to | 3238 | | zero on transmission and ignored upon reception. | 3239 | | | 3240 | Source | The number of source records that follow. The Source | 3241 | Count | ID, Metadata Size, and Metadata fields are repeated, | 3242 | | in order, the number of times indicated by this field. | 3243 | | This field MAY be 0, in which case no fields follow | 3244 | | (but this would only be done to indicate that the | 3245 | | SWIMA-PC has no active sources, which would not be a | 3246 | | usual situation). | 3247 | | | 3248 | Source | The Source ID number associated with the described | 3249 | ID | source for any communications with the recipient | 3250 | | SWIMA-PV. | 3251 | | | 3252 | Metadata | A 2-byte unsigned integer indicating the length in | 3253 | Length | bytes of the Metadata field. | 3254 | | | 3255 | Metadata | A string containing descriptive metadata about the | 3256 | | indicated data source. This string MUST NOT be NULL | 3257 | | terminated. | 3258 +----------+--------------------------------------------------------+ 3260 Source Metadata Response Fields 3262 A Source Metadata Response attribute contains 0 or more records, each 3263 describing one of the data sources the SWIMA-PC uses to collect 3264 software inventory information. It SHOULD contain one metadata 3265 record for each source that the SWIMA-PC uses. (There might be 3266 reasons not to inform certain SWIMA-PVs of the presence of certain 3267 data sources.) The attribute MUST contain a metadata record for each 3268 source that has been identified in inventory or event messages to the 3269 given SWIMA-PV. 3271 A SWIMA-PC MUST send a Source Metadata Response attribute in response 3272 to a Source Metadata Request attribute. The only exception to this 3273 is if the SWIMA-PC experiences an error condition that prevents it 3274 from correctly populating the Source Metadata Response attribute, in 3275 which case it MUST respond with a PA-TNC Error attribute appropriate 3276 to the type of error experienced. 3278 The Source Count field indicates how many source metadata records are 3279 included in the attribute. Each included record consists of a Source 3280 Identifier, Metadata Length, and Metadata field. 3282 The Source Identifier corresponds to the Source Identifier field in 3283 inventory and event messages. In the case where the Source 3284 Identifier value in a Source Metadata Response attribute matches a 3285 Source Identifier associated with an event or inventory record and 3286 both the Source Metadata Response and the inventory/event record were 3287 sent to the same SWIMA-PV, the source described in the Metadata field 3288 MUST be the same source that provided the event or inventory record 3289 associated with the Source Identifier. Recall that a SWIMA-PC MAY 3290 use different Source Identifier associations with different SWIMA- 3291 PVs. When sending to a giving SWIMA-PV, the SWIMA-PC MUST use the 3292 recipient SWIMA-PVs Source Identifier associations. 3294 The Metadata Length indicates the length, in bytes, if the Metadata 3295 field. The Metadata field contains information about the indicated 3296 data source. This specification does not dictate a format for the 3297 contents of the Metadata field. This field MAY include machine- 3298 readable information. For broadest utility, the Metadata field 3299 SHOULD include human-readable, descriptive information about the data 3300 source. 3302 5.16. PA-TNC Error as Used by Software Inventory Message and Attributes 3303 for PA-TNC 3305 The PA-TNC Error attribute is defined in the PA-TNC specification 3306 [RFC5792], and its use here conforms to that specification. A PA-TNC 3307 Error can be sent due to any error in the PA-TNC exchange and might 3308 also be sent in response to error conditions specific to the Software 3309 Inventory Message and Attributes for PA-TNC exchange. The latter 3310 case utilizes error codes defined below. 3312 A PA-TNC Error MUST be sent by a SWIMA-PC in response to a SWIMA 3313 Request in the case where the SWIMA-PC encounters a fatal error 3314 (i.e., an error that prevents further processing of an exchange) 3315 relating to the attribute exchange. A SWIMA-PV MUST NOT send this 3316 attribute. In the case where the SWIMA-PV experiences a fatal error, 3317 it MUST handle the error without sending a PA-TNC Error attribute. 3318 The SWIMA-PV MAY take other actions in response to the error, such as 3319 logging the cause of the error, or even taking actions to isolate the 3320 endpoint. 3322 A PA-TNC Error attribute is sent instead of a SWIMA Response 3323 attribute due to factors that prevent the reliable creation of a 3324 SWIMA Response. As such, a SWIMA-PC MUST NOT send both a PA-TNC 3325 Error attribute and a SWIMA Response attribute in response to a 3326 single SWIMA Request attribute. 3328 Table 8 lists the Error Code values for the PA-TNC Error attribute 3329 specific to the Software Inventory Message and Attributes for PA-TNC 3330 exchange. Error codes are shown in both hexadecimal and decimal 3331 format. In all of these cases, the Error Code Vendor ID field MUST 3332 be set to 0x000000, corresponding to the IETF SMI Private Enterprise 3333 Number. The Error Information structures for each error type are 3334 described in the following subsections. 3336 Note that a message with a Software Inventory Message and Attributes 3337 for PA-TNC attribute might also result in an error condition covered 3338 by the Standard PA-TNC Error Codes defined in PA-TNC. For example, a 3339 SWIMA Attribute might have an invalid parameter, leading to an error 3340 code of "Invalid Parameter". In this case, the SWIMA-PC MUST use the 3341 appropriate PA-TNC Error Code value as defined in Section 4.2.8 of 3342 PA-TNC specification. 3344 +-----------------------+-------------------------------------------+ 3345 | Error Code Value | Description | 3346 +-----------------------+-------------------------------------------+ 3347 | 0x00000020 (32) | SWIMA_ERROR. This indicates a fatal error | 3348 | | (i.e., an error that precludes the | 3349 | | creation of a suitable response | 3350 | | attribute) other than the errors | 3351 | | described below but still specific to the | 3352 | | processing of SWIMA Attributes. The | 3353 | | Description field SHOULD contain | 3354 | | additional diagnostic information. | 3355 | | | 3356 | 0x00000021 (33) | SWIMA_SUBSCRIPTION_DENIED_ERROR. This | 3357 | | indicates that the SWIMA-PC denied the | 3358 | | SWIMA-PV's request to establish a | 3359 | | subscription. The Description field | 3360 | | SHOULD contain additional diagnostic | 3361 | | information. | 3362 | | | 3363 | 0x00000022 (34) | SWIMA_RESPONSE_TOO_LARGE_ERROR. This | 3364 | | indicates that the SWIMA-PC's response to | 3365 | | the SWIMA-PV's request was too large to | 3366 | | be serviced. The error information | 3367 | | structure indicates the largest possible | 3368 | | size of a response supported by the | 3369 | | SWIMA-PC (see Section 5.16.2). The | 3370 | | Description field SHOULD contain | 3371 | | additional diagnostic information. | 3372 | | | 3373 | 0x00000023 (35) | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR. | 3374 | | This indicates that the SWIMA-PC | 3375 | | experienced an error fulfilling a given | 3376 | | subscription. The error information | 3377 | | includes the Subscription ID of the | 3378 | | relevant subscription, as well as a sub- | 3379 | | error that describes the nature of the | 3380 | | error the SWIMA-PC experienced. The | 3381 | | SWIMA-PC and SWIMA-PV MUST treat the | 3382 | | identified subscription as cancelled. | 3383 | | | 3384 | 0x00000024 (36) | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. This | 3385 | | indicates that the SWIMA-PC received a | 3386 | | SWIMA Request from a given SWIMA-PV where | 3387 | | the Request ID of that SWIMA Request is | 3388 | | currently used as the Subscription ID of | 3389 | | an active subscription with that SWIMA- | 3390 | | PV. This error does not cancel the | 3391 | | identified subscription. | 3392 | | | 3393 | 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved | 3394 | (37-47) | for use by future revisions of the | 3395 | | Software Inventory Message and Attributes | 3396 | | for PA-TNC specification. Any PA-TNC | 3397 | | Error attribute using one of these Error | 3398 | | Codes MUST be treated as indicating a | 3399 | | fatal error on the sender without further | 3400 | | interpretation. | 3401 +-----------------------+-------------------------------------------+ 3403 Table 8: PA-TNC Error Codes for Software Inventory Message and 3404 Attributes for PA-TNC 3406 The following subsections describe the structures present in the 3407 Error Information fields. 3409 5.16.1. SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR and 3410 SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information 3412 The SWIMA_ERROR error code indicates that the sender (the SWIMA-PC) 3413 has encountered an error related to the processing of a SWIMA Request 3414 attribute but which is not covered by more specific SWIMA error 3415 codes. The SWIMA_SUBSCRIPTION_DENIED_ERROR is used when the SWIMA-PV 3416 requests to establish a subscription or clear all subscriptions from 3417 the given SWIMA-PV, but the SWIMA-PC is unable or unwilling to comply 3418 with this request. The SWIMA_SUBSCRIPTION_ID_REUSE_ERROR is used 3419 when the SWIMA-PC receives a SWIMA Request whose Request ID 3420 duplicates a Subscription ID of an active subscription with the 3421 request's sender. All of these error codes use the following error 3422 information structure. 3424 1 2 3 3425 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 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3427 | Copy of Request ID / Subscription ID | 3428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3429 | Description (variable length) | 3430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3432 Figure 12: SWIMA Error, Subscription Error, and Subscription ID Reuse 3433 Information 3435 +--------------+----------------------------------------------------+ 3436 | Field | Description | 3437 +--------------+----------------------------------------------------+ 3438 | Copy of | In the case that this error condition is generated | 3439 | Request ID / | in direct response to a SWIMA Request attribute, | 3440 | Subscription | this field MUST contain an exact copy of the | 3441 | ID | Request ID field in the SWIMA Request attribute | 3442 | | that caused this error. In the case that the | 3443 | | attribute in question is generated in fulfillment | 3444 | | of an active subscription, this field MUST contain | 3445 | | the Subscription ID of the subscription for which | 3446 | | the attribute was generated. (This is only | 3447 | | possible if the error code is SWIMA_ERROR as the | 3448 | | other errors are not generated by subscription | 3449 | | fulfillment.) Note that, in this case, the | 3450 | | indicated error appears as a sub-error for a | 3451 | | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described | 3452 | | in Section 5.16.3. | 3453 | | | 3454 | Description | A UTF-8 string describing the condition that | 3455 | | caused this error. This field MAY be 0-length. | 3456 | | However, senders SHOULD include some description | 3457 | | in all PA-TNC Error attributes of these types. | 3458 | | This field MUST NOT be NULL terminated. | 3459 +--------------+----------------------------------------------------+ 3461 Table 9: SWIMA Error, Subscription Error, and Subscription ID Reuse 3462 Information Fields 3464 This error information structure is used with SWIMA_ERROR, 3465 SWIMA_SUBSCRIPTION_DENIED_ERROR, and 3466 SWIMA_SUBSCRIPTION_ID_REUSE_ERROR status codes to identify the SWIMA 3467 Request attribute that precipitated the error condition and to 3468 describe the error. The Description field contains text describing 3469 the error. The SWIMA-PC MAY encode machine-interpretable information 3470 in this field, but SHOULD also include a human-readable description 3471 of the error, since the receiving SWIMA-PV might not recognize the 3472 SWIMA-PC's encoded information. 3474 5.16.2. SWIMA_RESPONSE_TOO_LARGE_ERROR Information 3476 The SWIMA_RESPONSE_TOO_LARGE_ERROR error code indicates that a 3477 response generated by a SWIMA-PC in response to a SWIMA-PV's SWIMA 3478 Request attribute was too large to send. 3480 1 2 3 3481 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 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3483 | Copy of Request ID / Subscription I | 3484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3485 | Maximum Allowed Size | 3486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3487 | Description (variable length) | 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3490 Figure 13: SWIMA Response Too Large Error Information 3492 +--------------+----------------------------------------------------+ 3493 | Field | Description | 3494 +--------------+----------------------------------------------------+ 3495 | Copy of | In the case that the attribute in question is | 3496 | Request ID / | generated in direct response to a SWIMA Request, | 3497 | Subscription | this field MUST contain an exact copy of the | 3498 | ID | Request ID field in the SWIMA Request attribute | 3499 | | that caused this error. In the case that the | 3500 | | attribute in question is generated in fulfillment | 3501 | | of an active subscription, this field MUST contain | 3502 | | the Subscription ID of the subscription for which | 3503 | | the attribute was generated. Note that, in the | 3504 | | latter case, the SWIMA_RESPONSE_TOO_LARGE_ERROR | 3505 | | appears as a sub-error for a | 3506 | | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described | 3507 | | in Section 5.16.3. | 3508 | | | 3509 | Maximum | This field MUST contain an unsigned integer | 3510 | Allowed Size | indicating the largest permissible size, in bytes, | 3511 | | of SWIMA Attribute that the SWIMA-PC is currently | 3512 | | willing to send in response to a SWIMA Request | 3513 | | attribute. | 3514 | | | 3515 | Description | A UTF-8 string describing the condition that | 3516 | | caused this error. This field MAY be 0-length. | 3517 | | However, senders SHOULD include some description | 3518 | | in all PA-TNC Error attributes of these types. | 3519 | | This field MUST NOT be NULL terminated. | 3520 +--------------+----------------------------------------------------+ 3522 Table 10: SWIMA Response Too Large Error Information Fields 3524 This error structure is used with the SWIMA_RESPONSE_TOO_LARGE_ERROR 3525 status code to identify the SWIMA Request attribute that precipitated 3526 the error condition and to describe the error. The Maximum Allowed 3527 Size field indicates the largest attribute the SWIMA-PC is willing to 3528 send in response to a SWIMA Request under the current circumstances. 3529 Note that under other circumstances, the SWIMA-PC might be willing to 3530 return larger or smaller responses than indicated (such as if the 3531 endpoint connects to the NEA Server using a different network 3532 protocol). The other fields in this error information structure have 3533 the same meanings as corresponding fields in the SWIMA_ERROR and 3534 SWIMA_SUBSCRIPTION_DENIED_ERROR information structure. 3536 5.16.3. SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information 3538 The SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that 3539 the SWIMA-PC encountered an error while fulfilling a subscription. 3540 The bytes after the first 4 octets duplicate a PA-TNC Error attribute 3541 (as described in Section 4.2.8 of PA-TNC) that is used to identify 3542 the nature of the encountered error. 3544 1 2 3 3545 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 3546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3547 | Subscription ID | 3548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3549 | Reserved | Sub Error Code Vendor ID | 3550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3551 | Sub Error Code | 3552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3553 | Sub Error Information (variable Length) | 3554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3556 Figure 14: SWIMA Subscription Fulfillment Error Information 3558 +--------------+----------------------------------------------------+ 3559 | Field | Description | 3560 +--------------+----------------------------------------------------+ 3561 | Subscription | This field MUST contain the Subscription ID of the | 3562 | ID | subscription whose fulfillment caused this error. | 3563 | | | 3564 | Reserved | This field MUST contain the value of the Reserved | 3565 | | field of a PA-TNC Error attribute that describes | 3566 | | the error condition encountered during | 3567 | | subscription processing. | 3568 | | | 3569 | Sub Error | This field MUST contain the value of the Error | 3570 | Code Vendor | Code Vendor ID field of a PA-TNC Error attribute | 3571 | ID | that describes the error condition encountered | 3572 | | during subscription processing. | 3573 | | | 3574 | Sub Error | This field MUST contain the value of the Error | 3575 | Code | Code field of a PA-TNC Error attribute that | 3576 | | describes the error condition encountered during | 3577 | | subscription processing. | 3578 | | | 3579 | Sub Error | This field MUST contain the value of the Error | 3580 | Information | Information field of a PA-TNC Error attribute that | 3581 | | describes the error condition encountered during | 3582 | | subscription processing. | 3583 +--------------+----------------------------------------------------+ 3585 Table 11: SWIMA Subscription Fulfillment Error Information Fields 3587 This error structure is used with the 3588 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets 3589 of this error structure contain the Subscription ID of the 3590 subscription that was being fulfilled when the error occurred. The 3591 remaining fields of this error structure duplicate the fields of a 3592 PA-TNC Error attribute, referred to as the "sub-error". The error 3593 code of the sub-error corresponds to the type of error that the 3594 SWIMA-PC encountered while fulfilling the given subscription. The 3595 sub-error MUST NOT have an error code of 3596 SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR. 3598 The SWIMA-PC sending a PA-TNC Error attribute with this error code, 3599 and the SWIMA-PV receiving it, MUST treat the subscription identified 3600 by the Subscription ID field as cancelled. All other subscriptions 3601 are unaffected. 3603 6. Supported Data Models 3605 Software Inventory Message and Attributes for PA-TNC supports an 3606 extensible list of data models for representing and transmitting 3607 software inventory information. This list of data models appears in 3608 the Software Data Model IANA registry (see Section 10.4). This 3609 document provides guidance for an initial set of data models. Other 3610 documents might provide guidance on the use of new data models by 3611 Software Inventory Message and Attributes for PA-TNC, and will be 3612 referenced by extensions to the Software Data Model IANA registry. 3614 6.1. ISO 2015 SWID Tags using XML 3616 The International Organization for Standardization and the 3617 International Electrotechnical Commission (ISO/IEC) published the 3618 specification governing SWID tag construction and use in 2009 with a 3619 revised version published in 2015. [SWID15] Since that time, a 3620 growing number of vendors have integrated SWID tags into their 3621 software products. Doing so significantly simplifies the task of 3622 identifying these pieces of software: instead of relying on discovery 3623 processes that look for clues as to software presence, such as the 3624 presence of particular files or registry keys. A readily available 3625 list of SWID tags provides simple and immediate evidence as to the 3626 presence of the given piece of software. 3628 SWIMA has no reliance on the presence or management of SWID tags on 3629 an endpoint as described in the ISO specification. However, the data 3630 model for describing software that is presented in the ISO 3631 specification provides a robust and comprehensive way of describing 3632 software and is adopted here as a means of representing and 3633 transmitting software information. It should be emphasized, the use 3634 of the ISO SWID tag data model makes no assumption as to whether the 3635 source of the recorded information was, in fact, an ISO SWID tag 3636 harvested from the endpoint or whether the information was created 3637 using some other source and normalized to the SWID format. 3639 6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags using 3640 XML 3642 Any record associated with this Software Data Model Type MUST conform 3643 to the ISO/IEC 19770-2-2015 [SWID15] specification. 3645 If generating a new ISO 2015 SWID tag, the software generating the 3646 tag MUST use a Tag Creator RegID that is associated with the 3647 generating software, unless this is impossible, in which case it MUST 3648 use the "http://invalid.unavailable" Tag Creator RegID value. Do not 3649 use a RegID associated with any other party. In particular, it is 3650 incorrect to use a Tag Creator RegID associated with the software 3651 being described by the tag, the enterprise that is using the 3652 software, or any other entity except that of the party that built the 3653 tool that is generating the SWID tag. This reflects the requirement 3654 that the Tag Creator RegID identify the party that created the tag. 3655 Moreover, any generated tags SHOULD conform with guidance for tag 3656 creators provided NIST IR 8060 [NIST8060], which provides additional 3657 recommendations to increase interoperable use of SWID tags. 3659 6.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID 3660 Tags 3662 A Software Identifier generated from an ISO 2015 SWID tag is 3663 expressed as a concatenation of the value of the Tag Creator RegID 3664 field and the Unique ID field. Specifically, it MUST be of the form: 3665 TAG_CREATOR_REGID "_" "_" UNIQUE_ID. Specifically, the Software 3666 Identifier consists of, the Tag Creator RegID and the Unique ID from 3667 the tag connected with a double underscore (_), without any other 3668 connecting character or whitespace. 3670 6.2. ISO 2009 SWID Tags using XML 3672 As noted above, ISO's SWID tag specification provides a useful data 3673 model for representation of software information. As of the writing 3674 of this specification, while the 2015 specification is considered 3675 more comprehensive and addresses some issues with the 2009 3676 specification, 2009-format SWID tags remain far more common in 3677 deployments. For this reason, ISO 2009 SWID tags are included in the 3678 Software Data Model IANA table. 3680 6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID Tags using 3681 XML 3683 Any record associated with this Software Data Model Type MUST conform 3684 to the ISO/IEC 19770-2-2009 [SWID09] specification. Any such tag 3685 SHOULD use a UTF-8 encoding, but MUST NOT alter the existing encoding 3686 if doing so would invalidate digital signatures included in the tag. 3688 If generating a new ISO 2009 SWID tag, the software generating the 3689 tag MUST use a Tag Creator RegID that is associated with the 3690 generating software unless this is impossible, in which case it MUST 3691 use "http://invalid.unavailable", which indicates the Tag Creator is 3692 unknown. Do not use a RegID associated with any other party. In 3693 particular, it is incorrect to use a Tag Creator RegID associated 3694 with the software being described by the tag, the enterprise that is 3695 using the software, or any other entity except that of the party that 3696 built the tool that is generating the SWID tag. This reflects the 3697 requirement that the Tag Creator RegID identify the party that 3698 created the tag. 3700 6.2.2. Guidance on Creation of Software Identifiers from ISO 2009 SWID 3701 Tags 3703 A Software Identifier generated from an ISO 2009 SWID tag is 3704 expressed as a concatenation of the value of the Tag Creator RegID 3705 field and the Unique ID field. Specifically, it MUST be of the form: 3706 TAG_CREATOR_REGID "_" "_" UNIQUE_ID. Specifically, the Software 3707 Identifier consists of, the Tag Creator RegID and the Unique ID from 3708 the tag connected with a double underscore (_), without any other 3709 connecting character or whitespace. 3711 7. Security Considerations 3713 This section discusses some of the security threats facing Posture 3714 Collectors and Posture Validators that implement the Software 3715 Inventory Message and Attributes for PA-TNC protocol. This section 3716 primarily notes potential issues for implementers to consider, 3717 although it does contain a handful of normative requirements to 3718 address certain security issues. The issues identified below focus 3719 on capabilities specific to this document. Implementers are advised 3720 to consult other relevant NEA specifications, particularly [RFC5209] 3721 (the NEA Architecture) and [RFC5792] (PA-TNC), for security issues 3722 that are applicable to such components in general. 3724 7.1. Evidentiary Value of Software Inventory Evidence Records 3726 The degree to which an endpoint's Software Inventory Evidence 3727 Collection accurately reflects the endpoint's actual software load 3728 and any changes made to this software load is dependent on the 3729 accuracy of the tools used to populate and manage the software 3730 inventory evidence records in this collection. Some tools might not 3731 be designed to update records in the Software Inventory Evidence 3732 Collection in real time, resulting in a collection that is out-of- 3733 sync with actual system state. Moreover, tools might inaccurately 3734 characterize software, or fail to properly record its removal. 3735 Finally, it is likely that there will be software on the endpoint 3736 that is not tracked by any source and thus is not reflected in the 3737 Software Inventory Evidence Collection. Users of collected software 3738 inventory evidence records need to understand that the information 3739 provided by the Software Inventory Message and Attributes for PA-TNC 3740 capability cannot be treated as completely accurate. Nonetheless, 3741 having endpoints report this information can still provide useful 3742 insights into the state of the endpoint's software load, and can 3743 alert administrators and policy tools of situations that require 3744 remediation. 3746 7.2. Sensitivity of Collected Records 3748 Software records on an endpoint are generally not considered to be 3749 sensitive, although there can be exceptions to this generalization as 3750 noted in the section on Privacy Considerations. In general, an 3751 endpoint's Software Inventory Evidence Collection can be browsed and 3752 individual records read by any party with access to the endpoint. 3753 This is generally not considered to be problematic, as those with 3754 access to the endpoint can usually learn of everything disclosed by 3755 that endpoint's records simply by inspecting other parts of the 3756 endpoint. 3758 The situation changes when an endpoint's inventory records are 3759 collected and stored off of the endpoint itself, such as on a NEA 3760 Server or CMDB. Inventory records represent a wealth of information 3761 about the endpoint in question and, for an adversary who does not 3762 already have access to the endpoint, a collection of the endpoint's 3763 inventory records might provide many details that are useful for 3764 mounting an attack. A list of the inventory records associated with 3765 an endpoint reveals a list of software installed on the endpoint. 3766 This list can be very detailed, noting specific versions and even 3767 patch levels, which an adversary can use to identify vulnerable 3768 software and design efficacious attacks. 3770 In addition, other information might also be gleaned from a 3771 collection of software inventory records: 3773 o An inventory record might include information about where the 3774 product was installed on a given endpoint. This can reveal 3775 details about the file organization of that endpoint that an 3776 attacker can utilize. 3778 o An inventory record might include information about how the 3779 software was provided to the endpoint, who in an organization 3780 signs off on the package release, and who packaged the product for 3781 installation. This information might be used as a starting point 3782 for the development of supply chain attacks. 3784 o Events affecting inventory records are reported with timestamps 3785 indicating when each given event occurred. This can give the 3786 attacker an indication of how quickly an organization distributes 3787 patches and updates, helping the attacker determine how long an 3788 attack window might remain open. 3790 Any consolidated software inventory is a potential risk, because such 3791 an inventory can provide an adversary an insight into the 3792 enterprise's configuration and management process. It is recommended 3793 that a centralized software inventory record collection be protected 3794 against unauthorized access. Mechanisms to accomplish this can 3795 include encrypting the data at rest, ensuring that access to the data 3796 is limited only to authorized individuals and processes, and other 3797 basic security precautions. 3799 7.3. Integrity of Endpoint Records 3801 SWIMA-PCs maintain records of detected changes to the endpoint's 3802 Software Inventory Evidence Collection. These records are used to 3803 respond to a SWIMA-PV's request for change events. The SWIMA-PV 3804 might use a list of reported events to update its understanding of 3805 the endpoint's Software Inventory Evidence Collection without needing 3806 to receive a full inventory report from the SWIMA-PC. For this 3807 reason, preserving the integrity of the SWIMA-PC's record of events 3808 is extremely important. If an attacker modifies the SWIMA-PC's 3809 record of changes to the endpoint's Software Inventory Evidence 3810 Collection, this might cause the SWIMA-PV's understanding of the 3811 endpoint's Software Inventory Evidence Collection to differ from its 3812 actual state. Results might include leading the SWIMA-PV to believe 3813 that absent software was present, that present software was absent, 3814 that patches have been installed even if this is not the case, or to 3815 be unaware of other changes to Software Inventory Evidence Records. 3816 As such, the SWIMA-PC MUST take steps to protect the integrity of its 3817 event records. 3819 In addition, records of established SWIMA-PV subscriptions also 3820 require protection against manipulation or corruption. If an 3821 attacker is able to modify or delete records of an established 3822 subscription by a SWIMA-PV, the SWIMA-PC might fail to correctly 3823 fulfill this subscription. The SWIMA-PV would not be aware that its 3824 subscription was not being correctly fulfilled unless it received 3825 additional information that indicated a discrepancy. For example, 3826 the SWIMA-PV might collect a full inventory and realize from this 3827 that certain events had not been correctly reported in accordance 3828 with an established subscription. For this reason, the SWIMA-PC MUST 3829 protect the integrity of subscription records. 3831 7.4. SWIMA-PC Access Permissions 3833 A SWIMA-PC requires sufficient permissions to collect Software 3834 Inventory Evidence Records from all of its supported sources, as well 3835 as sufficient permissions to interact with the endpoint's Posture 3836 Broker Client. With regard to the former, this might require 3837 permissions to read the contents of directories throughout the file 3838 system. Depending on the operating environment and other activities 3839 undertaken by a SWIMA-PC (or software that incorporates a SWIMA-PC as 3840 one of its capabilities) additional permissions might be required by 3841 the SWIMA-PC software. The SWIMA-PC SHOULD NOT be granted 3842 permissions beyond what it needs in order to fulfill its duties. 3844 7.5. Sanitization of Record Fields 3846 Not all sources of software inventory evidence are necessarily 3847 tightly controlled. For example, consider a source that gathers 3848 .swid files from the endpoint's file system. Any party could create 3849 a new .swid file that could be collected and turned into a Software 3850 Inventory Evidence Record. As a result, it is important that the 3851 contents of source information not be automatically trusted. In 3852 particular, tools that read source information and the Software 3853 Inventory Evidence Records derived therefrom, including SWIMA-PCs, 3854 need to be careful to sanitize input to prevent buffer overflow 3855 attacks, encoding attacks, and other weaknesses that might be 3856 exploited by an adversary who can control the contents of a record. 3858 7.6. PA-TNC Security Threats 3860 In addition to the aforementioned considerations the Software 3861 Inventory Message and Attributes for PA-TNC protocol is subject to 3862 the same security threats as other PA-TNC transactions, as noted in 3863 Section 5.2 of PA-TNC [RFC5792]. These include, but are not limited 3864 to, attribute theft, message fabrication, attribute modification, 3865 attribute replay, attribute insertion, and denial of service. 3866 Implementers are advised to consult the PA-TNC specification to 3867 better understand these security issues. 3869 8. Privacy Considerations 3871 As noted in Section 7.2, if an adversary can gain an understanding of 3872 the software installed on an endpoint, they can utilize this to 3873 launch attacks and maintain footholds on this endpoint. For this 3874 reason, the NEA Server needs to ensure adequate safeguards are in 3875 place to prevent exposure of collected inventory records. For 3876 similar reasons, it is advisable that an endpoint only send records 3877 to a NEA Server that is authorized to receive this information and 3878 that can be trusted to safeguard this information after collection. 3880 9. Relationship to Other Specifications 3882 This specification makes frequent reference to and use of other 3883 specifications. This section describes these relationships. 3885 This specification is expected to participate in a standard NEA 3886 architecture. As such, it is expected to be used in conjunction with 3887 the other protocols used in a NEA exchange. In particular, SWIMA 3888 Attributes are conveyed over PB-TNC [RFC5793], which is in turn 3889 conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP 3890 [RFC7171]). These protocols have an especially important role, as 3891 they are responsible for ensuring that attributes defined under this 3892 specification are delivered reliably, securely, and to the 3893 appropriate party. 3895 It is important to note that the Product Information, Numeric 3896 Version, and String Version attributes defined in the PA-TNC 3897 specification [RFC5792] are also meant to convey information about 3898 installed applications and the versions thereof. As such, there is 3899 some conceptual overlap between those attributes and the intent of 3900 this specification. However, PA-TNC was designed to respond to very 3901 specific queries about specific classes of products, while the 3902 Software Inventory Message and Attributes for PA-TNC specification is 3903 able to convey a broader query, resulting in a more comprehensive set 3904 of evidence regarding an endpoint's installed software. As such, 3905 this specification provides important capabilities not present in the 3906 PA-TNC specification. 3908 10. IANA Considerations 3910 This section extends multiple existing IANA registries. 3911 Specifically, it extends the PA-TNC Attribute Types and PA-TNC Error 3912 Codes defined in the PA-TNC specification [RFC5792] and the PA- 3913 Subtypes registry defined in the PB-TNC specification [RFC5793] and 3914 extended in PA-TNC. This specification only adds values to these 3915 registries and does not alter how these registries work or are 3916 maintained. Consult the appropriate specifications for details on 3917 the operations and maintenance of these registries. 3919 10.1. PA Subtypes 3921 The following is an extension to the PA Subtype registry [1] defined 3922 in section 7.2 of the PA-TNC specification [RFC5792]. 3924 +-----+---------+-------------+-------------------------------------+ 3925 | PEN | Integer | Name | Defining Specification | 3926 +-----+---------+-------------+-------------------------------------+ 3927 | 0 | 9 | SWIMA | Software Inventory Message and | 3928 | | | Attributes | Attributes for PA-TNC | 3929 +-----+---------+-------------+-------------------------------------+ 3931 10.2. Registry for PA-TNC Attribute Types 3933 Section 5.4 of this specification defines several new PA-TNC 3934 attributes. The following values are added to the registry for PA- 3935 TNC Attribute Types defined in the PA-TNC specification. Note that 3936 Table 1 in Section 5.4 lists these attributes but uses a hexadecimal 3937 value to identify their associated integer. The integer values given 3938 in that table are identical to those provided here. Note also that 3939 Table 1 includes an entry for PA-TNC Error attributes, but the IANA 3940 information associated with that attribute is already defined in the 3941 PA-TNC specification and is not reproduced here. 3943 +-----+---------+-------------------+-------------------------------+ 3944 | PEN | Integer | Name | Defining Specification | 3945 +-----+---------+-------------------+-------------------------------+ 3946 | 0 | 17 | SWIMA Request | Software Inventory Message | 3947 | | | | and Attributes for PA-TNC | 3948 | | | | | 3949 | 0 | 18 | Software | Software Inventory Message | 3950 | | | Identifier | and Attributes for PA-TNC | 3951 | | | Inventory | | 3952 | | | | | 3953 | 0 | 19 | Software | Software Inventory Message | 3954 | | | Identifier Events | and Attributes for PA-TNC | 3955 | | | | | 3956 | 0 | 20 | Software | Software Inventory Message | 3957 | | | Inventory | and Attributes for PA-TNC | 3958 | | | | | 3959 | 0 | 21 | Software Events | Software Inventory Message | 3960 | | | | and Attributes for PA-TNC | 3961 | | | | | 3962 | 0 | 22 | Subscription | Software Inventory Message | 3963 | | | Status Request | and Attributes for PA-TNC | 3964 | | | | | 3965 | 0 | 23 | Subscription | Software Inventory Message | 3966 | | | Status Response | and Attributes for PA-TNC | 3967 | | | | | 3968 | 0 | 24 | Source Metadata | Software Inventory Message | 3969 | | | Request | and Attributes for PA-TNC | 3970 | | | | | 3971 | 0 | 25 | Source Metadata | Software Inventory Message | 3972 | | | Response | and Attributes for PA-TNC | 3973 | | | | | 3974 | 0 | 26 - 31 | Reserved for | Software Inventory Message | 3975 | | | future use | and Attributes for PA-TNC | 3976 +-----+---------+-------------------+-------------------------------+ 3978 10.3. Registry for PA-TNC Error Codes 3980 Section 5.16 of this specification defines several new PA-TNC Error 3981 Codes. The following values are added to the registry for PA-TNC 3982 Error Codes defined in the PA-TNC specification. Note that Table 8 3983 in Section 5.16 lists these codes but uses a hexadecimal value to 3984 identify their associated integer. The integer values given in that 3985 table are identical to those provided here. 3987 +----+--------+-------------------------------------+---------------+ 3988 | PE | Intege | Name | Defining | 3989 | N | r | | Specification | 3990 +----+--------+-------------------------------------+---------------+ 3991 | 0 | 32 | SWIMA_ERROR | Software | 3992 | | | | Inventory | 3993 | | | | Message and | 3994 | | | | Attributes | 3995 | | | | for PA-TNC | 3996 | | | | | 3997 | 0 | 33 | SWIMA_SUBSCRIPTION_DENIED_ERROR | Software | 3998 | | | | Inventory | 3999 | | | | Message and | 4000 | | | | Attributes | 4001 | | | | for PA-TNC | 4002 | | | | | 4003 | 0 | 34 | SWIMA_RESPONSE_TOO_LARGE_ERROR | Software | 4004 | | | | Inventory | 4005 | | | | Message and | 4006 | | | | Attributes | 4007 | | | | for PA-TNC | 4008 | | | | | 4009 | 0 | 35 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERRO | Software | 4010 | | | R | Inventory | 4011 | | | | Message and | 4012 | | | | Attributes | 4013 | | | | for PA-TNC | 4014 | | | | | 4015 | 0 | 36 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR | Software | 4016 | | | | Inventory | 4017 | | | | Message and | 4018 | | | | Attributes | 4019 | | | | for PA-TNC | 4020 | | | | | 4021 | 0 | 37-47 | Reserved for future use | Software | 4022 | | | | Inventory | 4023 | | | | Message and | 4024 | | | | Attributes | 4025 | | | | for PA-TNC | 4026 +----+--------+-------------------------------------+---------------+ 4028 10.4. Registry for Software Data Models 4030 The name for this registry is "Software Data Model Types". Each 4031 entry in this registry should include a human readable name, an SMI 4032 Private Enterprise Number, a decimal integer value between 1 and 4033 2^8-1 (inclusive), and a reference to the specification where the use 4034 of this data model is defined. This specification needs to provide 4035 both a description of the format used by the data model and the 4036 procedures by which Software Identifiers are derived from a record 4037 expressed using this data model. Note that a specification that just 4038 defines the data model structure and its use is generally not 4039 sufficient as it would likely lack the procedures for constructing a 4040 Software Identifier. This is why the table below references the 4041 current specification for ISO SWID tags, rather than using the actual 4042 ISO SWID tag specification. 4044 The following entries for this registry are defined in this document. 4045 They are the initial entries in the registry for Software Data Model 4046 Types. Additional entries to this registry are added by Expert 4047 Review with Specification Required, following the guidelines in 4048 [RFC5226]. 4050 +-----+---------+----------------------------+----------------------+ 4051 | PEN | Integer | Name | Defining | 4052 | | | | Specification | 4053 +-----+---------+----------------------------+----------------------+ 4054 | 0 | 1 | ISO 2015 SWID Tags using | **CURRENT | 4055 | | | XML | SPECIFICATION** | 4056 | | | | | 4057 | 0 | 2 | ISO 2009 SWID Tags using | **CURRENT | 4058 | | | XML | SPECIFICATION** | 4059 | | | | | 4060 | 0 | 192-255 | Reserved for local | N/A | 4061 | | | enterprise use | | 4062 +-----+---------+----------------------------+----------------------+ 4064 11. References 4066 11.1. Normative References 4068 [NIST8060] 4069 Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, 4070 "Guidelines for the Creation of Interoperable Software 4071 Identification (SWID) Tags", April 2016. 4073 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4074 Requirement Levels", BCP 14, RFC 2119, 4075 DOI 10.17487/RFC2119, March 1997, 4076 . 4078 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 4079 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 4080 . 4082 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4083 Resource Identifier (URI): Generic Syntax", STD 66, 4084 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4085 . 4087 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 4088 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 4089 . 4091 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 4092 Tardo, "Network Endpoint Assessment (NEA): Overview and 4093 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 4094 . 4096 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4097 IANA Considerations Section in RFCs", RFC 5226, 4098 DOI 10.17487/RFC5226, May 2008, 4099 . 4101 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 4102 (PA) Protocol Compatible with Trusted Network Connect 4103 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 4104 . 4106 [SWID09] The International Organization for Standardization/ 4107 International Electrotechnical Commission, "Information 4108 Technology - Software Asset Management - Part 2: Software 4109 Identification Tag, ISO/IEC 19770-2", November 2009. 4111 [SWID15] The International Organization for Standardization/ 4112 International Electrotechnical Commission, "Information 4113 Technology - Software Asset Management - Part 2: Software 4114 Identification Tag, ISO/IEC 19770-2", October 2015. 4116 11.2. Informative References 4118 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 4119 A Posture Broker (PB) Protocol Compatible with Trusted 4120 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 4121 March 2010, . 4123 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 4124 Transport Protocol over TLS (PT-TLS)", RFC 6876, 4125 DOI 10.17487/RFC6876, February 2013, 4126 . 4128 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 4129 (PT) Protocol for Extensible Authentication Protocol (EAP) 4130 Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, 4131 . 4133 11.3. URIs 4135 [1] https://www.iana.org/assignments/pb-tnc-parameters/pb-tnc- 4136 parameters.xhtml#pb-tnc-parameters-2 4138 Authors' Addresses 4140 Charles Schmidt 4141 The MITRE Corporation 4142 202 Burlington Road 4143 Bedford, MA 01730 4144 USA 4146 Email: cmschmidt@mitre.org 4148 Daniel Haynes 4149 The MITRE Corporation 4150 202 Burlington Road 4151 Bedford, MA 01730 4152 USA 4154 Email: dhaynes@mitre.org 4156 Chris Coffin 4157 The MITRE Corporation 4158 202 Burlington Road 4159 Bedford, MA 01730 4160 USA 4162 Email: ccoffin@mitre.org 4163 David Waltermire 4164 National Institute of Standards and Technology 4165 100 Bureau Drive 4166 Gaithersburg, Maryland 4167 USA 4169 Email: david.waltermire@nist.gov 4171 Jessica Fitzgerald-McKay 4172 Department of Defense 4173 9800 Savage Road 4174 Ft. Meade, Maryland 4175 USA 4177 Email: jmfitz2@nsa.gov