RFC 5793
PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)
5. Security Considerations
PT is required and assumed to provide reliable and secure transport for the PB-TNC protocol (including authentication, confidentiality, integrity protection, and replay protection). Still, it is useful to describe the possible threats to PB-TNC and the countermeasures that are or can be employed. This section does that.5.1. Threat Model
There are several possible threats to the PB-TNC protocol. Untrusted intermediaries on the network between the NEA Client and the NEA Server may attempt to observe data sent between the Posture Broker Client and the Posture Broker Server via PB-TNC, modify this data in transit, reorder it, or replay it. They may also attempt to mount a denial-of-service attack against either party or truncate the exchange prematurely. If successful, these attacks may result in improper assessment decisions relating to the NEA Client, failure to reassess these decisions in light of changed circumstances, improper remediation instructions sent to the NEA Client (which could lead to the compromise of the NEA Client), unauthorized access to confidential information about the NEA Client's health and/or identity, improper reason strings or other messages that might be displayed to the user, access to reusable credentials such as posture assertions, denial of service on the NEA Client, and even complete denial of access to the network (if a denial-of-service attack against the NEA Server was successful and the network required permission from the NEA Server to grant network access). Trusted intermediaries between the Posture Broker Client and the Posture Broker Server include the Posture Transport Client and the Posture Transport Server. These parties are considered trusted because they are responsible for properly implementing the security protections provided by PT. If they fail to do so properly, these security protections may be diminished or eliminated altogether. The possible attacks are the same as those listed in the previous paragraph. To give one fairly likely example, if a Posture Transport Client fails to properly authenticate and authorize the Posture Transport Server (whether through implementation error or through user configuration to "trust anyone"), the improperly authorized Posture Transport Server may mount any of the previously described attacks against the NEA Client. Compromise of any of the trusted parties (the Posture Broker Client, the Posture Transport Client, the Posture Broker Server, or the Posture Transport Server) may result in failures that are equivalent to those listed in the first paragraph. These failures may be even
more dangerous since they will not be detectable by observing network traffic or by examining and comparing audit logs. Failure to properly secure communications between the Posture Broker Client and the Posture Transport Client or between the Posture Broker Server and the Posture Transport Server is usually indistinguishable from compromise of those parties. Compromise of the operating system or other critical software, firmware, or hardware components on the NEA Client or NEA Server will typically result in an equivalent result. And an attacker's ability to gain privileged access to the NEA Client or NEA Server (even for a brief time, long enough to disable or misconfigure security settings) is generally equivalent as well. If the NEA Client or NEA Server are dependent on other services for their proper operation (including Posture Collectors, Posture Validators, directories, and patch management services), compromise of those services may result in compromise or failure of the dependent parties. Of course, compromise or failure of NEA Server components is most serious since this would probably affect a large number of NEA Clients while the effects of NEA Client compromise might well be limited to a single machine.5.2. Countermeasures
The primary countermeasure against attacks by untrusted network intermediaries is the security provided by the PT protocol. Any candidate PT protocols should be carefully examined to ensure that all the threats described above are adequately addressed. As noted above, compromise or erroneous operation of any of the trusted parties is a serious matter with substantial security implications. This includes the Posture Broker Client, the Posture Broker Server, the Posture Transport Client, and the Posture Transport Server. These are all security-sensitive components so they should be built and managed in accordance with best practices for security devices. This is especially important for the NEA Server and its components since a compromise of this device would affect the security and availability of the entire network (similar to compromise of a AAA server). Communications between the trusted parties must also be secured. For example, if the Posture Broker Server and the Posture Transport Server are separate components, their communications must be secured. Since the NEA Client may be a mobile device with little physical security (such as a laptop computer or even a public telephone), it should generally be assumed that some proportion of Access NEA Clients will be compromised and therefore hostile. The NEA Server should be designed to be robust against hostile NEA Clients. Once a
compromised NEA Client is detected, it can be treated in a manner equivalent to an untrusted party and should pose no greater threat than any other untrusted party. Countermeasures against a compromised NEA Server (or a component thereof such as a Posture Broker Server or a Posture Transport Server) include prevention of compromise, detection of compromise, and mitigation of the effects of compromise. For prevention, the NEA Server and its components and dependencies should be implemented using secure implementation techniques (e.g., secure coding and minimization) and managed using secure practices (e.g., strong authentication and separation of duty). For detection, the behavior of the NEA Server should be monitored (e.g., via logging especially of remediation instructions, intrusion detection systems, and probes that impersonate a valid NEA Client and record NEA Server behavior) and any anomalies analyzed. For mitigation, NEA Clients should not blindly follow remediation instructions received from a trusted NEA Server. At least for patches and other dangerous actions, they should validate these actions (e.g., via user confirmation) before proceeding. It should not be possible to configure a NEA Client to trust all NEA Servers without proper authentication and authorization.6. IANA Considerations
Four new IANA registries are defined by this specification: PB-TNC Message Types, PA Subtypes, PB-TNC Remediation Parameters Types, and PB-TNC Error Codes. This section explains how these registries work. All of these registries support IETF standard values and vendor- defined values. To explain this phenomenon, we will use the PB-TNC Message Type as an example but the other three registries work the same way. Whenever a PB-TNC Message Type appears on a network, it is always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID. If this vendor ID is zero, the accompanying PB-TNC Message Type is an IETF standard value listed in the IANA registry for PB-TNC Message Types and its meaning is defined in the specification listed for that PB-TNC Message Type in that registry. If the vendor ID is not zero, the meaning of the PB-TNC Message Type is defined by the vendor identified by the vendor ID (as listed in the IANA registry for SMI PENs). The identified vendor is encouraged but not required to register with IANA some or all of the PB-TNC Message Types used with their vendor ID and publish a specification for each of these values. This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such
behavior is explicitly prohibited by this specification, which dictates that "Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types and MUST interoperate with other parties despite any differences in the set of vendor-specific PB-TNC message types supported (although they MAY permit administrators to configure them to require support for specific PB-TNC message types)." Similar requirements are included for PA Subtypes, Remediation Parameters Types, and PB-TNC Error Codes.6.1. Designated Expert Guidelines
For all of the four IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [5]. This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for these registries. The registries defined in this document have plenty of values. In most cases, the IETF has approximately 2^32 values available for it to define and each vendor the same number of values for its use. The only exception is the registry for PB-TNC Error Codes where 2^16 values are available for the IETF and 2^16 values for each vendor. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values. Instead, designated experts should focus on the following requirements. All values in these IANA registries MUST be documented in a specification that is permanently and publicly available. IETF standard values MUST also be useful, not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability. Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single IETF standard value. However, it is beneficial to document existing practice. There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor MUST supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if at some point the document becomes no longer freely available to all through other channels.
6.2. Registry for PB-TNC Message Types
The name for this registry is "PB-TNC Message Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-2, and a reference to a specification where the contents of this message type are defined. This specification must define the meaning of this PB-TNC message type and the format and semantics of the PB-TNC Message Value field for PB-TNC messages that include the designated numeric value in the PB-TNC Message Type field and the designated Private Enterprise Number in the PB-TNC Vendor ID field. Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Message Types. PEN Integer Name Defining Specification --- ------- ---- ---------------------- 0 0 PB-Experimental RFC 5793 0 1 PB-PA RFC 5793 0 2 PB-Assessment-Result RFC 5793 0 3 PB-Access-Recommendation RFC 5793 0 4 PB-Remediation-Parameters RFC 5793 0 5 PB-Error RFC 5793 0 6 PB-Language-Preference RFC 5793 0 7 PB-Reason-String RFC 5793 0 0xffffffff Reserved RFC 57936.3. Registry for PA Subtypes
The name for this registry is "PA Subtypes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-2, and a reference to a specification where the contents of this PA subtype are defined. This specification must define the meaning of this PA subtype and the format and semantics of the PA Message Body field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-PA, the designated numeric value in the PA Subtype field, and the designated Private Enterprise Number in the PA Message Vendor ID field. Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
This document does not define any initial entries for this registry. Therefore, this registry should initially be empty. Subsequent RFCs (such as PA-TNC) will define entries in this registry.6.4. Registry for PB-TNC Remediation Parameters Types
The name for this registry is "PB-TNC Remediation Parameters Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference to a specification where the contents of this remediation parameters type are defined. This specification must define the meaning of this remediation parameters type value and the format and semantics of the Remediation Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Remediation-Parameters, the designated numeric value in the Remediation Parameters Type field, and the designated Private Enterprise Number in the Remediation Parameters Vendor ID field. Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Remediation Parameters Types. PEN Integer Name Defining Specification --- ------- ---- ---------------------- 0 1 Remediation-URI RFC 5793 0 2 Remediation-String RFC 57936.5. Registry for PB-TNC Error Codes
The name for this registry is "PB-TNC Error Codes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^16-1, and a reference to a specification where this error code is defined. This specification must define the meaning of this error code and the format and semantics of the Error Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Error, the designated numeric value in the Error Code field, and the designated Private Enterprise Number in the Error Code Vendor ID field. Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Error Codes.
PEN Integer Name Defining Specification --- ------- ---- ---------------------- 0 0 Unexpected Batch Type RFC 5793 0 1 Invalid Parameter RFC 5793 0 2 Local Error RFC 5793 0 3 Unsupported Mandatory Message RFC 5793 0 4 Version Not Supported RFC 57937. Acknowledgments
Thanks to the Trusted Computing Group for contributing the initial text upon which this document was based. The authors of this document would like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Bernard Aboba, Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen, Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin, Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad, Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali, Guha Prasad Venataraman, John Vollbrecht, Jun Wang, and Han Yin.8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [3] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.8.2. Informative References
[7] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV Binding", Trusted Computing Group, February 2008. [8] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008. [9] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [10] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
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 PRslt | | | |
| |<----------| | | |
| VndrX Patch PResult | | | |
|<--------------------| | | |
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 doesn't 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, NEA doesn't specify the contents of this flow.A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)
This flow contains the PA message from the Vendor X Patch Posture Collector; the message content is described in the PA-TNC specification.A.1.1.4. OS Posture
This flow contains the PA message from the OS Posture Collector; the message content is described in the PA-TNC specification.A.1.1.5. Posture Report
This flow contains the PB message containing the PA messages from the Patch and OS Posture Collectors: PB Envelope { HDR { D bit=0 (Posture Broker Client is originator) Batch Type=CDATA Batch Length } PB Message 1 { Vendor-id=0 Type =2 (PB-PA) Length Value = { PA-Msg-vendor-id=0 (Standard) PA-subtype=1 (OS)
OS Posture PA Message
}
}
PB Message 2 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=1 (Vendor X PA sub-type for patch management)
Vendor X Patch Posture PA Message
}
}
}
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 doesn't specify the message content.
A.1.1.7. OS Posture Result (OS Reslt)
This flow contains the PA message (Posture Assessment Result) from
the OS Posture Validator; the message content is described in the PA-
TNC specification.
A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result)
This flow contains the PA message (Posture Assessment Result) from
the Vendor X Patch Posture Validator; the message content is
described in the PA-TNC specification.
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: PB Envelope { HDR { D bit=1 (Posture Broker Server is originator) Batch Type=RESULT Batch Length } PB Message 1 { Vendor-id=0, Type =3 (Access-Recommendation) Length Value = { System-Evaluation-Result=0 (Compliant) } } PB Message 2 { Vendor-id=0, Type=2 (PB-PA) Length Value = { PA-Msg-vendor-id=0 PA-subtype=1 (OS)
OS Posture Result PA Message
}
}
PB Message 3 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=1 (Vendor X PA sub-type for patch management)
Vendor X Patch Posture Result PA Message
}
}
}
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 doesn't 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. 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 Posture 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 Posture 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 doesn't 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 requesting posture requests to be created. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV Post. Req)
This flow contains the PA message (Posture Request) from the Vendor X Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.A.2.1.4. Vendor Y Anti-Virus Posture Request
This flow contains the PA message (Posture Request) from the Vendor Y Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.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: PB Envelope { HDR { D bit=1 (Posture Broker Server is originator) Batch Type=SDATA Batch Length
}
PB Message 1 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture Request PA Message
}
}
PB Message 2 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture Request PA Message
}
}
}
A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr Y AV Posture Req)
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to process the Posture Request and return particular posture attributes requested. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.A.2.1.7. Vendor Y Anti-Virus Posture (Vndr Y AV Posture)
This flow contains the PA message (response to the Posture Request) from the Vendor Y Anti-Virus Posture Collector; the message content is described in the PA-TNC specification.A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture)
This flow contains the PA message (response to the Posture Request) from the Vendor X Anti-Virus Posture Collector; the message content is described in the PA-TNC specification.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: PB Envelope { HDR { D bit=0 (Posture Broker Client is originator) Batch Type=CDATA Batch Length } PB Message 1 { Vendor-id=0 Type =2 (PB-PA) Length Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture PA Message
}
}
PB Message 2 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture PA Message
}
}
}
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 doesn't specify the message contents.
A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post Result)
This flow contains the PA message (Posture Assessment Result) from
the Vendor Y Anti-Virus Posture Validator; the message content is
described in the PA-TNC specification.
A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post Result)
This flow contains the PA message (Posture Assessment Result) from the Vendor X Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.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 Patch and OS Posture Validators: PB Envelope { HDR { D bit=1 (Posture Broker Server is originator) Batch Type=RESULT Batch Length } PB Message 1 { Vendor-id=0, Type=3 (Access-Recommendation) Length Value = { PB-Assessment-Result=1 (Non-Compliant) } } PB Message 2 { Vendor-id=0, Type=4 (Remediation-Parameters) Length
Value = {
Remediation-Param-Vendor-ID=0
Remediation-Param-Type=1 (Remediation-URI)
Remediation-Param=''http://xyz''
}
}
PB Message 3 {
Vendor-id=0,
Type=4 (Remediation-Parameters)
Length
Value = {
Remediation-Param-Vendor-ID=0
Remediation-Param-Type=2 (Remediation-String)
Remediation-Param=''Try Step1, Step2,...''
}
}
PB Message 4 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture Result PA Message
}
}
PB Message 5 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture Result PA Message
}
}
}
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 doesn't 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 posture
policy. The Posture Broker Client triggers the posture assessment
when it receives a notification from the Standard VPN Posture
Collector about the change to the operational state of the VPN
component on the endpoint. Note that the VPN Posture Collector
supports standard attributes and some vendor-defined attributes from
vendor X's and vendor Y's namespaces. This use case doesn't 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 a virtual Posture Collector concept described in section 3.3 of the PA-TNC specification. As illustrated in this example, the Posture Broker Client will assign two Posture Collector IDs to a single Posture Collector (Standard VPN PC), and the Posture Collector will generate two separate PA messages to report the posture for Vendor X and Vendor Y VPN Clients. The Posture Broker Client will use 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 doesn't
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 Standard VPN Posture Collector. This is
merely an event and doesn't 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 doesn't 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, the contents of this flow aren't specified by NEA.A.3.1.5. Inspect/Request Information (Ins/Rq Info)
This flow illustrates the acquisition of the posture attributes by the Standard VPN Posture Collector from the Vendor X and Vendor Y VPN Client components. Because this flow is triggered locally, NEA doesn't 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 for Vendor X VPN Client posture; the message content is described in the PA-TNC specification.A.3.1.7. Vendor Y VPN Posture (VPNY Post.)
This flow contains the PA message from the VPN Posture Collector for Vendor Y VPN Client posture; the message content is described in the PA-TNC specification.A.3.1.8. Posture Report (Post. Rpt.)
This flow contains the PB message containing the PA message from the VPN Posture Collector: PB Envelope { HDR { D bit=0 (Posture Broker Client is originator) Batch Type=CRETRY Batch Length }
PB Message 1 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
Posture-Collector-ID=1 //Virtual Posture Collector ID for
Vendor X VPN Client
Vendor X VPN Posture PA Message
}
}
PB Message 2 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
Posture-Collector-ID=2 //Virtual Posture Collector ID for
Vendor Y VPN Client
Vendor Y VPN Posture PA Message
}
}
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 doesn't 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; the message content is described in the PA-TNC specification.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: PB Envelope { HDR { D bit=1 (Posture Broker Server is originator) Batch Type=RESULT Batch Length } PB Message 1 { Vendor-id=0, Type =3 (Access-Recommendation) Length Value = { PB-Assessment-Result=1 (Non-Compliant) } }
PB Message 2 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
VPN Posture Result PA Message
}
}
A.3.1.12. Posture Result (VPN PRslt)
This flow illustrate an invocation of the VPN Posture Collectors to
receive the posture assessment result. Because this flow is
triggered locally, NEA doesn't specify the contents of this flow.
Appendix B. Evaluation against NEA Requirements
This section evaluates the PB-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-11) and PB requirements (PB-1 through PB-6) are considered, since these are the only ones that apply to PB.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. PB-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. PB-TNC meets this requirement. Either the NEA Client or the NEA Server can initiate a posture assessment or reassessment. There is one limitation on this support. If a NEA Server wishes to initiate a reassessment after it has sent a RESULT batch, it must close the underlying transport session and initiate a new assessment. For half-duplex transports, this is unavoidable unless a constant exchange of messages is maintained, which would be very wasteful. For full-duplex transports, it would be possible to allow the Posture Broker Server to send an SRETRY batch even in the Decided state. If the NEA working group reaches consensus that this change should be made, it will be.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.
PB-TNC does not include any security capabilities. It depends on PT to supply a secure transport. This addresses all the necessary threats without adding an extra layer of security. Since this requirement only applies to NEA protocols that include security capabilities, PB-TNC meets this requirement.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). PB-TNC meets this requirement. PB-TNC can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. Also, PB-TNC insulates the PA protocol from any specifics of the PT protocol. With PB-TNC, all PT protocols are equivalent from the perspective of the PA 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, PB-TNC should receive a strong preference. PB-TNC is equivalent with IF-TNCCS 2.0, an open TCG specification. IF-TNCCS 2.0 is an extension of the existing IF-TNCCS 1.X protocols, which have been implemented by dozens of vendors and open source projects.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.
PB-TNC meets this requirement. PB-TNC supports up to 2^16-1 Posture Collectors and an equal number of Posture Validators in a given PB- TNC session. It also supports an unlimited number of NEA Clients and NEA Servers. The scalability of PB-TNC extends into other areas as well. For example, PB-TNC supports an unlimited number of batches and each batch can contain up to 2^32-1 octets and about 2^24 PA messages. Each PA message can contain up to 2^32-1 octets. Of course, sending this much data in a NEA assessment is not generally advisable, but the point is that PB-TNC is highly scalable.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. PB-TNC meets this requirement. Each PB-TNC batch can contain about 2^24 PA messages. Since PB-TNC supports an unlimited number of batches in a session, this number is actually unlimited (except perhaps by PT protocols, user patience, or other external factors). As for efficiency, PB-TNC adds only 24 octets of overhead per PA message. PA-TNC can include many attributes in a single PA message so this overhead is diluted further.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. PB-TNC meets this requirement. A minimal PB-TNC exchange can be as small as 72 octets and one round trip. Even if privacy policies or other factors require multiple round trips, PB-TNC generally imposes an overhead of only 8 octets per batch and 24 octets per PA message.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.
PB-TNC meets this requirement. It defines a standard way for
the NEA Client and NEA Server to send their language
preferences to each other, leveraging the widely implemented
Accept-Language format defined in RFC 3282.
B.10. Evaluation against Requirement C-10
Requirement C-10 says:
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.
PB-TNC meets this requirement. All strings in the PB-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.
PB-TNC meets this requirement. The PB-TNC protocol is designed to be
flexible enough to operate with a variety of underlying PT protocols,
including those that may have limitations on message or assessment
size, number of round trips, and duplex. Local APIs can 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 PB-1
Requirement PB-1 says: PB-1 The PB protocol MUST be capable of carrying attributes from the Posture Broker Server to the Posture Broker Client. This enables the Posture Broker Client to learn the posture assessment decision and if appropriate to aid in remediation and notification of the endpoint owner. PB-TNC meets this requirement. It can carry attributes from the Posture Broker Client to the Posture Broker Server and back in an unlimited number of round trips. Furthermore, PB-TNC provides explicit attribute support for posture decision and remediation aid notification.B.13. Evaluation against Requirement PB-2
Requirement PB-2 says: PB-2 The PB protocol MUST NOT interpret the contents of PA messages being carried; i.e., the data it is carrying must be opaque to it. PB-TNC meets this requirement. It does not parse or interpret PA messages in any way.B.14. Evaluation against Requirement PB-3
Requirement PB-3 says: PB-3 The PB protocol MUST carry unique identifiers that are used by the Posture Brokers to route (deliver) PA messages between Posture Collectors and Posture Validators. Such message routing should facilitate dynamic registration or deregistration of Posture Collectors and Validators. For example, a dynamically registered anti-virus Posture Validator should be able to subscribe to receive messages from its respective anti-virus Posture Collector on NEA Clients. PB-TNC meets this requirement. PB-TNC tags each PA message with a PA subtype that the Posture Brokers can use to deliver the PA messages to the proper Posture Collectors and Posture Validators. By tagging messages according to their content, PB-TNC allows Posture Collectors and Posture Validators to be dynamically registered and deregistered, ensuring that each one receives the proper data. PB-TNC also supports exclusive delivery, which allows messages to be targeted at a particular Posture Collector or Posture Validator.
B.15. Evaluation against Requirement PB-4
Requirement PB-4 says: PB-4 The PB protocol MUST be capable of supporting a half-duplex PT protocol. However, this does not preclude PB from operating full-duplex when running over a full-duplex PT. PB-TNC meets this requirement. In order to insulate PA from any differences between half-duplex and full-duplex PT protocols, PB-TNC always operates in a half-duplex mode, regardless of the capabilities of the PT protocol. While this could in theory slow assessments that require many round trips or bidirectional multimedia exchanges, this is not a problem in practice because endpoint assessments do not typically involve multimedia or a large number of round trips.B.16. Evaluation against Requirement PB-5
Requirement PB-5 says: PB-5 The PB protocol MAY support authentication, integrity, and confidentiality protection for the attribute messages it carries between a Posture Broker Client and Posture Broker Server. This provides security protection for a message dialog of the groupings of attribute messages exchanged between the Posture Broker Client and Posture Broker Server. Such protection is orthogonal to PA protections (which are end to end) and allows for simpler Posture Collector and Validators to be implemented, and for consolidation of cryptographic operations possibly improving scalability and manageability. PB-TNC does not address this optional requirement. It leaves security to PT (which is required to address it) and PA (which SHOULD do so). There seems to be minimal benefit in adding a third layer of security to the NEA protocol stack. However, if the NEA working group determines that PB should include support for authentication, integrity protection, and confidentiality protection, then this could be added to PB in a similar manner to the way that the PA-TNC security is done.
B.17. Evaluation against Requirement PB-6
Requirement PB-6 says: PB-6 The PB protocol MUST support grouping of attribute messages to optimize transport of messages and minimize round trips. PB-TNC meets this requirement. Multiple attribute messages can be conveyed in a single PA message. In fact, that's how PA-TNC works.Authors' Addresses
Ravi Sahita Intel Corporation 2200 Mission College Blvd. Santa Clara, CA 95054 USA EMail: Ravi.Sahita@intel.com Steve Hanna Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA EMail: shanna@juniper.net Ryan Hurst Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: Ryan.Hurst@microsoft.com Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA EMail: kaushik@cisco.com