Software Inventory Message and Attributes (SWIMA) for PA-TNC
Extracted elements (32)
EID Epoch values should not be assigned sequentially because loss of state (e.g., SWIMA-PC reverts to a snapshot) could cause an earlier sequential epoch value to be reused, destroying the ordering invariant. Non-sequential epoch generation (e.g., timestamp-based or random) minimizes the chance of reuse even after state loss.
Software Identifiers are intentionally small fractions of the full records, enabling bandwidth-efficient inventory exchanges. A SWIMA-PV can track software presence over time using only identifiers, requesting full records via targeted requests only when necessary. This design supports the scalability requirement for enterprises with tens of thousands of endpoints.
SWIMA does not standardize how software is detected or which sources populate the Software Inventory Evidence Collection, instead defining only the transport interface. This allows SWIMA to accommodate heterogeneous sources (SWID tags, package managers, discovery tools) without mandating a specific discovery mechanism, at the cost of potentially reporting the same software multiple times from different sources.
SWIMA operates exclusively over the PA-TNC interface (RFC 5792) within the NEA architecture (RFC 5209). It has no dependencies on the SACM architecture despite being developed to support it, and is usable wherever the NEA architecture is employed. The TNC and NEA architectures are interoperable and many components are equivalent.
SWIMA provides no confidentiality mechanism of its own. Confidentiality must be provided by the underlying NEA transport: PT-TLS (RFC 6876) binding to TLS, or PT-EAP (RFC 7171) for tunneled EAP methods. Implementors that deploy SWIMA without a confidentiality-providing transport expose sensitive software inventory data.
A record change MUST retain the same Software Identifier. Any action that changes the software product version MUST NOT be reflected by a record alteration but MUST result in deletion of the old record and creation of a new record.
A SWIMA-PC MUST completely support all requirements of this specification for every source of software inventory it uses; a potential source that cannot support some required functionality (e.g., change-event monitoring) MUST NOT be used at all, even if it could provide partial information.
A SWIMA-PC MUST NOT report events with EIDs from any Epoch other than the current EID Epoch. When a SWIMA-PV observes an Epoch change, it MUST obtain a full inventory to resynchronize before tracking further events.
All numeric values sent in SWIMA messages MUST be sent in network (big-endian) byte order.
All SWIMA-PCs MUST track the source of each piece of software information they report. For each source, the SWIMA-PC MUST assign an 8-bit unsigned Source Identifier and MUST deliver all information from that source with the same Source Identifier consistently throughout a PB-TNC session.
EID Epoch values MUST be generated to minimize the chance of reuse even when the SWIMA-PC reverts to an earlier state; sequential EID Epochs are discouraged. Within an Epoch, EIDs MUST be assigned sequentially, and two change events MUST NOT be assigned the same EID within the same Epoch.
Software Locator URIs MUST conform to RFC 3986. When expressing filesystem locations, the URI scheme MUST be 'file' and the URI MUST conform to RFC 8089, including percent-encoding of whitespace and special characters. If a location cannot be determined, the SWIMA-PC MUST provide a zero-length Software Locator.
SWIMA-PCs MUST accept targeted requests and limit their response to records matching the specified Software Identifier(s). Both SWIMA-PCs and SWIMA-PVs MUST support targeted requests for event records.
SWIMA-PCs MUST detect changes (creation, deletion, alteration) to the Software Inventory Evidence Collection in close to real time (within seconds) while operational, and MUST be able to determine net changes that occurred while the SWIMA-PC was not operational.
SWIMA-PVs MUST discard, without error, any SWIMA Response attributes they receive for which they do not know the corresponding SWIMA Request parameters, because the Request parameters control interpretation of the Response.
The SWIMA-PC MUST assign a unique Record Identifier (4-byte unsigned integer) to each record when it is added to the endpoint's Software Inventory Evidence Collection; the identifier SHOULD remain unchanged if the record is modified.
The SWIMA-PC MUST be able to generate a Software Identifier for each record it delivers; if it cannot, the record cannot be delivered. All SWIMA-PCs MUST at least be able to generate Software Identifiers for the data model types specified in Section 6.
The SWIMA-PC's event records MUST NOT contain coverage gaps. If undetected changes may have occurred, the SWIMA-PC MUST either compute a net change and update event records, or pick a new EID Epoch to signal a discontinuity.
The SWIMA-PV MUST NOT reject a message or respond with a PA-TNC Error due to the data model used to structure records in received attributes, nor if a record fails to comply with a stated format, unless that failure prevents correct parsing of the attribute itself.
Upon deletion of a record, the SWIMA-PC MUST retain a copy of the full deleted record along with its Record Identifier and Software Locator for a reasonable amount of time; the copy SHOULD be retained as long as the deletion event remains in the event log.
When sending software inventory information, the SWIMA-PC MUST include the complete set of relevant data from all supported sources and MUST NOT attempt to reduce or deduplicate records across sources, even if this results in multiple records for a single installed software instance.
Software inventory data reveals detailed information about an endpoint's configuration, which can be sensitive for both individuals and organizations. The NEA architecture allows an enterprise to collect comprehensive software inventory data; privacy protections must be considered in deployment, particularly when inventory data crosses trust boundaries.
Data Model Type: a two-field identifier composed of a Private Enterprise Number (PEN, 3 bytes) and a Data Model Type value (1 byte), together identifying the format of a software inventory record. The IANA PEN (0x000000) governs centrally registered types; values 0xC0–0xFF are reserved for local enterprise use.
Event Identifier (EID) and EID Epoch: each a 4-byte unsigned integer. The SWIMA-PC assigns EIDs sequentially within an Epoch to each observed inventory change event. EID value 0 is reserved: in a SWIMA Request it signals an inventory request; in a SWIMA Response it indicates the pre-event baseline state.
Software Identifier: an opaque string that uniquely identifies a specific version of a specific software product. It is derived deterministically from a Software Inventory Evidence Record using rules defined per data model type. The same software product may have multiple Software Identifiers if reported by different sources or data models.
Subscription mechanism: allows a SWIMA-PV to register with a SWIMA-PC for continuous or periodic push of inventory or event data. Subscriptions can be established, managed (including targeted subscriptions limited to specific Software Identifiers), and terminated; the SWIMA-PC fulfills subscriptions by sending SWIMA Response attributes.
SWIMA Request attribute: sent by the SWIMA-PV to request inventory or event data. Includes a Request ID (echoed in responses for matching), an EID field (0 for inventory, non-zero for events starting from that EID), and an optional list of Software Identifiers for targeted requests.
Four IANA registries are created or updated: (1) PA Subtypes — new SWIMA subtype added; (2) PA-TNC Attribute Types — new SWIMA attribute type codes registered; (3) PA-TNC Error Codes — new SWIMA-specific error codes (SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, SWIMA_SUBSCRIPTION_ID_REUSE_ERROR, SWIMA_RESPONSE_TOO_LARGE_ERROR, SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR); (4) Software Data Model Types — new registry for data model type values under the IANA PEN.
Integrity of endpoint records and SWIMA-PC access permissions must be protected. An attacker with access to the Software Inventory Evidence Collection can manipulate what is reported. SWIMA-PCs should operate with the minimum permissions necessary to access relevant data sources and record fields should be sanitized.
Software inventory data is highly sensitive: it reveals what software is installed, enabling adversaries to identify vulnerable software or attack vectors. Implementors MUST ensure that appropriate NEA transport mechanisms providing confidentiality (e.g., PT-TLS per RFC 6876 or PT-EAP per RFC 7171) are employed, as SWIMA itself provides no confidentiality.
SWIMA does not verify the accuracy of reported software inventory data; endpoints may report false information through malice or error. The specification focuses solely on correct and reliable transport of what is reported, not on attestation of truthfulness. Tools that employ SWIMA must implement their own verification mechanisms.
SWIMA defines nine attribute types layered on PA-TNC (RFC 5792): SWIMA Request, Software Identifier Inventory, Software Identifier Events, Software Inventory, Software Events, Subscription Status Request/Response, Source Metadata Request/Response, and PA-TNC Error extensions. All numeric fields are encoded in network (big-endian) byte order.