PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods
Extracted elements (26)
PT-EAP uses tls-unique (RFC 5929) rather than a mutual cryptographic binding because PT-EAP generates no keying material — it is a posture data transport method, not an authentication method. The EMA on the NEA Client can cryptographically bind the tls-unique value, which prevents the client's attestation from being replayed in a different TLS session context.
Success or failure of PT-EAP does not determine the outcome of the overall EAP tunnel authentication; that depends on administrator policy. This decoupling allows flexible deployment where NEA assessment failure need not necessarily deny network access.
PT-EAP is designed to work with the NEA reference model defined in RFC 5209. The Trusted Computing Group (TCG) stated its intent to replace existing posture transport protocols with new versions equivalent to and interoperable with the NEA specifications.
TEAP (RFC 7170) is the mandatory-to-implement EAP tunnel method for use with PT-EAP. PT-EAP may also be carried within EAP-FAST (RFC 4851) or EAP-TTLS (RFC 5281), each of which uses TLS to establish a protected tunnel before running inner methods.
If the version sent by the NEA Client is not acceptable to the NEA Server, the NEA Server MUST terminate the PT-EAP session immediately. Otherwise, both the NEA Client and NEA Server MUST use the chosen version in all subsequent PT-EAP messages.
Implementations MUST send bits in each message diagram traversing top-to-bottom, left-to-right. Multi-byte fields representing numeric values MUST be sent in network (big-endian) byte order.
PT-EAP implementers SHOULD support tls-unique channel binding countermeasures against NEA Asokan attacks by providing the tls-unique value to higher layers (Posture Broker Clients, Posture Broker Servers, Posture Collectors, and Posture Validators). If implemented, tls-unique must be verified before any other attestations.
PT-EAP MUST be used inside a TLS-based EAP tunnel method that provides strong cryptographic authentication (possibly server only), message integrity, and confidentiality services. PT-EAP does not itself provide these protections.
Strong mutual authentication of the NEA Server and Client is REQUIRED to prevent disclosure of possibly sensitive NEA Client information to an attacker. If the tls-unique values of NEA Client and NEA Server do not match, the Posture Validator SHOULD fail its verification.
The Data field MUST include PB-TNC messages (RFC 5793) and is processed by the PB layer. Its length is determined by subtracting the PT-EAP header length from the two-octet Length field value.
The EAP tunnel method carrying PT-EAP MUST provide strong cryptographic authentication, integrity, and confidentiality protection to protect against NEA assessment message theft. The PT protocol MUST support mutual authentication, integrity, confidentiality, and replay protection (requirement PT-2 from RFC 5209).
The NEA Client SHOULD choose the version sent by the NEA Server if it supports it, but MAY choose a lesser version. If the NEA Client only supports versions greater than the NEA Server's value, it MUST abnormally terminate EAP negotiation.
The NEA Server MUST set the Version field in the Start message to the maximum PT-EAP version it supports and is willing to accept. Version 0 is reserved and MUST never be sent.
The security requirements in Section 5 MUST be implemented in any product claiming PT-EAP compliance. If security mechanisms may be deactivated by policy, an implementation SHOULD offer an interface to query how a message will be protected so higher-layer NEA protocols can factor this into their decisions.
PT-EAP does not directly utilize or require knowledge of any personally identifiable information (PII). However, deployers must leverage the outer EAP tunnel's confidentiality protections to prevent disclosure of PII potentially contained within PA-TNC or PB-TNC payloads carried in PT-EAP.
PT-EAP has two phases in strict sequence: a negotiation phase (initiated by the NEA Server's Start message) and a data transport phase (where PB-TNC batches are exchanged, always beginning with the NEA Client sending first). The data transport phase always ends with an EAP Response from the NEA Client.
To prevent NEA Asokan attacks, the Posture Broker on an EMA-equipped endpoint must pass the tls-unique channel binding (RFC 5929) from PT-EAP's tunnel method to the EMA. The EMA includes it in its attestation, allowing the Posture Validator to confirm both ends of the tunnel share the same tls-unique value.
IANA assigned EAP Method Type value 54 to PT-EAP, used in the Type field of every PT-EAP message as defined in Section 3.3.
IANA created the 'PT-EAP Versions' registry with values 0 (Reserved) and 1 (defined by RFC 7171). Values 2–7 may be added only by Standards Action (approved Standards Track RFC), reflecting the high bar imposed by the registry's small size of only 8 possible values.
NEA Asokan attacks allow an attacker to forward PA-TNC messages from a healthy machine through an unhealthy one, enabling the unhealthy machine to gain network access. This attack is primarily relevant when an External Measurement Agent (EMA) is in use; countermeasures use tls-unique channel bindings.
PT-EAP itself provides no authentication, ciphersuite negotiation, mutual authentication, integrity protection, replay protection, confidentiality, key derivation, fast reconnect, or fragmentation. All such protections are delegated entirely to the outer EAP tunnel method.
The Posture Transport Client is trusted by the Posture Broker Client not to observe, fabricate, or alter PB-TNC batches in either direction, to apply configured security protections, and to expose the authenticated identity of the Posture Transport Server. Since the Posture Transport Server cannot validate the trustworthiness of the PT Client, it must protect itself appropriately.
Without confidentiality from the outer EAP tunnel, an eavesdropper could observe PA-TNC attributes in PB-TNC batches and determine that an endpoint lacks patches or that sub-networks have lenient policies, enabling targeted attacks. The EAP tunnel must provide strong cryptographic authentication, integrity, and confidentiality.
PT-EAP begins in the negotiation phase triggered by the NEA Server sending a Start message (S flag set). Upon receipt, the NEA Client responds with its chosen version, transitioning to the data transport phase. Abnormal termination can occur at any time by either party stopping the exchange.
PT-EAP messages consist of: Code (1 octet, values 1=Request or 2=Response), Identifier (1 octet), Length (2 octets, total message length from Code field), Type (1 octet, value 54), Flags|Version (1 octet: S bit + 4 reserved bits + 3-bit Version), and variable-length Data.
The Flags field contains: S (Start) — indicates beginning of PT-EAP exchange, MUST be set only in first NEA Server message and MUST NOT accompany Data; R (Reserved, 4 bits) — MUST be set to 0 and ignored on receipt. The Version subfield (3 bits) follows the flags.