tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5792

 
 
 

PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)

Part 4 of 4, p. 59 to 83
Prev RFC Part

 


prevText      Top      Up      ToC       Page 59 
9.  References

9.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
         63, RFC 3629, November 2003.

   [3]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

   [4]   Klyne, G. and C. Newman, "Date and Time on the Internet:
         Timestamps", RFC 3339, July 2002.

   [5]   Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A
         Posture Broker (PB) Protocol Compatible with Trusted Network
         Connect (TNC)", RFC 5793, March 2010.

   [6]   Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying
         Languages", BCP 47, RFC 5646, September 2009.

   [7]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.

9.2.  Informative References

   [8]   Trusted Computing Group, "IF-M: TLV Binding",
         http://www.trustedcomputinggroup.org/resources/
         tnc_ifm_tlv_binding_specification, February 2010.

   [9]   Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
         Tardo, "Network Endpoint Assessment (NEA): Overview and
         Requirements", RFC 5209, June 2008.

Top      Up      ToC       Page 60 
Appendix A.  Use Cases

A.1.  Initial Client-Triggered Assessment

   This scenario involves the assessment of an endpoint initiated during
   network join.  The assessment is triggered by the Posture Broker
   Client (PBC) and involves collection of patch information from both
   Standard Operating System (OS) Posture Collector and vendor-specific
   Patch Posture Collector (PC).  The assessment by both the vendor-
   specific Patch Posture Validator (PV) and Standard OS Posture
   Validator result in a compliant assessment decision that results in a
   compliant System Assessment Decision to be returned by the Posture
   Broker Server (PBS).

   +--------+ +-------+ +---------+ +--------+ +-------++--------+
   | Vndr. X| |  Std. | |   Std.  | |  Std.  | | Std.  || Vndr. X|
   |Patch PC| | OS PC | |   PBC   | |  PBS   | | OS PV ||Patch PV|
   +--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
      |         |   N/W Join|         |          |         |
      |         |     ----->|         |          |         |
      |         | Req Post. |         |          |         |
      |         |<----------|         |          |         |
      |         | Req Post. |         |          |         |
      |<--------------------|         |          |         |
      |Vndr X Patch Posture |         |          |         |
      |-------------------->|         |          |         |
      |         |OS Posture |         |          |         |
      |         |---------->|         |          |         |
      |         |           | Posture |          |         |
      |         |           | Report  |          |         |
      |         |           |-------->|          |         |
      |         |           |         |  Verify  |         |
      |         |           |         |  Posture |         |
      |         |           |         |--------->          |
      |         |           |         |          | Verify  |
      |         |           |         |          | Posture |
      |         |           |         |------------------->|
      |         |           |         | OS Reslt |         |
      |         |           |         |<---------|         |
      |         |           |         | VndrX Patch Result |
      |         |           | Assess  |<-------------------|
      |         |           | Result  |                    |
      |         |           |<--------|          |         |
      |         | OS Reslt  |         |          |         |
      |         |<----------|         |          |         |
      | VndrX Patch Result  |         |          |         |
      |<--------------------|         |          |         |

Top      Up      ToC       Page 61 
A.1.1.  Message Contents

   This section shows the contents of the key fields in each of the PA
   messages exchanged in this use case.  When necessary, additional
   commentary is provided to explain why certain fields contain the
   shown values.  Note that many of the flows shown are between
   components on the same system so no message contents are shown.

A.1.1.1.  N/W Join

   This flow represents the event that causes the PBC to decide to start
   an assessment of the endpoint in order to gain access to the network.
   This is merely an event and does not include a message being sent.

A.1.1.2.  Request Posture (Req Post.)

   This flow illustrates an invocation of the OS and patch posture
   collectors requesting particular posture attributes to be sent.
   Because this use case is triggered locally, the contents of this flow
   aren't specified by NEA.

A.1.1.3.  Vendor X Patch Posture (VndrX Patch Posture)

   This flow contains the PA message from the Patch Posture Collector:

   Vendor X Patch Posture PA Message  {
      Attribute HDR {Message ID}
      Attribute 1 {
         vendor-id=1 (vendor X)
         type=1 (Vendor X namespace attribute)
         length
         Value = {
            VendorXAttribute1=123
         }
      }
      Attribute 2 {
         vendor-id=1 (vendor X)
         type=2 (Vendor X namespace attribute)
         length
         Value = {
            VendorXAttribute2=456
         }
      }
   }

Top      Up      ToC       Page 62 
A.1.1.4.  OS Posture

   This flow contains the PA message from the OS Posture Collector:

   OS Posture PA Message  {

      Attribute HDR {Message ID}
      Attribute 1 {
         vendor-id=0
         type=2 (product information)
         length
         Value = {
            Product-vendor-id=311   -- Microsoft's PEN
            Product-name="Windows Vista"
         }
      }
      Attribute 2 {
         vendor-id=0
         type=3 (numeric version)
         length
         Value = {
            major-version=6     -- Vista is version 6.0
            minor-version=0
            build-number=456789
            service-pack-major=0   -- No service packs
            service-pack-minor=0
         }
      }
   }

A.1.1.5.  Posture Report

   This flow contains the PB message containing the PA messages from the
   Patch and OS Posture Collectors; the message content is described in
   the PB-TNC specification.

A.1.1.6.  Verify Posture

   This flow illustrates an invocation of the OS and patch Posture
   Validators requesting verification of the posture attributes
   received.  Because this flow happens locally within the NEA server,
   NEA does not specify the message contents.

Top      Up      ToC       Page 63 
A.1.1.7.  OS Posture Result (OS Reslt)

   This flow contains the PA message (Posture Assessment Result) from
   the OS Posture Validator

   OS Posture Result PA Message {
      Attribute HDR {Message ID}
         Attribute 1 {
              vendor-id=0
              type=9 (assessment-result)
              length
              Value = {
                 assessment-result=0 (compliant)
              }
        }
    }

A.1.1.8.  Vendor X Patch Result (VndrX Patch Result)

   This flow contains the PA message (Posture Assessment Result) from
   the Vendor X Patch Posture Validator

   Patch Vendor X Posture Result PA Message {
      Attribute HDR {Message ID}
         Attribute 1 {
              vendor-id=0
              type=9 (assessment-result)
              length
              Value = {
                 assessment-result=0 (compliant)
              }
         }
    }

A.1.1.9.  Assessment Result (Assess Result)

   This flow contains the PB message containing the system assessment
   result computed by the Posture Broker Server and the PA messages from
   the Patch and OS Posture Validators; the message content is described
   in the PB-TNC specification.

A.1.1.10.  Posture Result (OS PRslt & Vndr X Post PResult)

   These flows illustrate an invocation of the OS and Vendor X Patch
   Posture Collectors to receive the posture assessment results.
   Because this flow is triggered locally, NEA does not specify the
   contents of this flow.

Top      Up      ToC       Page 64 
A.2.  Server-Initiated Assessment with Remediation

   This scenario involves the assessment of an endpoint initiated by the
   NEA Server.  The assessment is triggered by the Posture Broker Server
   and involves collection of Anti-Virus attributes for two Anti-Virus
   components running on the endpoint.  The endpoint is assessed to be
   compliant by one of the vendor (Vendor X) anti-virus Posture
   Validators and non-compliant by the other vendor (Vendor Y) anti-
   virus Posture Validator.  Based upon the Posture Broker Server's
   policy, this results in a non-compliant system assessment decision to
   be returned by the Posture Broker Server.  The Posture Broker Server
   also returns remediation instructions for the endpoint as part of the
   response.

Top      Up      ToC       Page 65 
   +--------+  +-------+ +---------+ +--------+ +-------+ +--------+
   | Vndr Y |  | Vndr X| |   Std.  | |  Std.  | | Vndr X| | Vndr Y |
   |  AV PC |  | AV PC | |   PBC   | |  PBS   | | AV PV | |  AV PV |
   +----+---+  +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
        |          |           | N/W Join|          |          |
        |          |           | ------->|          |          |
        |          |           |         |  Create  |          |
        |          |           |         |Post. Req |          |
        |          |           |         |--------->|          |
        |          |           |         |Create Posture Req   |
        |          |           |         |----------+--------->|
        |          |           |         | Vndr Y AV Post Req  |
        |          |           |         |<---------+----------|
        |          |           |         |Vndr X AV |          |
        |          |           |         |Post. Req |          |
        |          |           | Posture |<---------|          |
        |          |           | Request |          |          |
        |          | Vndr X AV |<--------|          |          |
        |          | Post. Req |         |          |          |
        |          |<----------|         |          |          |
        |      Vndr Y AV       |         |          |          |
        |     Posture Req      |         |          |          |
        +<---------+-----------|         |          |          |
        |  Vndr Y AV Posture   |         |          |          |
        +----------+---------->|         |          |          |
        |          | Vndr X AV |         |          |          |
        |          |  Posture  |         |          |          |
        |          |---------->| Posture |          |          |
        |          |           |Response |          |          |
        |          |           |-------->|          |          |
        |          |           |         |  Verify  |          |
        |          |           |         |  Posture |          |
        |          |           |         |--------->|          |
        |          |           |         |     Verify Posture  |
        |          |           |         |----------+--------->|
        |          |           |         |Vndr Y AV Post Result|
        |          |           |         |<---------+----------|
        |          |           |         |Vndr X AV |          |
        |          |           |         |Post Reslt|          |
        |          |           |  Assess |<---------|          |
        |          |           |  Result |          |          |
        |          | Vndr X AV |<--------|          |          |
        |          |Post Reslt |<--------|          |          |
        |          |<----------|         |          |          |
        | Vndr Y AV Post Reslt |         |          |          |
        +<---------+-----------|         |          |          |

Top      Up      ToC       Page 66 
A.2.1.  Message Contents

   This section shows the contents of the key fields in each of the PA
   messages exchanged in this use case.  When necessary, additional
   commentary is provided to explain why certain fields contain the
   shown values.  Note that many of the flows shown are between
   components on the same system so no message contents are shown.

A.2.1.1.  N/W Join

   This flow represents the event that causes the PBS to decide to start
   an assessment of the endpoint in order to gain access to the network.
   This is merely an event and does not include a message being sent.

A.2.1.2.  Create Posture Request (Create Posture Req)

   This flow illustrates an invocation of the Vendor X and Vendor Y
   Anti-Virus Posture Validators enabling posture request attributes to
   be created.  Because this use case is triggered locally, NEA does not
   specify the contents of this flow.

A.2.1.3.  Vendor Y AV Posture Request (Vndr Y AV Posture Req)

   This flow contains the PA message (Posture Request) from the Vendor Y
   Anti-Virus Posture Validator

   Vendor Y AV Posture Request PA Message {
       Attribute HDR {Message ID}
          Attribute 1 {
              vendor-id=0
              type=1 (Attribute Request)
              length
              Value = {
                 Vendor-id=0 (IETF Standard)
                 Type=2 (Standard attribute, Product-Information)
                 Vendor-id=1 (Vendor Y)
                 Type=2 (Vendor Y attribute, Extended-Dat-Version)
               }
          }
   }

Top      Up      ToC       Page 67 
A.2.1.4.  Vendor X AV Posture Request (Vndr X AV Post. Req)

   This flow contains the PA message (Posture Request) from the Vendor X
   Anti-Virus Posture Validator

   Vendor X AV Posture Request PA Message {
       Attribute HDR {Message ID}
          Attribute 1 {
              vendor-id=0
              type=1 (Attribute Request)
              length
              Value = {
                 Vendor-id=1 (Vendor X)
                 Type=1 (Vendor X attribute, Scan-Engine-Version)
                 Vendor-id=0 (IETF Standard)
                 Type=5 (Standard, Operational-Status)
              }
          }
    }

A.2.1.5.  Posture Request

   This flow contains the PB message containing the PA messages from the
   Vendor X and Vendor Y Anti-Virus Posture Validators; the message
   content is described in the PB-TNC specification.

A.2.1.6.  Posture Request (Vndr X AV Post Req & Vndr Y AV Post Req)

   These flows illustrate an invocation of the Vendor X and Vendor Y
   Anti-Virus Posture Collectors to process the Posture Request and
   return the particular posture attributes requested.  Because this
   flow is triggered locally, NEA does not specify the contents of this
   flow.

Top      Up      ToC       Page 68 
A.2.1.7.  Vendor Y AV Posture (Vndr Y AV Posture)

   This flow contains the PA message (response to the Posture Request)
   from the Vendor Y Anti-Virus Posture Collector.

   Vendor Y AV Posture PA Message {
     Attribute HDR {Message ID}
         Attribute 1 {
            vendor-id=0 (IETF Standard)
            Type=2 (Standard attribute, Product-Information)
            length
            Value = {
               product-vendor-id=12345 (vendor Y)
               product-id=987 (AV product id from vendor Y)
               product-name="Vendor Y Anti-Virus"
            }
         }
         Attribute 2 {
            vendor-id=2 (vendor Y)
            type=2 (vendor Y attribute, DAT-Version)
            length
            Value = {
               DAT-version=5678
            }
         }
     }

Top      Up      ToC       Page 69 
A.2.1.8.  Vendor X AV Posture (Vndr X AV Posture)

   This flow contains the PA message (response to the Posture Request)
   from the Vendor X Anti-Virus Posture Collector.

   Vendor X AV Posture PA Message {
      Attribute HDR {Message ID}
         Attribute 1 {
            vendor-id=1
            type=1 (vendor X attribute, Scan-Engine-Version)
            length
            Value = {
               scan-engine-version=1234
            }
         }
         Attribute 2 {
            vendor-id=0 (IETF Standard)
            type=5 (Standard, Operational-Status)
            length
            Value = {
               status=2 (installed but non-operational)
               result=0 (unknown)
               last use="" (never used)
             }
         }
     }

A.2.1.9.  Posture Response

   This flow contains the PB message containing the PA messages from the
   Vendor X and Vendor Y Anti-Virus Posture Collectors; the message
   content is described in the PB-TNC specification.

A.2.1.10.  Verify Posture

   This flow illustrates an invocation of the Vendor X and Vendor Y
   Anti-Virus Posture Validators requesting verification of the posture
   attributes received.  Because this flow happens locally within the
   NEA server, NEA does not specify the message contents.

Top      Up      ToC       Page 70 
A.2.1.11.  Vendor Y AV Posture Result (Vndr Y AV Post Result)

   This flow contains the PA message (Posture Assessment Result) from
   the Vendor Y Anti-Virus Posture Validator

   Vendor Y AV Posture Result PA Message {
      Attribute HDR {Message ID}
        Attribute 1 {
           vendor-id=0
           type=9 (assessment-result)
           length
           Value = {
              assessment-result=0 (compliant)
           }
        }
     }

A.2.1.12.  Vendor X AV Posture Result (Vndr X AV Post Reslt)

   This flow contains the PA message (Posture Assessment Result) from
   the Vendor X Anti-Virus Posture Validator

   Vendor X AV Posture Result PA Message {
       Attribute HDR {Message ID}
         Attribute 1 {
            vendor-id=0
            type=9 (assessment-result)
            length
            Value = {
               assessment-result=1 (non-compliant)
            }
         }
    }

A.2.1.13.  Assessment Result (Assess Result)

   This flow contains the PB message containing the system assessment
   result computed by the Posture Broker Server and the PA messages from
   the Vendor X and Vendor Y Anti-Virus Posture Validators; the message
   content is described in the PB-TNC specification.

A.2.1.14.  Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post Reslt)

   These flows illustrate an invocation of the Vendor X and Vendor Y
   Anti-Virus Posture Collectors to receive the posture assessment
   results.  Because this flow is triggered locally, NEA does not
   specify the contents of this flow.

Top      Up      ToC       Page 71 
A.3.  Client-Triggered Reassessment

   This scenario involves the reassessment of an endpoint as a result of
   enabling a software component on the endpoint.  The endpoint has two
   VPN client software components, one from vendor X for the user's home
   network and other from vendor Y for the network that the endpoint is
   currently accessing.  The assessment is triggered when the user tries
   to use the Vendor X VPN client; this is a violation of the assessment
   policy.  The Posture Broker Client triggers the posture assessment
   when it receives a notification from the VPN Posture Collector about
   the change to the operational state of the VPN component on the
   endpoint.  Note that the VPN Posture Collector may support standard
   attributes and some vendor-defined attributes from vendor X's and
   vendor Y's namespaces.  This use case does not leverage vendor-
   defined attributes.  The assessment involves verification of the
   standard VPN posture attributes by the standard VPN Posture Validator
   that results in a non-compliant assessment result.

   This use case relies on the use of multiple Posture Collector IDs for
   a single Posture Collector as described in section 3.3 of the PA-TNC
   specification.  In this example, the Posture Collector will obtain
   two Posture Collector IDs to a single Posture Collector (Standard VPN
   PC) and the Posture Collector will generate two separate PA messages
   each using a different ID to report the posture for Vendor X and
   Vendor Y VPN Clients.  The Posture Broker Client will associate the
   assigned IDs in the PB message sent to the NEA Server.  This entire
   behavior will be completely opaque to the NEA Server, which will
   handle the PB message as if there were two VPN Posture Collectors on
   the NEA Client.

Top      Up      ToC       Page 72 
   +--------+  +-------+ +---------+ +--------+ +--------+ +--------+
   |Vndr X  |  |Vndr Y | |Standard | |Standard| |Standard| |Standard|
   |VPNClnt |  |VPNClnt| | VPN PC  | |  PBC   | |  PBS   | | VPN PV |
   +----+---+  +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
   Enble|          |           |         |          |           |
   ---->|          |           |         |          |           |
        |  VPN Status Change   |         |          |           |
        |--------------------->| Posture |          |           |
        |          |           | Change  |          |           |
        |          |           |-------->|          |           |
        |          |           |Req. Post|          |           |
        |          |           |<--------|          |           |
        |          |Ins/Rq Info|         |          |           |
        |          |<----------|         |          |           |
        | Inspect/Request Info |         |          |           |
        |<---------+-----------|VPNX Post|          |           |
        |          |           |-------->|          |           |
        |          |           |VPNY Post|          |           |
        |          |           |-------->|          |           |
        |          |           |         | Posture  |           |
        |          |           |         |  Report  |           |
        |          |           |         |--------->|           |
        |          |           |         |          |Vrfy Post. |
        |          |           |         |          |---------->|
        |          |           |         |          |VPN PRslt  |
        |          |           |         |  Assess  |<----------|
        |          |           |         |  Result  |           |
        |          |           |         |<---------|           |
        |          |           |VPN PRslt|          |           |
        |          |           |<--------|          |           |

A.3.1.  Message Contents

   This section shows the contents of the key fields in each of the PA
   messages exchanged in this use case.  When necessary, additional
   commentary is provided to explain why certain fields contain the
   shown values.  Note that many of the flows shown are between
   components on the same system so no message contents are shown.

A.3.1.1.  Enable VPN Client (Enble)

   This flow represents the end user triggered event of starting the VPN
   Client software from Vendor X.  This is merely an event and does not
   include a message being sent.

Top      Up      ToC       Page 73 
A.3.1.2.  Notify Status Change (VPN Status Change)

   This flow represents the detection of the active state of the Vendor
   X VPN Client software by the VPN Posture Collector.  This is merely
   an event and does not include a message being sent.

A.3.1.3.  Notify Posture Change (Posture Change)

   This flow represents the notification of the VPN posture change sent
   from the VPN Posture Collector to the Standard Posture Broker Client.
   This is merely an event and does not include a message being sent.

A.3.1.4.  Request Posture (Req. Post)

   This flow illustrates an invocation of the VPN Posture Collector
   requesting particular posture attributes to be sent.  Because this
   use case is triggered locally, NEA does not specify the contents of
   this flow.

A.3.1.5.  Inspect/Request Info (Ins/Rq Info)

   This flow illustrates the acquisition of the posture information by
   the VPN Posture Collector from the Vendor X and Vendor Y VPN Client
   components.  Because this flow is triggered locally, NEA does not
   specify the message contents.

Top      Up      ToC       Page 74 
A.3.1.6.  Vendor X VPN Posture (VPNX Post)

   This flow contains the PA message from the VPN Posture Collector
   describing the Vendor X VPN Client's posture:

   Vendor X VPN Posture PA Message{
      Attribute HDR {Message ID}
        Attribute 1 {
              vendor-id=0
              type=2 (product information)
              length
              Value = {
                 product-vendor-id=9876 (vendor X)
                 product-id=567 (VPN client identifier for Vndr X)
                 product-name="Vendor X VPN Client"
               }
         }
         Attribute 2 {
              vendor-id=0
              type=5 (operational status)
              length
              Value = {
                 Status=3 (Operational)
                 Result=1 (Successful use with no errors detected)
                 last Use="2008-07-07T12:00:00Z"
              }
         }

Top      Up      ToC       Page 75 
A.3.1.7.  Vendor Y VPN Posture (VPNY Post)

   This flow contains the PA message from the VPN Posture Collector
   including the Vendor Y VPN Client's posture:

   Vendor Y VPN Posture PA Message{
      Attribute HDR {Message ID}
          Attribute 1 {
              vendor-id=0
              type=2 (product information)
              length
              Value = {
                 product-vendor-id=Vendor Y
                 product-id=234 (VPN client identifier for Vndr Y)
                 product-name="Vendor Y VPN Client"
               }
         }
         Attribute 2 {
              vendor-id=0
              type=5 (operational status)
              length
              Value = {
                Status=3 (Operational)
                Result=1 (Successful use with no errors detected)
                last Use="2008-07-07T14:05:00Z"
              }
         }
   }

A.3.1.8.  Posture Report

   This flow contains the PB message containing the PA message from the
   VPN Posture Collector; the message content is described in the PB-TNC
   specification.

A.3.1.9.  Verify Posture (Vrfy Post.)

   This flow illustrates an invocation of the VPN Posture Validator
   requesting verification of the posture attributes received.  Because
   this flow happens locally within the NEA Server, NEA does not specify
   the message contents.

Top      Up      ToC       Page 76 
A.3.1.10.  VPN Posture Result (VPN PRslt)

   This flow contains the PA message (Posture Assessment Result) from
   the VPN Posture Validator

   VPN Posture Result PA Message {
      Attribute HDR {Message ID}
         Attribute 1 {
              vendor-id=0
              type=9 (assessment-result)
              length
              Value = {
                 assessment-result=1 (non-compliant)
              }
         }
    }

A.3.1.11.  Assessment Result (Assess Result)

   This flow contains the PB message containing the system assessment
   result computed by the Posture Broker Server and the PA messages from
   the VPN Posture Validator; the message content is described in the
   PB-TNC specification.

A.3.1.12.  Posture Result (VPN PRslt)

   This flow illustrates an invocation of the VPN Posture Collector to
   receive the posture assessment result.  Because this flow is
   triggered locally, NEA does not specify the contents of this flow.

Top      Up      ToC       Page 77 
Appendix B.  Evaluation against NEA Requirements

   This section evaluates the PA-TNC protocol against the requirements
   defined in the NEA Requirements document.  Each subsection considers
   a separate requirement from the NEA Requirements document.  Only
   common requirements (C-1 through C-10) and PA requirements (PA-1
   through PA-6) are considered, since these are the only ones that
   apply to PA.

B.1.  Evaluation against Requirement C-1

   Requirement C-1 says:

   C-1   NEA protocols MUST support multiple round trips between the NEA
   Client and NEA Server in a single assessment.

   PA-TNC meets this requirement.  It allows an unlimited number of
   round trips between the NEA Client and NEA Server.

B.2.  Evaluation against Requirement C-2

   Requirement C-2 says:

   C-2   NEA protocols SHOULD provide a way for both the NEA Client and
   the NEA Server to initiate a posture assessment or reassessment as
   needed.

   PA-TNC meets this requirement.  PA-TNC is designed to work whether
   the NEA Client or the NEA Server initiates a posture assessment or
   reassessment.

B.3.  Evaluation against Requirement C-3

   Requirement C-3 says:

   C-3   NEA protocols including security capabilities MUST be capable
   of protecting against active and passive attacks by intermediaries
   and endpoints including prevention from replay-based attacks.

   Security for PA-TNC messages being sent over the network is provided
   through PT protocol security.  Therefore, PA-TNC does not include any
   security capabilities.  Since this requirement only applies to NEA
   protocols "including security capabilities", this specification is
   not subject to this requirement (see section 5.2).

Top      Up      ToC       Page 78 
B.4.  Evaluation against Requirement C-4

   Requirement C-4 says:

   C-4   The PA and PB protocols MUST be capable of operating over any
   PT protocol.  For example, the PB protocol must provide a transport-
   independent interface allowing the PA protocol to operate without
   change across a variety of network protocol environments (e.g.,
   EAP/802.1X, PANA, TLS and IKE/IPsec).

   PA-TNC meets this requirement.  PA-TNC can operate over any PT
   protocol that meets the requirements for PT stated in the NEA
   Requirements document.  PA-TNC does not have any dependencies on
   specific details of the underlying PT protocol.

B.5.  Evaluation against Requirement C-5

   Requirement C-5 says:

   C-5   The selection process for NEA protocols MUST evaluate and
   prefer the reuse of existing open standards that meet the
   requirements before defining new ones.  The goal of NEA is not to
   create additional alternative protocols where acceptable solutions
   already exist.

   Based on this requirement, PA-TNC should receive a strong preference.
   PA-TNC is equivalent with IF-M 1.0, an open TCG specification.  Other
   specifications from TCG and other groups are also under development
   based on the IF-M 1.0 specification.  Selecting PA-TNC as the basis
   for the PA protocol will ensure compatibility with IF-M 1.0, with
   these other specifications, and with their implementations.

B.6.  Evaluation against Requirement C-6

   Requirement C-6 says:

   C-6   NEA protocols MUST be highly scalable; the protocols MUST
   support many Posture Collectors on a large number of NEA Clients to
   be assessed by numerous Posture Validators residing on multiple NEA
   Servers.

   PA-TNC meets this requirement.  PA-TNC supports an unlimited number
   of Posture Collectors, Posture Validators, NEA Clients, and NEA
   Servers.  It also is quite scalable in many other aspects as well.  A
   PA-TNC message can contain up to 2^32-1 octets and about 2^28 PA-TNC
   attributes.  Each organization with an SMI Private Enterprise Number
   is entitled to define up to 2^32 vendor-specific PA-TNC Attribute
   Types, 2^16 vendor-specific PA-TNC Product IDs, and 2^32 vendor-

Top      Up      ToC       Page 79 
   specific PA-TNC Error Codes.  Each attribute can contain almost 2^32
   octets.  It is generally not advisable or necessary to send this much
   data in a NEA assessment, but still PA-TNC is highly scalable and
   meets requirement C-6 easily.

B.7.  Evaluation against Requirement C-7

   Requirement C-7 says:

   C-7   The protocols MUST support efficient transport of a large
   number of attribute messages between the NEA Client and the NEA
   Server.

   PA-TNC meets this requirement.  Each PA-TNC message can contain about
   2^28 PA-TNC attributes.  PA-TNC supports up to 2^32 round trips in a
   session so the maximum number of attribute messages that can be sent
   in a single session is actually about 2^50.  However, it is generally
   inadvisable and unnecessary to send a large number of messages in a
   NEA assessment.  As for efficiency, PA-TNC adds only 12 octets of
   overhead per attribute and 8 octets per message (which is negligible
   on a per-attribute basis).

B.8.  Evaluation against Requirement C-8

   Requirement C-8 says:

   C-8   NEA protocols MUST operate efficiently over low bandwidth or
   high latency links.

   PA-TNC meets this requirement.  A PA-TNC exchange is envisioned
   (based on current deployment experience) to involve one or two round
   trips with less than 500 octets of PA-TNC messages.  Of course, use
   of vendor-specific PA-TNC attribute types could expand the
   assessment.  However, PA-TNC itself imposes an overhead of only 8
   octets per PA-TNC message and 12 octets per attribute.

B.9.  Evaluation against Requirement C-9

   Requirement C-9 says:

   C-9   For any strings intended for display to a user, the protocols
   MUST support adapting these strings to the user's language
   preferences.

   PA-TNC meets this requirement.  The only field included in a PB-TNC
   attribute for display to the user includes a language tag that could
   be selected based upon the user's PB-TNC negotiated preferred
   language for the assessment (see section 4.10 of the PB-TNC

Top      Up      ToC       Page 80 
   specification).  With this exception, all of the strings in the
   standard PA-TNC attributes are intended for logging and programmatic
   comparisons.

   If any vendor-specific PA-TNC attribute types or future IETF Standard
   PA-TNC Attribute Types include strings that are intended for display
   to a user, they should be translated to the user's preferred
   language.  The Posture Broker Server will need to expose the user's
   preferences to the Posture Validators through whatever API or
   protocol is used to connect those components.  However, that is all
   out of scope for this specification.

B.10.  Evaluation against Requirement C-10

   Requirement C-10 says:

   C-10  NEA protocols MUST support encoding of strings in UTF-8 format.

   PA-TNC meets this requirement.  All strings in the PA-TNC protocol
   are encoded in UTF-8 format.  This allows the protocol to support a
   wide range of languages efficiently.

B.11.  Evaluation against Requirement C-11

   Requirement C-11 says:

   C-11  Due to the potentially different transport characteristics
   provided by the underlying candidate PT protocols, the NEA Client and
   NEA Server MUST be capable of becoming aware of and adapting to the
   limitations of the available PT protocol.  For example, some PT
   protocol characteristics that might impact the operation of PA and PB
   include restrictions on which end can initiate a NEA connection,
   maximum data size in a message or full assessment, upper bound on
   number of round trips, and ordering (duplex) of messages exchanged.
   The selection process for the PT protocols MUST consider the
   limitations the candidate PT protocol would impose upon the PA and PB
   protocols.

   PA-TNC meets this requirement.  The design of the PA-TNC protocol
   emphasizes efficient transport of information in order to maximize
   its usability in constrained PT environments.  Local APIs could allow
   Posture Collectors and Posture Validators to discover when they are
   operating in a less constrained deployment and then make use of more
   verbose attributes.  Similarly, Posture Collectors could choose not
   to send or use smaller attributes (including assertions from previous
   assessments) when faced with a very constrained network connection.

Top      Up      ToC       Page 81 
B.12.  Evaluation against Requirement PA-1

   Requirement PA-1 says:

   PA-1  The PA protocol MUST support communication of an extensible set
   of NEA standards-defined attributes.  These attributes will be
   uniquely identifiable from non-standard attributes.

   PA-TNC meets this requirement.  Each attribute is identified with a
   PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.  IETF
   Standard PA-TNC Attribute Types use a vendor ID of zero (0), in
   contrast with vendor-specific PA-TNC Attribute Types, which will use
   the vendor's SMI Private Enterprise Number as the vendor ID.  The
   IANA will maintain a registry of PA-TNC Attribute Types with new
   values added by Expert Review with Specification Required, as
   described in the IANA Considerations section of this specification.
   Thus, the set of standard attribute types is extensible, but all
   standard attribute types are uniquely identifiable.

B.13.  Evaluation against Requirement PA-2

   Requirement PA-2 says:

   PA-2  The PA protocol MUST support communication of an extensible set
   of vendor-specific attributes.  These attributes will be segmented
   into uniquely identifiable vendor-specific namespaces.

   PA-TNC meets this requirement.  Each attribute is identified with a
   PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.  Vendor-
   defined PA-TNC Attribute Types use the vendor's SMI Private
   Enterprise Number as the PA-TNC Attribute Vendor ID.  Each vendor can
   define up to 2^32 PA-TNC Attribute Types, using its own internal
   processes to manage its set of attribute types.

   The IANA is not involved, other than the initial assignment of the
   vendor's SMI Private Enterprise Number.  Thus, the set of vendor-
   specific attributes is segmented into uniquely identifiable vendor-
   specific namespaces.

B.14.  Evaluation against Requirement PA-3

   Requirement PA-3 says:

   PA-3  The PA protocol MUST enable a Posture Validator to make one or
   more requests for attributes from a Posture Collector within a single
   assessment.  This enables the Posture Validator to reassess the
   posture of a particular endpoint feature or to request additional
   posture including from other parts of the endpoint.

Top      Up      ToC       Page 82 
   PA-TNC meets this requirement.  The Attribute Request attribute type
   is an IETF Standard PA-TNC Attribute Type that permits a Posture
   Validator to send to one or more Posture Collectors a request for one
   or more attributes.  This attribute may be sent at any point in the
   posture assessment process and may in fact be sent more than once if
   the Posture Validator needs to first determine the type of operating
   system and then request certain attributes specific to that operating
   system, for example.

B.15.  Evaluation against Requirement PA-4

   Requirement PA-4 says:

   PA-4  The PA protocol MUST be capable of returning attributes from a
   Posture Validator to a Posture Collector.  For example, this might
   enable the Posture Collector to learn the specific reason for a
   failed assessment and to aid in remediation and notification of the
   system owner.

   PA-TNC meets this requirement.  A Posture Validator can easily send
   attributes to one or more Posture Collectors.

B.16.  Evaluation against Requirement PA-5

   Requirement PA-5 says:

   PA-5  The PA protocol SHOULD provide authentication, integrity, and
   confidentiality of attributes communicated between a Posture
   Collector and Posture Validator.  This enables end-to-end security
   across a NEA deployment that might involve traversal of several
   systems or trust boundaries.

   PA-TNC does not include an explicit PA-level security mechanism but
   does lay a foundation allowing attribute-level security protections
   to be added later.  As an existence proof, the NEA working group
   considered an Internet-Draft proposal capable of encapsulating PA
   attributes within a Cryptographic Message Syntax (CMS) security
   wrapper in a new attribute type.  This proposal offered the
   protections described in this requirement.  However, the NEA WG
   decided that the use cases in scope for the working group did not
   require PA-level security.  The use cases involving PA message
   traversal of multiple systems or trust boundaries were considered out
   of scope; therefore, a Posture Validator to Posture Collector end-to-
   end security protection was considered not to be required.

   Instead, PA-TNC attributes are protected by the PT layer
   authentication, integrity, and confidentiality support.  This
   protects the attributes communicated between the Posture Transport

Top      Up      ToC       Page 83 
   Client and Posture Transport Server.  Because the Posture Collector
   is in the same address space as the Posture Broker Client and Posture
   Transport Client and the Posture Validator is in the same address
   space as the Posture Broker Server and Posture Transport Server, the
   underlying broker and transport components are deemed trusted with
   respect to not tampering with the PA messages (see trust model in
   section 5.1 for details).  Encrypting the PA-TNC messages would not
   prevent a hostile broker or transport component from attacking the
   messages.

B.17.  Evaluation against Requirement PA-6

   Requirement PA-6 says:

   PA-6  The PA protocol MUST be capable of carrying attributes that
   contain non-binary and binary data including encrypted content.

   PA-TNC meets this requirement.  PA-TNC attributes can contain non-
   binary and binary data including encrypted content.  For examples,
   see the attribute type definitions contained in this specification.

Authors' Addresses

   Paul Sangster
   Symantec Corporation
   6825 Citrine Drive
   Carlsbad, CA 92009
   USA
   EMail: Paul_Sangster@symantec.com

   Kaushik Narayan
   Cisco Systems Inc.
   10 West Tasman Drive
   San Jose, CA 95134
   USA
   EMail: kaushik@cisco.com