tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5793

 
 
 

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

Part 3 of 3, p. 41 to 76
Prev RFC Part

 


prevText      Top      Up      ToC       Page 41 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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