RFC 5792
PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
Internet Engineering Task Force (IETF) P. Sangster Request for Comments: 5792 Symantec Corporation Category: Standards Track K. Narayan ISSN: 2070-1721 Cisco Systems March 2010 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)Abstract
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. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5792. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction ....................................................4 1.1. Prerequisites ..............................................4 1.2. Message Diagram Conventions ................................4 1.3. Conventions Used in This Document ..........................4 2. Design Considerations ...........................................4 2.1. Standard Attribute Namespace for Interoperability ..........4 2.2. Vendor-Defined Namespace for Differentiation and Agility ...5 2.3. Use of TLV-Based Encoding for Efficiency ...................6 3. PA-TNC Message Protocol .........................................7 3.1. PA-TNC Messaging Model .....................................7 3.2. PA-TNC Relationship to PB-TNC ..............................8 3.3. PB-PA Posture Collector and Posture Validator Identifiers ...............................................10 3.4. PA-TNC Messages in PB-TNC .................................10 3.5. IETF Standard PA Subtypes .................................11 3.6. PA-TNC Message Header Format ..............................12 4. PA-TNC Attributes ..............................................13 4.1. PA-TNC Attribute Header ..................................13 4.2. IETF Standard PA-TNC Attribute Types .....................17 4.2.1. Attribute Request ..................................18 4.2.2. Product Information ................................20 4.2.3. Numeric Version ....................................22 4.2.4. String Version .....................................24 4.2.5. Operational Status .................................26 4.2.6. Port Filter ........................................29 4.2.7. Installed Packages .................................31 4.2.8. PA-TNC Error .......................................34 4.2.9. Assessment Result ..................................41 4.2.10. Remediation Instructions ..........................42 4.2.11. Forwarding Enabled ................................45 4.2.12. Factory Default Password Enabled ..................47 4.3. Vendor-Defined Attributes ................................48 5. Security Considerations ........................................48 5.1. Trust Relationships .......................................48
5.1.1. Posture Collector ..................................49
5.1.2. Posture Validator ..................................49
5.1.3. Posture Broker Client, Posture Broker Server .......49
5.2. Security Threats ..........................................50
5.2.1. Attribute Theft ....................................50
5.2.2. Message Fabrication ................................51
5.2.3. Attribute Modification .............................51
5.2.4. Attribute Replay ...................................52
5.2.5. Attribute Insertion ................................52
5.2.6. Denial of Service ..................................53
6. Privacy Considerations .........................................53
7. IANA Considerations ............................................54
7.1. Designated Expert Guidelines ..............................55
7.2. PA Subtypes ...............................................56
7.3. Registry for PA-TNC Attribute Types .......................56
7.4. Registry for PA-TNC Error Codes ...........................57
7.5. Registry for PA-TNC Remediation Parameters Types ..........58
8. Acknowledgments ................................................58
9. References .....................................................59
9.1. Normative References ......................................59
9.2. Informative References ....................................59
Appendix A. Use Cases .............................................60
A.1. Initial Client-Triggered Assessment .......................60
A.2. Server-Initiated Assessment with Remediation ..............64
A.3. Client-Triggered Reassessment .............................71
Appendix B. Evaluation against NEA Requirements ...................77
B.1. Evaluation against Requirements C-1 .......................77
B.2. Evaluation against Requirements C-2 .......................77
B.3. Evaluation against Requirements C-3 .......................77
B.4. Evaluation against Requirements C-4 .......................78
B.5. Evaluation against Requirements C-5 .......................78
B.6. Evaluation against Requirements C-6 .......................78
B.7. Evaluation against Requirements C-7 .......................79
B.8. Evaluation against Requirements C-8 .......................79
B.9. Evaluation against Requirements C-9 .......................79
B.10. Evaluation against Requirements C-10 .....................80
B.11. Evaluation against Requirements C-11 .....................80
B.12. Evaluation against Requirements PA-1 .....................81
B.13. Evaluation against Requirements PA-2 .....................81
B.14. Evaluation against Requirements PA-3 .....................81
B.15. Evaluation against Requirements PA-4 .....................82
B.16. Evaluation against Requirements PA-5 .....................82
B.17. Evaluation against Requirements PA-6 .....................83
1. Introduction
This document specifies PA-TNC, a Posture Attribute (PA) Protocol identical to the Trusted Computing Group's IF-M 1.0 protocol [8]. The document then evaluates PA-TNC against the requirements defined in the Network Endpoint Assessment (NEA) Requirements specification [9].1.1. Prerequisites
This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Overview and Requirements specification. The reader is assumed to be thoroughly familiar with that document. No familiarity with TCG specifications is assumed.1.2. Message Diagram Conventions
This specification defines the syntax of PA-TNC messages using diagrams. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits in each diagram as they are shown, traversing the diagram from top to bottom and then from left to right within each line (which represents a 32-bit quantity). Multi-byte fields representing numeric values must be sent in network (big endian) byte order. Descriptions of bit field (e.g., flag) values are described referring to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit, so a 1-octet field with only bit 0 set has the value 0x80.1.3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].2. Design Considerations
This section discusses some of the key design considerations for the PA protocol.2.1. Standard Attribute Namespace for Interoperability
The PA protocol requires the use of two categories of namespaces: component types (AKA PA subtypes) and attributes. Each of these namespace categories needs to contain well-known, interoperable names with defined syntax and semantics co-existing with names for vendor-
defined private extensions. Similarly, each namespace category needs to be readily extensible without repeated coordination yet avoids naming conflicts. The PA-TNC and PB-TNC protocols provide for multiple orthogonal namespaces for each category that exist without overlap by including a Structure of Management Information (SMI) Private Enterprise Number (PEN) field to identify the definer of namespace of the associated field. This allows the IETF NEA WG to define a set of standard component types and attribute types while allowing vendors to each create additional names outside of the IETF standard namespace. Over time, vendor-defined names might be proposed for standardization and thus migration into the IETF namespace. The PB-TNC protocol defines an IETF standard namespace (using vendor-id=0) that allows for definition of standard component types (e.g., Operating System, Firewall, Anti-Virus) using the PA Subtype field (see section 3.2). Similarly, PA-TNC defines a set of standard attributes in section 4.2 that represent the most common capabilities (attributes) of these types of components across a variety of vendor implementations. The standard namespace allows NEA deployments with both open source and vendor-provided NEA implementations to support a consistent set of policies across their environment based on these standard attributes. The standard attributes can be used with a variety of endpoints (hosts, printers, mobile devices) that are running applications and operating systems (defined by the PA subtypes) from a variety of vendors.2.2. Vendor-Defined Namespace for Differentiation and Agility
The endpoint is a very dynamic environment in terms of rate of new features being deployed and attacks that are crafted against existing and new applications such as viruses, worms, malware, and spyware. It is difficult to imagine the standard namespaces being able to keep pace with this rapidly changing environment. Vendors typically differentiate themselves by moving rapidly to provide unique mechanisms to address such threats and their ability to deal with changes in an agile manner. The PA-TNC and PB-TNC protocols allow for creation of vendor-defined namespace(s) where each namespace allows use of vendor-defined PA subtypes to identify non-standard applications or operating system variants and vendor-defined attributes describing new aspects of each type of component. The vendor namespaces will allow NEA deployments to craft compliance policies using a mixture of attributes from both the IETF standard namespace and vendor-defined namespaces that may include multiple vendors representing the various hardware and software components present on the endpoints.
The PA-TNC protocol's use of vendor-id to identify the namespace of each attribute allows Posture Collectors to support some or all of the IETF standard attributes plus optionally a set of vendor-defined attributes (potentially from more than one vendor-id namespace). For instance, an open source anti-virus Posture Collector might be written that supports all of the IETF standard attributes used to describe a local anti-virus component and a subset of multiple anti- virus manufacturers' vendor-defined attributes. This Posture Collector might therefore be able to interoperate with Posture Validators from multiple vendors. Conversely, a simple Posture Collector might be written to ignore any vendor-defined attributes requested and only return standard attributes that it supports. If the vendor-provided Posture Validator's policy allows for this subset to be considered compliant, then these simple Posture Collectors can be used to perform a successful assessment.2.3. Use of TLV-Based Encoding for Efficiency
The PA-TNC protocol has chosen to employ a binary encoding using a type-length-value (TLV) structure. TLV encoding was preferred over the use of a textual encoding format such as XML to provide a more efficient utilization of the potentially constrained bandwidth available between the NEA Client and NEA Server (see NEA Overview and Architecture [9]). Efficiency was a primary criterion for this choice with consideration given to both: 1. Optimization of the bits-on-the-wire to accommodate NEA requirements for assessment over low bandwidth or high latency links (C-8) and allow for the Posture Transport (PT) protocol to run over existing network access protocols (PT-4, C-11) that are constrained by packet size. 2. Optimization of CPU utilization on the endpoint to accommodate for low power endpoints such as mobile devices. The choice of TLV encoding does not preclude the use of XML-based attribute values within the vendor namespaces or future standard attributes. It is conceivable that certain vendors may utilize XML encoding for extensibility within their namespace when the above considerations are less applicable to their technologies. Attributes encoded within the vendor-defined namespace using alternate encoding such as XML will be opaque to NEA software only supporting standard attributes and will be processed primarily by the vendor-defined components (collector/validator).
3. PA-TNC Message Protocol
This section discusses the use of the PA-TNC message and its attributes, and specifies the syntax and semantics for the PA-TNC message header. The details of each attribute included within the PA-TNC payload are specified in section 4.2.3.1. PA-TNC Messaging Model
PA-TNC messages are carried by the PB-TNC protocol [5], which provides a multi-roundtrip reliable transport and end-to-end message delivery to subscribed (interested) parties using a variety of underlying network protocols. PA-TNC is unaware of these underlying PT protocols being used below PB-TNC. The interested parties consist of Posture Collectors on the NEA Client and Posture Validators associated with the NEA Server that have registered to receive messages about particular types of components (e.g., anti-virus) during an assessment. The PA-TNC messaging protocol operates synchronously within an assessment session, with Posture Collectors and Posture Validators taking turns sending one or more messages to each other. Each PA-TNC message may contain one or more attributes associated with the functional component identified in the component type (PA Subtype) of the Posture Broker (PB) protocol. Posture Collectors may only send PA-TNC messages to Posture Validators and vice versa. No Posture Collector-to-Posture Collector or Posture Validator-to-Posture Validator messaging is allowed to occur. Each Posture Collector or Posture Validator may send several PA-TNC messages in succession before indicating that it has completed its batch of messages to the Posture Broker Client or Posture Broker Server respectively. As necessary, the Posture Broker Client and Posture Broker Server will batch these messages prior to sending them over the network. PB-TNC provides a publish/subscribe model of message exchange. This means that, at any given point in time, zero or more subscribers for a particular type of message may be present on a Posture Broker Client or Posture Broker Server. This is beneficial, since it allows one Posture Collector or Posture Validator to combine multiple functions (like anti-virus and personal firewall) by subscribing to both TNC standard component types. It also allows multiple Posture Collectors or Posture Validators to support the same components, such as two anti-virus Posture Validators that are each used to manage their own respective anti-virus client software.
However, this publish/subscribe model has some possible negative side effects. When a Posture Collector or Posture Validator initially sends a PA-TNC message, it does not know whether it will receive many, one, or no PA-TNC messages from the other side. For many types of assessments, this is acceptable, but in some cases a more direct channel binding between a particular Posture Collector and Posture Validator pair is necessary. For example, a Posture Validator may wish to provide remediation instructions to a particular Posture Collector that it knows is capable of remediating a non-compliant component. This can be accomplished using the exclusive delivery PB- TNC capability to limit distribution of a message to a single Posture Collector by including the target Posture Collector Identifier in the PB-PA header. For more information on the PB-PA header, see section 4.5 of the PB-TNC specification.3.2. PA-TNC Relationship to PB-TNC
This section summarizes the major elements of a PA-TNC message as they might appear inside of a PB-TNC message. The double line (===) in the diagram below indicates the separation between the PB-TNC and PA-TNC protocols. The PA-TNC portion of the message is delivered to each Posture Collector or Posture Validator registered to receive messages containing a particular message type. Note that PB-TNC is capable of carrying multiple PB-TNC and PA-TNC messages in a single PB-TNC batch. See the PB-TNC specification [5] for more information on its capabilities. One important linkage between the PA-TNC and PB-TNC protocols is the PA message type (PA Message Vendor ID and PA Subtype) that is used by the Posture Broker Client and Posture Broker Server to route messages to interested Posture Collectors and Posture Validators. The message type indicates the software component (component type) that is associated with the attributes included inside the PA-TNC message. Therefore, Posture Collectors and Posture Validators written to support an assessment of a particular component can register to receive messages about the component and thus participate in its assessment. Each Posture Collector and Posture Validator MUST only send PA-TNC messages containing attributes that pertain to the software component defined in the message type of the message. This ensures that only the appropriate Posture Collectors and Posture Validators that support a particular type of component will receive attributes related to that component. If a PA-TNC message contained a mix of attributes about different components and a message type of only one of those components, the message would only be delivered to parties interested in the component type included in the message type, so other interested recipients wouldn't see those attributes.
The message type is composed of two fields: a PA Message Vendor ID and a PA Subtype. The PA Message Vendor ID identifies the vendor or other organization that defined this message type. The PA Subtype identifies the message type more specifically within the set of message types defined by that vendor. This specification defines several IETF Standard PA Subtypes to be used with a PA Message Vendor ID of zero (0). Within this specification, the PA Subtype field is used to indicate the type of component (e.g., firewall) involved with the message's attributes. Therefore, for clarity, the PA subtype will be referred to as the "component type" in this specification. Vendor-defined namespaces may use other semantics for the PA Subtype field as this is outside the scope of this specification. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PB-TNC Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PB-TNC Message of type PB-PA-Message | |(includes PA Message Vendor ID, PA Subtype, and other fields | | used by Posture Broker Client and Posture Broker Server for | | routing) | =============================================================== +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PA-TNC Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PA-TNC Attribute | | (e.g., Product Information) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PA-TNC Attribute | | (e.g., Operational Status) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Overview of a PB-TNC batch that contains a PA-TNC message For example, if a Posture Broker Client sent a PB-TNC batch that contained a PA-TNC message with a message type indicating firewall component, this message would be routed by the Posture Broker Server to Posture Validators registered to assess firewalls. Each registered Posture Validator would receive a copy of the PA-TNC message including the PA-TNC header and set of attributes. It is important that each of the attributes included in the PA-TNC message be associated with the firewall component because only the Posture Collector and Posture Validator interested in firewalls will receive such messages.
If the above message contained both firewall and operating system attributes inside a PA-TNC message with a component type of firewall, then any Posture Collector and Posture Validator registered to receive operating system messages would not receive those attributes, as the messages would only be delivered to those registered for firewall messages.3.3. PB-PA Posture Collector and Posture Validator Identifiers
The PB-PA header contains several fields important to the processing of a received PA message. The PA Vendor ID and Subtype are described in the PB-TNC specification and above in section 3.2. Also present in the PB-PA header is a pair of fields that identify the Posture Collector and/or Posture Validator involved in the exchange. These fields are used for performing exclusive delivery of messages as described in section 3.1 and as an indicator for correlation of received attributes. Correlation of attributes is necessary when the sending Posture Collector provides posture for multiple implementations of a single type of component during an assessment, so the recipient Posture Validators need to know which attributes are describing the same implementation. For example, a single Posture Collector might report attributes on two installed VPN implementations on the endpoint. Because the individual attributes do not include an indication of which VPN product they are describing, the recipient needs something to perform this correlation. Therefore, for this example, the VPN Posture Collector would need to obtain two Posture Collector Identifiers from the Posture Broker Client and consistently use one with each of the implementations during an assessment. The VPN Posture Collector would group all the attributes associated with a particular VPN implementation into a single PB-PA message and send the message using the Posture Collector Identifier it designates as going with the particular implementation. This approach allows the recipient to recognize when attributes in future assessment messages also describe the same component implementation.3.4. PA-TNC Messages in PB-TNC
As depicted in section 3.2, a PA-TNC message consists of a PA-TNC header followed by a sequence of one or more attributes. The PA-TNC message header (described in section 3.6) and the header for each of the PA-TNC attributes (specified in section 4.1) have a fixed type- length-value (TLV) format. Each PA-TNC message MAY contain a mixture of standards-based and vendor-defined attributes identifiable using the type portion of the attribute header. All Posture Collectors and
Posture Validators compliant with this specification MUST be capable of processing multiple attributes in a received PA-TNC message. A Posture Collector or Posture Validator that receives a PA-TNC message can use the attribute header's length field to skip any attributes that it does not understand, unless the attribute is marked as mandatory to process.3.5. IETF Standard PA Subtypes
This section defines several IETF Standard PA Subtypes. Each PA subtype defined here identifies a specific component relevant to the endpoint's posture. This allows a small set of generic PA-TNC attributes (e.g., Product Information) to be used to describe a large number of different components (e.g., operating system, anti-virus, etc.). It also allows Posture Collectors and Posture Validators to specialize in a particular component and only receive PA-TNC messages relevant to that component. Value Integer Definition ----- ------- ---------- 0 Testing Reserved for use in specification examples, experimentation and testing. 1 Operating System Operating system running on the endpoint 2 Anti-Virus Host-based anti-virus software 3 Anti-Spyware Host-based anti-spyware software 4 Anti-Malware Host-based anti-malware (e.g., anti- bot) software not included within anti-virus or anti-spyware components 5 Firewall Host-based firewall 6 IDPS Host-based Intrusion Detection and/or Prevention Software (IDPS) 7 VPN Host-based Virtual Private Network (VPN) software 8 NEA Client NEA client software These PA subtypes must be used in a PB-PA message with a PA Message Vendor ID of zero (0) indicating an IETF standard type of component (as described in the PB-TNC specification [5]). If these PA subtype
values are used with a different PA Message Vendor ID, they have a completely different meaning that is not defined in this specification. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA subtypes and MUST interoperate with other parties despite any differences in the set of vendor-specific PA subtypes supported (although they MAY permit administrators to configure them to require support for specific PA subtypes).3.6. PA-TNC Message Header Format
This section describes the format and semantics of the PA-TNC header. Every PA-TNC message MUST start with a PA-TNC header. The PA-TNC header provides a common context applying to all of the attributes contained within the PA-TNC payload. The payload consists of a sequence of assessment attributes described in section 4.2. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version This field indicates the version of the format for the PA-TNC message. This version is intended to allow for evolution of the PA-TNC message header and payload in a manner that can easily be detected by message recipients. PA-TNC message senders MUST set this field to 0x01 for all PA-TNC messages that comply with this specification. Implementations responding to a PA-TNC message containing a supported version MUST use the same version number to minimize the risk of version incompatibility. Message recipients MUST respond to a PA-TNC message containing an unsupported version by sending a Version Not Supported error in a PA-TNC Error attribute that is the only PA- TNC attribute in a PA-TNC message with version number 1. PA-TNC message initiators supporting multiple PA-TNC protocol versions SHOULD be able to alter which version of PA-TNC message they send based on prior message exchanges with a particular peer Posture Collector or Posture Validator.
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
Message Identifier
This field contains a value that uniquely identifies this message,
differentiating it from others sent by a particular PA-TNC message
sender within this assessment. This value can be included in the
payload of a response message to indicate which message was
received and caused the response. This value is included in the
payload of PA-TNC error messages so the party who receives the
error message can determine which of the messages they had sent
caused the error.
PA-TNC message senders MUST NOT send the same message identifier
more than once during an assessment. Message identifiers may be
randomly generated or sequenced as long as values are not repeated
during an assessment message exchange. PA-TNC message recipients
are not required to check for duplicate message identifiers.
(page 13 continued on part 2)
