Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5793

PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)

Pages: 76
Proposed Standard
Errata
Part 3 of 3 – Pages 41 to 76
First   Prev   None

Top   ToC   RFC5793 - Page 41   prevText

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
Top   ToC   RFC5793 - Page 42
   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
Top   ToC   RFC5793 - Page 43
   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
Top   ToC   RFC5793 - Page 44
   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.
Top   ToC   RFC5793 - Page 45

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 5793

6.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.
Top   ToC   RFC5793 - Page 46
   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 5793

6.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.
Top   ToC   RFC5793 - Page 47
   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 5793

7. 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.
Top   ToC   RFC5793 - Page 48
   [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.
Top   ToC   RFC5793 - Page 49

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 | | | | | +-------->| | |
Top   ToC   RFC5793 - Page 50
      |         |           |         |  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.
Top   ToC   RFC5793 - Page 51
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)
Top   ToC   RFC5793 - Page 52
          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.
Top   ToC   RFC5793 - Page 53
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)
Top   ToC   RFC5793 - Page 54
          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.
Top   ToC   RFC5793 - Page 55
   +--------+  +-------+ +---------+ +--------+ +-------+ +--------+

   | 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   |         |          |          |
Top   ToC   RFC5793 - Page 56
        +----------+---------->|         |          |          |

        |          | 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 |         |          |          |

        +<---------+-----------|         |          |          |

        |          |           |         |          |          |
Top   ToC   RFC5793 - Page 57

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
Top   ToC   RFC5793 - Page 58
    }

     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

        }

      }

   }
Top   ToC   RFC5793 - Page 59
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 = {
Top   ToC   RFC5793 - Page 60
           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.
Top   ToC   RFC5793 - Page 61
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
Top   ToC   RFC5793 - Page 62
       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
Top   ToC   RFC5793 - Page 63
        }

      }

     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
Top   ToC   RFC5793 - Page 64
   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|          |           |
Top   ToC   RFC5793 - Page 65
        |          |           |-------->|          |           |

        |          |           |         | 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.
Top   ToC   RFC5793 - Page 66
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 }
Top   ToC   RFC5793 - Page 67
     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

       }

     }
Top   ToC   RFC5793 - Page 68
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) } }
Top   ToC   RFC5793 - Page 69
     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.
Top   ToC   RFC5793 - Page 70

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.
Top   ToC   RFC5793 - Page 71
   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.
Top   ToC   RFC5793 - Page 72
   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.
Top   ToC   RFC5793 - Page 73
         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.
Top   ToC   RFC5793 - Page 74

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.
Top   ToC   RFC5793 - Page 75

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.
Top   ToC   RFC5793 - Page 76

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