idnits 2.17.1 draft-coffin-sacm-nea-swid-patnc-03.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 (October 31, 2016) is 2705 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 2845 == Unused Reference: 'NIST-SWID' is defined on line 3777, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5209 -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM C. Coffin 3 Internet-Draft D. Haynes 4 Intended status: Standards Track C. Schmidt 5 Expires: May 4, 2017 The MITRE Corporation 6 J. Fitzgerald-McKay 7 Department of Defense 8 October 31, 2016 10 Software Inventory Message and Attributes (SWIMA) for PA-TNC 11 draft-coffin-sacm-nea-swid-patnc-03 13 Abstract 15 This document specifies the Software Inventory Message and Attributes 16 for PA-TNC. It extends the PA-TNC specification [RFC5792] by 17 providing specific attributes and message exchanges to allow 18 endpoints to report their installed software inventory information to 19 a NEA server (as described in [RFC5209]). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 4, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Network Endpoint Assessment (NEA) . . . . . . . . . . . . 5 57 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 58 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 8 61 2.1.1. Use Software Inventory as a Factor in Determining 62 Endpoint Access . . . . . . . . . . . . . . . . . . . 8 63 2.1.2. Maintain a Central Repository Reflecting an 64 Endpoint's Software Inventory . . . . . . . . . . . . 9 65 2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10 66 2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 10 67 2.3. Specification Requirements . . . . . . . . . . . . . . . 11 68 2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 12 69 2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12 70 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 13 71 2.7. Software Inventory Message and Attributes for PA-TNC 72 Diagram Conventions . . . . . . . . . . . . . . . . . . . 13 73 3. Software Inventory Message and Attributes for PA-TNC System 74 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14 75 3.1. Basic Attribute Exchange . . . . . . . . . . . . . . . . 14 76 3.2. Core Software Reporting Information . . . . . . . . . . . 15 77 3.2.1. Software Identifiers . . . . . . . . . . . . . . . . 15 78 3.2.1.1. Record Identifiers . . . . . . . . . . . . . . . 16 79 3.2.1.2. Software Locators . . . . . . . . . . . . . . . . 17 80 3.2.1.3. Using Software and Record Identifiers in SW 81 Attributes . . . . . . . . . . . . . . . . . . . 18 82 3.3. Targeted Requests . . . . . . . . . . . . . . . . . . . . 18 83 3.4. Monitoring Changes in an Endpoint's Software Inventory 84 Evidence Collection . . . . . . . . . . . . . . . . . . . 19 85 3.5. Reporting Change Events . . . . . . . . . . . . . . . . . 22 86 3.5.1. Event Identifiers . . . . . . . . . . . . . . . . . . 22 87 3.5.2. Core Event Tracking Information . . . . . . . . . . . 23 88 3.5.3. Updating Inventory Knowledge Based on Events . . . . 24 89 3.5.4. Using Event Records in SW Attributes . . . . . . . . 24 90 3.5.5. Partial and Complete Lists of Event Records in SW 91 Attributes . . . . . . . . . . . . . . . . . . . . . 25 92 3.5.6. Synchronizing Event Identifiers and Epochs . . . . . 27 93 3.6. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 28 94 3.6.1. Establishing Subscriptions . . . . . . . . . . . . . 29 95 3.6.2. Managing Subscriptions . . . . . . . . . . . . . . . 29 96 3.6.3. Terminating Subscriptions . . . . . . . . . . . . . . 30 97 3.6.4. Subscription Status . . . . . . . . . . . . . . . . . 30 98 3.6.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 31 99 3.6.5.1. Subscriptions Reporting Inventories . . . . . . . 32 100 3.6.5.2. Subscriptions Reporting Events . . . . . . . . . 32 101 3.6.5.3. Targeted Subscriptions . . . . . . . . . . . . . 34 102 3.6.5.4. No Subscription Consolidation . . . . . . . . . . 34 103 3.6.5.5. Delayed Subscription Fulfillment . . . . . . . . 35 104 3.7. Multiple Sources of Software Inventory Evidence Records . 35 105 3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 37 106 4. Software Inventory Message and Attributes for PA-TNC Protocol 38 107 4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 38 108 4.2. SW Attribute Overview . . . . . . . . . . . . . . . . . . 39 109 4.3. SW Attribute Exchanges . . . . . . . . . . . . . . . . . 41 110 4.4. Software Inventory Message and Attributes for PA-TNC 111 Attribute Enumeration . . . . . . . . . . . . . . . . . . 43 112 4.5. Normalization of Text Encoding . . . . . . . . . . . . . 44 113 4.6. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 44 114 4.7. SW Request . . . . . . . . . . . . . . . . . . . . . . . 45 115 4.8. Software Identifier Inventory . . . . . . . . . . . . . . 49 116 4.9. Software Identifier Events . . . . . . . . . . . . . . . 52 117 4.10. Software Inventory . . . . . . . . . . . . . . . . . . . 57 118 4.11. Software Events . . . . . . . . . . . . . . . . . . . . . 60 119 4.12. Subscription Status Request . . . . . . . . . . . . . . . 64 120 4.13. Subscription Status Response . . . . . . . . . . . . . . 65 121 4.14. PA-TNC Error as Used by Software Inventory Message and 122 Attributes for PA-TNC . . . . . . . . . . . . . . . . . . 67 123 4.14.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and 124 SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 69 125 4.14.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 70 126 4.14.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 72 127 5. Supported Data Models . . . . . . . . . . . . . . . . . . . . 74 128 5.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 74 129 5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID 130 Tags using XML . . . . . . . . . . . . . . . . . . . 74 131 5.1.2. Guidance on Creation of Software Identifiers from ISO 132 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 75 133 5.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 75 134 5.2.1. Guidance on Normalizing Source Data to ISO 2015 SWID 135 Tags using XML . . . . . . . . . . . . . . . . . . . 75 136 5.2.2. Guidance on Creation of Software Identifiers from ISO 137 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 75 138 6. Security Considerations . . . . . . . . . . . . . . . . . . . 76 139 6.1. Evidentiary Value of Software Inventory Evidence Records 76 140 6.2. Sensitivity of Collected Records . . . . . . . . . . . . 76 141 6.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 78 142 6.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 78 143 6.5. Sanitization of Record Fields . . . . . . . . . . . . . . 79 144 6.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 79 146 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 79 147 8. Relationship to Other Specifications . . . . . . . . . . . . 79 148 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 149 9.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 80 150 9.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 81 151 9.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 82 152 9.4. Registry for Software Data Models . . . . . . . . . . . . 83 153 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 154 10.1. Normative References . . . . . . . . . . . . . . . . . . 83 155 10.2. Informative References . . . . . . . . . . . . . . . . . 84 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84 158 1. Introduction 160 Possession of a list of an endpoint's installed software is very 161 useful in understanding and maintaining the security state of an 162 enterprise. For example, if an enterprise policy requires the 163 presence of certain pieces of software and/or prohibits the presence 164 of other software, reported software installation inventory lists can 165 be used to indicate compliance or non-compliance with these 166 requirements. Software installation inventories and the patch level 167 of the identified software can be compared to vulnerability or threat 168 alerts to determine an endpoint's exposure to attack. All of these 169 uses make an understanding of an endpoint's installed software 170 inventory highly useful to NEA Servers and other enterprise security 171 applications. 173 There is a need for a standardized method for exchanging software 174 inventory that carries a software identifier (a unique identifier 175 associated with a specific software product and version thereof). In 176 some cases, it may also be necessary to convey information that 177 characterizes this product (i.e., provides metadata about the product 178 beyond its identifier) as well as observable installation 179 information. These "Messages and Attributes" would enable software 180 identification, installation, and characterization information to be 181 provided for any software installed on any endpoint that supports 182 this specification. 184 To that end, this specification defines a new set of PA-TNC 185 attributes, carried over PA-TNC messages, which are used to 186 communicate requests for software information and software events, 187 and for conveying that information back to a NEA Server. 189 This specification is designed only to report software that is 190 installed on an endpoint. In particular, it does not monitor or 191 report information about what software is running on the endpoint. 192 Likewise, it is not intended to report individual files, libraries, 193 installation packages, or similar artifacts. While all of this 194 information has its uses, this information requires different 195 metadata and different methods of monitoring the endpoint. As a 196 result, this specification focuses solely on installed software, 197 leaving reporting of other classes of endpoint information to other 198 specifications. 200 1.1. Network Endpoint Assessment (NEA) 202 The Network Endpoint Assessment (NEA) Working Group defines an open 203 solution architecture that enables network operators to collect and 204 utilize information about endpoint configuration and state. This 205 information can be used to enforce policies, monitor endpoint health, 206 and for many other activities. Information about the software 207 present on an endpoint is an important consideration for such 208 activities. Such information can come from multiple sources, 209 including tag files (such as ISO SWID tags [SWID], reports from third 210 party inventory tools, output from package managers, and other 211 sources. The attributes defined in this document are used to 212 communicate software inventory evidence, collected from a range of 213 possible sources, from the posture collector on the endpoint to the 214 posture validator on a NEA Server using the PA-TNC interface, as 215 shown in Figure 1 below. 217 +-------------+ +--------------+ 218 | Posture | <--------PA--------> | Posture | 219 | Collectors | | Validators | 220 | (1 .. N) | | (1 .. N) | 221 +-------------+ +--------------+ 222 | | 223 | | 224 | | 225 +-------------+ +--------------+ 226 | Posture | | Posture | 227 | Broker | <--------PB--------> | Broker | 228 | Client | | Server | 229 +-------------+ +--------------+ 230 | | 231 | | 232 +-------------+ +--------------+ 233 | Posture | | Posture | 234 | Transport | <--------PT--------> | Transport | 235 | Client | | Server | 236 | (1 .. N) | | (1 .. N) | 237 +-------------+ +--------------+ 238 NEA CLIENT NEA SERVER 240 Figure 1: NEA Reference Model 242 Before reading this specification any further, the reader should 243 review and understand the NEA reference architecture as described in 244 the Network Endpoint Assessment (NEA): Overview and Requirements 245 [RFC5209]. The reader should also understand the capabilities and 246 requirements common to PA-TNC interfaces as defined in RFC 5792 247 [RFC5792]. 249 This document is based on standards published by the Trusted 250 Computing Group's Trusted Network Communications (TNC) workgroup. 251 The TNC and NEA architectures are interoperable and the following 252 components are equivalent: 254 +---------------------------------------+-----------------------+ 255 | TNC Component | NEA Component | 256 +---------------------------------------+-----------------------+ 257 | Integrity Measurement Verifier (IMV) | Posture Validator | 258 | | | 259 | Integrity Measurement Collector (IMC) | Posture Collector | 260 | | | 261 | TNC Server (TNCS) | Posture Broker Server | 262 | | | 263 | TNC Client (TNCC) | Posture Broker Client | 264 +---------------------------------------+-----------------------+ 266 Table 1: Equivalent components in TNC and NEA architectures 268 1.2. Keywords 270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 272 specification are to be interpreted as described in RFC 2119 273 [RFC2119]. This specification does not distinguish blocks of 274 informative comments and normative requirements. Therefore, for the 275 sake of clarity, note that lower case instances of must, should, etc. 276 do not indicate normative requirements. 278 1.3. Definitions 280 This section defines terms with special meaning within this document. 282 SW-PC - A Posture Collector (PC) that conforms to this specification. 283 Note that such a posture collector might also support other PA-TNC 284 exchanges beyond Software Inventory Message and Attributes for PA- 285 TNC. 287 SW-PV - A Posture Validator (PV) that conforms to this specification. 288 Note that such a posture verifier might also support other PA-TNC 289 exchanges beyond Software Inventory Message and Attributes for PA- 290 TNC. 292 SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792 293 [RFC5792] extension for conveying software inventory information. 294 This specification defines several new attribute types. 296 Endpoint's Software Inventory Evidence Collection - The set of 297 information regarding the set of software installed on an endpoint. 298 An endpoint's software inventory evidence collection might include 299 information created by or derived from multiple sources, including 300 but not limited to SWID tag files deposited on the file system during 301 software installation, information generated to report output from 302 software discovery tools, and information dynamically generated by a 303 software or package management system on an endpoint. 305 Software Inventory Evidence Record - The endpoint's Software 306 Inventory Evidence Collection is composed of "records". Each record 307 corresponds to one installed instance of a particular software 308 product as reported by some data source. It is possible for a single 309 installed instance to have multiple software inventory evidence 310 records in an endpoint's Software Inventory Evidence Collection - 311 this can happen if multiple sources all report the same software 312 installation instance. 314 Software Identifier - A string associated with a specific version of 315 a specific software product. Each supported Software Inventory 316 Message and Attributes for PA-TNC data model has its own rules for 317 how a Software Identifier (see Section 3.2.1) is derived from the 318 representation of the given software product using that data model, 319 and different sources for this information might populate relevant 320 information differently. As such, while each Software Identifier 321 uniquely identifies a specific software product, the same software 322 product might be associated with multiple Software Identifiers 323 reflecting differences between different information sources and 324 supported data models. 326 2. Background 328 2.1. Supported Use Cases 330 This section describes the Software Inventory Message and Attributes 331 for PA-TNC use cases supported by this specification. The primary 332 use of exchanging software inventory information over the PA-TNC 333 interface is to enable a challenger (e.g. NEA Server) to obtain 334 inventory evidence about some system in a way that conforms to NEA 335 procedures and expressed using a standard format. Collected software 336 information can support a range of security activities including 337 determining whether an endpoint is permitted to connect to the 338 enterprise, determining which endpoints contain software that 339 requires patching, and similar activities. 341 2.1.1. Use Software Inventory as a Factor in Determining Endpoint 342 Access 344 Some enterprises might define security policies that require 345 connected endpoints to have certain pieces of security software 346 installed. By contrast, some security policies might prevent access 347 by endpoints that have certain prohibited pieces of software 348 installed, such as applications that pose known security risks. To 349 support such policies, the NEA Server needs to collect evidence 350 indicating the software inventory of an endpoint that is seeking to 351 initiate or continue connectivity to the enterprise. 353 Software Inventory Message and Attributes for PA-TNC facilitates 354 policy decisions that consider an endpoint's software inventory by 355 providing the NEA Server with software inventory information from the 356 endpoint. The SW-PC can provide a complete or partial inventory to 357 the SW-PV as required to determine policy compliance. The SW-PV can 358 then use this as evidence of compliance or non-compliance with 359 enterprise policy. 361 2.1.2. Maintain a Central Repository Reflecting an Endpoint's Software 362 Inventory 364 Many tools can use information about an endpoint's software inventory 365 to monitor and enforce the security of an enterprise. For example, a 366 software patching service can use an endpoint's software inventory to 367 determine whether certain endpoints have software that requires 368 patching. A vulnerability management tool might identify endpoints 369 with known vulnerabilities (patched or otherwise) and use this to 370 gauge enterprise exposure to attack. A license management tool might 371 verify that all copies of a particular piece of software are 372 accounted for within the enterprise. The presence of a central 373 repository representing a real-time understanding of each endpoint's 374 software inventory facilitates all such activities. Using a central 375 repository that can ensure the freshness of its collected information 376 is generally more efficient than having each tool collect the same 377 inventory information from each endpoint individually and leads to a 378 more consistent understanding of enterprise state. 380 Software Inventory Message and Attributes for PA-TNC supports this 381 activity through a number of mechanisms. As noted above, it allows a 382 SW-PC to provide a complete list of software present in an endpoint's 383 Software Inventory Evidence Collection to the SW-PV, which can then 384 pass this information on to a central repository such as a 385 Configuration Management Database (CMDB) or similar application. In 386 addition, SW-PCs are required to be able to monitor for changes to an 387 endpoint's Software Inventory Evidence Collection in near real-time 388 and push reports of changes to the SW-PV as soon as those changes are 389 detected. Thus any central repository fed by a SW-PV receiving such 390 information can be updated soon after the change occurs. Keeping 391 such a central repository synchronized with the state of each 392 endpoint's Software Inventory Evidence Collection allows tools that 393 use this information for their own security activities to make 394 decisions in a consistent, efficient manner. 396 2.1.3. PA-TNC Use Cases 398 Software Inventory Message and Attributes for PA-TNC are intended to 399 operate over the PA-TNC interface and, as such, are intended to meet 400 the use cases set out in the PA-TNC specification. 402 2.2. Non-supported Use Cases 404 Some use cases not covered by this version of Software Inventory 405 Message and Attributes for PA-TNC include: 407 o This specification does not address how the endpoint's Software 408 Inventory Evidence Collection is populated. In particular, NEA 409 components are not expected to perform software discovery 410 activities beyond compiling information in an endpoint's Software 411 Inventory Evidence Collection. This collection might potentially 412 come from multiple sources on the endpoint (e.g., information 413 generated dynamically by package management tools or discovery 414 tools, as well as SWID tag files discovered on the file system). 415 While an enterprise might make use of software discovery 416 procedures to identify installed software such procedures are 417 outside the scope of this specification. 419 o This specification does not address converting inventory 420 information expressed in a proprietary format into formats used in 421 the attributes described in this specification. Instead, it 422 focuses exclusively on defining interfaces for the transportation 423 of software information in the expectation that this is the format 424 around which reporting tools will converge. 426 o This specification provides no mechanisms for a posture validator 427 to request a specific list of software information based on 428 arbitrary software properties. For example, requesting only 429 information about software from a particular vendor is not 430 supported. After the endpoint's software inventory evidence 431 collection has been copied to some central location, such as the 432 CMDB, processes there can perform queries based on any criteria 433 present in the collected information, but this specification does 434 not address using such queries to constrain the initial collection 435 of this information from the endpoint. 437 o This specification does not address utilization of properties of 438 certain sources of software information that might facilitate 439 local tests (i.e., on the endpoint) of endpoint state. For 440 example, the optional package_footprint field of an ISO SWID tag 441 can contain a list of files and hash values associated with the 442 software indicated by the tag. Tools on the endpoint can use the 443 values in this field to test for the presence of the indicated 444 files. Successful evaluation of such tests leads to greater 445 assurance that the indicated software is present on the endpoint. 446 Currently, most SWID tag creators do not provide values for tag 447 fields that support local testing. For this reason, the added 448 complexity of supporting endpoint testing using these fields is 449 out of scope for this specification. Future versions of this 450 specification might add support for such testing. 452 2.3. Specification Requirements 454 Below are the requirements that the Software Inventory Message and 455 Attributes for PA-TNC specification is required to meet in order to 456 successfully play its role in the NEA architecture. 458 o Efficient 460 The NEA architecture enables delay of network access until the 461 endpoint is determined not to pose a security threat to the network 462 based on its asserted integrity information. To minimize user 463 frustration, the Software Inventory Message and Attributes for PA-TNC 464 ought to minimize overhead delays and make PA-TNC communications as 465 rapid and efficient as possible. 467 Efficiency is also important when one considers that some network 468 endpoints are small and low powered, some networks are low bandwidth 469 and/or high latency, and some transport protocols (such as PT-EAP, 470 Posture Transport (PT) Protocol for Extensible Authentication 471 Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier 472 protocol might allow only one packet in flight at a time or only one 473 roundtrip. However, when the underlying PT protocol imposes fewer 474 constraints on communications, this protocol ought to be capable of 475 taking advantage of more robust communication channels (e.g. using 476 larger messages or multiple roundtrips). 478 o Scalable 480 Software Inventory Message and Attributes for PA-TNC needs to be 481 usable in enterprises that contain tens of thousands of endpoints or 482 more. As such, it needs to allow a security tools to make decisions 483 based on up-to-date information about an endpoint's software 484 inventory without creating an excessive burden on the enterprise's 485 network. 487 o Interoperable 489 This specification defines the protocol for how PCs and PVs can 490 exchange and use software information to provide a NEA Server with 491 information about an endpoint's software inventory. Therefore a key 492 goal for this specification is ensuring that all SW PCs and PVs, 493 regardless of the vendor who created them, are able to interoperate 494 in their performance of these duties. 496 o Support precise and complete historical reporting 498 This specification outlines capabilities that support real-time 499 understanding of the state of endpoint in a network in a way that can 500 be used by other tools. One means of facilitating such an outcome is 501 for a Configuration Management Database (CMDB) to be able to contain 502 information about all endpoints connected to the enterprise for all 503 points in time between the endpoint's first connection and the 504 present. In such a scenario, it is necessary that any PC be able to 505 report any changes to its software inventory evidence collection in 506 near real-time while connected and, upon reconnection to the 507 enterprise, be able to update the NEA Server (and through it the 508 CMDB) with regard to the state of its software inventory evidence 509 collection throughout the entire interval when it was not connected. 511 2.4. Non-Requirements 513 There are certain requirements that the Software Inventory Message 514 and Attributes for PA-TNC specification explicitly is not required to 515 meet. This list is not exhaustive. 517 o End to End Confidentiality 519 This specification does not define mechanism for confidentiality, nor 520 is this property automatically provided by PA-TNC interface use. 521 Confidentiality is generally provided by the underlying transport 522 protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP Posture 523 Transport for Tunneled EAP Methods [RFC7171] - see Section 8 for more 524 information on related standards. Should users wish confidentiality 525 protection of assessment instructions or results, this needs to be 526 provided by parts of the NEA architecture other than this 527 specification. 529 2.5. Assumptions 531 Here are the assumptions that Software Inventory Message and 532 Attributes for PA-TNC makes about other components in the NEA 533 architecture. 535 o Reliable Message Delivery 537 The Posture Broker Client and Posture Broker Server are assumed to 538 provide reliable delivery for PA-TNC messages and therefore the 539 Attributes sent between the SW PCs and the PVs. In the event that 540 reliable delivery cannot be provided, the Posture Collector or 541 Posture Validator is expected to terminate the connection. 543 2.6. Non-Assumptions 545 The Software Inventory Message and Attributes for PA-TNC 546 specification explicitly does not assume: 548 o Authenticity and Accuracy of the Software Inventory Evidence 549 Collection with Regard to Endpoint Inventory 551 This specification makes no assumption as to whether the software 552 information that it reports correctly reflect the software state on 553 the endpoint. This specification does not attempt to detect when the 554 endpoint is providing false information, either through malice or 555 error, but instead focuses on correctly and reliably providing the 556 reported Software Inventory Evidence Collection to the NEA Server. 557 Similarly, this specification makes no assumption with regard to the 558 completeness of the Software Inventory Evidence Collection's coverage 559 of the total set of software installed on the endpoint. It is 560 possible, and even likely, that some installed software is not 561 represented by a record in an endpoints Software Inventory Evidence 562 Collection. See Section 6 for more on this security consideration. 564 2.7. Software Inventory Message and Attributes for PA-TNC Diagram 565 Conventions 567 This specification defines the syntax of the Software Inventory 568 Message and Attributes for PA-TNC using diagrams. Each diagram 569 depicts the format and size of each field in bits. Implementations 570 MUST send the bits in each diagram as they are shown from left to 571 right for each 32-bit quantity traversing the diagram from top to 572 bottom. Multi-octet fields representing numeric values MUST be sent 573 in network (big endian) byte order. 575 Descriptions of bit fields (e.g. flags) values refer to the position 576 of the bit within the field. These bit positions are numbered from 577 the most significant bit through the least significant bit. As such, 578 an octet with only bit 0 set would have a value of 0x80 (1000 0000), 579 an octet with only bit 1 set would have a value of 0x40 (0100 0000), 580 and an octet with only bit 7 set would have a value of 0x01 (0000 581 0001). 583 3. Software Inventory Message and Attributes for PA-TNC System 584 Requirements 586 The Software Inventory Message and Attributes for PA-TNC 587 specification facilitates the exchange of software inventory and 588 event information. Specifically, each application supporting 589 Software Inventory Message and Attributes for PA-TNC includes a 590 component known as the SW-PC that receives messages sent with the SW 591 Attributes component type. The SW-PC is also responsible for sending 592 appropriate SW Attributes back to the SW-PV in response. This 593 section outlines what software inventories and events are and the 594 requirements on SW-PCs and SW-PVs in order to support the stated use 595 cases of this specification. 597 3.1. Basic Attribute Exchange 599 In the most basic exchange supported by this specification, a SW-PV 600 sends a request to the SW-PC requesting some type of information 601 about the endpoint's software inventory. This simple exchange is 602 shown in Figure 2. 604 +-------------+ +--------------+ 605 | SW-PC | | SW-PV | Time 606 +-------------+ +--------------+ | 607 | | | 608 |<--------------SW Request----------------| | 609 | | | 610 |---------------SW Response-------------->| | 611 | | V 613 Figure 2: Basic SW Attribute Exchange 615 Upon receiving such a SW Request from the SW-PV, the SW-PC is 616 expected to collect all the relevant software inventory information 617 from the endpoint's software evidence collection and place it within 618 its response attribute. 620 SW-PVs MUST discard without error any SW Response attributes that 621 they receive for which they do not know the SW Request parameters 622 that led to this SW Response. This is due to the fact that the SW 623 Request includes parameters that control the nature of the response 624 (as will be described in the following sections) and without knowing 625 those parameters the SW Response cannot be reliably interpreted. 626 Most often receiving an unsolicited SW Response attribute happens 627 when a NEA Server has multiple SW-PVs; one SW-PV sends a SW Request 628 but, unless exclusive delivery is used by the SW-PC in sending the 629 response, both SW-PVs receive copies of the resulting SW Response. 630 In this case, the SW-PV that didn't send the SW Request would lack 631 the context necessary to correctly interpret the SW Response it 632 received and would simply discard it. Note, however, that 633 proprietary measures might allow a SW-PV to discover the SW Request 634 parameters for a SW Response even if that SW-PV did not send the 635 given SW Request. As such, there is no blanket requirement for a SW- 636 PV to discard all SW Responses to SW Request the SW-PV did not 637 generate itself, only that SW-PVs are required to discard SW 638 Responses for which they cannot get the necessary context to 639 interpret. 641 In the case that it is possible to do so, the SW-PC SHOULD send its 642 SW Response attribute to the SW-PV that requested it using exclusive 643 delivery as described in section 4.5 of RFC 5793 (PB-TNC) [RFC5793]. 644 Exclusive delivery ensures that only the sender of the SW Request 645 receives the resulting SW Response. 647 3.2. Core Software Reporting Information 649 Different parameters in the SW Request can influence what information 650 is returned in the SW Response. However, while each SW Response 651 provides different additional information about this installed 652 software, they all share a common set of fields that support reliable 653 software identification on an endpoint. These fields include: 654 Software Identifiers, Record Identifiers, and Software Locators. 655 These three fields are present for each reported piece of software in 656 each type of SW Response. The following sections examine these three 657 types of information in more detail. 659 3.2.1. Software Identifiers 661 A Software Identifier uniquely identifies a specific version of a 662 specific software product. The Software Inventory Message and 663 Attributes for PA-TNC specification does not dictate the structure of 664 a Software Identifier (beyond stating that it is a string) or define 665 how it is created. Instead, each data model described in the 666 Software Data Model IANA table (Section 9.4) includes its own rules 667 for how a Software Identifier is created based on a record in the 668 Endpoint's Software Inventory Evidence Collection expressed in that 669 data model. Other data models will have their own procedures for the 670 creation of associated Software Identifiers. Within the Software 671 Inventory Message and Attributes for PA-TNC specification, the 672 Software Identifier is simply an opaque string and there is never any 673 need to unpack any information that might be part of that identifier. 675 A Software Identifier is a fraction of the size of the inventory 676 record from which it is derived. For some combinations of data 677 models and sources, the full record might never be necessary as the 678 identifier can be directly correlated to the contents of the full 679 record. This is possible with authoritative SWID tags, since these 680 tags always have the same contents and thus a Software Identifier 681 derived from these tags can be used as a lookup to a local copy of 682 the full tag. For other combinations of source and data model, a 683 server might not be able to determine the specific software product 684 and version associated with the identifier without requesting 685 delivery of the full record. However, even in those cases, 686 downstream consumers of this information might never need the full 687 record as long as the Software Identifiers they receive can be 688 tracked reliably. A SW-PV can use Software Identifiers to track the 689 presence of specific software products on an endpoint over time in a 690 bandwidth-efficient manner. 692 There are two important limitations of Software Identifiers to keep 693 in mind: 695 1. The identifiers do not necessarily change when the associated 696 record changes. In some situations, a record in the endpoint's 697 Software Inventory Evidence Collection will change due to new 698 information becoming available or in order to correct prior 699 errors in that information. Such changes might or might not 700 result in changes to the Software Identifier, depending on the 701 nature of the changes and the rules governing how Software 702 Identifiers are derived from records of the appropriate data 703 model. 705 2. It is possible that a single software product is installed on a 706 single endpoint multiple times. If both of these installation 707 instances are reported by the same source using the same data 708 format, then this can result in identical Software Identifiers 709 for each installation instances. In other words, Software 710 Identifiers might not uniquely identify installation instances; 711 they just are intended to uniquely identify software products 712 (which might have more than one installation instance). Instead, 713 to reliably distinguish between multiple instances of a single 714 software product, one needs to make use of Record Identifiers, 715 described in the following section. 717 3.2.1.1. Record Identifiers 719 A Record Identifier is a 4-byte integer generated by the SW-PC that 720 is uniquely associated with a specific record within the Endpoint's 721 Software Inventory Evidence Collection. The SW-PC MUST assign a 722 unique identifier to each record when it is added to the Endpoint's 723 Software Inventory Evidence Collection. The Record Identifier SHOULD 724 remain unchanged if that record is modified. The SWID-PC might wish 725 to assign Record Identifiers sequentially, but any scheme is 726 acceptable provided that no two records receive the same identifier. 728 Servers can use Record Identifiers to distinguish between multiple 729 instances of a single software product installed on an endpoint. 730 Since each installation instance of a software product is associated 731 with a separate record, servers can use the record identifier to 732 distinguish between instances. For example, if an event is reported 733 (as described in Section 3.5), the record identifier will allow the 734 server to discern which instance of a software product is involved. 736 3.2.1.2. Software Locators 738 In addition to the need to identify software products, many use cases 739 of inventory information need to know where software is located on 740 the endpoint. This information might be needed to direct remediation 741 actions or similar processes. For this reason, every reported 742 software product also includes a Software Locator to identify where 743 the software is installed on the endpoint. 745 If the location is not provided directly by the record source the SW- 746 PC is responsible for attempting to determine the location of the 747 software product. The "location" of a product SHOULD be the 748 directory in which the software products executables are kept. 749 However, if that directory is shared by other software products, the 750 "location" SHOULD be the location of the primary executable 751 associated with the software product. The source and/or SW-PC MUST 752 be consistent in reporting the location of a software product (i.e., 753 it cannot use the executable location in one report and the directory 754 location in another). 756 The location is expressed as a URI string consisting of a scheme and 757 path. [RFC3986] The location URI does not include an authority part. 758 The URI schema describes the context of the described location. For 759 example, in most cases the location of the installed software product 760 will be expressed in terms of its path in the filesystem. For such 761 locations, the location URI scheme MUST be "file". It is possible 762 that other schemes could be used to represent other location 763 contexts. Apart from reserving the "file" and "unknown" (described 764 below) scheme to indicate an installation location expressed using a 765 path in the endpoint's file system, this specification does not 766 reserve schemes. When representing software products in other 767 location contexts, tools MUST be consistent in their use of schemes, 768 but the exact string used in those schemes is not normatively defined 769 here. 771 It is possible, that a SW-PC is unable to determine the location of a 772 reported software product. In this case, the SW-PC MUST assign that 773 software product a location of "unknown:". (I.e., the "unknown" 774 scheme and an empty path.) However, SW-PCs SHOULD only make such an 775 assignment as a last resort. Even a probable location for a software 776 product is preferable to using the unknown indicator. 778 3.2.1.3. Using Software and Record Identifiers in SW Attributes 780 A SW Attribute reporting an endpoint's Software Inventory Evidence 781 Collection always contains the Software Identifiers associated with 782 the identified software products. A SW Attribute might or might not 783 also contain copies of software inventory evidence records. The 784 attribute exchange is identical to the diagram shown in Figure 2 785 regardless of whether software inventory evidence records are 786 included. The SW Request attribute indicates whether the response is 787 required to include software inventory evidence records. Excluding 788 software inventory evidence records can reduce the attribute size of 789 the response by multiple orders of magnitude when compared to sending 790 the same inventory with full records. 792 3.3. Targeted Requests 794 Sometimes a SW-PV does not require information about every piece of 795 software on an endpoint but only needs to receive updates about 796 certain software instances. For example, enterprise endpoints might 797 be required to have certain software products installed and to keep 798 these updated. Instead of requesting a complete inventory just to 799 see if these products are present, the SW-PV can make a "targeted 800 request" for the software in question. 802 Targeted requests follow the same attribute exchange described in 803 Figure 2. The SW-PV targets its request by providing one or more 804 Software Identifiers in its SW Request attribute. The SW-PC MUST 805 then limit its response to contain only records that match the 806 indicated Software Identifier(s). This allows the network exchange 807 to exclude information that is not relevant to a given policy 808 question, thus reducing unnecessary bandwidth consumption. The SW- 809 PC's response might or might not include software inventory evidence 810 records, depending on the parameters of the SW Request. 812 Note that targeted requests identify the software relevant to the 813 request only through Software Identifiers. This specification does 814 not support arbitrary, parameterized querying of records. For 815 example, one cannot request all records from a certain software 816 publisher, or all records created by a particular record source. 817 Targeted requests only allow a requestor to request specific software 818 (as identified by their Software Identifiers) and receive a response 819 that is limited to the named software. 821 There is no assumption that a SW-PC will recognize "synonymous 822 records" - that is, records from different sources for the same 823 software. Recall that different sources and data models may use 824 different Software Identifier strings for the same software product. 825 The SW-PC returns only records that match the Software Identifiers in 826 the SW Request, even if there might be other records in the 827 endpoint's Software Inventory Evidence Collection for the same 828 software product. This is necessary because SW-PCs might not have 829 the ability to determine that two Software Identifiers refer to the 830 same product. 832 Targeted requests do not include Record Identifiers or Software 833 Locators. The response to a targeted request MUST include all 834 records associated with the named Software Identifiers, including the 835 case where there are multiple records associated with a single 836 Software Identifier. 838 SW-PCs MUST accept targeted requests and process them correctly as 839 described above. SW-PVs MUST be capable of making targeted requests 840 and processing the responses thereto. 842 3.4. Monitoring Changes in an Endpoint's Software Inventory Evidence 843 Collection 845 The software collection on an endpoint is not static. As software is 846 installed, uninstalled, patched, or updated, the Software Inventory 847 Evidence Collection is expected to change to reflect the new software 848 state on the endpoint. Different record sources might update the 849 evidence collection at different rates. For example, a package 850 manager might update its records in the Software Inventory Evidence 851 Collection immediately whenever it is used to add or remove a 852 software product. By contrast, sources that perform periodic 853 examination of the endpoint would likely only update their records in 854 the Software Inventory Evidence Collection after each examination. 856 All SW-PCs MUST be able to be able to detect changes to the Software 857 Inventory Evidence Collection. Specifically, SW-PCs MUST be able to 858 detect: 860 o The creation of records 862 o The deletion of records 864 o The alteration of records 866 An "alteration" is anything that modifies the contents of a record 867 (or would modify it, if the record is dynamically generated on 868 demand) in any way, regardless of whether the change is functionally 869 meaningful. 871 SW-PCs MUST detect such changes to the endpoint's Software Inventory 872 Evidence Collection in close to real-time (i.e., within seconds) when 873 the Posture Collector is operating. In addition, in the case where 874 there is a period during which the SW-PC is not operating, the SW-PC 875 MUST be able to determine the net change to the endpoint's Software 876 Inventory Evidence Collection over the period it was not operational. 877 Specifically, the "net change" represents the difference between the 878 state of the endpoint's Software Inventory Evidence Collection when 879 the SW-PC was last operational and monitoring its state, and the 880 state of the endpoint's software inventory evidence collection when 881 the SW-PC resumed operation. Note that a net change might not 882 reflect the total number of change events over this interval. For 883 example, if a record was altered three times during a period when the 884 SW-PC was unable to monitor for changes, the net change of this 885 interval might only note that there was an alteration to the record, 886 but not how many individual alteration events occurred. It is 887 sufficient for a SW-PC's determination of a net change to note that 888 there was a difference between the earlier and current state rather 889 than enumerating all the individual events that allowed the current 890 state to be reached. 892 The SW-PC MUST assign a time to each detected change in the 893 endpoint's Software Inventory Evidence Collection. These timestamps 894 correspond to the SW-PC's best understanding as to when the detected 895 change occurred. These timestamps MUST be as accurate as possible. 896 For changes to the endpoint's Software Inventory Evidence Collection 897 that occur while the SW-PC is operating, the SW-PC ought to be able 898 to assign a time to the event that is accurate to within a few 899 seconds. For changes to the endpoint's Software Inventory Evidence 900 Collection that occur while the SW-PC is not operational, upon 901 becoming operational the SW-PC needs to make a best guess as to the 902 time of the relevant events (possibly by looking at timestamps on 903 files), but these values might be off. In the case of dynamically 904 generated records, the time of change is the time at which the data 905 from which the records are generate changes, not the time at which a 906 changed record is generated. For example, if records are dynamically 907 generated based on data in an RPM database, the time of change would 908 be when the RPM database changed. 910 With regard to deletions of records, the SW-PC needs to detect the 911 deletion and MUST retain a copy of the full deleted record along with 912 the associated Record Identifier and Software Locator so that the 913 record and associated information can be provided to the SW-PV upon 914 request. This copy of the record MUST be retained for a reasonable 915 amount of time. Vendors and administrators determine what 916 "reasonable" means, but a copy of the record SHOULD be retained for 917 as long as the event recording the deletion of the record remains in 918 the SW-PC's event log (as described in Section 3.5). This is 919 recommended because, as long as the event is in the SW-PC's change 920 logs, the SW-PC might send an event attribute (described in 921 Section 3.5) that references this record, and a copy of the record is 922 needed if the SW-PV wanted a full copy of the relevant records. 924 With regard to alterations to a record, SW-PCs MUST detect any 925 alterations to the contents of a record. Alterations need to be 926 detected even if they have no functional impact on the record. A 927 good guideline is that any alteration to a record that might change 928 the value of a hash taken on the record's contents needs to be 929 detected by the SW-PC. A SW-PC might be unable to distinguish 930 modifications to the content of a record from modifications to the 931 metadata the file system associates with the record. For example, a 932 SW-PC might use the "last modification" timestamp as an indication of 933 alteration to a given record, but a record's last modification time 934 can change for reasons other than modifications to the record 935 contents. A SW-PC is still considered compliant with this 936 specification if it also reports metadata change events that do not 937 change the record itself as alterations to the record. In other 938 words, while SW-PC authors are encouraged to exclude modifications 939 that do not affect the bytes within the record, discriminating 940 between modifications to file contents and changes to file metadata 941 can be difficult and time consuming on some systems. As such, as 942 long as the alterations detected by a SW-PC always cover all 943 modifications to the contents of record, the SW-PC is considered 944 compliant even if it also registers alterations that do not modify 945 the contents of a record as well. When recording an alteration to a 946 record, the SW-PC is only required to note that an alteration 947 occurred. The SW-PC is not required to note or record how the record 948 altered, nor is it possible to include such details in SW Attributes 949 reporting the change to a SW-PV. There is no need to retain a copy 950 of the original record. 952 When a record changes it SHOULD retain the same Record Identifier. 953 The Software Locator might or might not change, depending on whether 954 the software changed locations during the changes that led to the 955 record change. A record change MUST retain the same Software 956 Identifier. This means that any action that changes a software 957 product (e.g., application of a patch that results in a change to the 958 product's version) MUST NOT be reflected by a record change but 959 instead MUST result in the deletion of the old record and the 960 creation of a new record. This reflects the requirement that a 961 record in the endpoint's Software Inventory Evidence Collection 962 correspond directly with an instance of a specific software product. 964 3.5. Reporting Change Events 966 As noted in the preceding section, SW-PCs MUST be able to detect 967 changes to the endpoints Software Inventory Evidence Collection 968 (creation, deletion, and alteration) in near real-time while the SW- 969 PC is operational, and MUST be able to account for any net change to 970 the endpoint's Software Inventory Evidence Collection that occurs 971 when the SW-PC is not operational. However, to be of use to the 972 enterprise, the NEA Server needs to be able to receive these events 973 and be able to understand how new changes relate to earlier changes. 974 In Software Inventory Message and Attributes for PA-TNC, this is 975 facilitated by reporting change events. All SW-PCs MUST be capable 976 of receiving requests for change events and sending change event 977 attributes. All SW-PVs MUST be capable of requesting and receiving 978 change event attributes. 980 3.5.1. Event Identifiers 982 To be useful, change events need to be correctly ordered. Ordering 983 of events is facilitated by two pieces of information: an Event 984 Identifier (EID) value and an EID Epoch value. 986 An EID is a 4-byte unsigned integer that the SW-PC assigns 987 sequentially to each observed event (whether detected in real-time or 988 deduced by looking for net changes over a period of SW-PC 989 inactivity). All EIDs exist within the context of some "EID Epoch", 990 which is also represented as a 4-byte unsigned integer. EID Epochs 991 are used to ensure synchronization between the SW-PC and any SW-PVs 992 with which it communicates. EID Epoch values SHOULD be generated 993 randomly and in such a way that it is unlikely that the same EID 994 Epoch is generated twice, even if the SW-PC reverted to an earlier 995 state (e.g., resetting it to factory defaults). In the case where a 996 SW-PC needs to reset its EID counter, either because it has exhausted 997 all available EID values or because the SW-PC's event log becomes 998 corrupted, then a new EID Epoch MUST be selected. 1000 Within an Epoch, EIDs MUST be assigned sequentially, so that if a 1001 particular event is assigned an EID of N, the next observed event is 1002 given an EID of N+1. In some cases, events might occur 1003 simultaneously, or the SW-PC might not otherwise be able to determine 1004 an ordering for events. In these cases, the SW-PC creates an 1005 arbitrary ordering of the events and assigns EIDs according to this 1006 ordering. Two change events MUST NOT ever be assigned the same EID 1007 within the same EID Epoch. No meaningful comparison can be made 1008 between EID values of different Epochs. 1010 The EID value of 0 is reserved and MUST NOT be associated with any 1011 event. Specifically, an EID of 0 in a SW Request attribute indicates 1012 that a SW-PV wants an inventory response rather than an event 1013 response, while an EID of 0 in a SW Response is used to indicate the 1014 initial state of the endpoint's Software Inventory Evidence 1015 Collection prior to the observation of any events. Thus the very 1016 first recorded event in a SW-PC's records within an EID Epoch MUST be 1017 assigned a value of 1 or greater. Note that EID and EID Epoch values 1018 are assigned by the SW-PC without regard to whether events are being 1019 reported to one or more SW-PVs. The SW-PC records events and assigns 1020 EIDs during its operation. Any and all SW-PVs that request event 1021 information from the SW-PC will have those requests served from the 1022 same event records and thus will see the same EIDs and EID Epochs for 1023 the same events. 1025 The SW-PC MUST ensure there is no coverage gap (i.e., change events 1026 that are not recorded in the SW-PC's records) in its change event 1027 records. This is necessary because a coverage gap might give a SW-PV 1028 a false impression of the endpoint's state. For example, if a SW-PV 1029 saw an event indicating that a particular record had been added to 1030 the endpoint's software inventory evidence collection, and saw no 1031 subsequent events indicating that record had been deleted, it might 1032 reasonably assume that this record was still present and thus that 1033 the indicated software was still installed (assuming the Epoch has 1034 not changed). If there is a coverage gap in the SW-PC's event 1035 records, however, this assumption could be false. For this reason, 1036 the SW-PC's event records MUST NOT contain gaps. In the case where 1037 there are periods where it is possible that changes occurred without 1038 the SW-PC detecting or recording them, the SW-PC MUST either compute 1039 a net change and update its event records appropriately, or pick a 1040 new EID Epoch to indicate a discontinuity with previous event 1041 records. 1043 Within a given Epoch, once a particular event has been assigned an 1044 EID, this association MUST NOT be changed. That is, within an Epoch, 1045 once an EID is assigned to an event, that EID cannot be reassigned to 1046 a different event, and the event cannot be assigned a different EID. 1047 When the SW-PC's Epoch changes, all of these associations between 1048 EIDs and events are cancelled, and EID values once again become free 1049 for assignment. 1051 3.5.2. Core Event Tracking Information 1053 Whether reporting events or full inventories it is important to know 1054 how the reported information fits into the overall timeline of change 1055 events. This is why all SW Response attributes include fields to 1056 place that response within the sequence of detected events. 1057 Specifically, all SW Responses include a Last EID and EID Epoch 1058 field. The EID Epoch field identifies the EID Epoch in which the SW 1059 Response was sent. If the SW Response is reporting events, all 1060 reported events occurred within the named EID Epoch. The Last EID 1061 (which is also always from the named EID Epoch) indicates the EID of 1062 the last recorded change event at the time that the SW Response was 1063 sent. These two fields allow any response to be placed in the 1064 context of the complete set of detected change events within a given 1065 EID Epoch. 1067 3.5.3. Updating Inventory Knowledge Based on Events 1069 Modern endpoints can have hundreds of software products installed, 1070 most of which are unlikely to change from one day to the next. As 1071 such, instead of exchanging a complete list of an endpoint's 1072 inventory on a regular basis, one might wish to only identify changes 1073 since some earlier known state of this inventory. This is readily 1074 facilitated by the use of EIDs to place change events in a context 1075 relative to earlier state. 1077 As noted above, every SW Response sent by a SW-PC to a SW-PV (as 1078 described in Section 3.1 through Section 3.3) includes the EID Epoch 1079 and EID of the last event recorded prior to that response being 1080 compiled. This allows the SW-PV to place all subsequently received 1081 event records in context relative to this SW Response attribute 1082 (since the EIDs represent a total ordering of all changes to the 1083 endpoint's software inventory evidence collection). Specifically, a 1084 SW-PV (or, more likely, a database that collects and records its 1085 findings) can record an endpoint's full inventory and also the EID 1086 and Epoch of the most recent event reflected at the time of that 1087 inventory. From that point on, if change events are observed, the 1088 attribute describing these events indicates the nature of the change, 1089 the affected records, and the order in which these events occurred 1090 (as indicated by the sequential EIDs). Using this information, any 1091 remote record of the endpoint's Software Inventory Evidence 1092 Collection can be updated appropriately. 1094 3.5.4. Using Event Records in SW Attributes 1096 A SW-PV MUST be able to request a list of event records instead of an 1097 inventory. The attribute flow in such an exchange looks the same as 1098 the basic flow shown in Figure 2. The only difference is that, in 1099 the SW Request attribute, the SW-PV provides an EID other than 0. (A 1100 value of 0 in these fields represents a request for an inventory.) 1101 When the SW-PC receives such a request, instead of identifying 1102 records from the endpoint's Software Inventory Evidence Collection, 1103 it consults its list of detected changes. The SW-PC MUST add an 1104 event record to the SW Response attribute for each recorded change 1105 event with an EID greater than or equal to the EID in the SW Request 1106 attribute (although targeting of requests, as described in the next 1107 paragraph, might limit this list). A list of event records MUST only 1108 contain events with EIDs that all come from the current Epoch. 1110 SW-PVs can target requests for event records by including one or more 1111 Software Identifiers, as described in Section 3.3, in the SW Request 1112 that requests an event record list. A targeted request for event 1113 records is used to indicate that only events affecting software that 1114 matches one of the provided Software Identifiers are to be returned. 1115 Specifically, in response to a targeted request for event records, 1116 the SW-PC MUST exclude any event records that are less than the 1117 indicated EID (within the current EID Epoch) and exclude any event 1118 records where the affected software does not match one of the 1119 provided Software Identifiers. This might mean that the resulting 1120 list of event records sent in the response attribute does not provide 1121 a continuous sequence of EIDs. Both SW-PCs and SWIC-PVs MUST support 1122 targeted request for event records. 1124 3.5.5. Partial and Complete Lists of Event Records in SW Attributes 1126 Over time, a SW-PC might record a large number of change events. If 1127 a SW-PV requests all change events covering a large period of time, 1128 the resulting SW Response attribute might be extremely large, 1129 especially if the SW-PV requests inclusion of software inventory 1130 evidence records in the response. In the case that the resulting 1131 attribute is too large to send (either because it exceeds the 4GB 1132 attribute size limit imposed by the PA-TNC specification, or because 1133 it exceeds some smaller size limit imposed on the SW-PC) the SW-PC 1134 MAY send a partial list of event records back to the SW-PV. 1136 Generation of a partial list of events in a SW Response attribute 1137 requires the SW-PC to identify a "consulted range" of EIDs. A 1138 consulted range is the set of event records that are examined for 1139 inclusion in the SW Response attribute and that are included in that 1140 attribute if applicable. Recall that, if a SW Request is targeted, 1141 only event records that involve the indicated software would be 1142 applicable. (See Section 3.3 for more on Targeted Request.) If a 1143 request is not targeted, all event records in the considered range 1144 are applicable and included in the SW Response attribute. 1146 The lower bound of the consulted range MUST be the EID provided in 1147 the SW Request. (Recall that a SW Request indicates a request for 1148 event records by providing a non-0 EID value in the SW Request. See 1149 Section 3.5.4.) The upper bound of the consulted range is the EID of 1150 the latest event record (as ordered by EID values) that is included 1151 in the SW Response attribute if it is applicable to the request. The 1152 EID of this last event record is called the "Last Consulted EID". 1153 The SW-PC chooses this Last Consulted EID based on the size of the 1154 event record list it is willing to provide to the SW-PV. 1156 A partial result list MUST include all applicable event records 1157 within the consulted range. This means that for any applicable event 1158 record (i.e., any event record in an un-targeted request, or any 1159 event record associated with software matching a requested Software 1160 Identifier in a targeted request) whose EID is greater than or equal 1161 to the EID provided in the SW Request and whose EID is less than or 1162 equal to the Last Consulted EID, that event record MUST be included 1163 in the SW Response conveying this partial list of event records. 1164 This ensures that every partial list of event records is always 1165 complete within its indicated range. 1167 All SW Response attributes that convey event records include a Last 1168 Consulted EID field. This is in addition to the EID Epoch and Last 1169 EID fields that are present in all SW Responses. Note that, if 1170 responding to a targeted SW Request, the SW Response attribute might 1171 not contain the event record whose EID matches the Last Consulted EID 1172 value. For example, the last consulted EID record might have been 1173 deemed inapplicable because it did not match the specified list of 1174 Software Identifiers in the SW Request. 1176 If a SW-PV receives a SW Response attribute where the Last EID and 1177 Last Consulted EID fields are identical, the SW-PV knows that it has 1178 received a result list that is complete, given the parameters of the 1179 request, up to the present time. 1181 On the other hand, if the Last EID is greater than the Last Consulted 1182 EID, the SW-PV has received a partial result list. (The Last 1183 Consulted EID MUST NOT exceed the Last EID.) In this case, if the 1184 SW-PV wishes to try to collect the rest of the partially delivered 1185 result list it then sends a new SW Request whose EID is one greater 1186 than the Last Consulted EID in the preceding response. Doing this 1187 causes the SW-PC to generate another SW Response attribute containing 1188 event records where the earliest reported event record is the one 1189 immediately after the event record with the Last Consulted EID (since 1190 EIDs are assigned sequentially). By repeating this process until it 1191 receives a SW Response where the Last EID and Last Consulted EID are 1192 equal, the SW-PV is able to collect all event records over a given 1193 range, even if the complete set of event records would be too large 1194 to deliver via a single attribute. 1196 Implementers need to be aware that a SW Request might specify an EID 1197 that is greater than the EID of the last event recorded by a SW-PC. 1198 In accordance with the behaviors described in Section 3.5.4, a SW-PC 1199 MUST respond to such a request with a SW Response attribute that 1200 contains zero event records. This is because the SW-PC has recorded 1201 no event records with EIDs greater than or equal to the EID in the SW 1202 Request. In such a case, the Last Consulted EID field MUST be set to 1203 the same value as the Last EID field in this SW Response attribute. 1205 This case is called out because the consulted range on a SW-PC in 1206 such a situation is a negative range, where the "first" EID in the 1207 range (provided in the SW Request) is greater than the "last" EID in 1208 the range (this being the EID of the last recorded event on the SW- 1209 PC). Implementers need to ensure that SW-PCs do not experience 1210 problems in such a circumstance. 1212 Note that this specification only supports the returning of partial 1213 results when returning event records. There is no way to return a 1214 partial inventory list under this specification. 1216 3.5.6. Synchronizing Event Identifiers and Epochs 1218 Since EIDs are sequential within an Epoch, if a SW-PV's list of event 1219 records contains gaps in the EID values within a single Epoch, the 1220 SW-PV knows that there are events that have not been accounted for. 1221 The SW-PV can either request a new event list to collect the missing 1222 events or request a full inventory to re-sync its understanding of 1223 the state of the endpoint's Software Inventory Evidence Collection. 1224 In either case, after the SW-PV's record of the endpoint's Software 1225 Inventory Evidence Collection has been updated, the SW-PV can record 1226 the new latest EID value and track events normally from that point 1227 on. 1229 If the SW-PV receives any attribute from a SW-PC where the EID Epoch 1230 differs from the EID Epoch that was used previously, then SW-PV or 1231 any entity using this information to track the endpoint's Software 1232 Inventory Evidence Collection knows that there is a discontinuity in 1233 their understanding of the endpoint's state. To move past this 1234 discontinuity and reestablish a current understanding of the state of 1235 the endpoint's Software Inventory Evidence Collection, the SW-PV 1236 needs to receive a full inventory from the endpoint. The SW-PV 1237 cannot be brought in sync with the endpoint's state through the 1238 collection of any set of event records in this situation. This is 1239 because it is not possible to account for all events on the SW-PC 1240 since the previous Epoch was used, because there is no way to query 1241 for EIDs from a previous Epoch. Once the SW-PV has received a full 1242 inventory for the new Epoch, the SW-PV records the latest EID 1243 reported in this new Epoch and can track further events normally. 1245 A SW-PC MUST NOT report events with EIDs from any Epoch other than 1246 the current EID Epoch. The SW-PC MAY choose to purge all event 1247 records from a previous Epoch from memory after an Epoch change. 1248 Alternately, the SW-PC MAY choose to retain some event records from a 1249 previous EID Epoch and assign them new EIDs in the current Epoch. 1250 However, in the case where a SW-PC chooses the latter option it MUST 1251 ensure that the order of events according to their EIDs is unchanged 1252 and that there is no coverage gap between the first retained event 1253 recorded during the previous Epoch (now reassigned with an EID in the 1254 current Epoch) and the first event recorded during the current Epoch. 1255 In particular, the SW-PC MUST ensure that all change events that 1256 occurred after the last recorded event from the previous Epoch are 1257 known and recorded. (This might not be possible if the Epoch change 1258 is due to state corruption on the SW-PC.) A SW-PC might choose to 1259 reassign EIDs to records from a preceding Epoch to create a "sliding 1260 window" of events, where each Epoch change represents a shift in the 1261 window of available events. 1263 In the case where a SW-PC suffers a crash and loses track of its 1264 current EID Epoch or current EID, then it MUST generate a new EID 1265 Epoch value and begin assigning EIDs within that Epoch. In this 1266 case, the SW-PC MUST purge all event records from before the crash as 1267 it cannot ensure that there is not a gap between the last of those 1268 records and the next detected event. The process for generating a 1269 new EID Epoch MUST minimize the possibility that the newly generated 1270 EID Epoch is the same as a previously used EID Epoch. 1272 The SW-PV will normally never receive an attribute indicating that 1273 the latest EID is less than the latest EID reported in a previous 1274 attribute within the same EID Epoch. If this occurs, the SW-PC has 1275 suffered an error of some kind, possibly indicative of at least 1276 partial corruption of its event log. In this case, the SW-PV SHOULD 1277 treat the situation as if there was a change in Epoch and treat any 1278 local copy of the endpoint's Software Inventory Evidence Collection 1279 as out-of-sync until a full inventory can be reported by the SW-PC. 1280 In this case, the SW-PV SHOULD flag the occurrence so the SW-PC can 1281 be examined to ensure it is now operating properly. 1283 3.6. Subscriptions 1285 Thus far, all attribute exchanges discussed assume that a SW-PV sent 1286 an SW Request attribute and the SW-PC is providing a direct response 1287 to that request. The Software Inventory Message and Attributes for 1288 PA-TNC specification also supports the ability for a SW-PC to send a 1289 SW Response to the SW-PV in response to observed changes in the 1290 endpoint's software inventory evidence collection, instead of in 1291 direct response to a SW Request. An agreement by a SW-PC to send 1292 content when certain changes are detected to the endpoint's Software 1293 Inventory Evidence Collection is referred to in this specification as 1294 a "subscription", and the SW-PV that receives this content is said to 1295 be "subscribed to" the given SW-PC. All SW-PCs and SW-PVs MUST 1296 support the use of subscriptions. 1298 3.6.1. Establishing Subscriptions 1300 A SW-PV establishes a subscription on a particular SW-PC by sending a 1301 SW Request attribute with the Subscription flag set. The SW Request 1302 attribute is otherwise identical to the SW Requests discussed in 1303 previous sections. Specifically, such a SW Request might or might 1304 not request inclusion of software inventory evidence records, might 1305 or might not be targeted, and might request change event records or 1306 endpoint inventory. Assuming no error is encountered, a SW-PC MUST 1307 send a SW Response attribute in direct response to this SW Request 1308 attribute, just as if the Subscription flag was not set. As such, 1309 the attribute exchange that establishes a new subscription in a SW-PC 1310 has the same flow seen in the previous attribute exchanges, as 1311 depicted in Figure 2. If the SW-PV does not receive a PA-TNC Error 1312 attribute (as described in Section 3.8 and Section 4.14) in response 1313 to their subscription request, the subscription has been successfully 1314 established on the SW-PC. The SW Request attribute that establishes 1315 a new subscription is referred to as the "establishing request" for 1316 that subscription. 1318 When a subscription is established it is assigned a Subscription ID 1319 value. The Subscription ID is equal to the value of the Request ID 1320 of the establishing request. (For more about Request IDs, see 1321 Section 4.6.) 1323 A SW-PC MUST have the ability to record and support multiple 1324 simultaneous subscriptions from a single party and from multiple 1325 parties. A SW-PV MUST have the ability to record and support 1326 multiple simultaneous subscriptions to a single party and 1327 subscriptions to multiple parties. 1329 3.6.2. Managing Subscriptions 1331 The SW-PC MUST record each accepted subscription along with the 1332 identity of the party to whom attributes are to be pushed in 1333 compliance with the subscription. This identity includes both the 1334 NEA Server's connection ID and the Posture Validator Identifier from 1335 the PB-PA message that delivered the request. 1337 Likewise, SW-PVs MUST record each accepted subscription for which 1338 they are the subscribing party along with the associated Subscription 1339 ID and the identity of the SW-PC that will be fulfilling the 1340 subscription. The SW-PV needs to retain this information in order to 1341 correctly interpret pushed SW Response attributes sent in fulfillment 1342 of the subscription. The identity of the SW-PC is given in the 1343 Posture Collector Identifier of the PB-PA message header in all 1344 messages from that SW-PC. 1346 3.6.3. Terminating Subscriptions 1348 Subscriptions MAY be terminated at any time by the subscribing SW-PV 1349 by setting the Clear Subscriptions flag in a SW Request. (See 1350 Section 4.7 for more on using this flag.) In the case that a SW 1351 Request with the Clear Subscriptions flag set is received the SW-PC 1352 MUST only clear subscriptions that match both the NEA server 1353 connection ID and the SW-PV ID for this SW Request, and MUST clear 1354 all such subscriptions. 1356 This specification does not give the SW-PV the ability to terminate 1357 subscriptions individually - all subscriptions to the SW-PV are 1358 cleared when the Clear Subscriptions flag is set. 1360 This specification does not give the SW-PC the ability to 1361 unilaterally terminate a subscription. However, if the SW-PC 1362 experiences a fatal error fulfilling a subscription, resulting in 1363 sending a PA-TNC Error attribute of type 1364 SW_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose 1365 fulfillment led to the error MUST be treated as terminated by both 1366 the SW-PC and the SW-PV. Only the subscription experiencing the 1367 error is cancelled and other subscriptions are unaffected. See 1368 Section 3.8 for more on this error condition. 1370 Finally, a subscription is terminated if the connection between the 1371 SW-PC and SW-PV is deleted. This occurs when the connection ID used 1372 in the messages between the SW-PC and the SW-PV becomes unbound. 1373 Loss of this connection ID would prevent the SW-PC from sending 1374 messages in fulfillment of this subscription. As such, loss of the 1375 connection ID necessarily forces subscription termination between the 1376 affected parties. 1378 3.6.4. Subscription Status 1380 A SW-PV can request that a SW-PC report the list of active 1381 subscriptions for which the SW-PV is the subscriber. A SW-PV can use 1382 this to recover lost information about active subscriptions. A SW-PV 1383 can also use this capability to verify that a SW-PC has not forgotten 1384 any of its subscriptions. The latter is especially useful where a 1385 SW-PC does not send any attributes in fulfillment of a given 1386 subscription for a long period of time. The SW-PV can check the list 1387 of active subscriptions on the SW-PC and verify whether the 1388 inactivity is due to a lack of reportable events or due to the SW-PC 1389 forgetting its obligations to fulfill a given subscription. 1391 A SW-PV requests a list of its subscriptions on a given SW-PC by 1392 sending that SW-PC a Subscription Status Request. The SW-PC MUST 1393 then respond with a Subscription Status Response (or a PA-TNC Error 1394 if an error condition is experienced). The Subscription Status 1395 Response MUST contain one subscription record for each of the active 1396 subscriptions for which the SW-PV is the subscribing party. 1398 3.6.5. Fulfilling Subscriptions 1400 As noted in Section 3.4 SW-PCs MUST have the ability to automatically 1401 detect changes to an endpoint's Software Inventory Evidence 1402 Collection in near real-time. For every active subscription, the SW- 1403 PC MUST send an attribute to the subscribed SW-PV whenever a change 1404 is detected to relevant records within the endpoint's Software 1405 Inventory Evidence Collection. Such an attribute is said to be sent 1406 "in fulfillment of" the given subscription and any such attribute 1407 MUST include that subscription's Subscription ID. If the 1408 establishing request for that subscription was a targeted request, 1409 then only records that match the Software Identifiers provided in 1410 that establishing request are considered relevant. Otherwise, (i.e., 1411 for non-targeted requests) any record is considered relevant for this 1412 purpose. Figure 3 shows a sample attribute exchange where a 1413 subscription is established and then later attributes are sent from 1414 the SW-PC in fulfillment of the established subscription. 1416 +-------------+ +--------------+ 1417 | SW-PC | | SW-PV | Time 1418 +-------------+ +--------------+ | 1419 | | | 1420 |<-----------SW Request-------------| | 1421 | | | 1422 |------------SW Response----------->| | 1423 | | | 1424 . . . 1425 . . . 1426 . . . 1427 | | | 1428 |------------SW Response----------->| | 1429 | | | 1430 . . . 1431 . . . 1432 . . . 1433 | | | 1434 |------------SW Response----------->| | 1435 | | V 1437 Figure 3: Subscription Establishment and Fulfillment 1439 The contents of an attribute sent in fulfillment of a subscription 1440 depend on the parameters provided in the establishing request for 1441 that subscription. Specifically, the contents of an attribute sent 1442 in fulfillment of a subscription have the same format as would a 1443 direct response to the establishing request. For example, if the 1444 establishing request stipulated a response that contained an event 1445 record list that included software inventory evidence records, all 1446 attributes sent in fulfillment of this subscription will also consist 1447 of event record lists with software inventory evidence records. As 1448 such, all SW Responses displayed in the exchange depicted in Figure 3 1449 have the same format. A SW Response generated in fulfillment of an 1450 active subscription MUST be a valid SW Response attribute according 1451 to all the rules outlined in the preceding sections. In other words, 1452 an attribute constructed in fulfillment of a subscription will look 1453 the same as an attribute sent in direct response to an explicit 1454 request from a SW-PV that had the same request parameters and which 1455 arrived immediately after the given change event. There are a few 1456 special rules that expand on this guideline: 1458 3.6.5.1. Subscriptions Reporting Inventories 1460 In the case that a SW-PV subscribes to a SW-PC requesting an 1461 inventory attribute whenever changes are detected (i.e. the EID in 1462 the establishing request is 0), then the SW-PC MUST send the 1463 requested inventory whenever a relevant change is detected. (A 1464 "relevant change" is any change for untargeted requests, or a change 1465 to an indicated record in a targeted request.) Upon detection of a 1466 relevant change for an active subscription, the SW-PC sends the 1467 appropriate inventory information as if it had just received the 1468 establishing request. Attributes sent in fulfillment of this 1469 subscription will probably have a large amount of redundancy, as the 1470 same records are likely to be present in each of these SW Attributes. 1471 The role of an inventory subscription is not to report records just 1472 for the items that changed - that is the role of a subscription that 1473 reports events (see Section 3.6.5.2). A SW-PC MUST NOT exclude a 1474 record from an attribute sent in fulfillment of an inventory 1475 subscription simply because that record was not involved in the 1476 triggering event (although a record might be excluded for other 1477 reasons, such as if the subscription is targeted - see 1478 Section 3.6.5.3). 1480 3.6.5.2. Subscriptions Reporting Events 1482 The way in which a SW-PV indicates it wishes to establish a 1483 subscription requesting event records is by providing a non-zero EID 1484 in the SW Request establishing the subscription (see Section 3.5.1). 1485 However, when the SW-PC constructs an attribute in fulfillment of the 1486 subscription (other than the direct response to the establishing 1487 request), it MUST only include event records for the detected 1488 change(s) that precipitated this response attribute. In other words, 1489 it MUST NOT send a complete list of all changes starting with the 1490 indicated EID, up through the latest change, every time a new event 1491 is detected. In effect, the EID in the establishing request is 1492 treated as being updated every time an attribute is sent in 1493 fulfillment of this subscription, such that a single event is not 1494 reported twice in fulfillment of a single subscription. As such, 1495 every SW-PC MUST track the EID of the last event that triggered an 1496 attribute for the given subscription. When the next event (or set of 1497 events) is detected, the SW-PC MUST only report events with EIDs 1498 after the last reported event. In the case that the EID Epoch of the 1499 SW-PC changes, the SW-PC MUST treat EID values in the new Epoch as 1500 being after all EIDs assigned in the previous Epoch regardless of the 1501 relative numeric values of these EIDs. 1503 Note that while a subscription is active, the subscribing SW-PV MAY 1504 make other requests for event records that overlap with events that 1505 are reported in fulfillment of a subscription. Such requests are 1506 unaffected by the presence of the subscription, nor is the 1507 subscription affected by such requests. In other words, a given 1508 request will get the same results back whether or not there was a 1509 subscription. Likewise, an attribute sent in fulfillment of a 1510 subscription will contain the same information whether or not other 1511 requests had been received from the SW-PV. 1513 A SW-PV needs to pay attention to the EID Epoch in these attributes, 1514 as changes in the Epoch might create discontinuities in the SW-PV's 1515 understanding of the endpoint's Software Inventory Evidence 1516 Collection state, as discussed in Section 3.5.6. In particular, once 1517 the EID Epoch changes, a SW-PV is unable have confidence that it has 1518 a correct understanding of the state of an endpoint's Software 1519 Inventory Evidence Collection until after the SW-PV collects a 1520 complete inventory. 1522 SW-PCs MAY send partial lists of event records in fulfillment of a 1523 subscription. (See Section 3.5.5 for more on partial list of event 1524 records.) In the case that a SW-PC sends a partial list of event 1525 records in fulfillment of a subscription, it MUST immediately send 1526 the next consecutive partial list, and continue doing so until it has 1527 sent the equivalent of the complete list of event records. In other 1528 words, if the SW-PC sends a partial list it does not wait for another 1529 change event to send another SW Response, but continues sending SW 1530 Responses until it has sent all event records that would have been 1531 included in a complete fulfillment of the subscription. Note that 1532 the direct response to the establishing request is not considered to 1533 be sent in fulfillment of a subscription. However, in this case the 1534 SW-PC MUST treat the presence of unreported events as a triggering 1535 event for pushing additional messages in fulfillment of the newly 1536 established subscription. As such, the net effect is that, if the 1537 direct response to the establishing request (i.e., the Subscription 1538 Fulfillment flag is unset) is partial, the SW-PC will immediately 1539 follow this with additional attributes (with the Subscription 1540 Fulfillment flag set) until the complete set of events has been sent 1541 to the SW-PV. 1543 3.6.5.3. Targeted Subscriptions 1545 Subscriptions MAY be targeted to only apply to records that match a 1546 given set of Software Identifiers. In the case where changes are 1547 detected that affect multiple records, some matching the establishing 1548 request's Software Identifiers and some not, the attribute sent in 1549 fulfillment of the subscription MUST only include inventory or events 1550 (as appropriate) for records that match the establishing request's 1551 Software Identifiers. The SW-PC MUST NOT include non-matching 1552 records in the attribute, even if those non-matching records 1553 experienced change events that were co-temporal with change events on 1554 the matching records. 1556 In addition, a SW-PC MUST send an attribute in fulfillment of a 1557 targeted subscription only when changes to the endpoint's Software 1558 Inventory Evidence Collection impact one or more records matching the 1559 subscription's establishing request's Software Identifiers. A SW-PC 1560 MUST NOT send any attribute in fulfillment of a targeted subscription 1561 based on detected change to the endpoint's Software Inventory 1562 Evidence Collection that did not involve any of the records targeted 1563 by that subscription. 1565 3.6.5.4. No Subscription Consolidation 1567 A SW-PV MAY establish multiple subscriptions to a given SW-PC. If 1568 this is the case, it is possible that a single change event on the 1569 endpoint might require fulfillment by multiple subscriptions, and 1570 that the information included in attributes that fulfill each of 1571 these subscriptions might overlap. The SW-PC MUST send separate 1572 attributes for each established subscription that requires a response 1573 due to the given event. Each of these attributes MUST contain all 1574 information required to fulfill that individual subscription, even if 1575 that information is also sent in other attributes sent in fulfillment 1576 of other subscriptions at the same time. In other words, SW-PCs MUST 1577 NOT attempt to combine information when fulfilling multiple 1578 subscriptions simultaneously, even if this results in some redundancy 1579 in the attributes sent to the SW-PV. 1581 3.6.5.5. Delayed Subscription Fulfillment 1583 A SW-PC MAY delay the fulfillment of a subscription following a 1584 change event in the interest of waiting to see if additional change 1585 events are forthcoming and, if so, conveying the relevant records 1586 back to the SW-PV in a single SW Response attribute. This can help 1587 reduce network bandwidth consumption between the SW-PC and the SW-PV. 1588 For example, consider a situation where 10 changes occur a tenth of a 1589 second apart. If the SW-PC does not delay in assembling and sending 1590 SW Response attributes, the SW-PV will receive 10 separate SW 1591 Response attributes over a period of 1 second. However, if the SW-PC 1592 waits half a second after the initial event before assembling a SW 1593 Response, the SW-PV only receives two SW Response attributes over the 1594 same period of time. 1596 Note that the ability to consolidate events for a single subscription 1597 over a given period of time does not contradict the rules in 1598 Section 3.6.5.4 prohibiting consolidation across multiple 1599 subscriptions. When delaying fulfillment of subscriptions, SW-PCs 1600 are still required to fulfill each individual subscription 1601 separately. Moreover, in the case that change events within the 1602 delay window cancel each other out (e.g., a record is deleted and 1603 then re-added), the SW-PC MUST still report each change event rather 1604 than just reporting the net effect of changes over the delay period. 1605 In other words, delayed fulfillment can decrease the number of 1606 attributes send by the SW-PC, but it does not reduce the total number 1607 of change events reported. 1609 SW-PCs are not required to support delayed fulfillment of 1610 subscriptions. However, in the case that the SW-PC does support 1611 delayed subscription fulfillment, it MUST be possible to configure 1612 the SW-PC to disable delayed fulfillment. In other words, parties 1613 deploying SW-PCs need to be allowed to disable delayed subscription 1614 fulfillment in their SW-PCs. The manner in which such configuration 1615 occurs is left to the discretion of implementers, although 1616 implementers MUST protect the configuration procedure from 1617 unauthorized tampering. In other words, there needs to be some 1618 assurance that unauthorized individuals are not able to introduce 1619 long delays in subscription fulfillment. 1621 3.7. Multiple Sources of Software Inventory Evidence Records 1623 The records in an endpoint's software inventory evidence collection 1624 might potentially come from multiple sources. For example, records 1625 might be derived from ISO SWID tags deposited on the file system and 1626 collected therefrom. Records might also be generated by tools such 1627 as software and package managers (e.g., RPM or YUM) or might be 1628 translated from software discovery reports. 1630 A SW-PC is not required to identify every possible source of software 1631 information on its endpoint. Some SW-PCs might be explicitly tied 1632 only to one or a handful of software inventory sources. For all 1633 software inventory evidence sources that a particular SW-PC supports, 1634 it MUST completely support all requirements of this specification 1635 with regard to those sources. In other words, for supported sources, 1636 the SW-PC is required to be capable of providing a complete set of 1637 the provided software inventory evidence records; monitoring for 1638 changes in the records reported by those sources, correctly providing 1639 responses for both full and targeted requests for records from those 1640 sources, and delivering complete software inventory evidence records 1641 as appropriate. In all cases, the SW-PC MUST also be capable of 1642 deriving a Software Identifier from the resulting record and also 1643 assigning that record a unique Record Identifier. The SW-PC MUST NOT 1644 provide any inventory or event information from software inventory 1645 sources for which it cannot provide this full support. Note that the 1646 SW-PC SHOULD be able to provide a Software Locator for each software 1647 product reported by a given source, but it is recognized that this 1648 might not be possible in all circumstances and the inability to do so 1649 does not preclude use of the given source. 1651 When providing a SW Response (either in direct response to a SW 1652 Request or in fulfillment of a subscription) the SW-PC MUST include 1653 the complete set of relevant data from all supported sources of 1654 software inventory evidence. In other words, a full inventory is 1655 required to contain all records from all supported sources, a 1656 targeted inventory is required to contain all relevant records from 1657 all sources, and event tracking is required to cover all events from 1658 all sources. With regard to events, a SW-PC's assignment of EIDs 1659 MUST reflect the presence and order of all events on the endpoint (at 1660 least for supported sources) regardless of the source. This means 1661 that if source A experiences an event, and then source B experiences 1662 two events, and then source A experiences another two events, the SW- 1663 PC is required to capture five events with consecutive EID values 1664 reflecting the order in which the events occur. 1666 Note that, if a SW-PC collects data from multiple sources, it is 1667 possible that some software products might be "double counted". This 1668 can happen if both sources of inventory evidence provide a record for 1669 a single installation of a software product. Moreover, each of these 1670 provided records might have different Software Identifier and 1671 Software Locator values due to the different ways a source might 1672 report its information. When a SW-PC reports information or records 1673 events from multiple inventory evidence sources, it MUST use the 1674 information those sources provide, rather than attempting to perform 1675 some form of reduction. In other words, if multiple sources report 1676 records corresponding to a single installation of a software product, 1677 all such records from each source are required to be part of the SW- 1678 PC's processing even if this might lead to multiple reporting, and 1679 the SW-PC is not to ignore some records to avoid such multiple 1680 reporting. Similarly, in the case that multiple sources report an 1681 event, the SW-PC MUST create separate event records with separate 1682 EIDs for each of these, even if there is the chance that they 1683 represent multiple sources reporting the same action on the endpoint. 1684 Entities tracking software inventory information collected via SW-PCs 1685 and SW-PVs need to be aware that such double-reporting might occur. 1686 How (or if) such occurrences are detected and resolved is up to the 1687 implementers of those entities. 1689 3.8. Error Handling 1691 In the case where the SW-PC detects an error in a SW Request 1692 attribute that it receives it MUST respond with a PA-TNC Error 1693 attribute with an error code appropriate to the nature of the error. 1694 (See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC 1695 Error attributes and error codes as well as Section 4.14 in this 1696 specification for error codes specific to SW Attributes.) In the 1697 case that an error is detected in a SW Request the SW-PC MUST NOT 1698 take any action requested by this SW Request, even if partial 1699 completion of the SW is possible. In other words, a SW Request that 1700 contains an error is completely ignored by the SW-PC (beyond sending 1701 a PA-TNC Error attribute, and possibly logging the error locally) 1702 rather than being partially executed. 1704 In the case where the SW-PC receives a valid SW Request attribute but 1705 experiences an error during the process of responding to that 1706 attribute's instructions where that error prevents the SW-PC from 1707 properly or completely fulfilling that request, the SW-PC MUST send a 1708 PA-TNC Error attribute with an error code appropriate to the nature 1709 of the error. In the case where a PA-TNC Error attribute is sent, 1710 the SW-PC MUST NOT take any of the actions requested by the SW 1711 Request attribute which led to the detected error. This is the case 1712 even if some actions could have been completed successfully, and 1713 might even require the SW-PC to reverse some successful actions 1714 already taken before the error condition was detected. In other 1715 words, either all aspects of a SW Request complete fully and 1716 successfully (in which case the SW-PC sends a SW Response attribute), 1717 or no aspects of the SW Request occur (in which case the SW-PC sends 1718 a PA-TNC Error attribute). In the case that a SW-PC sends a PA-TNC 1719 Error attribute in response to a SW Request then the SW-PC MUST NOT 1720 also send any SW Response attribute in response to the same SW 1721 Request. For this reason, the sending of a SW Response attribute 1722 MUST be the last action taken by a SW-PC in response to a SW Request 1723 to avoid the possibility of a processing error occurring after that 1724 SW Response attribute is sent. 1726 In the case that the SW-PC detects an error that prevents it from 1727 properly or completely fulfilling its obligations under an active 1728 subscription, the SW-PC MUST send a PA-TNC Error attribute of type 1729 SW_SUBSCRIPTION_FULFILLMENT_ERROR to the SW-PV that established this 1730 subscription. This type of PA-TNC Error attribute identifies the 1731 specific subscription that cannot be adequately honored due to the 1732 error condition as well as an error "sub-type". The error sub-type 1733 is used to indicate the type of error condition the SW-PC experienced 1734 that prevented it from honoring the given subscription. In the case 1735 that the error condition cannot be identified or does not align with 1736 any of the defined error codes, the SW_ERROR error code SHOULD be 1737 used in the sub-type. In the case that a 1738 SW_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated 1739 subscription MUST be treated as cancelled by both the SW-PC and SW- 1740 PV. 1742 The SW-PV MUST NOT send any PA-TNC Error attributes to SW-PCs. In 1743 the case that a SW-PV detects an error condition, it SHOULD log this 1744 error but does not inform any SW-PC's of this event. Errors might 1745 include, but are not limited to, detection of malformed SW Response 1746 attributes sent from a given SW-PC, as well as detection of error 1747 conditions when the SW-PV processes SW Responses. 1749 Both SW-PCs and SW-PVs SHOULD log errors so that administrators can 1750 trace the causes of errors. Log entries SHOULD include the type of 1751 the error, the time it was detected, and additional descriptive 1752 information to aid in understanding the nature and cause of the 1753 error. 1755 4. Software Inventory Message and Attributes for PA-TNC Protocol 1757 This section describes the format and semantics of the Software 1758 Inventory Message and Attributes for PA-TNC protocol. Software 1759 Inventory Message and Attributes for PA-TNC uses the standard PA-TNC 1760 message header format. See the PA-TNC specification [RFC5792] for 1761 information on this header format. 1763 4.1. PA Subtype (AKA PA-TNC Component Type) 1765 The NEA PB-TNC interface provides a general message-batching protocol 1766 capable of carrying one or more PA-TNC messages between the Posture 1767 Broker Client and Posture Broker Server. When PB-TNC is carrying a 1768 PA-TNC message, the PB-TNC message headers contain a 32 bit 1769 identifier called the PA Subtype. The PA Subtype field indicates the 1770 type of component associated with all of the PA-TNC attributes 1771 carried by the PB-TNC message. The core set of PA Subtypes is 1772 defined in the PA-TNC specification. This specification adds the 1773 following enumeration element to the IANA registry defined in section 1774 7.2 of the PA-TNC specification [RFC5792] using the IETF Standard 1775 name space (SMI Private Enterprise Number 0x000000): 1777 +-----+---------+------------+--------------------------------------+ 1778 | PEN | Integer | Name | Defining Specification | 1779 +-----+---------+------------+--------------------------------------+ 1780 | 0 | 9 | SW | Software Inventory Message and | 1781 | | | Attributes | Attributes for PA-TNC | 1782 +-----+---------+------------+--------------------------------------+ 1784 Table 2: PA Subtype 1786 Each PA-TNC attribute described in this specification is intended to 1787 be sent between the SW-PC and SW-PV, so will be carried in a PB-TNC 1788 message indicating a PA Subtype of SW Attributes. Note that although 1789 the PA-TNC Error attribute is defined in the PA-TNC specification, 1790 when it is used in a SW Attribute exchange, it uses the SW Attributes 1791 Component Definition Value, as described in Section 4.2.8 of the PA- 1792 TNC specification [RFC5792]. PB-TNC messages MUST always include the 1793 SW Attributes Subtype defined in this section when carrying SW 1794 Attributes over PA-TNC. 1796 For more information on PB-TNC and PA-TNC messages and message 1797 headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792] 1798 specifications, respectively. 1800 4.2. SW Attribute Overview 1802 The attributes defined in this specification appear below with a 1803 short summary of their purposes. Each attribute is described in 1804 greater detail in subsequent sections. 1806 o SW Request - This attribute is used to request a software 1807 inventory or software event list from an endpoint. This attribute 1808 might also establish a subscription on the recipient SW-PC. A SW- 1809 PC MUST NOT send this attribute. 1811 o Software Identifier Inventory - This attribute is used to convey 1812 an inventory without the inclusion of software inventory evidence 1813 records. When a SW-PC receives a SW Request attribute requesting 1814 an inventory without software inventory evidence records, the SW- 1815 PC MUST send a Software Identifier Inventory attribute (or a PA- 1816 TNC Error) in response. This attribute also MAY be sent by the 1817 SW-PC in fulfillment of an active subscription. A SW-PV MUST NOT 1818 send this attribute. 1820 o Software Identifier Events - This attribute is used to convey a 1821 list of events concerning changes to an endpoint's Software 1822 Inventory Evidence Collection. Reported events do not include 1823 software inventory evidence records. When a SW-PC receives a SW 1824 Request attribute requesting an event collection without software 1825 inventory evidence records, the SW-PC MUST send a Software 1826 Identifier Events attribute (or a PA-TNC Error) in response. This 1827 attribute also MAY be sent by the SW-PC in fulfillment of an 1828 active subscription. A SW-PV MUST NOT send this attribute. 1830 o Software Inventory - This attribute is used to convey an inventory 1831 expressed including software inventory evidence records. When a 1832 SW-PC receives a SW Request attribute requesting an inventory 1833 including software inventory evidence records, the SW-PC MUST send 1834 a Software Inventory attribute (or a PA-TNC Error) in response. 1835 This attribute also MAY be sent by the SW-PC in fulfillment of an 1836 active subscription. A SW-PV MUST NOT send this attribute. 1838 o Software Events - This attribute is used to convey a list of 1839 events concerning changes to an endpoint's inventory evidence 1840 collection. Reported events include software inventory evidence 1841 records. When a SW-PC receives a SW Request attribute requesting 1842 an event collection including software inventory evidence records, 1843 the SW-PC MUST send a Software Events attribute (or a PA-TNC 1844 Error) in response. This attribute also MAY be sent by the SW-PC 1845 in fulfillment of an active subscription. A SW-PV MUST NOT send 1846 this attribute. 1848 o Subscription Status Request - This attribute is used to request a 1849 SW-PC send a summary of all the active subscriptions it has where 1850 the requesting party is the subscriber. The SW-PC MUST respond 1851 with a Subscription Status Response (or a PA-TNC Error). A SW-PC 1852 MUST NOT send this attribute. 1854 o Subscription Status Response - This attribute is used to convey 1855 information about the active subscriptions that a SW-PC has for a 1856 given subscriber. A SW-PV MUST NOT send this attribute. 1858 o PA-TNC Error - This is the standard PA-TNC Error attribute as 1859 defined in PA-TNC [RFC5792] and is used to indicate that an error 1860 was encountered during a SW Attribute exchange. It MUST be sent 1861 by a SW-PC in response to a SW Request in the case where the SW-PC 1862 encounters a fatal error (i.e., an error that prevents further 1863 processing of an exchange) relating to the attribute exchange. A 1864 SW-PV MUST NOT send this attribute. The SW-PC MUST then ignore 1865 the erroneous attribute after a PA-TNC Error attribute is sent 1866 (i.e., do not attempt to act on an attribute that generated a PA- 1867 TNC Error beyond sending the PA-TNC Error). In the case where the 1868 SW-PV experiences a fatal error, it MUST ignore the erroneous 1869 attribute without sending a PA-TNC Error attribute. It MAY take 1870 other actions in response to the error, such as logging the cause 1871 of the error, or even taking actions to isolate the endpoint 1873 Because one of the Software Identifier Inventory, Software Identifier 1874 Events, Software Inventory, or Software Events attributes is expected 1875 to be sent to a SW-PV in direct response to a SW Request attribute or 1876 in fulfillment of an active subscription, those four attribute types 1877 are referred to collectively in this document as "SW Response" 1878 attributes. 1880 All SW-PVs MUST be capable of sending SW Requests and be capable of 1881 receiving and processing all SW Response attributes as well as PA-TNC 1882 Error attributes. All SW-PCs MUST be capable of receiving and 1883 processing SW Requests and be capable of sending all types of SW 1884 Response attributes as well as PA-TNC Error attributes. In other 1885 words, both SW-PVs and SW-PCs are required to support their role in 1886 exchanges using any of the attribute types defined in this section. 1887 SW-PVs MUST ignore any SW Request attributes that they receive. SW- 1888 PCs MUST ignore any SW Response attributes or PA-TNC Error attributes 1889 that they receive. 1891 4.3. SW Attribute Exchanges 1893 A SW Attribute Exchange is used to provide the SW-PV with a software 1894 inventory or event collection from the queried endpoint. 1896 +-------------+ +--------------+ 1897 | SW-PC | | SW-PV | Time 1898 +-------------+ +--------------+ | 1899 | | | 1900 |<------------SW Request--------------| | 1901 | | | 1902 | SW Response* | | 1903 |-----------------or----------------->| | 1904 | PA-TNC Error | | 1905 | | V 1907 *SW Response is one of the following: Software Identifier 1908 Inventory, Software Identifier Events, Software Inventory, 1909 or Software Events. 1911 Figure 4: SW Attribute Exchange (Direct Response to SW Request) 1913 In this exchange, the SW-PV indicates to the SW-PC, via a SW Request, 1914 the nature of the information it wishes to receive (inventory vs. 1915 events, full or targeted) and how it wishes the returned inventory to 1916 be expressed (with or without software inventory evidence records). 1917 The SW-PC responds with the requested information using the 1918 appropriate attribute type. A single SW Request MUST only lead to a 1919 single SW Response or PA-TNC Error that is in direct response to that 1920 request. 1922 In addition, if there is an active subscription on the endpoint, the 1923 SW-PC sends a SW Response to the SW-PV following a change event on 1924 the endpoint in fulfillment of that subscription. Such an exchange 1925 is shown in Figure 5. 1927 +-------------+ +--------------+ 1928 | SW-PC | | SW-PV | Time 1929 +-------------+ +--------------+ | 1930 | | | 1931 | | | 1932 |--------SW Response(s)*------->| | 1933 | | | 1935 *SW Response is one of the following: Software Identifier 1936 Inventory, Software Identifier Events, Software Inventory, 1937 or Software Events. 1939 Figure 5: SW Attribute Exchange (In Fulfillment of an Active 1940 Subscription) 1942 Note that, unlike direct responses to a SW Request, a single change 1943 event can precipitate multiple SW Responses for a single 1944 subscription, but only if all but the last of those SW Responses 1945 convey partial lists of event records, and the last of those SW 1946 Responses conveys a complete list of event records. (That is, the 1947 initial responses are partial lists and the last response is the 1948 remainder of the relevant event records, completing the delivery of 1949 all relevant events at the time of the change event.) A single 1950 Change Event MUST NOT otherwise be followed by multiple SW Response 1951 or PA-TNC Error attributes in any combination. 1953 All SW-PVs and SW-PCs MUST support both types of exchanges. In 1954 particular, SW-PCs MUST be capable of pushing a SW Response to a SW- 1955 PV immediately upon detection of a change to the endpoint's Software 1956 Inventory Evidence Collection in fulfillment of established SW-PV 1957 subscriptions, as described in Section 3.6. 1959 4.4. Software Inventory Message and Attributes for PA-TNC Attribute 1960 Enumeration 1962 PA-TNC attribute types are identified in the PA-TNC Attribute Header 1963 via the Attribute Type Vendor ID and Attribute Type fields. Table 3 1964 identifies the appropriate values for these fields for each attribute 1965 type used within the Software Inventory Message and Attributes for 1966 PA-TNC protocol. 1968 +--------------+----------+------------+----------------------------+ 1969 | Attribute | PEN | Integer | Description | 1970 | Name | | | | 1971 +--------------+----------+------------+----------------------------+ 1972 | SW Request | 0x000000 | 0x00000011 | Request from a SW-PV to a | 1973 | | | | SW-PC for the SW-PC to | 1974 | | | | provide a software | 1975 | | | | inventory or event list | 1976 | | | | | 1977 | Software | 0x000000 | 0x00000012 | An inventory sent without | 1978 | Identifier | | | softare inventory evidence | 1979 | Inventory | | | records sent from a SW-PC. | 1980 | | | | | 1981 | Software | 0x000000 | 0x00000013 | A collection of events | 1982 | Identifier | | | impacting the endpoint's | 1983 | Events | | | Software Inventory | 1984 | | | | Evidence Collection, where | 1985 | | | | events do not include | 1986 | | | | software inventory | 1987 | | | | evidence records. | 1988 | | | | | 1989 | Software | 0x000000 | 0x00000014 | An inventory including | 1990 | Inventory | | | software inventory | 1991 | | | | evidence records sent from | 1992 | | | | a SW-PC. | 1993 | | | | | 1994 | Software | 0x000000 | 0x00000015 | A collection of events | 1995 | Events | | | impacting the endpoint's | 1996 | | | | Software Inventory | 1997 | | | | Evidence Collection, where | 1998 | | | | events include software | 1999 | | | | inventory evidence | 2000 | | | | records. | 2001 | | | | | 2002 | Subscription | 0x000000 | 0x00000016 | A request for a list of a | 2003 | Status | | | SW-PV's active | 2004 | Request | | | subscription. | 2005 | | | | | 2006 | Subscription | 0x000000 | 0x00000017 | A list of a SW-PV's active | 2007 | Status | | | subscriptions. | 2008 | Response | | | | 2009 | | | | | 2010 | Reserved | 0x000000 | 0x00000018 | These attribute types are | 2011 | | | - | reserved for future use in | 2012 | | | 0x0000001F | revisions to Software | 2013 | | | | Inventory Message and | 2014 | | | | Attributes for PA-TNC. | 2015 | | | | | 2016 | PA-TNC Error | 0x000000 | 0x00000008 | An error attribute as | 2017 | | | | defined in the PA-TNC | 2018 | | | | specification [RFC5792]. | 2019 +--------------+----------+------------+----------------------------+ 2021 Table 3: SW Attribute Enumeration 2023 4.5. Normalization of Text Encoding 2025 In order to ensure consistency of transmitted attributes some fields 2026 require normalization of their format. When this is necessary, this 2027 is indicated in the field's description. In such cases, the field 2028 contents MUST be normalized to Network Unicode format as defined in 2029 RFC 5198 [RFC5198]. Network Unicode format defines a refinement of 2030 UTF-8 that ensures a normalized expression of characters. SW-PCs and 2031 SW-PVs MUST NOT perform conversion and normalization on any field 2032 values except those specifically identified as requiring 2033 normalization in the following sections. Note, however, that some 2034 data models require additional normalization before source 2035 information is added to an Endpoint's Inventory Evidence Collection 2036 as a record. The references from the Software Data Model IANA table 2037 (see Section 9.4) will note where this is necessary. 2039 4.6. Request IDs 2041 All SW Request attributes MUST include a Request ID value. The 2042 Request ID field provides a value that identifies a given request 2043 relative to other requests between a SW-PV and the receiving SW-PC. 2044 Specifically, the SW-PV assigns each SW Request attribute a Request 2045 ID value that is intended to be unique within the lifetime of a given 2046 network connection ID as assigned by the SW-PV's Posture Broker 2047 Server. In the case where all possible Request ID values have been 2048 exhausted within the lifetime of a single network connection ID, the 2049 sender MAY reuse previously used Request IDs within the same network 2050 connection that are not being used as Subscription IDs. (See below 2051 in this section for an explanation of Subscription ID assignment.) 2052 In this case of Request ID reuse, Request IDs SHOULD be reused in the 2053 order of their original use. In other words, a SW-PC SHOULD NOT use 2054 a given Request ID value more than once within a persistent 2055 connection between a given Posture Broker Client-Posture Broker 2056 Server pair, but, in the case where reuse is necessary due to 2057 exhaustion of possible ID values, the SW-PC SHOULD structure the 2058 reuse to maximize the time between original and subsequent use. The 2059 Request ID value is included in a SW Response attribute directly 2060 responding to this SW Request to indicate which SW Request was 2061 received and caused the response. Request IDs can be randomly 2062 generated or sequential, as long as values are not repeated per the 2063 rules in this paragraph. SW-PCs are not required to check for 2064 duplicate Request IDs. 2066 In the case that a SW Request requests the establishment of a 2067 subscription and the receiving SW-PC agrees to that subscription, the 2068 Request ID of that SW Request (i.e., the establishing request of the 2069 subscription) becomes that subscription's Subscription ID. All 2070 attributes sent in fulfillment of this subscription include a flag 2071 indicating that the attribute fulfills a subscription and the 2072 subscription's Subscription ID. A SW-PV MUST NOT reuse a Request ID 2073 value in communicating to a given SW-PC while that Request ID is also 2074 serving as a Subscription ID for an active subscription with that SW- 2075 PC. In the case where a SW-PC receives a SW Request from a given SW- 2076 PV where that Request ID is also the Subscription ID of an active 2077 subscription with that SW-PV, the SW-PC MUST respond with a PA-TNC 2078 Error attribute with an error code of SW_SUBSCRIPTION_ID_REUSE_ERROR. 2079 Note that this error does not cancel the indicated subscription. 2081 Subscription Status Requests and Subscription Status Responses do not 2082 include Request IDs. 2084 4.7. SW Request 2086 A SW-PV sends this attribute to a SW-PC to request that the SW-PC 2087 send software inventory information to the SW-PV. A SW-PC MUST NOT 2088 send this attribute. 2090 1 2 3 2091 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 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 | Flags | Software Identifier Count | 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Request ID | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | Earliest EID | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Software Identifier Length | Software ID (var length) | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 Figure 6: SW Request Attribute 2104 +---------------+---------------------------------------------------+ 2105 | Field | Description | 2106 +---------------+---------------------------------------------------+ 2107 | Flags: Bit 0 | If set (1), the SW-PC MUST delete all | 2108 | - Clear | subscriptions established by the requesting SW-PV | 2109 | Subscriptions | (barring any errors). | 2110 | | | 2111 | Flags: Bit 1 | If set (1), in addition to responding to the | 2112 | - Subscribe | request as described, the SW-PC MUST establish a | 2113 | | subscription with parameters matching those in | 2114 | | the request attribute (barring any errors). | 2115 | | | 2116 | Flags: Bit 2 | If unset (0), the SW-PC's response MUST include | 2117 | - Result Type | software inventory evidence records and thus the | 2118 | | response MUST be a Software Inventory, a Software | 2119 | | Events, or a PA-TNC Error attribute. If set (1), | 2120 | | the response MUST NOT include software inventory | 2121 | | evidence records and thus the response MUST be a | 2122 | | Software Identifier Inventory, a Software | 2123 | | Identifier Events, or a PA-TNC Error attribute. | 2124 | | | 2125 | Flags: Bit | Reserved for future use. This field MUST be set | 2126 | 3-7 - | to zero on transmission and ignored upon | 2127 | Reserved | reception. | 2128 | | | 2129 | Software | A 3-byte unsigned integer indicating the number | 2130 | Identifier | of Software Identifiers that follow. If this | 2131 | Count | value is non-zero, this is a targeted request, as | 2132 | | described in Section 3.3. The Software | 2133 | | Identifier Length and Software ID fields are | 2134 | | repeated, in order, the number of times indicated | 2135 | | in this field. In the case where Software | 2136 | | Identifiers are present, the SW-PC MUST only | 2137 | | report software that corresponds to the | 2138 | | identifiers the SW-PV provided in this attribute | 2139 | | (or with a PA-TNC Error attribute). This field | 2140 | | value MAY be 0, in which case there are no | 2141 | | instances of the Software Identifier Length and | 2142 | | Software ID fields. In this case, the SW-PV is | 2143 | | indicating an interest in all software inventory | 2144 | | evidence records on the endpoint (i.e., this is | 2145 | | not a targeted request). | 2146 | | | 2147 | Request ID | A value that uniquely identifies this SW Request | 2148 | | from a particular SW-PV. | 2149 | | | 2150 | Earliest EID | In the case where the SW-PV is requesting | 2151 | | software events, this field contains the EID | 2152 | | value of the earliest event the SW-PV wishes to | 2153 | | have reported. (Note - the report will be | 2154 | | inclusive of the event with this EID value.) In | 2155 | | the case where the SW-PV is requesting an | 2156 | | inventory, then this field MUST be 0. | 2157 | | (0x00000000) In the case where this field is non- | 2158 | | zero, the SW-PV is requesting events and the SW- | 2159 | | PC MUST respond using a Software Events, Software | 2160 | | Identifier Events, or a PA-TNC Error attribute. | 2161 | | In the case where this field is zero, the SW-PV | 2162 | | is requesting an inventory and the SW-PC MUST | 2163 | | respond using a Software Inventory, a Software | 2164 | | Identifier Inventory, or a PA-TNC Error | 2165 | | attribute. | 2166 | | | 2167 | Software | A 2-byte unsigned integer indicating the length | 2168 | Identifier | in bytes of the Software ID field. | 2169 | Length | | 2170 | | | 2171 | Software ID | A string containing the Software Identifier value | 2172 | | from a software inventory evidence record. This | 2173 | | field value MUST be normalized to Network Unicode | 2174 | | format, as described in Section 4.5. This string | 2175 | | MUST NOT be NULL terminated. | 2176 +---------------+---------------------------------------------------+ 2178 Table 4: SW Request Attribute Fields 2180 The SW-PV sends the SW Request attribute to a SW-PC to request the 2181 indicated information. Note that between the Result Type flag and 2182 the Earliest EID field, the SW-PC is constrained to a single possible 2183 SW Response attribute type (or a PA-TNC Error attribute) in its 2184 response to the request. 2186 The Subscribe and Clear Subscription flags are used to manage 2187 subscriptions for the requesting SW-PV on the receiving SW-PC. 2188 Specifically, an attribute with the Subscribe flag set seeks to 2189 establish a new subscription by the requesting SW-PV to the given SW- 2190 PC, while an attribute with the Clear Subscription flag seeks to 2191 delete all existing subscriptions by the requesting SW-PV on the 2192 given SW-PC. Note that, in the latter case, only the subscriptions 2193 associated with the Connection ID and the Posture Validator ID of the 2194 requester are deleted as described in Section 3.6.3. A newly 2195 established subscription has the parameters outlined in the Request 2196 attribute. Specifically, the Result Type flag indicates the type of 2197 result to send in fulfillment of the subscription, the value of the 2198 Earliest EID field indicates whether the fulfillment attributes list 2199 inventories or events, and the fields describing Software Identifiers 2200 (if present) indicate if and how a subscription is targeted. In the 2201 case that the SW-PC is unable or unwilling to comply with the SW-PV's 2202 request to establish or clear subscriptions, the SW-PC MUST respond 2203 with a PA-TNC Error attribute with the SW_SUBSCRIPTION_DENIED_ERROR 2204 error code. (Note that if the SW-PV requests that subscriptions be 2205 cleared but has no existing subscriptions, this is not an error.) 2207 An attribute requesting the establishment of a subscription is 2208 effectively doing double-duty, as it is a request for an immediate 2209 response from the SW-PC in addition to setting up the subscription. 2210 Assuming the SW-PC is willing to comply with the subscription it MUST 2211 send an appropriate response attribute to a request with the 2212 Subscribe flag set containing all requested information. The same is 2213 true of the Clear Subscription flag - assuming there is no error the 2214 SW-PC MUST generate a response attribute without regard to the 2215 presence of this flag in addition to clearing its subscription list. 2217 Both the Subscribe and Clear Subscription flags MAY be set in a 2218 single SW Request attribute. In the case where this request is 2219 successful, the end result MUST be equivalent to the SW-PC clearing 2220 its subscription list for the given SW-PV first and then creating a 2221 new subscription in accordance with the request parameters. (In 2222 other words, do not first create the new subscription and then clear 2223 all the subscriptions including the one that was just created.) In 2224 the case that the requested actions are successfully completed, the 2225 SW-PC MUST respond with a SW Response attribute. (The specific type 2226 of SW Response attribute depends on the Result Type and Earliest EID 2227 fields, as described above.) In the case where there is a failure 2228 that prevents some part this request from completing, the SW-PC MUST 2229 NOT add a new subscription, MUST NOT clear the old subscriptions, and 2230 the SW-PC MUST respond with a PA-TNC Error attribute. In other 2231 words, the SW-PC MUST NOT partially succeed at implementing such a 2232 request; either all actions succeed, or none succeed. 2234 The Earliest EID field is used to indicate whether the SW-PV is 2235 requesting an inventory or event list from the SW-PC. A value of 0 2236 (0x00000000) represents a request for inventory information. 2237 Otherwise, the SW-PV is requesting event information. For Earliest 2238 EID values other than 0, the SW-PC's response MUST respond with event 2239 records, as described in Section 3.5. Note that the request does not 2240 identify a particular EID Epoch, since responses can only include 2241 events in the SW-PC's current EID Epoch. 2243 The Software Identifier Count indicates the number of Software 2244 Identifiers in the attribute. This number might be any value between 2245 0 and 16,777,216, inclusive. A single Software Identifier is 2246 represented by the following fields: Software Identifier Length and 2247 Software ID. These fields are repeated a number of times equal to 2248 the Software Identifier Count. Note that this could be 0 times. The 2249 Software Identifier Length field indicates the number of bytes 2250 allocated to the Software ID field. The Software Identifier field 2251 contains a Software Identifier as describe in Section 3.2.1. The 2252 presence of one or more Software Identifiers is used by the SW-PV to 2253 indicate a targeted request, which seeks only inventories of or 2254 events affecting software corresponding to the given identifiers. 2255 The SW-PC MUST only report software that matched the Software 2256 Identifiers provided in the SW-PVs SW Request attribute. 2258 4.8. Software Identifier Inventory 2260 A SW-PC sends this attribute to a SW-PV to convey the inventory of 2261 the endpoint's Software Inventory Evidence Collection without the 2262 inclusion of software inventory evidence records. This list might 2263 represent a complete inventory or a targeted list of records, 2264 depending on the parameters in the SW-PV's request. A SW-PV MUST NOT 2265 send this attribute. The SW-PC either sends this attribute in 2266 fulfillment of an existing subscription where the establishing 2267 request has a Result Type of 1 and the Earliest EID is zero, or in 2268 direct response to a SW Request attribute where the Result Type is 1 2269 and the Earliest EID is zero. 2271 1 2 3 2272 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 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Flags | Software Identifier Count | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | Request ID Copy / Subscription ID | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | EID Epoch | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | Last EID | 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 | Record ID | 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 |Data Model Type| Software IdentifierLength |SW ID (var len)| 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | Software Locator Length | Software Locator (variable len) | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 Figure 7: Software Identifier Inventory Attribute 2291 +--------------+----------------------------------------------------+ 2292 | Field | Description | 2293 +--------------+----------------------------------------------------+ 2294 | Flags: Bit 0 | In the case that this attribute is sent in | 2295 | - | fulfillment of a subscription this bit MUST be set | 2296 | Subscription | (1). In the case that this attribute is a direct | 2297 | Fulfillment | response to a SW Request, this bit MUST be unset | 2298 | | (0). | 2299 | | | 2300 | Flags: Bit | Reserved for future use. This field MUST be set to | 2301 | 1-7 - | zero on transmission and ignored upon reception. | 2302 | Reserved | | 2303 | | | 2304 | Software | The number of Software Identifiers that follow. | 2305 | Identifier | This field is an unsigned integer. The Record ID, | 2306 | Count | Data Model Type, Software Identifier Length, SW | 2307 | | ID, Software Locator Length, and Software Locator | 2308 | | fields are repeated, in order, the number of times | 2309 | | indicated in this field. This field value MAY be | 2310 | | 0, in which case there are no instances of these | 2311 | | fields. | 2312 | | | 2313 | Request ID | In the case where this attribute is in direct | 2314 | Copy / | response to a SW Request attribute from a SW-PV, | 2315 | Subscription | this field MUST contain an exact copy of the | 2316 | ID | Request ID field from that SW Request. In the | 2317 | | case where this attribute is sent in fulfillment | 2318 | | of an active subscription, this field MUST contain | 2319 | | the Subscription ID of the subscription being | 2320 | | fulfilled by this attribute. | 2321 | | | 2322 | EID Epoch | The EID Epoch of the Last EID value. This field is | 2323 | | an unsigned 4-byte integer. | 2324 | | | 2325 | Last EID | The EID of the last event recorded by the SW-PC, | 2326 | | or 0 if the SW-PC has no recorded events. This | 2327 | | field is an unsigned 4-byte integer. | 2328 | | | 2329 | Record ID | A 4-byte, unsigned integer containing the Record | 2330 | | Identifier value from a software inventory | 2331 | | evidence record. | 2332 | | | 2333 | Data Model | A 1-byte unsigned integer containing an identifier | 2334 | Type | number from the Software Data Model IANA table | 2335 | | that identifies the data model of the reported | 2336 | | record. | 2337 | | | 2338 | Software | A 2-byte unsigned integer indicating the length in | 2339 | Identifier | bytes of the SW ID field. | 2340 | Length | | 2341 | | | 2342 | SW ID | A string containing the Software Identifier value | 2343 | | from a software inventory evidence record. This | 2344 | | field value MUST be normalized to Network Unicode | 2345 | | format, as described in Section 4.5. This string | 2346 | | MUST NOT be NULL terminated. | 2347 | | | 2348 | Software | A 2-byte unsigned integer indicating the length in | 2349 | Locator | bytes of the Software Locator field. | 2350 | Length | | 2351 | | | 2352 | Software | A string containing the Software Locator value. | 2353 | Locator | This is expressed as a URI. This field value MUST | 2354 | | be normalized to Network Unicode format as | 2355 | | described in Section 3.2.1.2. This string MUST NOT | 2356 | | be NULL terminated. | 2357 +--------------+----------------------------------------------------+ 2359 Table 5: Software Identifier Inventory Attribute Fields 2361 In the case that this attribute is sent in fulfillment of a 2362 subscription, the Subscription Fulfillment bit MUST be set (1). In 2363 the case that this attribute is sent in direct response to a SW 2364 Request, the Subscription Fulfillment bit MUST be unset (0). Note 2365 that the SW Response attribute sent in direct response to a SW 2366 Request that establishes a subscription (i.e., a subscription's 2367 establishing request) MUST be treated as a direct response to that SW 2368 Request (and thus the Subscription Fulfillment bit is unset). SW 2369 Response attributes are only treated as being in fulfillment of a 2370 subscription (i.e., Subscription Fulfillment bit set) if they are 2371 sent following a change event, as shown in Figure 3. 2373 The Software Identifier Count field indicates the number of Software 2374 Identifiers present in this inventory. Each Software Identifier is 2375 represented by the following set of fields: Record ID, Data Model 2376 Type, Software Identifier Length, SW ID, Software Locator Length, and 2377 Software Locator. These fields will appear once for each reported 2378 record. 2380 When responding directly to a SW Request attribute, the Request ID 2381 Copy / Subscription ID field MUST contain an exact copy of the 2382 Request ID field from that SW Request. When this attribute is sent 2383 in fulfillment of an existing subscription on this Posture Collector, 2384 then this field MUST contain the Subscription ID of the fulfilled 2385 subscription. 2387 The EID Epoch field indicates the EID Epoch of the Last EID value. 2388 The Last EID field MUST contain the EID of the last recorded change 2389 event (see Section 3.5 for more about EIDs and recorded events) at 2390 the time this inventory was collected. In the case where there are 2391 no recorded change events at the time that this inventory was 2392 collected, the Last EID field MUST contain 0. These fields can be 2393 interpreted to indicate that the provided inventory reflects the 2394 state of the endpoint after all changes up to and including this last 2395 event have been accounted for. 2397 4.9. Software Identifier Events 2399 A SW-PC sends this attribute to a SW-PV to convey events where the 2400 affected records are reported without software inventory evidence 2401 records. A SW-PV MUST NOT send this attribute. The SW-PC either 2402 sends this attribute in fulfillment of an existing subscription where 2403 the establishing request has a Result Type is 1 and the Earliest EID 2404 is non-zero, or in direct response to a SW Request attribute where 2405 the Result Type is 1 and the Earliest EID is non-zero. 2407 1 2 3 2408 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 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2410 | Flags | Event Count | 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 | Request ID Copy / Subscription ID | 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 | EID Epoch | 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 | Last EID | 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 | Last Consulted EID | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | EID | 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | Timestamp | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | Timestamp | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | Timestamp | 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | Timestamp | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | Timestamp | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | Record ID | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | Action |Data Model Type| Software Identifier Length | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Software Locator Length | Software Identifier (var len) | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Software Locator (variable length) | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 Figure 8: Software Identifier Events Attribute 2443 +--------------+----------------------------------------------------+ 2444 | Field | Description | 2445 +--------------+----------------------------------------------------+ 2446 | Flags: Bit 0 | In the case that this attribute is sent in | 2447 | - | fulfillment of a subscription this bit MUST be set | 2448 | Subscription | (1). In the case that this attribute is a direct | 2449 | Fulfillment | response to a SW Request, this bit MUST be unset | 2450 | | (0). | 2451 | | | 2452 | Flags: Bit | Reserved for future use. This field MUST be set to | 2453 | 1-7 - | zero on transmission and ignored upon reception. | 2454 | Reserved | | 2455 | | | 2456 | Event Count | The number of events that are reported in this | 2457 | | attribute. This field is a 3-byte unsigned | 2458 | | integer. The EID, Timestamp, Record ID, Action, | 2459 | | Data Model Type, Software Identifier Length, | 2460 | | Software Locator Length, Software Identifier, and | 2461 | | Software Locator fields are repeated, in order, | 2462 | | the number of times indicated in this field. This | 2463 | | field value MAY be 0, in which case there are no | 2464 | | instances of these fields. | 2465 | | | 2466 | Request ID | In the case where this attribute is in direct | 2467 | Copy / | response to a SW Request attribute from a SW-PV, | 2468 | Subscription | this field MUST contain an exact copy of the | 2469 | ID | Request ID field from that SW Request. In the | 2470 | | case where this attribute is sent in fulfillment | 2471 | | of an active subscription, this field MUST contain | 2472 | | the Subscription ID of the subscription being | 2473 | | fulfilled by this attribute. | 2474 | | | 2475 | EID Epoch | The EID Epoch of the Last EID value. This field is | 2476 | | an unsigned 4-byte integer. | 2477 | | | 2478 | Last EID | The EID of the last event recorded by the SW-PC, | 2479 | | or 0 if the SW-PC has no recorded events. This | 2480 | | field contains the EID of the SW-PC's last | 2481 | | recorded change event (which might or might not be | 2482 | | included as an event record in this attribute). | 2483 | | | 2484 | Last | The EID of the last event record that was | 2485 | Consulted | consulted when generating the event record list | 2486 | EID | included in this attribute. This is different from | 2487 | | the Last EID field value if and only if this | 2488 | | attribute is conveying a partial list of event | 2489 | | records. See Section 3.5.5 for more on partial | 2490 | | list of event records. | 2491 | | | 2492 | EID | The EID of the event in this event record. | 2493 | | | 2494 | Timestamp | The timestamp associated with the event in this | 2495 | | event record. This timestamps is the SW-PC's best | 2496 | | understanding of when the given event occurred. | 2497 | | Note that this timestamp might be an estimate. | 2498 | | The Timestamp date and time MUST be represented as | 2499 | | an RFC 3339 [5] compliant ASCII string in | 2500 | | Coordinated Universal Time (UTC) time with the | 2501 | | additional restrictions that the 'T' delimiter and | 2502 | | the 'Z' suffix MUST be capitalized and fractional | 2503 | | seconds (time-secfrac) MUST NOT be included. This | 2504 | | field conforms to the date-time ABNF production | 2505 | | from section 5.6 of RFC 3339 [RFC3339] with the | 2506 | | above restrictions. Leap seconds are permitted | 2507 | | and SW-PVs MUST support them. The Timestamp | 2508 | | string MUST NOT be NULL terminated or padded in | 2509 | | any way. The length of this field is always 20 | 2510 | | octets. | 2511 | | | 2512 | Record ID | A 4-byte, unsigned integer containing the Record | 2513 | | Identifier value from a software inventory | 2514 | | evidence record. | 2515 | | | 2516 | Action | The type of event that is recorded in this event | 2517 | | record. Possible values are: 1 = CREATION - the | 2518 | | addition of a record to the endpoint's Software | 2519 | | Inventory Evidence Collection; 2 = DELETION - the | 2520 | | removal of a record from the endpoint's Software | 2521 | | Inventory Evidence Collection; 3 = ALTERATION - | 2522 | | There was an alteration to a record within the | 2523 | | endpoint's Software Inventory Evidence Collection. | 2524 | | All other values are reserved for future use and | 2525 | | MUST NOT be used when sending attributes. In the | 2526 | | case where a SW-PV receives an event record that | 2527 | | uses an action value other than the ones defined | 2528 | | here, it MUST ignore that event record but SHOULD | 2529 | | process other event records in this attribute as | 2530 | | normal. | 2531 | | | 2532 | Data Model | A 1-byte unsigned integer containing an identifier | 2533 | Type | number from the Software Data Model IANA table | 2534 | | that identifies the data model of the reported | 2535 | | record. | 2536 | | | 2537 | Software | A 2-byte unsigned integer indicating the length in | 2538 | Identifier | bytes of the Software Identifier field. | 2539 | Length | | 2540 | | | 2541 | Software | A 2-byte unsigned integer indicating the length in | 2542 | Locator | bytes of the Software Locator field. | 2543 | Length | | 2544 | | | 2545 | Software | A string containing the Software Identifier value | 2546 | Identifier | from a software inventory evidence record. This | 2547 | | field value MUST be normalized to Network Unicode | 2548 | | format, as described in Section 4.5. This string | 2549 | | MUST NOT be NULL terminated. | 2550 | | | 2551 | Software | A string containing the Software Locator value. | 2552 | Locator | This is expressed as a URI. This field value MUST | 2553 | | be normalized to Network Unicode format as | 2554 | | described in Section 3.2.1.2. This string MUST NOT | 2555 | | be NULL terminated. | 2556 +--------------+----------------------------------------------------+ 2558 Table 6: Software Identifier Events Attribute Fields 2560 The first few fields in the Software Identifier Events attribute 2561 mirror those in the Software Identifier Inventory attribute. The 2562 primary difference is that, instead of conveying an inventory, the 2563 attribute conveys zero or more event records, consisting of the EID, 2564 timestamp, Record ID, action type, data model type, Software 2565 Identifier, and Software Locator of the affected software inventory 2566 evidence record. 2568 With regard to the Timestamp field, it is important to note that 2569 clock skew between the SW-PC and SW-PV as well as between different 2570 SW-PCs within an enterprise might make correlation of timestamp 2571 values difficult. This specification does not attempt to resolve 2572 clock skew issues, although other mechanisms outside of this 2573 specification do exist to reduce the impact of clock skew and make 2574 the timestamp more useful for such correlation. Instead, Software 2575 Inventory Message and Attributes for PA-TNC uses Timestamp value 2576 primarily as a means to indicate the amount of time between two 2577 events on a single endpoint. For example, by taking the difference 2578 of the times for when a record was removed and then subsequently re- 2579 added, one can get an indication as to how long the system was 2580 without the given record (and, thus without the associated software). 2581 Since this will involve comparison of timestamp values all 2582 originating on the same system, clock skew between the SW-PC and SW- 2583 PV is not an issue. However, if the SW-PC's clock was adjusted 2584 between two recorded events, it is possible for such a calculation to 2585 lead to incorrect understandings of the temporal distance between 2586 events. Users of this field need to be aware of the possibility for 2587 such occurrences. In the case where the Timestamp values of two 2588 events appear to contradict the EID ordering of those events (i.e., 2589 the later EID has an earlier timestamp) the recipient MUST treat the 2590 EID ordering as correct. 2592 All events recorded in a Software Identifier Events Attribute are 2593 required to be part of the same EID Epoch. Specifically, all 2594 reported events MUST have an EID from the same EID Epoch as each 2595 other, and which is the same as the EID Epoch of the Last EID and 2596 Last Consulted EID values. The SW-PC MUST NOT report events with 2597 EIDs from different EID Epochs. 2599 The Last Consulted EID field contains the EID of the last event 2600 record considered for inclusion in this attribute. If this attribute 2601 contains a partial event set (as described in Section 3.5.5) this 2602 field value will be less than the Last EID value; if this attribute 2603 contains a complete event set, the Last EID and Last Consulted EID 2604 values are identical. 2606 If multiple events are sent in a Software Identifier Events 2607 attribute, the order in which they appear within the attribute is not 2608 significant. The EIDs associated with them are used for ordering the 2609 indicated events appropriately. Also note that a single software 2610 record might be reported multiple times in an attribute, such as if 2611 multiple events involving the associated record were being reported. 2613 4.10. Software Inventory 2615 A SW-PC sends this attribute to a SW-PV to convey a list of inventory 2616 records. A SW-PV MUST NOT send this attribute. The SW-PC either 2617 sends this attribute in fulfillment of an existing subscription where 2618 the establishing request had a Result Type of 0 and the Earliest EID 2619 is zero, or in direct response to a SW Request attribute where the 2620 Result Type is 0 and the Earliest EID is zero. 2622 1 2 3 2623 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 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2625 | Flags | Record Count | 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 | Request ID Copy / Subscription ID | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 | EID Epoch | 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 | Last EID | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | Record ID | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Software Identifier Length | Software Locator Length | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | Record Length | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 |Data Model Type| Software Identifier (variable length) | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | Software Locator (Variable length) | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | Record (Variable length) | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 Figure 9: Software Inventory Attribute 2648 +--------------+----------------------------------------------------+ 2649 | Field | Description | 2650 +--------------+----------------------------------------------------+ 2651 | Flags: Bit 0 | In the case that this attribute is sent in | 2652 | - | fulfillment of a subscription this bit MUST be set | 2653 | Subscription | (1). In the case that this attribute is a direct | 2654 | Fulfillment | response to a SW Request, this bit MUST be unset | 2655 | | (0). | 2656 | | | 2657 | Flags: Bit | Reserved for future use. This field MUST be set to | 2658 | 1-7 - | zero on transmission and ignored upon reception. | 2659 | Reserved | | 2660 | | | 2661 | Record Count | The number of records that follow. This field is a | 2662 | | 3-byte unsigned integer. The Record ID, Software | 2663 | | Identifier Length, Software Locator Length, Record | 2664 | | Length, Data Model Type, Software Identifier, | 2665 | | Software Locator, and Record fields are repeated, | 2666 | | in order, the number of times indicated in this | 2667 | | field. This field value MAY be 0 in which case | 2668 | | there are no instances of these fields. | 2669 | | | 2670 | Request ID | In the case where this attribute is in direct | 2671 | Copy / | response to a SW Request attribute from a SW-PV, | 2672 | Subscription | this field MUST contain an exact copy of the | 2673 | ID | Request ID field from that SW Request. In the | 2674 | | case where this attribute is sent in fulfillment | 2675 | | of an active subscription, this field MUST contain | 2676 | | the Subscription ID of the subscription being | 2677 | | fulfilled by this attribute. | 2678 | | | 2679 | EID Epoch | The EID Epoch of the Last EID value. This field is | 2680 | | an unsigned 4-byte integer. | 2681 | | | 2682 | Last EID | The EID of the last event recorded by the SW-PC, | 2683 | | or 0 if the SW-PC has no recorded events. This | 2684 | | field is an unsigned 4-byte integer. | 2685 | | | 2686 | Record ID | A 4-byte, unsigned integer containing the Record | 2687 | | Identifier value from a software inventory | 2688 | | evidence record. | 2689 | | | 2690 | Software | A 2-byte unsigned integer indicating the length in | 2691 | Identifier | bytes of the Software Identifier field. | 2692 | Length | | 2693 | | | 2694 | Software | A 2-byte unsigned integer indicating the length in | 2695 | Locator | bytes of the Software Locator field. | 2696 | Length | | 2697 | | | 2698 | Record Len | This is a 4-byte unsigned integer indicating the | 2699 | | length of the Record field in bytes. | 2700 | | | 2701 | Data Model | A 1-byte unsigned integer containing an identifier | 2702 | Type | number from the Software Data Model IANA table | 2703 | | that identifies the data model of the reported | 2704 | | record. | 2705 | | | 2706 | Software | A string containing the Software Identifier value | 2707 | Identifier | from a software inventory evidence record. This | 2708 | | field value MUST be normalized to Network Unicode | 2709 | | format, as described in Section 4.5. This string | 2710 | | MUST NOT be NULL terminated. | 2711 | | | 2712 | Software | A string containing the Software Locator value. | 2713 | Locator | This is expressed as a URI. This field value MUST | 2714 | | be normalized to Network Unicode format as | 2715 | | described in Section 3.2.1.2. This string MUST NOT | 2716 | | be NULL terminated. | 2717 | | | 2718 | Record | A software inventory evidence record as a string. | 2719 | | The record MUST be converted and normalized to | 2720 | | Network Unicode format, as described in Section | 2721 | | 4.5. This string MUST NOT be NULL terminated. | 2722 +--------------+----------------------------------------------------+ 2724 Table 7: Software Inventory Attribute Fields 2726 The Software Inventory attribute contains some number of software 2727 inventory evidence records along with the core response attribute 2728 fields. Given that the size of records can vary considerably, the 2729 length of this attribute is highly variable and, if transmitting a 2730 complete inventory, can be extremely large. Enterprises might wish 2731 to constrain the use of Software Inventory attributes to targeted 2732 requests to avoid over-burdening the network unnecessarily. 2734 When copying a software inventory evidence record into the Record 2735 field, the record MUST be converted and normalized to use Network 2736 Unicode format prior to its inclusion in the record field. 2738 4.11. Software Events 2740 A SW-PC sends this attribute to a SW-PV to convey a list of events 2741 that include software inventory evidence records. A SW-PV MUST NOT 2742 send this attribute. The SW-PC either sends this attribute in 2743 fulfillment of an existing subscription where the establishing 2744 request has a Result Type of 0 and the Earliest EID is non-zero, or 2745 in direct response to a SW Request attribute where the Result Type is 2746 0 and the Earliest EID is non-zero. 2748 1 2 3 2749 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 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 | Flags | Event Count | 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | Request ID Copy / Subscription ID | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 | EID Epoch | 2756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 | Last EID | 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 | Last Consulted EID | 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2761 | EID | 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | Timestamp | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | Timestamp | 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 | Timestamp | 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 | Timestamp | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | Timestamp | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 | Record Identifier | 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | Software Identifier Length | Software Locator Length | 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | Record Length | 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | Action |Data Model Type| Software Identifier (var len) | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | Software Locator (Variable Length) | 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | Record (Variable Length) | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 Figure 10: Software Events Attribute 2788 +--------------+----------------------------------------------------+ 2789 | Field | Description | 2790 +--------------+----------------------------------------------------+ 2791 | Flags: Bit 0 | In the case that this attribute is sent in | 2792 | - | fulfillment of a subscription this bit MUST be set | 2793 | Subscription | (1). In the case that this attribute is a direct | 2794 | Fulfillment | response to a SW Request, this bit MUST be unset | 2795 | | (0). | 2796 | | | 2797 | Flags: Bit | Reserved for future use. This field MUST be set to | 2798 | 1-7 - | zero on transmission and ignored upon reception. | 2799 | Reserved | | 2800 | | | 2801 | Event Count | The number of events being reported in this | 2802 | | attribute. This field is a 3-byte unsigned | 2803 | | integer. The EID, Timestamp, Record Identifier, | 2804 | | Software Identifier Length, Software Locator | 2805 | | Length, Record Length, Action, Data Model Type, | 2806 | | Software Identifier, Software Locator, and Record | 2807 | | fields are repeated, in order, the number of times | 2808 | | indicated in this field. This field value MAY be | 2809 | | 0, in which case there are no instances of these | 2810 | | fields. | 2811 | | | 2812 | Request ID | In the case where this attribute is in direct | 2813 | Copy / | response to a SW Request attribute from a SW-PV, | 2814 | Subscription | this field MUST contain an exact copy of the | 2815 | ID | Request ID field from that SW Request. In the | 2816 | | case where this attribute is sent in fulfillment | 2817 | | of an active subscription, this field MUST contain | 2818 | | the Subscription ID of the subscription being | 2819 | | fulfilled by this attribute. | 2820 | | | 2821 | EID Epoch | The EID Epoch of the Last EID value. This field is | 2822 | | an unsigned 4-byte integer. | 2823 | | | 2824 | Last EID | The EID of the last event recorded by the SW-PC, | 2825 | | or 0 if the SW-PC has no recorded events. This | 2826 | | field contains the EID of the SW-PC's last | 2827 | | recorded change event (which might or might not be | 2828 | | included as an event record in this attribute). | 2829 | | | 2830 | Last | The EID of the last event record that was | 2831 | Consulted | consulted when generating the event record list | 2832 | EID | included in this attribute. This is different from | 2833 | | the Last EID field value if and only if this | 2834 | | attribute is conveying a partial list of event | 2835 | | records. See Section 3.5.5 for more on partial | 2836 | | list of event records. | 2837 | | | 2838 | EID | The EID of the event in this event record. | 2839 | | | 2840 | Timestamp | The timestamp associated with the event in this | 2841 | | event record. This timestamp is the SW-PC's best | 2842 | | understanding of when the given event occurred. | 2843 | | Note that this timestamp might be an estimate. | 2844 | | The Timestamp date and time MUST be represented as | 2845 | | an RFC 3339 [5] compliant ASCII string in | 2846 | | Coordinated Universal Time (UTC) time with the | 2847 | | additional restrictions that the 'T' delimiter and | 2848 | | the 'Z' suffix MUST be capitalized and fractional | 2849 | | seconds (time-secfrac) MUST NOT be included. This | 2850 | | field conforms to the date-time ABNF production | 2851 | | from section 5.6 of RFC 3339 [RFC3339] with the | 2852 | | above restrictions. Leap seconds are permitted | 2853 | | and SW-PVs MUST support them. The Timestamp | 2854 | | string MUST NOT be NULL terminated or padded in | 2855 | | any way. The length of this field is always 20 | 2856 | | octets. | 2857 | | | 2858 | Record | A 4-byte, unsigned integer containing the Record | 2859 | Identifier | Identifier value from a software inventory | 2860 | | evidence record. | 2861 | | | 2862 | Software | A 2-byte unsigned integer indicating the length in | 2863 | Identifier | bytes of the Software Identifier field. | 2864 | Length | | 2865 | | | 2866 | Software | A 2-byte unsigned integer indicating the length in | 2867 | Locator | bytes of the Software Locator field. | 2868 | Length | | 2869 | | | 2870 | Record Len | This is a 4-byte unsigned integer indicating the | 2871 | | length of the Record field in bytes. | 2872 | | | 2873 | Action | The type of event that is recorded in this event | 2874 | | record. Possible values are: 1 = CREATION - the | 2875 | | addition of a record to the endpoint's Software | 2876 | | Inventory Evidence Collection; 2 = DELETION - the | 2877 | | removal of a record from the endpoint's Software | 2878 | | Inventory Evidence Collection; 3 = ALTERATION - | 2879 | | There was an alteration to a record within the | 2880 | | endpoint's Software Inventory Evidence Collection. | 2881 | | All other values are reserved for future use and | 2882 | | MUST NOT be used when sending attributes. In the | 2883 | | case where a SW-PV receives an event record that | 2884 | | uses an action value other than the ones defined | 2885 | | here, it MUST ignore that event record but SHOULD | 2886 | | process other event records in this attribute as | 2887 | | normal. | 2888 | | | 2889 | Data Model | A 1-byte unsigned integer containing an identifier | 2890 | Type | number from the Software Data Model IANA table | 2891 | | that identifies the data model of the reported | 2892 | | record. | 2893 | | | 2894 | Software | A string containing the Software Identifier value | 2895 | Identifier | from a software inventory evidence record. This | 2896 | | field value MUST be normalized to Network Unicode | 2897 | | format, as described in Section 4.5. This string | 2898 | | MUST NOT be NULL terminated. | 2899 | | | 2900 | Software | A string containing the Software Locator value. | 2901 | Locator | This is expressed as a URI. This field value MUST | 2902 | | be normalized to Network Unicode format as | 2903 | | described in Section 3.2.1.2. This string MUST NOT | 2904 | | be NULL terminated. | 2905 | | | 2906 | Record | A software inventory evidence record as a string. | 2907 | | The record MUST be converted and normalized to | 2908 | | Network Unicode format, as described in Section | 2909 | | 4.5. This string MUST NOT be NULL terminated. | 2910 +--------------+----------------------------------------------------+ 2912 Table 8: Software Events Attribute Fields 2914 The fields of this attribute are used in the same way as the 2915 corresponding fields of the previous attributes. As with the 2916 Software Inventory attribute, a Software Events attribute can be 2917 quite large if many events have occurred following the event 2918 indicated by a request's Earliest EID. As such, it is recommended 2919 that the SW Request attributes only request full records be sent 2920 (Result Type set to 0) in a targeted request, thus constraining the 2921 response just to records that match a given set of Software 2922 Identifiers. 2924 As with the Software Identifier Events Attribute, this attribute MUST 2925 only contain event records with EIDs coming from the current EID 2926 Epoch of the SW-PC. 2928 As with the Software Inventory Attribute, the SW-PC MUST perform 2929 conversion and normalization of the record. 2931 4.12. Subscription Status Request 2933 A SW-PV sends this attribute to a SW-PC to request a list of active 2934 subscriptions for which the requesting SW-PV is the subscriber. A 2935 SW-PC MUST NOT send this attribute. 2937 This attribute has no fields. 2939 A SW-PC MUST respond to this attribute by sending a Subscription 2940 Status Response attribute (or a PA-TNC Error attribute if it is 2941 unable to correctly provide a response). 2943 4.13. Subscription Status Response 2945 A SW-PC sends this attribute to a SW-PV to report the list of active 2946 subscriptions for which the receiving SW-PV is the subscriber. A SW- 2947 PV MUST NOT send this attribute. 2949 1 2 3 2950 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 2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 | Status Flags | Subscription Record Count | 2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2954 | Flags | Software Identifier Count | 2955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2956 | Request ID | 2957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2958 | Earliest EID | 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | Software Identifier Length | Software ID (var length) | 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 Figure 11: Subscription Status Response Attribute 2965 +-----------------+-------------------------------------------------+ 2966 | Field | Description | 2967 +-----------------+-------------------------------------------------+ 2968 | Flags: Bit 0-7 | Reserved for future use. This field MUST be set | 2969 | - Reserved | to zero on transmission and ignored upon | 2970 | | reception. | 2971 | | | 2972 | Subscription | The number of subscription records that follow. | 2973 | Record Count | This field is a 3-byte unsigned integer. The | 2974 | | Flags, Software Identifier Count, Request ID, | 2975 | | Earliest EID, Software Identifier Length, and | 2976 | | Software ID fields are repeated, in order, the | 2977 | | number of times indicated in this field. This | 2978 | | field value MAY be 0 in which case there are no | 2979 | | instances of these fields. | 2980 | | | 2981 | Flags, Software | For each active subscription, these fields | 2982 | Identifier | contain an exact copy of the fields with the | 2983 | Count, Request | same name as provided in the subscription's | 2984 | ID, Earliest | establishing request. | 2985 | EID, Software | | 2986 | Identifier | | 2987 | Length, and | | 2988 | Software ID | | 2989 +-----------------+-------------------------------------------------+ 2991 Table 9: Subscription Status Response Fields 2993 A Subscription Status Response contains zero or more subscription 2994 records. Specifically, it MUST contain one subscription record for 2995 each active subscription associated with the party that sent the 2996 Subscription Status Request to which this attribute is a response. 2997 As described in Section 3.6.2, the SW-PC MUST use the requester's 2998 Connection ID and its Posture Validator ID to determine which 2999 subscriptions are associated with the requester. 3001 A SW-PC MUST send a Subscription Status Response attribute in 3002 response to a Subscription Status Request attribute. The only 3003 exception to this is if the SW-PC experiences an error condition that 3004 prevents it from correctly populating the Subscription Status 3005 Response attribute, in which case it MUST respond with a PA-TNC Error 3006 attribute appropriate to the type of error experienced. If there are 3007 no active subscriptions associated with the requesting party, the 3008 Subscription Status Response attribute will consist of its Status 3009 Flags field, a Subscription Record Count field with a value of 0, and 3010 no additional fields. 3012 Each subscription record included in a Subscription Status Response 3013 attribute duplicates the fields of a SW Request attribute that was 3014 the establishing request of a subscription. Note that the Request ID 3015 field in the record captures the Subscription ID associated with the 3016 given subscription record (since the Subscription ID is the same as 3017 the Request ID of the establishing request). Note also that if the 3018 establishing request is targeted, then its Record Count field will be 3019 non-zero and, within that subscription record, the Software 3020 Identifier Length and Software Identifier fields are repeated, in 3021 order, the number of times indicated in the Record Count field. As 3022 such, each subscription record can be different sizes. If the 3023 establishing request is not targeted (Record Count field is 0), the 3024 subscription record has no Software Identifier Length or Software 3025 Identifier fields. 3027 When a SW-PV compares the information received in a Subscription 3028 Status Response to its own records of active subscriptions it should 3029 be aware that the SW-PC might be unable to distinguish this SW-PV 3030 from other SW-PVs on the same NEA Server. As a result, it is 3031 possible that the SW-PC will report more subscription records than 3032 the SW-PV recognizes. For this reason, SW-PVs SHOULD NOT 3033 automatically assume that extra subscriptions reported in a 3034 Subscription Status Response indicate a problem. 3036 4.14. PA-TNC Error as Used by Software Inventory Message and Attributes 3037 for PA-TNC 3039 The PA-TNC Error attribute is defined in the PA-TNC specification 3040 [RFC5792], and its use here conforms to that specification. A PA-TNC 3041 Error can be sent due to any error in the PA-TNC exchange and might 3042 also be sent in response to error conditions specific to the Software 3043 Inventory Message and Attributes for PA-TNC exchange. The latter 3044 case utilizes error codes defined below. 3046 A PA-TNC Error attribute is sent instead of a SW Response attribute 3047 due to factors that prevent the reliable creation of a SW Response. 3048 As such, a SW-PC MUST NOT send both a PA-TNC Error attribute and a SW 3049 Response attribute in response to a single SW Request attribute. 3051 Table 10 lists the Error Code values for the PA-TNC Error attribute 3052 specific to the Software Inventory Message and Attributes for PA-TNC 3053 exchange. In all of these cases, the Error Code Vendor ID field MUST 3054 be set to 0x000000, corresponding to the IETF SMI Private Enterprise 3055 Number. The Error Information structures for each error type are 3056 described in the following subsections. 3058 Note that a message with a Software Inventory Message and Attributes 3059 for PA-TNC attribute might also result in an error condition covered 3060 by the Standard PA-TNC Error Codes defined in PA-TNC. For example, a 3061 SW Attribute might have an invalid parameter, leading to an error 3062 code of "Invalid Parameter". In this case, the SW-PC MUST use the 3063 appropriate PA-TNC Error Code value as defined in Section 4.2.8 of 3064 PA-TNC specification. 3066 +-----------------------+-------------------------------------------+ 3067 | Error Code Value | Description | 3068 +-----------------------+-------------------------------------------+ 3069 | 0x00000020 | SW_ERROR. This indicates a fatal error | 3070 | | (i.e., an error that precludes the | 3071 | | creation of a suitable response | 3072 | | attribute) other than the errors | 3073 | | described below but still specific to the | 3074 | | processing of SW Attributes. The | 3075 | | Description field SHOULD contain | 3076 | | additional diagnostic information. | 3077 | | | 3078 | 0x00000021 | SW_SUBSCRIPTION_DENIED_ERROR. This | 3079 | | indicates that the SW-PC denied the SW- | 3080 | | PV's request to establish a subscription. | 3081 | | The Description field SHOULD contain | 3082 | | additional diagnostic information. | 3083 | | | 3084 | 0x00000022 | SW_RESPONSE_TOO_LARGE_ERROR. This | 3085 | | indicates that the SW-PC's response to | 3086 | | the SW-PV's request was too large to be | 3087 | | serviced. The error information structure | 3088 | | indicates the largest possible size of a | 3089 | | response supported by the SW-PC (see | 3090 | | Section 4.14.2). The Description field | 3091 | | SHOULD contain additional diagnostic | 3092 | | information. | 3093 | | | 3094 | 0x00000023 | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This | 3095 | | indicates that the SW-PC experienced an | 3096 | | error fulfilling a given subscription. | 3097 | | The error information includes the | 3098 | | Subscription ID of the relevant | 3099 | | subscription, as well as a sub-error that | 3100 | | describes the nature of the error the SW- | 3101 | | PC experienced. The SW-PC and SW-PV MUST | 3102 | | treat the identified subscription as | 3103 | | cancelled. | 3104 | | | 3105 | 0x00000024 | SW_SUBSCRIPTION_ID_REUSE_ERROR. This | 3106 | | indicates that the SW-PC received a SW | 3107 | | Request from a given SW-PV where the | 3108 | | Request ID of that SW Request is | 3109 | | currently used as the Subscription ID of | 3110 | | an active subscription with that SW-PV. | 3111 | | This error does not cancel the identified | 3112 | | subscription. | 3113 | | | 3114 | 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved | 3115 | | for use by future revisions of the | 3116 | | Software Inventory Message and Attributes | 3117 | | for PA-TNC specification. Any PA-TNC | 3118 | | Error attribute using one of these Error | 3119 | | Codes MUST be treated as indicating a | 3120 | | fatal error on the sender without further | 3121 | | interpretation. | 3122 +-----------------------+-------------------------------------------+ 3124 Table 10: PA-TNC Error Codes for Software Inventory Message and 3125 Attributes for PA-TNC 3127 The following subsections describe the structures present in the 3128 Error Information fields. 3130 4.14.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and 3131 SW_SUBSCRIPTION_ID_REUSE_ERROR Information 3133 The SW_ERROR error code indicates that the sender (the SW-PC) has 3134 encountered an error related to the processing of a SW Request 3135 attribute but which is not covered by more specific SW error codes. 3136 The SW_SUBSCRIPTION_DENIED_ERROR is used when the SW-PV requests to 3137 establish a subscription or clear all subscriptions from the given 3138 SW-PV, but the SW-PC is unable or unwilling to comply with this 3139 request. The SW_SUBSCRIPTION_ID_REUSE_ERROR is used when the SW-PC 3140 receives a SW Request whose Request ID duplicates a Subscription ID 3141 of an active subscription with the request's sender. All of these 3142 error codes use the following error information structure. 3144 1 2 3 3145 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 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 | Copy of Request ID / Subscription ID | 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3149 | Description (variable length) | 3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3152 Figure 12: SW Error, Subscription Error, and Subscription ID Reuse 3153 Information 3155 +--------------+----------------------------------------------------+ 3156 | Field | Description | 3157 +--------------+----------------------------------------------------+ 3158 | Copy of | In the case that this error condition is generated | 3159 | Request ID / | in direct response to a SW Request attribute, this | 3160 | Subscription | field MUST contain an exact copy of the Request ID | 3161 | ID | field in the SW Request attribute that caused this | 3162 | | error. In the case that the attribute in question | 3163 | | is generated in fulfillment of an active | 3164 | | subscription, this field MUST contain the | 3165 | | Subscription ID of the subscription for which the | 3166 | | attribute was generated. (This is only possible | 3167 | | if the error code is SW_ERROR as the other errors | 3168 | | are not generated by subscription fulfillment.) | 3169 | | Note that, in this case, the indicated error | 3170 | | appears as a sub-error for a | 3171 | | SW_SUBSCRIPTION_FULFILLMENT_ERROR, as described in | 3172 | | Section 4.14.3. | 3173 | | | 3174 | Description | A UTF-8 string describing the condition that | 3175 | | caused this error. This field MAY be 0-length. | 3176 | | However, senders SHOULD include some description | 3177 | | in all PA-TNC Error attributes of these types. | 3178 | | This field MUST NOT be NULL terminated. | 3179 +--------------+----------------------------------------------------+ 3181 Table 11: SW Error, Subscription Error, and Subscription ID Reuse 3182 Information Fields 3184 This error information structure is used with SW_ERROR, 3185 SW_SUBSCRIPTION_DENIED_ERROR, and SW_SUBSCRIPTION_ID_REUSE_ERROR 3186 status codes to identify the SW Request attribute that precipitated 3187 the error condition and to describe the error. The Description field 3188 contains text describing the error. The SW-PC MAY encode machine- 3189 interpretable information in this field, but SHOULD also include a 3190 human-readable description of the error, since the receiving SW-PV 3191 might not recognize the SW-PC's encoded information. 3193 4.14.2. SW_RESPONSE_TOO_LARGE_ERROR Information 3195 The SW_RESPONSE_TOO_LARGE_ERROR error code indicates that a response 3196 generated by a SW-PC in response to a SW-PV's SW Request attribute 3197 was too large to send. 3199 1 2 3 3200 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 3201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3202 | Copy of Request ID / Subscription I | 3203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 | Maximum Allowed Size | 3205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3206 | Description (variable length) | 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3209 Figure 13: SW Response Too Large Error Information 3211 +--------------+----------------------------------------------------+ 3212 | Field | Description | 3213 +--------------+----------------------------------------------------+ 3214 | Copy of | In the case that the attribute in question is | 3215 | Request ID / | generated in direct response to a SW Request, this | 3216 | Subscription | field MUST contain an exact copy of the Request ID | 3217 | ID | field in the SW Request attribute that caused this | 3218 | | error. In the case that the attribute in question | 3219 | | is generated in fulfillment of an active | 3220 | | subscription, this field MUST contain the | 3221 | | Subscription ID of the subscription for which the | 3222 | | attribute was generated. Note that, in the latter | 3223 | | case, the SW_RESPONSE_TOO_LARGE_ERROR appears as a | 3224 | | sub-error for a SW_SUBSCRIPTION_FULFILLMENT_ERROR, | 3225 | | as described in Section 4.14.3. | 3226 | | | 3227 | Maximum | This field MUST contain an unsigned integer | 3228 | Allowed Size | indicating the largest permissible size, in bytes, | 3229 | | of SW Attribute that the SW-PC is currently | 3230 | | willing to send in response to a SW Request | 3231 | | attribute. | 3232 | | | 3233 | Description | A UTF-8 string describing the condition that | 3234 | | caused this error. This field MAY be 0-length. | 3235 | | However, senders SHOULD include some description | 3236 | | in all PA-TNC Error attributes of these types. | 3237 | | This field MUST NOT be NULL terminated. | 3238 +--------------+----------------------------------------------------+ 3240 Table 12: SW Response Too Large Error Information Fields 3242 This error structure is used with the SW_RESPONSE_TOO_LARGE_ERROR 3243 status code to identify the SW Request attribute that precipitated 3244 the error condition and to describe the error. The Maximum Allowed 3245 Size field indicates the largest attribute the SW-PC is willing to 3246 send in response to a SW Request under the current circumstances. 3247 Note that under other circumstances, the SW-PC might be willing to 3248 return larger or smaller responses than indicated (such as if the 3249 endpoint connects to the NEA Server using a different network 3250 protocol). The other fields in this error information structure have 3251 the same meanings as corresponding fields in the SW_ERROR and 3252 SW_SUBSCRIPTION_DENIED_ERROR information structure. 3254 4.14.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information 3256 The SW_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the 3257 SW-PC encountered an error while fulfilling a subscription. The 3258 bytes after the first 4 octets duplicate a PA-TNC Error attribute (as 3259 described in Section 4.2.8 of PA-TNC) that is used to identify the 3260 nature of the encountered error. 3262 1 2 3 3263 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 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 | Subscription ID | 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 | Reserved | Sub Error Code Vendor ID | 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 | Sub Error Code | 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 | Sub Error Information (Variable Length) | 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3274 Figure 14: SW Subscription Fulfillment Error Information 3276 +--------------+----------------------------------------------------+ 3277 | Field | Description | 3278 +--------------+----------------------------------------------------+ 3279 | Subscription | This field MUST contain the Subscription ID of the | 3280 | ID | subscription whose fulfillment caused this error. | 3281 | | | 3282 | Reserved | This field MUST contain the value of the Reserved | 3283 | | field of a PA-TNC Error attribute that describes | 3284 | | the error condition encountered during | 3285 | | subscription processing. | 3286 | | | 3287 | Sub Error | This field MUST contain the value of the Error | 3288 | Code Vendor | Code Vendor ID field of a PA-TNC Error attribute | 3289 | ID | that describes the error condition encountered | 3290 | | during subscription processing. | 3291 | | | 3292 | Sub Error | This field MUST contain the value of the Error | 3293 | Code | Code field of a PA-TNC Error attribute that | 3294 | | describes the error condition encountered during | 3295 | | subscription processing. | 3296 | | | 3297 | Sub Error | This field MUST contain the value of the Error | 3298 | Information | Information field of a PA-TNC Error attribute that | 3299 | | describes the error condition encountered during | 3300 | | subscription processing. | 3301 +--------------+----------------------------------------------------+ 3303 Table 13: SW Subscription Fulfillment Error Information Fields 3305 This error structure is used with the 3306 SW_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets of 3307 this error structure contain the Subscription ID of the subscription 3308 that was being fulfilled when the error occurred. The remaining 3309 fields of this error structure duplicate the fields of a PA-TNC Error 3310 attribute, referred to as the "sub-error". The error code of the 3311 sub-error corresponds to the type of error that the SW-PC encountered 3312 while fulfilling the given subscription. The sub-error MUST NOT have 3313 an error code of SW_SUBSCRIPTION_FULFILLMENT_ERROR. 3315 The SW-PC sending a PA-TNC Error attribute with this error code, and 3316 the SW-PV receiving it, MUST treat the subscription identified by the 3317 Subscription ID field as cancelled. All other subscriptions are 3318 unaffected. 3320 5. Supported Data Models 3322 Software Inventory Message and Attributes for PA-TNC supports an 3323 extensible list of data models for representing and transmitting 3324 software inventory information. This list of data models appears in 3325 the Software Data Model IANA table (see Section 9.4). This document 3326 provides guidance for an initial set of data models. Other documents 3327 might provide guidance on the use of new data models by Software 3328 Inventory Message and Attributes for PA-TNC, and will be referenced 3329 by extensions to the Software Data Model IANA table. 3331 5.1. ISO 2015 SWID Tags using XML 3333 The International Organization for Standardization and the 3334 International Electrotechnical Commission (ISO/IEC) published the 3335 specification governing SWID tag construction and use in 2009 with a 3336 revised version published in 2015. [SWID] Since that time, a growing 3337 number of vendors have integrated SWID tags into their software 3338 products. Doing so significantly simplifies the task of identifying 3339 these pieces of software: instead of relying on discovery processes 3340 that look for clues as to software presence, such as the presence of 3341 particular files or registry keys, a readily available list of SWID 3342 tags provides simple and immediate evidence as to the presence of the 3343 given piece of software. 3345 SWID Message and Attributes for PA-TNC has no reliance on the 3346 presence or management of SWID tags on an endpoint as described in 3347 the ISO specification. However, the data model for describing 3348 software that is presented in the ISO specification provides a robust 3349 and comprehensive way of describing software and is adopted here as a 3350 means of representing and transmitting software information. It 3351 should be emphasized, the use of the ISO SWID tag data model makes no 3352 assumption as to whether the source of the recorded information was, 3353 in fact, an ISO SWID tag harvested from the endpoint or whether the 3354 information was created using some other source and normalized to the 3355 SWID format. 3357 5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags using 3358 XML 3360 TBD 3362 Don't violate the specification 3364 Use your own Tag Creator RegID or the Unknown Tag Creator RegID. Do 3365 not use some other party's RegID, especially not the RegID of the 3366 software author if you are not the author. 3368 5.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID 3369 Tags 3371 TBD 3373 Use combination of Tag Creator RegID and Unique ID fields. 3374 Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID, 3375 where NUMBER is the length of TAG_CREATOR_REGID in bytes. The rest 3376 of the Software Identifier MUST be the concatenation of the Tag 3377 Creator RegID and the Unique ID from the tag, without any connecting 3378 character or whitespace. 3380 5.2. ISO 2009 SWID Tags using XML 3382 As noted above, ISO's SWID tag specification provides a useful data 3383 model for representation of software information. As of the writing 3384 of this specification, while the 2015 specification is considered 3385 more comprehensive and addresses some issues with the 2009 3386 specification, 2009-format SWID tags remain far more common in 3387 deployments. For this reason, ISO 2009 SWID tags are included in the 3388 Software Data Model IANA table. 3390 5.2.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags using 3391 XML 3393 TBD 3395 Don't violate the specification 3397 Use your own Tag Creator RegID or the Unknown Tag Creator RegID. Do 3398 not use some other party's RegID, especially not the RegID of the 3399 software author if you are not the author. 3401 5.2.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID 3402 Tags 3404 TBD 3406 Use combination of Tag Creator RegID and Unique ID fields. 3407 Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID, 3408 where NUMBER is the length of TAG_CREATOR_REGID in bytes. The rest 3409 of the Software Identifier MUST be the concatenation of the Tag 3410 Creator RegID and the Unique ID from the tag, without any connecting 3411 character or whitespace. 3413 6. Security Considerations 3415 This section discusses some of the security threats facing Posture 3416 Collectors and Posture Validators that implement the Software 3417 Inventory Message and Attributes for PA-TNC protocol. This section 3418 primarily notes potential issues for implementers to consider, 3419 although it does contain a handful of normative requirements to 3420 address certain security issues. Implementers need to make the final 3421 decision as to how their implementations address the given issues. 3422 The issues identified below focus on capabilities specific to this 3423 document. Implementers are advised to consult other relevant NEA 3424 specifications for security issues that are applicable to such 3425 components in general. 3427 Reading the Security Considerations section of any well-written 3428 specification can be discouraging, as a long list of possible threats 3429 is catalogued. Keep in mind that no security measure is absolute, 3430 but each one can be beneficial. By understanding the weaknesses of 3431 each security measure, we can put in place countermeasures to protect 3432 against exploitation of these weaknesses. 3434 6.1. Evidentiary Value of Software Inventory Evidence Records 3436 It must be remembered that the accuracy of an endpoints Software 3437 Inventory Evidence Collection as an indicator of the endpoints 3438 software load and changes thereon is only as accurate as the tools 3439 that populate and manage the software inventory evidence records in 3440 this collection. Some tools might not be designed to update records 3441 in the Software Inventory Evidence Collection in real time resulting 3442 in a collection that is out-of-step with actual system state. 3443 Moreover, tools might inaccurately characterize software, or fail to 3444 properly record its removal. Finally, it is likely that there will 3445 be software on the endpoint that is not tracked by any source and 3446 thus is not reflected in the Software Inventory Evidence Collection. 3447 Users of collected software inventory evidence records need to 3448 understand that the information provided by the Software Inventory 3449 Message and Attributes for PA-TNC capability cannot be treated as 3450 completely accurate. Nonetheless, having endpoints report this 3451 information can still provide useful insights into the state of the 3452 endpoint's software load, and can alert administrators and policy 3453 tools of situations that require remediation. 3455 6.2. Sensitivity of Collected Records 3457 Software records on an endpoint are generally not considered to be 3458 sensitive, although there can be exceptions to this generalization as 3459 noted in the section on Privacy Considerations. In general, an 3460 endpoint's Software Inventory Evidence Collection can be browsed and 3461 individual records read by any party with access to the endpoint. 3462 This is generally not considered to be problematic, as those with 3463 access to the endpoint can usually learn of everything disclosed by 3464 that endpoint's records simply by inspecting other parts of the 3465 endpoint. 3467 The situation changes when an endpoint's inventory records are 3468 collected and stored off of the endpoint itself, such as on a NEA 3469 Server or CMDB. Inventory records represent a wealth of information 3470 about the endpoint in question and, for an adversary who does not 3471 already have access to the endpoint, a collection of the endpoint's 3472 inventory records might provide many details that are useful for 3473 mounting an attack. A list of the inventory records associated with 3474 an endpoint reveals a list of software installed on the endpoint. 3475 This list can be very detailed, noting specific versions and even 3476 patch levels, which an adversary can use to identify vulnerable 3477 software and design efficacious attacks. 3479 In addition, other information might also be gleaned from a 3480 collection of software inventory records: 3482 o An inventory record might include information about where the 3483 product was installed on a given endpoint. This can reveal 3484 details about the file organization of that endpoint that an 3485 attacker can utilize. 3487 o An inventory record might include information about how the 3488 software was provided to the endpoint, who in an organization 3489 signs off on the package release, and who packaged the product for 3490 installation. This information might be used as a starting point 3491 for the development of supply chain attacks. 3493 o Events affecting inventory records are reported with timestamps 3494 indicating when each given event occurred. This can give the 3495 attacker an indication of how quickly an organization distributes 3496 patches and updates, helping the attacker determine how long an 3497 attack window might remain open. 3499 Any consolidated software inventory is a potential risk, because such 3500 an inventory can provide an adversary an insight into the 3501 enterprise's configuration and management process. It is recommended 3502 that a centralized software inventory record collection be protected 3503 against unauthorized access. Mechanisms to accomplish this can 3504 include encrypting the data at rest, ensuring that access to the data 3505 is limited only to necessary individuals and processes, and other 3506 basic security precautions. 3508 6.3. Integrity of Endpoint Records 3510 SW-PCs maintain records of detected changes to the endpoint's 3511 Software Inventory Evidence Collection. These records are used to 3512 respond to a SW-PV's request for change events. The SW-PV might use 3513 a list of reported events to update its understanding of the 3514 endpoint's Software Inventory Evidence Collection without needing to 3515 receive a full inventory report from the SW-PC. For this reason, 3516 preserving the integrity of the SW-PC's record of events is extremely 3517 important. If an attacker modifies the SW-PC's record of changes to 3518 the endpoint's Software Inventory Evidence Collection, this might 3519 cause the SW-PV's understanding of the endpoint's Software Inventory 3520 Evidence Collection to differ from its actual state. Results might 3521 include leading the SW-PV to believe that absent software was 3522 present, that present software was absent, that patches have been 3523 installed even if this is not the case, or to be unaware of other 3524 changes to Software Inventory Evidence Records. As such, the SW-PC 3525 MUST take steps to protect the integrity of its event records. 3527 In addition, records of established SW-PV subscriptions also require 3528 protection against manipulation or corruption. If an attacker is 3529 able to modify or delete records of an established subscription by a 3530 SW-PV, the SW-PC might fail to correctly fulfill this subscription. 3531 The SW-PV would not be aware that its subscription was not being 3532 correctly fulfilled unless it received additional information that 3533 indicated a discrepancy. For example, the SW-PV might collect a full 3534 inventory and realize from this that certain events had not been 3535 correctly reported in accordance with an established subscription. 3536 For this reason, the SW-PC MUST protect the integrity of subscription 3537 records. 3539 6.4. SW-PC Access Permissions 3541 A SW-PC requires sufficient permissions to collect Software Inventory 3542 Evidence Records from all of its supported sources, as well as 3543 sufficient permissions to interact with the endpoint's Posture Broker 3544 Client. With regard to the former, this might require permissions to 3545 read the contents of directories throughout the file system. 3546 Depending on the operating environment and other activities 3547 undertaken by a SW-PC (or software that incorporates a SW-PC as one 3548 of its capabilities) additional permissions might be required by the 3549 SW-PC software. The SW-PC SHOULD NOT be granted permissions beyond 3550 what it needs in order to fulfill its duties. 3552 6.5. Sanitization of Record Fields 3554 Not all sources of software inventory evidence are necessarily 3555 tightly controlled. For example, consider a source that gathers 3556 .swid files from the endpoint's file system. Any party could create 3557 a new .swid file that could be collected and turned into a Software 3558 Inventory Evidence Record. As a result, it is important that the 3559 contents of source information not be automatically trusted. In 3560 particular, tools that read source information and the Software 3561 Inventory Evidence Records derived therefrom, including SW-PCs, need 3562 to be careful to sanitize input to prevent buffer overflow attacks, 3563 encoding attacks, and other weaknesses that might be exploited by an 3564 adversary who can control the contents of a record. 3566 6.6. PA-TNC Security Threats 3568 In addition to the aforementioned considerations the Software 3569 Inventory Message and Attributes for PA-TNC protocol is subject to 3570 the same security threats as other PA-TNC transactions, as noted in 3571 Section 5.2 of PA-TNC [RFC5792]. These include, but are not limited 3572 to, attribute theft, message fabrication, attribute modification, 3573 attribute replay, attribute insertion, and denial of service. 3574 Implementers are advised to consult the PA-TNC specification to 3575 better understand these security issues. 3577 7. Privacy Considerations 3579 As noted in Section 6.2, if an adversary can gain an understanding of 3580 the software installed on an endpoint, they can utilize this to 3581 launch attacks and maintain footholds on this endpoint. For this 3582 reason, the NEA Server needs to ensure adequate safeguards are in 3583 place to prevent exposure of collected inventory records. For 3584 similar reasons, it is advisable that an endpoint only send records 3585 to a NEA Server that is authorized to receive this information and 3586 that can be trusted to safeguard this information after collection. 3588 8. Relationship to Other Specifications 3590 This specification makes frequent reference to and use of other 3591 specifications. This section describes these relationships. 3593 This specification is expected to participate in a standard NEA 3594 architecture. As such, it is expected to be used in conjunction with 3595 the other protocols used in a NEA exchange. In particular, SW 3596 Attributes are conveyed over PB-TNC [RFC5793], which is in turn 3597 conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP 3598 [RFC7171]). These protocols have an especially important role, as 3599 they are responsible for ensuring that attributes defined under this 3600 specification are delivered reliably, securely, and to the 3601 appropriate party. 3603 It is important to note that the Product Information, Numeric 3604 Version, and String Version attributes defined in the PA-TNC 3605 specification [RFC5792] are also meant to convey information about 3606 installed applications and the versions thereof. As such, there is 3607 some conceptual overlap between those attributes and the intent of 3608 this specification. However, PA-TNC was designed to respond to very 3609 specific queries about specific classes of products, while the 3610 Software Inventory Message and Attributes for PA-TNC specification is 3611 able to convey a broader query, resulting in a more comprehensive set 3612 of evidence regarding an endpoint's installed software. As such, 3613 this specification provides important capabilities not present in the 3614 PA-TNC specification. 3616 9. IANA Considerations 3618 This section extends multiple existing IANA registries. 3619 Specifically, it extends the PA-TNC Attribute Types and PA-TNC Error 3620 Codes defined in the PA-TNC specification [RFC5792] and the PA- 3621 Subtypes registry defined in the PB-TNC specification [RFC5793] and 3622 extended in PA-TNC. This specification only adds values to these 3623 registries and does not alter how these registries work or are 3624 maintained. Consult the appropriate specifications for details on 3625 the operations and maintenance of these registries. 3627 9.1. Registry for PA-TNC Attribute Types 3629 Section 4.4 of this specification defines several new PA-TNC 3630 attributes. The following values are added to the registry for PA- 3631 TNC Attribute Types defined in the PA-TNC specification. Note that 3632 Table 3 in Section 4.4 lists these attributes but uses a hexadecimal 3633 value to identify their associated integer. The integer values given 3634 in that table are identical to those provided here. Note also that 3635 Table 3 includes an entry for PA-TNC Error attributes, but the IANA 3636 information associated with that attribute is already defined in the 3637 PA-TNC specification and is not reproduced here. 3639 +-----+---------+-------------------+-------------------------------+ 3640 | PEN | Integer | Name | Defining Specification | 3641 +-----+---------+-------------------+-------------------------------+ 3642 | 0 | 17 | SW Request | Software Inventory Message | 3643 | | | | and Attributes for PA-TNC | 3644 | | | | | 3645 | 0 | 18 | Software | Software Inventory Message | 3646 | | | Identifier | and Attributes for PA-TNC | 3647 | | | Inventory | | 3648 | | | | | 3649 | 0 | 19 | Software | Software Inventory Message | 3650 | | | Identifier Events | and Attributes for PA-TNC | 3651 | | | | | 3652 | 0 | 20 | Software | Software Inventory Message | 3653 | | | Inventory | and Attributes for PA-TNC | 3654 | | | | | 3655 | 0 | 21 | Software Events | Software Inventory Message | 3656 | | | | and Attributes for PA-TNC | 3657 | | | | | 3658 | 0 | 22 | Subscription | Software Inventory Message | 3659 | | | Status Request | and Attributes for PA-TNC | 3660 | | | | | 3661 | 0 | 23 | Subscription | Software Inventory Message | 3662 | | | Status Response | and Attributes for PA-TNC | 3663 | | | | | 3664 | 0 | 24 | Subscription | Software Inventory Message | 3665 | | | Status Response | and Attributes for PA-TNC | 3666 | | | | | 3667 | 0 | 25 - 31 | Reserved for | Software Inventory Message | 3668 | | | future use | and Attributes for PA-TNC | 3669 +-----+---------+-------------------+-------------------------------+ 3671 9.2. Registry for PA-TNC Error Codes 3673 Section 4.14 of this specification defines several new PA-TNC Error 3674 Codes. The following values are added to the registry for PA-TNC 3675 Error Codes defined in the PA-TNC specification. Note that Table 10 3676 in Section 4.14 lists these codes but uses a hexadecimal value to 3677 identify their associated integer. The integer values given in that 3678 table are identical to those provided here. 3680 +-----+---------+-----------------------------------+---------------+ 3681 | PEN | Integer | Name | Defining | 3682 | | | | Specification | 3683 +-----+---------+-----------------------------------+---------------+ 3684 | 0 | 32 | SW_ERROR | Software | 3685 | | | | Inventory | 3686 | | | | Message and | 3687 | | | | Attributes | 3688 | | | | for PA-TNC | 3689 | | | | | 3690 | 0 | 33 | SW_SUBSCRIPTION_DENIED_ERROR | Software | 3691 | | | | Inventory | 3692 | | | | Message and | 3693 | | | | Attributes | 3694 | | | | for PA-TNC | 3695 | | | | | 3696 | 0 | 34 | SW_RESPONSE_TOO_LARGE_ERROR | Software | 3697 | | | | Inventory | 3698 | | | | Message and | 3699 | | | | Attributes | 3700 | | | | for PA-TNC | 3701 | | | | | 3702 | 0 | 35 | SW_SUBSCRIPTION_FULFILLMENT_ERROR | Software | 3703 | | | | Inventory | 3704 | | | | Message and | 3705 | | | | Attributes | 3706 | | | | for PA-TNC | 3707 | | | | | 3708 | 0 | 36 | SW_SUBSCRIPTION_ID_REUSE_ERROR | Software | 3709 | | | | Inventory | 3710 | | | | Message and | 3711 | | | | Attributes | 3712 | | | | for PA-TNC | 3713 | | | | | 3714 | 0 | 37-47 | Reserved for future use | Software | 3715 | | | | Inventory | 3716 | | | | Message and | 3717 | | | | Attributes | 3718 | | | | for PA-TNC | 3719 +-----+---------+-----------------------------------+---------------+ 3721 9.3. Registry for PA Subtypes 3723 Section 4.1 of this specification defines one new PA Subtype. The 3724 following value is added to the registry for PA Subtypes defined in 3725 the PB-TNC specification. 3727 +-----+---------+------------+--------------------------------------+ 3728 | PEN | Integer | Name | Defining Specification | 3729 +-----+---------+------------+--------------------------------------+ 3730 | 0 | 9 | SW | Software Inventory Message and | 3731 | | | Attributes | Attributes for PA-TNC | 3732 +-----+---------+------------+--------------------------------------+ 3734 9.4. Registry for Software Data Models 3736 TBD 3738 10. References 3740 10.1. Normative References 3742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3743 Requirement Levels", BCP 14, RFC 2119, 3744 DOI 10.17487/RFC2119, March 1997, 3745 . 3747 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3748 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3749 . 3751 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3752 Resource Identifier (URI): Generic Syntax", STD 66, 3753 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3754 . 3756 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 3757 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 3758 . 3760 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 3761 Tardo, "Network Endpoint Assessment (NEA): Overview and 3762 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 3763 . 3765 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 3766 (PA) Protocol Compatible with Trusted Network Connect 3767 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 3768 . 3770 [SWID] The International Organization for Standardization/ 3771 International Electrotechnical Commission, "Information 3772 Technology - Software Asset Management - Part 2: Software 3773 Identification Tag, ISO/IEC 19770-2", November 2009. 3775 10.2. Informative References 3777 [NIST-SWID] 3778 The National Institute of Standards and Technology and The 3779 MITRE Corporation, "Guidelines for the Creation of 3780 Interoperable Software Identification (SWID) Tags", August 3781 2013. 3783 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 3784 A Posture Broker (PB) Protocol Compatible with Trusted 3785 Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, 3786 March 2010, . 3788 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 3789 Transport Protocol over TLS (PT-TLS)", RFC 6876, 3790 DOI 10.17487/RFC6876, February 2013, 3791 . 3793 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 3794 (PT) Protocol for Extensible Authentication Protocol (EAP) 3795 Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, 3796 . 3798 Authors' Addresses 3800 Chris Coffin 3801 The MITRE Corporation 3802 202 Burlington Road 3803 Bedford, MA 01730 3804 USA 3806 Email: ccoffin@mitre.org 3808 Daniel Haynes 3809 The MITRE Corporation 3810 202 Burlington Road 3811 Bedford, MA 01730 3812 USA 3814 Email: dhaynes@mitre.org 3815 Charles Schmidt 3816 The MITRE Corporation 3817 202 Burlington Road 3818 Bedford, MA 01730 3819 USA 3821 Email: cmschmidt@mitre.org 3823 Jessica Fitzgerald-McKay 3824 Department of Defense 3825 9800 Savage Road 3826 Ft. Meade, Maryland 3827 USA 3829 Email: jmfitz2@nsa.gov