PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)
Extracted elements (30)
Dynamic identifiers (assigned per-session Posture Collector/Validator IDs) were chosen over static identifiers to avoid the brittleness of a static model. Static IDs fail when two components share the same ID; dynamic IDs are broker-assigned and unique per session. The tradeoff is that directed routing requires at least one prior message exchange to learn the peer's dynamic identifier.
PB-TNC supports half-duplex operation to enable use over EAP-based PT protocols. Although half-duplex could slow multi-round-trip exchanges, endpoint assessments rarely involve many round trips or multimedia, so the benefit of broad transport compatibility outweighs the limitation. Full-duplex is additionally supported for re-initialization scenarios.
PB-TNC uses a compact binary TLV format rather than XML or text encoding to support low-bandwidth transports and low-power devices. The TLV structure also allows recipients to skip unrecognized messages by length without understanding their content.
Vendor IDs (SMI PENs) prefix all extensible value spaces (Message Types, PA Subtypes, Remediation Parameters Types, Error Codes) to allow vendor-specific extensions without central coordination. Vendor ID 0 means IANA-registered; non-zero values are managed by the owning vendor. Vendor-specific messages with unknown types are skipped unless NOSKIP is set.
A CRETRY message may be received while in the Server Working or Client Working state if the client sent CRETRY simultaneously with the server's decision. Similarly, SRETRY may be received in the Server Working state. These concurrent messages are redundant and MUST be ignored without causing a state change.
On half-duplex transports, the Posture Broker Server cannot send SRETRY from the Decided state because it sent the last batch (RESULT). Instead, the server must close the PT connection without a CLOSE batch and initiate a new PB-TNC session. This limitation does not apply when a full-duplex transport is used.
Both the Posture Broker Server and Posture Broker Client MUST follow the state machine defined in section 3.2. A CLOSE batch SHOULD be sent before terminating the underlying PT connection, though this may not always be possible.
If a batch is received with an invalid B-Type value, the recipient MUST ignore the batch and send a fatal Invalid Parameter error in a CLOSE batch. If the batch type is valid but not permitted in the current state, the recipient MUST send a fatal Unexpected Batch Type error in a CLOSE batch.
If a PB-TNC message has the NOSKIP flag set and a recipient cannot or will not process it, the recipient MUST NOT act on any part of the batch and MUST respond with a fatal Unsupported Mandatory Message error in a CLOSE batch. Recipients MAY scan all messages before acting on any to detect unsupported NOSKIP messages early.
If a receiver gets an unsupported Version value, it MUST respond with a CLOSE batch containing only a fatal Version Not Supported error, with the Version header field set to 2. Implementations responding to a supported version MUST use the same version number. Reserved version values 0x00, 0x09, 0x0a, 0x0d, 0x20, and 0x3c MUST NOT be used.
Implementations MUST send bits in each diagram from top to bottom and left to right within each 32-bit line. Multi-byte numeric fields MUST be transmitted in network (big endian) byte order.
PB-Experimental (message type 0, Vendor ID 0) MUST NOT be used in production environments or products. A production implementation receiving it MUST ignore it unless NOSKIP is set, in which case it MUST respond with a fatal Unsupported Mandatory Message error in a CLOSE batch.
PB-TNC Vendor ID 0xffffff is reserved: senders MUST NOT use it and receivers MUST respond with a fatal Invalid Parameter error in a CLOSE batch. PB-TNC Message Type 0xffffffff is similarly reserved with the same send/receive constraints.
PT MUST support mutual authentication of the Posture Transport Client and Server, confidentiality and integrity protection for PB-TNC batches, and replay attack protection. Additional PT requirements: connection-oriented with confirmed initiation/close (PT-6), binary data transport (PT-7), flow and congestion control (PT-8), and documented capability limitations for PB (PT-9).
The NOSKIP flag MUST be set in all PB-PA messages. Any receiver of a PB-PA message with NOSKIP not set MUST ignore the message and respond with a fatal Invalid Parameter error. All Posture Broker Client and Server implementations MUST support this message type.
The Posture Broker Server MUST assign a unique Posture Validator Identifier (not 0xffff) to each Posture Validator and that value MUST NOT change during a PT session. The Posture Broker Client similarly assigns Posture Collector Identifiers that MUST NOT change during the session. When EXCL is set, the relevant identifier field MUST be set to the target component.
The RESULT batch MUST include exactly one PB-Assessment-Result message and MUST NOT appear in any other batch type. The Posture Broker Client MUST NOT send this message type. The Posture Broker Client MUST implement and process this message and MUST ignore instances not in a RESULT batch.
When the FATAL flag is set in PB-Error, the recipient MUST terminate the PB-TNC session after processing the batch without sending any response. The sender of a fatal error MUST NOT process the triggering batch and MUST terminate after sending the CLOSE batch containing the error. Any PB-Error generated while processing a PB-Error MUST itself be fatal to avoid infinite error loops.
PB-TNC defines eight IETF Standard Message Types (Vendor ID 0): PB-Experimental (0, testing only), PB-PA (1, carries a PA message), PB-Assessment-Result (2), PB-Access-Recommendation (3), PB-Remediation-Parameters (4), PB-Error (5), PB-Language-Preference (6), and PB-Reason-String (7). Vendor-specific types use non-zero SMI PEN Vendor IDs.
PB-TNC defines six batch types encoded in the B-Type field: CDATA (1, client-to-server data), SDATA (2, server-to-client data), RESULT (3, server evaluation complete), CRETRY (4, client requests restart), SRETRY (5, server requests restart), CLOSE (6, session termination). Only the Posture Broker Client may send CDATA and CRETRY; only the Posture Broker Server may send SDATA, SRETRY, and RESULT.
This document creates four IANA registries: (1) PB-TNC Message Types (section 6.2), (2) PA Subtypes (section 6.3), (3) PB-TNC Remediation Parameters Types (section 6.4), and (4) PB-TNC Error Codes (section 6.5). All use Expert Review with Specification Required as the registration policy. Vendor ID 0 entries require IANA registration; non-zero Vendor ID values are vendor-managed via SMI PENs.
PB-TNC relies entirely on the underlying Posture Transport (PT) protocol for security services: mutual authentication of endpoints, confidentiality and integrity of batches, and replay attack prevention. The threat model identifies risks of endpoint impersonation, data interception, tampering, and replay. PB-TNC has no independent security mechanisms and is only as secure as the PT layer beneath it.
The PB-TNC session has five states: Init (start), Server Working, Client Working, Decided, and End (terminal). Transitions are triggered by batch types CDATA (client sends data), SDATA (server sends data), RESULT (server signals evaluation complete), CRETRY/SRETRY (restart exchange), and CLOSE (termination or PT disconnect). Both Posture Broker Client and Server MUST follow this state machine.
Each PB-TNC message has a TLV structure: Flags (8 bits, bit 0 = NOSKIP), PB-TNC Vendor ID (24 bits, SMI PEN, 0 = IETF), PB-TNC Message Type (32 bits), PB-TNC Message Length (32 bits, MUST be at least 12), and PB-TNC Message Value (variable length).
The PB-Access-Recommendation message value contains: Reserved (16 bits, MUST be 0) and Access Recommendation Code (16 bits): 1=Access Allowed, 2=Access Denied, 3=Quarantined. PB-TNC Message Length MUST be exactly 16. NOSKIP MUST NOT be set for this message type.
The PB-Assessment-Result message value contains a single 32-bit Assessment Result field: 0=compliant, 1=minor non-compliance, 2=significant non-compliance, 3=error determining compliance, 4=unable to determine. The PB-TNC Message Length MUST be exactly 16.
The PB-Error message value contains: Flags (8 bits, bit 0 = FATAL), Error Code Vendor ID (24 bits), Error Code (16 bits), Reserved (16 bits), and Error Parameters (variable). Minimum PB-TNC Message Length is 20. The NOSKIP flag MUST be set. A fatal PB-Error MUST always be sent in a CLOSE batch.
The PB-PA message value contains: Flags (8 bits, bit 0 = EXCL for exclusive delivery), PA Message Vendor ID (24 bits), PA Subtype (32 bits), Posture Collector Identifier (16 bits), Posture Validator Identifier (16 bits), and PA Message Body (variable). Total fixed-length fields are 12 octets; minimum PB-TNC Message Length for PB-PA is 24.
The PB-Remediation-Parameters message value contains: Reserved (8 bits), Remediation Parameters Vendor ID (24 bits), Remediation Parameters Type (32 bits), and Remediation Parameters (variable). Minimum PB-TNC Message Length is 20. IETF standard types: Remediation-URI (type 1, RFC 3986 URI) and Remediation-String (type 2, UTF-8 string with length and RFC 4646 language tag).
The PB-TNC batch header contains: Version (8 bits, MUST be 2), Directionality D (1 bit, 0=client, 1=server), Reserved (19 bits, MUST be 0), B-Type/Batch Type (4 bits), and Batch Length (32 bits, MUST be at least 8). All multi-byte numeric fields are in network (big endian) byte order.