rfc-5792

PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)

P. Sangster, K. Narayan
date2010-03 streamIETF areasec wgnea statusPROPOSED STANDARD pages83 canonicalhttps://www.rfc-editor.org/rfc/rfc5792 doi10.17487/RFC5792 errataview
This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

Extracted elements (31)

design-rationale §2.3

PA-TNC chose binary TLV encoding over XML to minimize bandwidth on constrained links (e.g., 802.1X) and reduce CPU overhead on low-power endpoints such as mobile devices. XML encoding remains possible within vendor-defined attribute namespaces where these constraints are less applicable.

security

design-rationale §2.1

SMI Private Enterprise Numbers serve as namespace identifiers for both PA subtypes and attribute types, allowing the IETF standard namespace (Vendor ID=0) to coexist with any number of vendor-defined namespaces without coordination or risk of collision.

security, registry

design-rationale §2.2

Vendor-defined namespaces are provided alongside the IETF standard namespace to enable rapid response to new threats and endpoint capabilities without waiting for IETF standardization, allowing agile vendor differentiation while maintaining a stable interoperable baseline.

security

interoperability-note §1

PA-TNC is specified to be identical to TCG's IF-M 1.0 protocol, enabling interoperability between IETF NEA deployments and Trusted Network Connect (TNC) implementations. PA subtype and attribute type values carry completely different meanings when used with different Vendor IDs; the IETF standard namespace requires Vendor ID = 0.

security

normative-requirement §3.4 MUST

All compliant Posture Collectors and Posture Validators MUST be capable of processing multiple attributes in a received PA-TNC message, using the length field to skip unrecognized non-NOSKIP attributes.

security

normative-requirement §4.1 MUST

All PA-TNC attribute TLVs within a single PA-TNC message MUST pertain to the same implementation of the component. Posture Collectors reporting multiple implementations of the same component type MUST send separate PA-TNC messages for each implementation.

security

normative-requirement §3.2 MUST

Each Posture Collector and Posture Validator MUST only send PA-TNC messages containing attributes that pertain to the software component defined in the message's PA Subtype, ensuring correct PB-TNC routing to the right subscribers.

security

normative-requirement §4.1 MUST NOT

If an attribute with the NOSKIP flag set (bit 0 = 1) is not supported by the recipient, the recipient MUST NOT process any part of the PA-TNC message and SHOULD respond with an Attribute Type Not Supported error. Recipients of multi-attribute messages may need to pre-scan all attributes before acting on any.

security

normative-requirement §4.1 MUST

PA-TNC Attribute Length MUST be at least 12 (the size of the attribute header). Recipients that receive a length less than 12, or a length inconsistent with a known fixed-length attribute, SHOULD respond with an Invalid Parameter PA-TNC error code.

security

normative-requirement §4.1 MUST NOT

PA-TNC Attribute Vendor ID 0xffffff is reserved; implementations MUST NOT send it and SHOULD respond with an Invalid Parameter error on receipt. PA-TNC Attribute Type 0xffffffff carries the same prohibition.

security

normative-requirement §3.6 MUST NOT

PA-TNC message senders MUST NOT reuse the same Message Identifier during a single assessment. Identifiers may be random or sequential but MUST remain unique per sender per assessment session.

security

normative-requirement §3.6 MUST

PA-TNC message senders MUST set the Version field to 0x01. Implementations responding to a supported version MUST use the same version number in their reply. Recipients MUST respond to an unsupported version with a Version Not Supported error as the sole attribute in a version-1 message.

security

normative-requirement §4.2.6 MUST NOT

Port Filter: Posture Collectors MUST NOT include two Protocol/Port Number pairs in a single Port Filter attribute where the protocol number is the same but the B (blocked) flag differs, and MUST NOT list the same Protocol/Port combination twice.

security

normative-requirement §3.5 MUST NOT

Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA subtypes and MUST interoperate with other parties despite differences in the set of supported vendor-specific PA subtypes.

security

normative-requirement §4.2.7 SHOULD NOT

Posture Collectors SHOULD NOT send the Installed Packages attribute unless specifically requested via an Attribute Request, and Posture Validators SHOULD NOT request it unless the transport can support the potentially large response.

security

normative-requirement §4.2.8 MUST NOT

When a PA-TNC Error attribute is received, the recipient MUST NOT respond with another PA-TNC Error to prevent infinite error loops. The recipient MAY log, modify behavior, ignore, or terminate the assessment.

security

privacy-consideration §6

PA-TNC attributes such as Product Information, Installed Packages, and String Version can expose sensitive details about an endpoint's software configuration. Whether a Posture Collector actually sends such attributes SHOULD be governed by local privacy and security policies, even when technically capable of doing so.

privacy, security

protocol-element §3.5

IETF Standard PA Subtypes (used with PA Message Vendor ID = 0): 0=Testing, 1=Operating System, 2=Anti-Virus, 3=Anti-Spyware, 4=Anti-Malware, 5=Firewall, 6=IDPS, 7=VPN, 8=NEA Client. Each identifies a component type for routing PA-TNC messages.

security, registry

protocol-element §4.2

IETF Standard PA-TNC Attribute Types (Vendor ID = 0): 1=Attribute Request, 2=Product Information, 3=Numeric Version, 4=String Version, 5=Operational Status, 6=Port Filter, 7=Installed Packages, 8=PA-TNC Error, 9=Assessment Result, 10=Remediation Instructions, 11=Forwarding Enabled, 12=Factory Default Password Enabled.

security, registry

registry §7

IANA maintains four registries created by this document: PA Subtypes (section 7.2), PA-TNC Attribute Types (section 7.3), PA-TNC Error Codes (section 7.4), and PA-TNC Remediation Parameters Types (section 7.5). All use Expert Review with Specification Required for new entries.

registry, security

security-consideration §5.2.6

Denial-of-service attacks may exploit large PA-TNC attributes (especially Installed Packages) to overwhelm constrained endpoints or bandwidth-limited transports. Posture Collectors SHOULD NOT send large attributes unless explicitly requested, and Posture Validators SHOULD NOT request them unless the transport supports the data volume.

security

security-consideration §5.2

PA-TNC identifies six threat classes: attribute theft (unauthorized interception of posture data), message fabrication (spoofed messages from unauthenticated parties), attribute modification (in-transit tampering), attribute replay, attribute insertion, and denial of service. Mitigations require the underlying PT transport to provide confidentiality, authentication, and integrity protection.

security

security-consideration §5.1

Trust in the PA-TNC exchange depends on each component in the chain: Posture Collectors must accurately report endpoint posture, Posture Validators must correctly evaluate it, and the Posture Broker Client/Server must faithfully route messages. A compromised endpoint can report false posture and defeat the assessment.

security

wire-format §4.2.7

Installed Packages attribute value: 2-octet Reserved, 2-octet Package Count, then for each package: 1-octet Pkg Name Len, variable UTF-8 Package Name, 1-octet Version Len, variable UTF-8 Package Version Number. No padding or NUL termination in string fields.

security

wire-format §4.2.3

Numeric Version attribute value: 4-octet Major Version Number, 4-octet Minor Version Number, 4-octet Build Number, 2-octet Service Pack Major, 2-octet Service Pack Minor. PA-TNC Attribute Length MUST be exactly 28.

security

wire-format §4.2.5

Operational Status attribute value: 1-octet Status (0=Unknown, 1=Not installed, 2=Installed not operational, 3=Operational), 1-octet Result, 2-octet Reserved, 20-octet Last Use as RFC 3339 UTC string (YYYY-MM-DDTHH:MM:SSZ; '0000-00-00T00:00:00Z' if unknown). PA-TNC Attribute Length MUST be 36.

security

wire-format §4.1

PA-TNC Attribute Header TLV: 1-octet Flags, 3-octet PA-TNC Attribute Vendor ID (SMI PEN), 4-octet PA-TNC Attribute Type, 4-octet PA-TNC Attribute Length (MUST be ≥12), followed by variable-length Attribute Value. Bit 0 of Flags is the NOSKIP flag.

security

wire-format §3.6

PA-TNC Message Header: 1-octet Version, 3-octet Reserved (MUST be 0), 4-octet Message Identifier. All PA-TNC messages MUST begin with this 8-octet header; multi-byte numeric fields are big-endian.

security

wire-format §4.2.6

Port Filter attribute value: one or more 4-octet entries, each containing 7-bit Reserved, 1-bit B flag (1=blocked, 0=allowed), 1-octet IANA Protocol number, 2-octet Port Number. MUST contain at least one entry.

security

wire-format §4.2.2

Product Information attribute value: 3-octet Product Vendor ID (SMI PEN), 2-octet Product ID, variable-length UTF-8 Product Name. PA-TNC Attribute Length MUST be at least 17. If Product Vendor ID is 0, Product ID MUST also be 0.

security

wire-format §4.2.4

String Version attribute value: 1-octet Version Len + variable UTF-8 Product Version Number, 1-octet Build Num Len + variable Internal Build Number, 1-octet Config Len + variable Configuration Version Number. PA-TNC Attribute Length MUST be at least 15.

security