A Posture Transport Protocol over TLS (PT-TLS)
Extracted elements (35)
NEA Clients SHOULD proactively establish and hold open a TLS session to the NEA Server after obtaining network access, rather than listening for inbound server-initiated connections. Server-initiated sessions require the NEA Client to hold an X.509 certificate and expose inbound TCP ports, creating scalability, cost, and security-policy challenges.
Rather than integrating PT into the TLS handshake (which would require changes to widely deployed TLS implementations), PT-TLS was designed to layer on top of TLS as an application protocol using the standard application_data ContentType. This allowed existing TLS software to be reused and offered the fastest path to adoption.
TLV-based encoding was chosen to match the PA-TNC and PB-TNC protocols, enabling a common message-parsing code path and simplified debugging tools. TLV encoding also provides a space-efficient representation suitable for lower-powered or battery-constrained devices.
The Trusted Computing Group (TCG) will replace its existing proprietary posture transport protocols with new versions that are equivalent to and interoperable with the NEA specifications (PT-TLS and PT-EAP), aiming for a single unified set of endpoint assessment standards.
All implementations of PT-TLS MUST support full-duplex PT-TLS message exchange, allowing either party to send a PT-TLS message at any time.
All PT-TLS implementations compliant with this specification MUST at least support the PLAIN SASL mechanism (RFC 4616). Implementations MUST provide the EXTERNAL SASL mechanism if both parties authenticated during TLS establishment. Implementations MUST also support the case where no client authentication is required.
Implementations of PT-TLS MUST at least support the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. Implementations SHOULD NOT include anonymous Diffie-Hellman cipher suites (e.g., TLS_DH_anon_WITH_AES_128_CBC_SHA) that provide no server authentication. Implementations MUST support RFC 5746 (TLS renegotiation indication).
Implementations of PT-TLS SHOULD support TLS 1.2. At the time of writing TLS 1.0 and 1.1 offer the broadest interoperability.
NEA assessment messages (PB-TNC batches) MUST NOT be sent prior to the completion of the PT-TLS Negotiation phase. The PT-TLS Negotiation phase MUST NOT be repeated after the session has entered the Data Transport phase.
Once the TLS Setup phase completes (after TLS Finished messages), the TLS session MUST NOT be renegotiated. TLS session renegotiation MAY be used before the TLS Setup phase ends.
SASL security layers MUST be negotiated off during SASL authentication because PT-TLS always runs under TLS protection. The PT-TLS SASL service name is 'nea-pt-tls'.
The Message Identifier MUST be a monotonically increasing counter starting at zero per message sender per TLS session. The sender MUST roll over to zero upon reaching the 2^32nd message; recipients MUST handle rollover without generating errors.
The Message Length field MUST always be at least 16 (size of the PT-TLS header). Recipients receiving a Message Length less than 16 SHOULD respond with an Invalid Parameter PT-TLS Error Code.
The NEA Client MUST validate the server certificate according to RFC 5280 and MUST follow RFC 6125 when checking the server domain name. Wildcards MUST NOT appear in the DNS-ID or CN-ID of a PT-TLS server certificate; use of CN-IDs is NOT RECOMMENDED.
The NEA Server MUST always send an empty SASL Mechanisms TLV (with no mechanisms listed) as the last message of the PT-TLS Negotiation phase to signal transition to Data Transport. The NEA Client MUST NOT transition to the Data Transport phase until it receives this empty SASL Mechanisms TLV.
The Posture Validator MUST fail its verification of the endpoint if an NEA Asokan attack is detected (i.e., the tls-unique channel binding value provided by the EMA does not match the tls-unique value for the server's end of the connection).
The PT-TLS Initiator MUST send a Version Request message as its first PT-TLS message and MUST NOT send any other messages until it receives a Version Response or Error. Subsequent assessments on the same session MUST use the negotiated version and MUST NOT send additional version negotiation messages.
The PT-TLS Responder MUST possess a trustworthy X.509 certificate used to authenticate to the PT-TLS Initiator and bootstrap TLS session security. The PT-TLS Initiator MAY also present an X.509 certificate for bidirectional authentication.
When a PT-TLS error message is received, the recipient MUST NOT respond with another PT-TLS error, as this could cause an infinite error loop. Recipients may log, ignore, or terminate the assessment.
PT-TLS messages carry potentially sensitive posture information (software versions, patch levels, configuration details). TLS confidentiality protects this data in transit; however, data held within the NEA Server's assessment components may also be sensitive and should be protected at rest and disclosed only to authorized parties.
IANA has reserved TCP port 271 for use by 'pt-tls'. PT-TLS Initiators connect to this port on the PT-TLS Responder to establish a session.
Nine initial IETF-namespace PT-TLS Message Types are defined: 0 (Experimental), 1 (Version Request), 2 (Version Response), 3 (SASL Mechanisms), 4 (SASL Mechanism Selection), 5 (SASL Authentication Data), 6 (SASL Result), 7 (PB-TNC Batch), and 8 (PT-TLS Error). Types 9–4294967294 are unassigned.
PT-TLS uses a vendor-namespaced message type scheme: a 24-bit SMI Private Enterprise Number (Vendor ID) combined with a 32-bit Message Type. IETF namespace types use Vendor ID 0; vendor ID 0xffffff and Message Type 0xffffffff are reserved and MUST NOT be sent.
Seven initial IETF-defined PT-TLS Error Codes are defined: 0 (Reserved/debug), 1 (Malformed Message, fatal), 2 (Version Not Supported, fatal), 3 (Type Not Supported, non-fatal), 4 (Invalid Message, fatal), 5 (SASL Mechanism Error, fatal), and 6 (Invalid Parameter, fatal).
IANA maintains a 'PT-TLS Error Codes' registry for the IETF namespace. Entries use Specification Required policy following Section 6.1 guidelines. The initial set of error codes (0–6) is defined in Section 3.9.
IANA maintains a 'PT-TLS Message Types' registry. Entries use Specification Required policy following Section 6.1 guidelines. The initial set of values (0–8) is defined in Section 3.6; values 9–4294967294 are unassigned; 4294967295 is reserved.
Denial-of-service risks exist because a PT-TLS session requires resources on both sides. Implementations should be prepared for malformed or excessive messages from untrusted endpoints; the trust relationship model in Section 4.1 assumes clients do not intentionally send malicious traffic.
PT-TLS is vulnerable to NEA Asokan attacks (RFC 6813), where a MITM forwards PA-TNC messages from a healthy machine through an unhealthy one. The countermeasure is to use tls-unique channel bindings (RFC 5929): an EMA-equipped endpoint includes the tls-unique value in its attestation, enabling the Posture Validator to verify that the attesting endpoint is the same as the TLS client.
Without TLS confidentiality, an eavesdropper can observe PA-TNC attributes to learn that an endpoint lacks patches or that sub-networks have lenient policies, facilitating targeted attacks. PT-TLS mitigates message theft by requiring TLS authentication, integrity, and confidentiality; deployers are encouraged to use 'best practice of the day' cipher suites.
PT-TLS operates in three sequential phases: TLS Setup (TCP connection and TLS handshake), PT-TLS Negotiation (version negotiation and optional SASL client authentication), and PT-TLS Data Transport (exchange of PB-TNC batches). The Negotiation phase runs only once per TLS session; the Data Transport phase persists for the session's lifetime.
Every PT-TLS message begins with a 16-byte header: Reserved (8 bits), Message Type Vendor ID (24 bits, SMI PEN), Message Type (32 bits), Message Length (32 bits, total including header, minimum 16), and Message Identifier (32 bits, monotonically increasing per sender). The Message Value field follows and carries the payload (e.g., a PB-TNC batch).
The PT-TLS Error message value contains: Reserved (8 bits), Error Code Vendor ID (24 bits), Error Code (32 bits), and a variable-length copy of the original message that caused the error (up to 1024 bytes).
The SASL Mechanisms TLV encodes a list of mechanisms, each as a 5-bit Reserved field, 3-bit Mech Len, and a 1–20 byte Mechanism Name (no padding). The SASL Result TLV carries a 16-bit Result Code (0=Success, 1=Failure, 2=Abort, 3=Mechanism Failure) followed by optional variable-length result data.
The Version Request message payload is 4 bytes: Reserved (8 bits), Min Vers (8 bits), Max Vers (8 bits), and Pref Vers (8 bits). Currently all three version fields MUST be set to 1; responders MUST tolerate other values for forward compatibility.
The Version Response message payload is 4 bytes: Reserved (24 bits) and Version (8 bits). The selected version MUST fall within the Min Vers to Max Vers range from the Version Request.