RFC 5792
PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [4] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [5] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010. [6] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.9.2. Informative References
[8] Trusted Computing Group, "IF-M: TLV Binding", http://www.trustedcomputinggroup.org/resources/ tnc_ifm_tlv_binding_specification, February 2010. [9] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
Appendix A. Use Cases
A.1. Initial Client-Triggered Assessment
This scenario involves the assessment of an endpoint initiated during network join. The assessment is triggered by the Posture Broker Client (PBC) and involves collection of patch information from both Standard Operating System (OS) Posture Collector and vendor-specific Patch Posture Collector (PC). The assessment by both the vendor- specific Patch Posture Validator (PV) and Standard OS Posture Validator result in a compliant assessment decision that results in a compliant System Assessment Decision to be returned by the Posture Broker Server (PBS). +--------+ +-------+ +---------+ +--------+ +-------++--------+ | Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X| |Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV| +--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+ | | N/W Join| | | | | | ----->| | | | | | Req Post. | | | | | |<----------| | | | | | Req Post. | | | | |<--------------------| | | | |Vndr X Patch Posture | | | | |-------------------->| | | | | |OS Posture | | | | | |---------->| | | | | | | Posture | | | | | | Report | | | | | |-------->| | | | | | | Verify | | | | | | Posture | | | | | |---------> | | | | | | Verify | | | | | | Posture | | | | |------------------->| | | | | OS Reslt | | | | | |<---------| | | | | | VndrX Patch Result | | | | Assess |<-------------------| | | | Result | | | | |<--------| | | | | OS Reslt | | | | | |<----------| | | | | VndrX Patch Result | | | | |<--------------------| | | |
A.1.1. Message Contents
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.A.1.1.1. N/W Join
This flow represents the event that causes the PBC to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and does not include a message being sent.A.1.1.2. Request Posture (Req Post.)
This flow illustrates an invocation of the OS and patch posture collectors requesting particular posture attributes to be sent. Because this use case is triggered locally, the contents of this flow aren't specified by NEA.A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)
This flow contains the PA message from the Patch Posture Collector: Vendor X Patch Posture PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=1 (vendor X) type=1 (Vendor X namespace attribute) length Value = { VendorXAttribute1=123 } } Attribute 2 { vendor-id=1 (vendor X) type=2 (Vendor X namespace attribute) length Value = { VendorXAttribute2=456 } } }
A.1.1.4. OS Posture
This flow contains the PA message from the OS Posture Collector: OS Posture PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=2 (product information) length Value = { Product-vendor-id=311 -- Microsoft's PEN Product-name="Windows Vista" } } Attribute 2 { vendor-id=0 type=3 (numeric version) length Value = { major-version=6 -- Vista is version 6.0 minor-version=0 build-number=456789 service-pack-major=0 -- No service packs service-pack-minor=0 } } }A.1.1.5. Posture Report
This flow contains the PB message containing the PA messages from the Patch and OS Posture Collectors; the message content is described in the PB-TNC specification.A.1.1.6. Verify Posture
This flow illustrates an invocation of the OS and patch Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA does not specify the message contents.
A.1.1.7. OS Posture Result (OS Reslt)
This flow contains the PA message (Posture Assessment Result) from the OS Posture Validator OS Posture Result PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=9 (assessment-result) length Value = { assessment-result=0 (compliant) } } }A.1.1.8. Vendor X Patch Result (VndrX Patch Result)
This flow contains the PA message (Posture Assessment Result) from the Vendor X Patch Posture Validator Patch Vendor X Posture Result PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=9 (assessment-result) length Value = { assessment-result=0 (compliant) } } }A.1.1.9. Assessment Result (Assess Result)
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the Patch and OS Posture Validators; the message content is described in the PB-TNC specification.A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)
These flows illustrate an invocation of the OS and Vendor X Patch Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA does not specify the contents of this flow.
A.2. Server-Initiated Assessment with Remediation
This scenario involves the assessment of an endpoint initiated by the NEA Server. The assessment is triggered by the Posture Broker Server and involves collection of Anti-Virus attributes for two Anti-Virus components running on the endpoint. The endpoint is assessed to be compliant by one of the vendor (Vendor X) anti-virus Posture Validators and non-compliant by the other vendor (Vendor Y) anti- virus Posture Validator. Based upon the Posture Broker Server's policy, this results in a non-compliant system assessment decision to be returned by the Posture Broker Server. The Posture Broker Server also returns remediation instructions for the endpoint as part of the response.
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | ------->| | |
| | | | Create | |
| | | |Post. Req | |
| | | |--------->| |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | | Vndr Y AV Post Req |
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post. Req | |
| | | Posture |<---------| |
| | | Request | | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Posture Req | | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Posture | | | |
| |---------->| Posture | | |
| | |Response | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |--------->| |
| | | | Verify Posture |
| | | |----------+--------->|
| | | |Vndr Y AV Post Result|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Result | | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |
A.2.1. Message Contents
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.A.2.1.1. N/W Join
This flow represents the event that causes the PBS to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and does not include a message being sent.A.2.1.2. Create Posture Request (Create Posture Req)
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Validators enabling posture request attributes to be created. Because this use case is triggered locally, NEA does not specify the contents of this flow.A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture Req)
This flow contains the PA message (Posture Request) from the Vendor Y Anti-Virus Posture Validator Vendor Y AV Posture Request PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=1 (Attribute Request) length Value = { Vendor-id=0 (IETF Standard) Type=2 (Standard attribute, Product-Information) Vendor-id=1 (Vendor Y) Type=2 (Vendor Y attribute, Extended-Dat-Version) } } }
A.2.1.4. Vendor X AV Posture Request (Vndr X AV Post. Req)
This flow contains the PA message (Posture Request) from the Vendor X Anti-Virus Posture Validator Vendor X AV Posture Request PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=1 (Attribute Request) length Value = { Vendor-id=1 (Vendor X) Type=1 (Vendor X attribute, Scan-Engine-Version) Vendor-id=0 (IETF Standard) Type=5 (Standard, Operational-Status) } } }A.2.1.5. Posture Request
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators; the message content is described in the PB-TNC specification.A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV Post Req)
These flows illustrate an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to process the Posture Request and return the particular posture attributes requested. Because this flow is triggered locally, NEA does not specify the contents of this flow.
A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture)
This flow contains the PA message (response to the Posture Request) from the Vendor Y Anti-Virus Posture Collector. Vendor Y AV Posture PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 (IETF Standard) Type=2 (Standard attribute, Product-Information) length Value = { product-vendor-id=12345 (vendor Y) product-id=987 (AV product id from vendor Y) product-name="Vendor Y Anti-Virus" } } Attribute 2 { vendor-id=2 (vendor Y) type=2 (vendor Y attribute, DAT-Version) length Value = { DAT-version=5678 } } }
A.2.1.8. Vendor X AV Posture (Vndr X AV Posture)
This flow contains the PA message (response to the Posture Request) from the Vendor X Anti-Virus Posture Collector. Vendor X AV Posture PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=1 type=1 (vendor X attribute, Scan-Engine-Version) length Value = { scan-engine-version=1234 } } Attribute 2 { vendor-id=0 (IETF Standard) type=5 (Standard, Operational-Status) length Value = { status=2 (installed but non-operational) result=0 (unknown) last use="" (never used) } } }A.2.1.9. Posture Response
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Collectors; the message content is described in the PB-TNC specification.A.2.1.10. Verify Posture
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA does not specify the message contents.
A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post Result)
This flow contains the PA message (Posture Assessment Result) from the Vendor Y Anti-Virus Posture Validator Vendor Y AV Posture Result PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=9 (assessment-result) length Value = { assessment-result=0 (compliant) } } }A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post Reslt)
This flow contains the PA message (Posture Assessment Result) from the Vendor X Anti-Virus Posture Validator Vendor X AV Posture Result PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=9 (assessment-result) length Value = { assessment-result=1 (non-compliant) } } }A.2.1.13. Assessment Result (Assess Result)
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators; the message content is described in the PB-TNC specification.A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post Reslt)
These flows illustrate an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA does not specify the contents of this flow.
A.3. Client-Triggered Reassessment
This scenario involves the reassessment of an endpoint as a result of enabling a software component on the endpoint. The endpoint has two VPN client software components, one from vendor X for the user's home network and other from vendor Y for the network that the endpoint is currently accessing. The assessment is triggered when the user tries to use the Vendor X VPN client; this is a violation of the assessment policy. The Posture Broker Client triggers the posture assessment when it receives a notification from the VPN Posture Collector about the change to the operational state of the VPN component on the endpoint. Note that the VPN Posture Collector may support standard attributes and some vendor-defined attributes from vendor X's and vendor Y's namespaces. This use case does not leverage vendor- defined attributes. The assessment involves verification of the standard VPN posture attributes by the standard VPN Posture Validator that results in a non-compliant assessment result. This use case relies on the use of multiple Posture Collector IDs for a single Posture Collector as described in section 3.3 of the PA-TNC specification. In this example, the Posture Collector will obtain two Posture Collector IDs to a single Posture Collector (Standard VPN PC) and the Posture Collector will generate two separate PA messages each using a different ID to report the posture for Vendor X and Vendor Y VPN Clients. The Posture Broker Client will associate the assigned IDs in the PB message sent to the NEA Server. This entire behavior will be completely opaque to the NEA Server, which will handle the PB message as if there were two VPN Posture Collectors on the NEA Client.
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |-------->| | |
| | |Req. Post| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |-------->| | |
| | | | Posture | |
| | | | Report | |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | |---------->|
| | | | |VPN PRslt |
| | | | Assess |<----------|
| | | | Result | |
| | | |<---------| |
| | |VPN PRslt| | |
| | |<--------| | |
A.3.1. Message Contents
This section shows the contents of the key fields in each of the PA
messages exchanged in this use case. When necessary, additional
commentary is provided to explain why certain fields contain the
shown values. Note that many of the flows shown are between
components on the same system so no message contents are shown.
A.3.1.1. Enable VPN Client (Enble)
This flow represents the end user triggered event of starting the VPN
Client software from Vendor X. This is merely an event and does not
include a message being sent.
A.3.1.2. Notify Status Change (VPN Status Change)
This flow represents the detection of the active state of the Vendor X VPN Client software by the VPN Posture Collector. This is merely an event and does not include a message being sent.A.3.1.3. Notify Posture Change (Posture Change)
This flow represents the notification of the VPN posture change sent from the VPN Posture Collector to the Standard Posture Broker Client. This is merely an event and does not include a message being sent.A.3.1.4. Request Posture (Req. Post)
This flow illustrates an invocation of the VPN Posture Collector requesting particular posture attributes to be sent. Because this use case is triggered locally, NEA does not specify the contents of this flow.A.3.1.5. Inspect/Request Info (Ins/Rq Info)
This flow illustrates the acquisition of the posture information by the VPN Posture Collector from the Vendor X and Vendor Y VPN Client components. Because this flow is triggered locally, NEA does not specify the message contents.
A.3.1.6. Vendor X VPN Posture (VPNX Post)
This flow contains the PA message from the VPN Posture Collector describing the Vendor X VPN Client's posture: Vendor X VPN Posture PA Message{ Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=2 (product information) length Value = { product-vendor-id=9876 (vendor X) product-id=567 (VPN client identifier for Vndr X) product-name="Vendor X VPN Client" } } Attribute 2 { vendor-id=0 type=5 (operational status) length Value = { Status=3 (Operational) Result=1 (Successful use with no errors detected) last Use="2008-07-07T12:00:00Z" } }
A.3.1.7. Vendor Y VPN Posture (VPNY Post)
This flow contains the PA message from the VPN Posture Collector including the Vendor Y VPN Client's posture: Vendor Y VPN Posture PA Message{ Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=2 (product information) length Value = { product-vendor-id=Vendor Y product-id=234 (VPN client identifier for Vndr Y) product-name="Vendor Y VPN Client" } } Attribute 2 { vendor-id=0 type=5 (operational status) length Value = { Status=3 (Operational) Result=1 (Successful use with no errors detected) last Use="2008-07-07T14:05:00Z" } } }A.3.1.8. Posture Report
This flow contains the PB message containing the PA message from the VPN Posture Collector; the message content is described in the PB-TNC specification.A.3.1.9. Verify Posture (Vrfy Post.)
This flow illustrates an invocation of the VPN Posture Validator requesting verification of the posture attributes received. Because this flow happens locally within the NEA Server, NEA does not specify the message contents.
A.3.1.10. VPN Posture Result (VPN PRslt)
This flow contains the PA message (Posture Assessment Result) from the VPN Posture Validator VPN Posture Result PA Message { Attribute HDR {Message ID} Attribute 1 { vendor-id=0 type=9 (assessment-result) length Value = { assessment-result=1 (non-compliant) } } }A.3.1.11. Assessment Result (Assess Result)
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the VPN Posture Validator; the message content is described in the PB-TNC specification.A.3.1.12. Posture Result (VPN PRslt)
This flow illustrates an invocation of the VPN Posture Collector to receive the posture assessment result. Because this flow is triggered locally, NEA does not specify the contents of this flow.
Appendix B. Evaluation against NEA Requirements
This section evaluates the PA-TNC protocol against the requirements defined in the NEA Requirements document. Each subsection considers a separate requirement from the NEA Requirements document. Only common requirements (C-1 through C-10) and PA requirements (PA-1 through PA-6) are considered, since these are the only ones that apply to PA.B.1. Evaluation against Requirement C-1
Requirement C-1 says: C-1 NEA protocols MUST support multiple round trips between the NEA Client and NEA Server in a single assessment. PA-TNC meets this requirement. It allows an unlimited number of round trips between the NEA Client and NEA Server.B.2. Evaluation against Requirement C-2
Requirement C-2 says: C-2 NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed. PA-TNC meets this requirement. PA-TNC is designed to work whether the NEA Client or the NEA Server initiates a posture assessment or reassessment.B.3. Evaluation against Requirement C-3
Requirement C-3 says: C-3 NEA protocols including security capabilities MUST be capable of protecting against active and passive attacks by intermediaries and endpoints including prevention from replay-based attacks. Security for PA-TNC messages being sent over the network is provided through PT protocol security. Therefore, PA-TNC does not include any security capabilities. Since this requirement only applies to NEA protocols "including security capabilities", this specification is not subject to this requirement (see section 5.2).
B.4. Evaluation against Requirement C-4
Requirement C-4 says: C-4 The PA and PB protocols MUST be capable of operating over any PT protocol. For example, the PB protocol must provide a transport- independent interface allowing the PA protocol to operate without change across a variety of network protocol environments (e.g., EAP/802.1X, PANA, TLS and IKE/IPsec). PA-TNC meets this requirement. PA-TNC can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. PA-TNC does not have any dependencies on specific details of the underlying PT protocol.B.5. Evaluation against Requirement C-5
Requirement C-5 says: C-5 The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones. The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist. Based on this requirement, PA-TNC should receive a strong preference. PA-TNC is equivalent with IF-M 1.0, an open TCG specification. Other specifications from TCG and other groups are also under development based on the IF-M 1.0 specification. Selecting PA-TNC as the basis for the PA protocol will ensure compatibility with IF-M 1.0, with these other specifications, and with their implementations.B.6. Evaluation against Requirement C-6
Requirement C-6 says: C-6 NEA protocols MUST be highly scalable; the protocols MUST support many Posture Collectors on a large number of NEA Clients to be assessed by numerous Posture Validators residing on multiple NEA Servers. PA-TNC meets this requirement. PA-TNC supports an unlimited number of Posture Collectors, Posture Validators, NEA Clients, and NEA Servers. It also is quite scalable in many other aspects as well. A PA-TNC message can contain up to 2^32-1 octets and about 2^28 PA-TNC attributes. Each organization with an SMI Private Enterprise Number is entitled to define up to 2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor-specific PA-TNC Product IDs, and 2^32 vendor-
specific PA-TNC Error Codes. Each attribute can contain almost 2^32 octets. It is generally not advisable or necessary to send this much data in a NEA assessment, but still PA-TNC is highly scalable and meets requirement C-6 easily.B.7. Evaluation against Requirement C-7
Requirement C-7 says: C-7 The protocols MUST support efficient transport of a large number of attribute messages between the NEA Client and the NEA Server. PA-TNC meets this requirement. Each PA-TNC message can contain about 2^28 PA-TNC attributes. PA-TNC supports up to 2^32 round trips in a session so the maximum number of attribute messages that can be sent in a single session is actually about 2^50. However, it is generally inadvisable and unnecessary to send a large number of messages in a NEA assessment. As for efficiency, PA-TNC adds only 12 octets of overhead per attribute and 8 octets per message (which is negligible on a per-attribute basis).B.8. Evaluation against Requirement C-8
Requirement C-8 says: C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links. PA-TNC meets this requirement. A PA-TNC exchange is envisioned (based on current deployment experience) to involve one or two round trips with less than 500 octets of PA-TNC messages. Of course, use of vendor-specific PA-TNC attribute types could expand the assessment. However, PA-TNC itself imposes an overhead of only 8 octets per PA-TNC message and 12 octets per attribute.B.9. Evaluation against Requirement C-9
Requirement C-9 says: C-9 For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences. PA-TNC meets this requirement. The only field included in a PB-TNC attribute for display to the user includes a language tag that could be selected based upon the user's PB-TNC negotiated preferred language for the assessment (see section 4.10 of the PB-TNC
specification). With this exception, all of the strings in the standard PA-TNC attributes are intended for logging and programmatic comparisons. If any vendor-specific PA-TNC attribute types or future IETF Standard PA-TNC Attribute Types include strings that are intended for display to a user, they should be translated to the user's preferred language. The Posture Broker Server will need to expose the user's preferences to the Posture Validators through whatever API or protocol is used to connect those components. However, that is all out of scope for this specification.B.10. Evaluation against Requirement C-10
Requirement C-10 says: C-10 NEA protocols MUST support encoding of strings in UTF-8 format. PA-TNC meets this requirement. All strings in the PA-TNC protocol are encoded in UTF-8 format. This allows the protocol to support a wide range of languages efficiently.B.11. Evaluation against Requirement C-11
Requirement C-11 says: C-11 Due to the potentially different transport characteristics provided by the underlying candidate PT protocols, the NEA Client and NEA Server MUST be capable of becoming aware of and adapting to the limitations of the available PT protocol. For example, some PT protocol characteristics that might impact the operation of PA and PB include restrictions on which end can initiate a NEA connection, maximum data size in a message or full assessment, upper bound on number of round trips, and ordering (duplex) of messages exchanged. The selection process for the PT protocols MUST consider the limitations the candidate PT protocol would impose upon the PA and PB protocols. PA-TNC meets this requirement. The design of the PA-TNC protocol emphasizes efficient transport of information in order to maximize its usability in constrained PT environments. Local APIs could allow Posture Collectors and Posture Validators to discover when they are operating in a less constrained deployment and then make use of more verbose attributes. Similarly, Posture Collectors could choose not to send or use smaller attributes (including assertions from previous assessments) when faced with a very constrained network connection.
B.12. Evaluation against Requirement PA-1
Requirement PA-1 says: PA-1 The PA protocol MUST support communication of an extensible set of NEA standards-defined attributes. These attributes will be uniquely identifiable from non-standard attributes. PA-TNC meets this requirement. Each attribute is identified with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. IETF Standard PA-TNC Attribute Types use a vendor ID of zero (0), in contrast with vendor-specific PA-TNC Attribute Types, which will use the vendor's SMI Private Enterprise Number as the vendor ID. The IANA will maintain a registry of PA-TNC Attribute Types with new values added by Expert Review with Specification Required, as described in the IANA Considerations section of this specification. Thus, the set of standard attribute types is extensible, but all standard attribute types are uniquely identifiable.B.13. Evaluation against Requirement PA-2
Requirement PA-2 says: PA-2 The PA protocol MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identifiable vendor-specific namespaces. PA-TNC meets this requirement. Each attribute is identified with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. Vendor- defined PA-TNC Attribute Types use the vendor's SMI Private Enterprise Number as the PA-TNC Attribute Vendor ID. Each vendor can define up to 2^32 PA-TNC Attribute Types, using its own internal processes to manage its set of attribute types. The IANA is not involved, other than the initial assignment of the vendor's SMI Private Enterprise Number. Thus, the set of vendor- specific attributes is segmented into uniquely identifiable vendor- specific namespaces.B.14. Evaluation against Requirement PA-3
Requirement PA-3 says: PA-3 The PA protocol MUST enable a Posture Validator to make one or more requests for attributes from a Posture Collector within a single assessment. This enables the Posture Validator to reassess the posture of a particular endpoint feature or to request additional posture including from other parts of the endpoint.
PA-TNC meets this requirement. The Attribute Request attribute type is an IETF Standard PA-TNC Attribute Type that permits a Posture Validator to send to one or more Posture Collectors a request for one or more attributes. This attribute may be sent at any point in the posture assessment process and may in fact be sent more than once if the Posture Validator needs to first determine the type of operating system and then request certain attributes specific to that operating system, for example.B.15. Evaluation against Requirement PA-4
Requirement PA-4 says: PA-4 The PA protocol MUST be capable of returning attributes from a Posture Validator to a Posture Collector. For example, this might enable the Posture Collector to learn the specific reason for a failed assessment and to aid in remediation and notification of the system owner. PA-TNC meets this requirement. A Posture Validator can easily send attributes to one or more Posture Collectors.B.16. Evaluation against Requirement PA-5
Requirement PA-5 says: PA-5 The PA protocol SHOULD provide authentication, integrity, and confidentiality of attributes communicated between a Posture Collector and Posture Validator. This enables end-to-end security across a NEA deployment that might involve traversal of several systems or trust boundaries. PA-TNC does not include an explicit PA-level security mechanism but does lay a foundation allowing attribute-level security protections to be added later. As an existence proof, the NEA working group considered an Internet-Draft proposal capable of encapsulating PA attributes within a Cryptographic Message Syntax (CMS) security wrapper in a new attribute type. This proposal offered the protections described in this requirement. However, the NEA WG decided that the use cases in scope for the working group did not require PA-level security. The use cases involving PA message traversal of multiple systems or trust boundaries were considered out of scope; therefore, a Posture Validator to Posture Collector end-to- end security protection was considered not to be required. Instead, PA-TNC attributes are protected by the PT layer authentication, integrity, and confidentiality support. This protects the attributes communicated between the Posture Transport
Client and Posture Transport Server. Because the Posture Collector is in the same address space as the Posture Broker Client and Posture Transport Client and the Posture Validator is in the same address space as the Posture Broker Server and Posture Transport Server, the underlying broker and transport components are deemed trusted with respect to not tampering with the PA messages (see trust model in section 5.1 for details). Encrypting the PA-TNC messages would not prevent a hostile broker or transport component from attacking the messages.B.17. Evaluation against Requirement PA-6
Requirement PA-6 says: PA-6 The PA protocol MUST be capable of carrying attributes that contain non-binary and binary data including encrypted content. PA-TNC meets this requirement. PA-TNC attributes can contain non- binary and binary data including encrypted content. For examples, see the attribute type definitions contained in this specification.Authors' Addresses
Paul Sangster Symantec Corporation 6825 Citrine Drive Carlsbad, CA 92009 USA EMail: Paul_Sangster@symantec.com Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA EMail: kaushik@cisco.com