[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-sangster-nea-pa-tnc) 00 01 02 03 04 05 06 RFC 5792

    Network Working Group                                P. Sangster
    Internet Draft                              Symantec Corporation
    Intended status: Proposed Standard                    K. Narayan
    Expires: April 2009                                Cisco Systems
                                                     October 6, 2008
    
    
       PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC
                     draft-ietf-nea-pa-tnc-02.txt
    
    Status of this Memo
      By submitting this Internet-Draft, each author represents that
      any applicable patent or other IPR claims of which he or she is
      aware have been or will be disclosed, and any of which he or she
      becomes aware will be disclosed, in accordance with Section 6 of
      BCP 79.
    
      Internet-Drafts are working documents of the Internet
      Engineering Task Force (IETF), its areas, and its working
      groups.  Note that other groups may also distribute working
      documents as Internet-Drafts.
    
      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time.  It is inappropriate to use Internet-
      Drafts as reference material or to cite them other than as "work
      in progress."
    
      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt
    
      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html
    
      This Internet-Draft will expire on January 6, 2009.
    
    Copyright Notice
    
      Copyright (C) The IETF Trust (2008).
    
    Abstract
    
      This document specifies PA-TNC, a Posture Attribute Protocol
      identical to the Trusted Computing Group's IF-M 1.0 protocol.
      The document then evaluates PA-TNC against the requirements
      defined in the NEA Requirements specification.
    
    Sangster & Narayan     Expires April 6, 2009           [Page 1]
    

    Internet-Draft              PA-TNC              October 2008
    
    Conventions used in this document
    
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described
      in RFC 2119 [1].
    
    Table of Contents
    
      1. Introduction.................................................3
        1.1. Relationship to Trusted Network Connect..................3
        1.2. Prerequisites............................................4
        1.3. Message Diagram Conventions..............................4
      2. Design Considerations........................................4
        2.1. Standard Attribute Namespace for Interoperability........4
        2.2. Vendor Defined Namespace for Differentiation and Agility 5
        2.3. Use of TLV Based Encoding for Efficiency.................5
      3. PA-TNC Message Protocol......................................6
        3.1. PA-TNC Messaging Model...................................6
        3.2. PA-TNC Relationship to PB-TNC............................7
        3.3. PA-PB Posture Collector and Posture Validator Identifiers8
        3.4. PA-TNC Messages in PB-TNC................................9
        3.5. IETF Standard PA Subtypes................................9
        3.6. PA-TNC Field Types......................................10
        3.7. PA-TNC Message Header Format............................10
      4. PA-TNC Attributes...........................................11
        4.1. PA-TNC Attribute Header.................................11
        4.2. IETF Standard PA-TNC Attribute Types....................13
           4.2.1. Attribute Request..................................15
           4.2.2. Product Information................................16
           4.2.3. Numeric Version....................................17
           4.2.4. String Version.....................................19
           4.2.5. Operational Status.................................21
           4.2.6. Port Filter........................................22
           4.2.7. Installed Packages.................................24
           4.2.8. PA-TNC Error.......................................26
             4.2.8.1. Invalid Parameter Error Code...................27
             4.2.8.2. Version Not Supported Error Code...............28
             4.2.8.3. Attribute Type Not Supported Error Code........29
           4.2.9. Assessment Result..................................30
           4.2.10. Remediation Instructions..........................31
             4.2.10.1. IETF Standard PA-TNC Remediation Parameters
              Types..................................................32
           4.2.11. Forwarding Enabled................................33
           4.2.12. Factory Default Password Enabled..................34
        4.3. Vendor-Defined Attributes...............................35
      5. Evaluation Against NEA Requirements.........................35
    
    
    Sangster & Narayan     Expires April 6, 2009           [Page 2]
    

    Internet-Draft              PA-TNC              October 2008
    
        5.1. Evaluation Against Requirement C-1......................35
        5.2. Evaluation Against Requirement C-2......................36
        5.3. Evaluation Against Requirement C-3......................36
        5.4. Evaluation Against Requirement C-4......................36
        5.5. Evaluation Against Requirement C-5......................36
        5.6. Evaluation Against Requirement C-6......................36
        5.7. Evaluation Against Requirement C-7......................37
        5.8. Evaluation Against Requirement C-8......................37
        5.9. Evaluation Against Requirement C-9......................37
        5.10. Evaluation Against Requirement C-10....................38
        5.11. Evaluation Against Requirement C-11....................38
        5.12. Evaluation Against Requirement PA-1....................38
        5.13. Evaluation Against Requirement PA-2....................38
        5.14. Evaluation Against Requirement PA-3....................39
        5.15. Evaluation Against Requirement PA-4....................39
        5.16. Evaluation Against Requirement PA-5....................39
        5.17. Evaluation Against Requirement PA-6....................40
      6. Security Considerations.....................................40
        6.1. Trust Relationships.....................................40
           6.1.1. Posture Collector..................................40
           6.1.2. Posture Validator..................................40
           6.1.3. Posture Broker Client, Posture Broker Server.......41
        6.2. Security Threats........................................41
           6.2.1. Attribute Theft....................................41
           6.2.2. Message Fabrication................................42
           6.2.3. Attribute Modification.............................42
           6.2.4. Attribute Replay...................................42
           6.2.5. Attribute Insertion................................42
           6.2.6. Denial of Service..................................43
      7. Privacy Considerations......................................43
      8. IANA Considerations.........................................44
        8.1. IETF Standard PA Subtypes...............................44
        8.2. Registry for IETF Standard PA-TNC Attribute Types.......44
        8.3. Registry for IETF Standard PA-TNC Error Codes...........45
        8.4. Registry for IETF Standard Remediation Parameter Types..45
      9. Acknowledgments.............................................46
      10. References.................................................46
        10.1. Normative References...................................46
        10.2. Informative References.................................46
      Appendix A: Use Cases..........................................46
        A.1. Initial Client triggered assessment.....................46
           A.1.1. Message Contents...................................48
             A.1.1.1. N/W Join.......................................48
             A.1.1.2. Request Posture (Req Post.)....................48
             A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)...48
             A.1.1.4. OS Posture.....................................49
             A.1.1.5. Posture Report.................................49
    
    Sangster & Narayan     Expires April 6, 2009           [Page 3]
    

    Internet-Draft              PA-TNC              October 2008
    
             A.1.1.6. Verify Posture.................................49
             A.1.1.7. OS Posture Result (OS Reslt)...................50
             A.1.1.8. Vendor X Patch Result (VndrX Patch Result).....50
             A.1.1.9. Assessment Result (Assess Result)..............50
             A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)50
        A.2. Server initiated Assessment with Remediation............51
           A.2.1. Message Contents...................................52
             A.2.1.1. N/W Join.......................................52
             A.2.1.2. Create Posture Request (Create Posture Req.)...52
             A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture
              Req)...................................................53
             A.2.1.4. Vendor X AV Posture Request (Vndr X AV Posture
              Req)...................................................53
             A.2.1.5. Posture Request................................54
             A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV
             Post Req)...............................................54
             A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture)........54
             A.2.1.8. Vendor X AV Posture (Vndr X AV Posture)........54
             A.2.1.9. Posture Response...............................55
             A.2.1.10. Verify Posture................................55
             A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post
              Result)................................................55
             A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post Reslt)
              .......................................................56
             A.2.1.13. Assessment Result (Assess Result).............56
             A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV
             Post Reslt).............................................56
        A.3. Client triggered re-assessment..........................56
           A.3.1. Message Contents...................................58
             A.3.1.1. Enable VPN Client (Enble)......................58
             A.3.1.2. Notify Status Change (VPN Status Change).......58
             A.3.1.3. Notify Posture Change (Posture Change).........58
             A.3.1.4. Request Posture (Req. Post)....................58
             A.3.1.5. Inspect/Request Info (Ins/Rq Info).............58
             A.3.1.6. Vendor X VPN Posture (VPNX Post)...............58
             A.3.1.7. Vendor Y VPN Posture (VPNY Post)...............59
             A.3.1.8. Posture Report.................................60
             A.3.1.9. Verify Posture (Vrfy Post.)....................60
             A.3.1.10. VPN Posture Result (VPN PRslt)................60
             A.3.1.11. Assessment Result (Assess Result).............61
             A.3.1.12. Posture Result (VPN PRslt)....................61
      Author's Address...............................................61
      Intellectual Property Statement................................61
      Disclaimer of Validity.........................................61
    
    
    
    Sangster & Narayan     Expires April 6, 2009           [Page 4]
    

    Internet-Draft              PA-TNC              October 2008
    
    1. Introduction
    
      This document specifies PA-TNC, a Posture Attribute Protocol
      (PA) identical to the Trusted Computing Group's IF-M 1.0
      protocol [6].  The document then evaluates PA-TNC against the
      requirements defined in the NEA Requirements specification [7].
    
    1.1. Relationship to Trusted Network Connect
    
      Starting in 2004, the Trusted Computing Group (TCG) has defined
      and published the Trusted Network Connect (TNC) architecture and
      standards for network access control.  These standards enable
      multi-vendor interoperability throughout the TNC architecture
      and have been widely adopted and deployed.  In order to avoid
      the development of multiple incompatible standards in this area,
      the TCG offered several of its TNC standards to the IETF as
      candidates for standardization in the IETF also.  This document
      is one of those standards, known in the IETF as PA-TNC and in
      the TCG as IF-M 1.0.  PA-TNC and IF-M 1.0 are equivalent.
    
      Consistent with IETF's requirements for standards track
      documents, the TCG has authorized the editors of this document
      to offer the specification to the IETF without restriction.  As
      with other Internet-Drafts, the IETF Trust owns the copyright to
      this document.  The IETF may modify this document, ignore it,
      publish it as an RFC, or take any other action.  If the IETF
      decides to adopt a version of this document as an RFC, the TCG
      plans to publish a specification for an equivalent TNC protocol
      to ensure continued compatibility.
    
    1.2. Prerequisites
    
      This document does not define an architecture or reference
      model.  Instead, it defines a protocol that works within the
      reference model described in the NEA Overview and Requirements
      specification.  The reader is assumed to be thoroughly familiar
      with that document.  No familiarity with TCG specifications is
      assumed.
    
    1.3. Message Diagram Conventions
    
      This specification defines the syntax of PA-TNC messages using
      diagrams.  Each diagram depicts the format and size of each
      field in bits.  Implementations MUST send the bits in each
      diagram as they are shown, traversing the diagram from top to
      bottom and then from left to right within each line (which
    
    
    Sangster & Narayan     Expires April 6, 2009           [Page 5]
    

    Internet-Draft              PA-TNC              October 2008
    
      represents a 32-bit quantity).  Multi-byte fields representing
      numeric values must be sent in network (big endian) byte order.
      Descriptions of bit field (e.g. flag) values are described
      referring to the position of the bit within the field.  These
      bit positions are numbered from the most significant bit through
      the least significant bit so a one octet field with only bit 0
      set has the value 0x80.
    
    2. Design Considerations
    
      This section discusses some of the key design considerations for
      the PA protocol.
    
    2.1. Standard Attribute Namespace for Interoperability
    
      The PA protocol requires the use of two categories of
      namespaces: component types (AKA PA Subtypes) and attributes.
      Each of these namespace categories needs to contain well known,
      interoperable names with defined syntax and semantics co-
      existing with names for vendor defined private extensions.
      Similarly, each namespace category needs to be readily
      extensible without repeated coordination yet avoids naming
      conflicts.
    
      The PA-TNC and PB-TNC protocols provide for multiple orthogonal
      namespaces for each category that exist without overlap by
      including a SMI Private Enterprise Number (PEN) field to
      identify the definer of namespace of the associated field.  This
      allows the IETF NEA WG to define a set of standard component
      types and attribute types while allowing vendors to each create
      additional names outside of the IETF standard namespace.  Over
      time, vendor defined names might be proposed for standardization
      and thus migration into the IETF namespace.
    
      The PB-TNC protocol defines an IETF standard namespace (using
      vendor-id=0) that allows for definition of standard component
      types (e.g. Operating System, Firewall, Anti-Virus) using the PA
      Subtype field (see section 3.2.  Similarly, PA-TNC defines a set
      of standard attributes in section 4.2. that represent the most
      common capabilities (attributes) of these types of components
      across a variety of vendor implementations.  The standard
      namespace allows NEA deployments with both open source and
      vendor provided NEA implementations to support a consistent set
      of policies across their environment based on these standard
      attributes.  The standard attributes can be used with a variety
      of endpoints (hosts, printers, mobile devices) that are running
    
    
    Sangster & Narayan     Expires April 6, 2009           [Page 6]
    

    Internet-Draft              PA-TNC              October 2008
    
      applications and operating systems (defined by the PA Subtypes)
      from a variety of vendors.
    
    2.2. Vendor Defined Namespace for Differentiation and Agility
    
      The endpoint is a very dynamic environment in terms of rate of
      new features being deployed and attacks that are crafted against
      existing and new applications such as: viruses, worms, malware,
      and spyware.  It is difficult to imagine the standard namespaces
      to being able to keep pace with this rapidly changing
      environment.  Vendors typically differentiate themselves by
      moving rapidly to provide unique mechanisms to address such
      threats and their ability to deal with changes in an agile
      manner.  The PA-TNC and PB-TNC protocols allows for creation of
      vendor defined namespace(s) where each namespace allows use of
      vendor defined PA Subtypes to identify non-standard applications
      or operating system variants and vendor defined attributes
      describing new aspects of each type of component.  The vendor
      namespaces will allow NEA deployments to craft compliance
      policies using a mixture of attributes from both the IETF
      standard namespace and vendor defined namespaces that may
      include multiple vendors representing the various hardware and
      software components present on the endpoints.
    
      The PA-TNC protocol's use of vendor-id to identify the namespace
      of each attribute allows Posture Collectors to support some or
      all of the IETF standard attributes plus optionally a set of
      vendor defined attributes (potentially from more then one
      vendor-id namespace).  For instance, an open source anti-virus
      Posture Collector might be written that supports all of the IETF
      standard attributes used to describe a local anti-virus
      component and a subset of multiple anti-virus manufacturers'
      vendor defined attributes.  This Posture Collector might
      therefore be able to interoperate with Posture Validators from
      multiple vendors.  Conversely, a simple Posture Collector might
      be written to ignore any vendor defined attributes requested and
      only return standard attributes that it supports.  If the vendor
      provided Posture Validator's policy allows for this subset to be
      considered compliant, then these simple Posture Collectors can
      be used to perform a successful assessment.
    
    2.3. Use of TLV Based Encoding for Efficiency
    
      The PA-TNC protocol has chosen to employ a binary encoding using
      a type-length-value (TLV) structure.  TLV encoding was preferred
      over the use of a textual encoding format such as XML to provide
      a more efficient utilization of the potentially constrained
    
    
    Sangster & Narayan     Expires April 6, 2009           [Page 7]
    

    Internet-Draft              PA-TNC              October 2008
    
      bandwidth available between the NEA Client and NEA Server (see
      NEA Overview and Architecture [7]).  Efficiency was a primary
      criteria for this choice with consideration given to both:
    
       1. Optimization of the bits-on-the-wire to accommodate NEA
          requirements for assessment over low bandwidth or high
          latency links (C-8) and allow for the PT protocol to run
          over existing network access protocols (PT-4, C-11) that
          are constrained by packet size.
       2. Optimization of CPU utilization on the endpoint to
          accommodate for low power endpoints such as mobile devices.
    
      The choice of TLV encoding does not preclude the use of XML-
      based attribute values within the vendor namespaces or future
      standard attributes.  It is conceivable that certain vendors may
      utilize XML encoding for extensibility within their namespace
      when the above considerations are less applicable to their
      technologies.  Attributes encoded within the vendor defined
      namespace using alternate encoding such as XML will be opaque to
      NEA software only supporting standard attributes and will be
      processed primarily by the vendor defined components
      (collector/validator).
    
    3. PA-TNC Message Protocol
    
      This section discusses the use of the PA-TNC message and its
      attributes, and specifies the syntax and semantics for the PA-
      TNC message header.  The details of each attribute included
      within the PA-TNC payload are specified in section 4.2.
    
    3.1. PA-TNC Messaging Model
    
      PA-TNC messages are carried by the PB-TNC protocol [5], which
      provides a multi-roundtrip reliable transport and end-to-end
      message delivery to subscribed (interested) parties using a
      variety of underlying network protocols.  PA-TNC is unaware of
      these underlying PT transport protocols being used below PB-TNC.
      The interested parties consist of Posture Collectors on the NEA
      Client and Posture Validators associated with the NEA Server
      that have registered to receive messages about particular types
      of components (e.g. anti-virus) during an assessment.  The PA-
      TNC messaging protocol operates synchronously within an
      assessment session, with Posture Collectors and Posture
      Validators taking turns sending one or more messages to each
      other.  Each PA-TNC message may contain one or more attributes
    
    
    Sangster & Narayan     Expires April 6, 2009           [Page 8]
    

    Internet-Draft              PA-TNC              October 2008
    
      associated with the functional component identified in the
      component type (PA Subtype) of the PB protocol.
    
      Posture Collectors may only send PA-TNC messages to Posture
      Validators and vice versa.  No Posture Collector to Posture
      Collector or Posture Validator to Posture Validator messaging is
      allowed to occur.  Each Posture Collector or Posture Validator
      may send several PA-TNC messages in succession before indicating
      that it has completed its response to the Posture Broker Client
      or Posture Broker Server respectively.  As necessary, the
      Posture Broker Client and Posture Broker Server will batch these
      messages prior to sending them over the network.
    
      PB-TNC provides a publish/subscribe model of message exchange.
      This means that, at any given point in time, zero or more
      subscribers for a particular type of message may be present on a
      Posture Broker Client or Posture Broker Server.  This is
      beneficial, since it allows one Posture Collector or Posture
      Validator to combine multiple functions (like anti-virus and
      personal firewall) by subscribing to both TNC standard component
      types.  It also allows multiple Posture Collectors or Posture
      Validators to support the same components, such as two anti-
      virus Posture Validators that are each used to manage their own
      respective anti-virus client software.
    
      However, this publish/subscribe model has some possible negative
      side effects.  When a Posture Collector or Posture Validator
      initially sends a PA-TNC message, it does not know whether it
      will receive many, one, or no PA-TNC messages from the other
      side.  For many types of assessments, this is acceptable, but in
      some cases a more direct channel binding between a particular
      Posture Collector and Posture Validator pair is necessary.  For
      example, a Posture Validator may wish to provide remediation
      instructions to a particular Posture Collector that it knows is
      capable of remediating a non-compliant component.  This can be
      accomplished using the exclusive delivery PB-TNC capability to
      limit distribution of a message to a single Posture Collector by
      including the target Posture Collector Identifier in the PA-PB
      header.
    
    3.2. PA-TNC Relationship to PB-TNC
    
      This section summarizes the major elements of a PA-TNC message
      as they might appear inside of a PB-TNC message.  The double
      line (===) in the diagram below indicates the separation between
      the PB-TNC and PA-TNC protocols.  The PA-TNC portion of the
      message is delivered to each Posture Collector or Posture
    
    
    Sangster & Narayan     Expires April 6, 2009           [Page 9]
    

    Internet-Draft              PA-TNC              October 2008
    
      Validator registered to receive messages containing a particular
      message type.  Note that PB-TNC is capable of carrying multiple
      PB-TNC and PA-TNC messages in a single PB-TNC batch.  See the
      PB-TNC specification [5] for more information on its
      capabilities.
    
      One important linkage between the PA-TNC and PB-TNC protocols is
      the PA message type (PA Message Vendor ID and PA Subtype) that
      is used by the Posture Broker Client and Posture Broker Server
      to route messages to interested Posture Collectors and Posture
      Validators.  The message type indicates the software component
      (component type) that is associated with the attributes included
      inside the PA-TNC message.  Therefore, Posture Collectors and
      Posture Validators written to support an assessment of a
      particular component can register to receive messages about the
      component and thus participate in its assessment.  Each Posture
      Collector and Posture Validator MUST only send PA-TNC messages
      containing attributes that pertain to the software component
      defined in the message type of the message.  This ensures that
      only the appropriate Posture Collectors and Posture Validators
      that support a particular type of component will receive
      attributes related to that component.  If a PA-TNC message
      contained a mix of attributes about different components and a
      message type of only one of those components, the message would
      only be delivered to parties interested in the component type
      included in the message type, so other interested recipients
      wouldn't see those attributes.
    
      The message type is comprised of 2 fields: a PA Message Vendor
      ID and a PA Subtype. The PA Message Vendor ID identifies the
      vendor or other organization that defined this message type.
      The PA Subtype identifies the message type more specifically
      within the set of message types defined by that vendor.  This
      specification defines several IETF Standard PA Subtypes to be
      used with a PA Message Vendor ID of zero (0).  Within this
      specification, the PA Subtype field is used to indicate the type
      of component (e.g. firewall) involved with the message's
      attributes.  Therefore for clarity the PA subtype will be
      referred to as the "component type" in this specification.
      Vendor-defined name spaces may use other semantics for the PA
      Subtype field as this is outside the scope of this
      specification.
    
    
    
    
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 10]
    

    Internet-Draft              PA-TNC              October 2008
    
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         PB-TNC Header                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                PB-TNC Message of type PB-PA-Message         |
      |(includes: PA Message Vendor ID, PA Subtype, and other fields|
      | used by Posture Broker Client and Posture Broker Server for |
      | routing)                                                    |
      ===============================================================
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     PA-TNC Message Header                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         PA-TNC Attribute                    |
      |                  (e.g. Product Information)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         PA-TNC Attribute                    |
      |                  (e.g. Operational Status)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Figure 1 Overview: PB-TNC batch that contains a PA-TNC Message
    
      For example, if a Posture Broker Client sent a PB-TNC batch that
      contained a PA-TNC message with a message type indicating
      firewall component, this message would be routed by the Posture
      Broker Server to Posture Validators registered to assess
      firewalls.  Each registered Posture Validator would receive a
      copy of the PA-TNC message including the PA-TNC header and set
      of attributes.  It is important that each of the attributes
      included in the PA-TNC message be associated with the firewall
      component because only the Posture Collector and Posture
      Validator interested in firewalls will receive such messages.
      If the above message contained both firewall and operating
      system attributes inside a PA-TNC message with a component type
      of firewall, then any Posture Collector and Posture Validator
      registered to receive operating system messages would not
      receive those attributes, as the messages would only be
      delivered to those registered for firewall messages.
    
    3.3. PA-PB Posture Collector and Posture Validator Identifiers
    
      The PA-PB header contains several fields important to the
      processing of a received PA message.  The PA Vendor ID and Subtype
      are described in the PB-TNC specification and above in section
      3.2.  Also present in the PA-PB header is a pair of fields that
      identify the Posture Collector and/or Posture Validator involved
      in the exchange.  These fields are used for performing exclusive
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 11]
    

    Internet-Draft              PA-TNC              October 2008
    
      delivery of messages as described in section 3.1 and as an
      indicator for correlation of received attributes.
    
      Correlation of attributes is necessary when the sending Posture
      Collector provides posture for multiple implementations of a
      single type of component during an assessment, so the recipient
      Posture Validators need to know which attributes are describing
      the same implementation.
    
      For example, a single Posture Collector might report attributes
      on two installed VPN implementations on the endpoint.  Because
      the individual attributes do not include an indication of which
      VPN product they are describing, the recipient needs something to
      perform this correlation.  Therefore, for this example, the VPN
      Posture Collector would need to obtain two Posture Collector
      Identifiers from the Posture Broker Client and consistently use
      one with each of the implementations during an assessment. The
      VPN Posture Collector would group all the attributes associated
      with a particular VPN implementation into a single PA-PB message
      and send the message using the Posture Collector Identifier it
      designates as going with the particular implementation.  This
      approach allows the recipient to recognize when attributes in
      future assessment messages also describe the same component
      implementation.
    
    3.4. PA-TNC Messages in PB-TNC
    
      As depicted in section 3.2. a PA-TNC message consists of a PA-
      TNC header followed by a sequence of one or more attributes.
      The PA-TNC message header (described in section 3.6. and the
      header for each of the PA-TNC attributes (specified in section
      4.1) have a fixed type-length-value (TLV) format.  Each PA-TNC
      message MAY contain a mixture of standards-based and vendor-
      defined attributes identifiable using the type portion of the
      attribute header.  All Posture Collectors and Posture Validators
      compliant with this specification MUST be capable of processing
      multiple attributes in a received PA-TNC message.  A Posture
      Collector or Posture Validator that receives a PA-TNC message
      can use the attribute header's length field to skip any
      attributes that it does not understand, unless the attribute is
      marked as mandatory to process.
    
    3.5. IETF Standard PA Subtypes
    
      This section defines several IETF Standard PA Subtypes.  Each PA
      subtype defined here identifies a specific component relevant to
      the endpoint's posture.  This allows a small set of generic PA-
      TNC attributes (e.g. Product Information) to be used to describe
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 12]
    

    Internet-Draft              PA-TNC              October 2008
    
      a large number of different components (e.g. operating system,
      anti-virus, etc.).  It also allows Posture Collectors and
      Posture Validators to specialize in a particular component and
      only receive PA-TNC messages relevant to that component.
    
      Value   Name              Definition
      -----   ----              ----------
      0      Testing          Reserved for use in specification
                              examples, experimentation and
                              testing.
      1      Operating System Operating system running on the
                              endpoint
      2      Anti-Virus       Host-based anti-virus software
      3      Anti-Spyware     Host-based anti-spyware software
      4      Anti-Malware     Host-based anti-malware (e.g. anti-
                              bot) software not included within
                              anti-virus or anti-spyware components
      5      Firewall         Host-based firewall
      6      IDPS             Host-based Intrusion Detection and/or
                              Prevention Software (IDPS)
      7      VPN              Host-based Virtual Private Networking
                              (VPN) software
      8      NEA Client       NEA client software
    
      These PA subtypes must be used in a PB-PA message with a PA
      Message Vendor ID of zero (0) indicating an IETF standard type
      of component (as described in the PB-TNC specification [5]).  If
      these PA subtype values are used with a different PA Message
      Vendor ID, they have a completely different meaning that is not
      defined in this specification.
    
    3.6. PA-TNC Field Types
    
      This section describes some commonly used primitive types found
      in the value field of attributes.  The value field for each
      attribute is typically a structure composed of several data
      items.  Many of these data items share a common syntax and/or
      encoding.  In order to consolidate the description of these
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 13]
    

    Internet-Draft              PA-TNC              October 2008
    
      common syntax or encoding rules, this section defines type
      definitions that are to be applied.
    
        Type Name         Description
        ---------         -----------
        OctetArray  Variable number of octets containing binary
                    data.
        Integer     32-bit unsigned value in network (big endian)
                    byte order
        String      OctetArray that contains a human readable text
                    encoded in UTF-8 transformation format [2]
        IPv4Address OctetArray composed of 4 octets starting with
                    the most significant octet.
        IPv6Address OctetArray composed of 16 octets starting with
                    the most significant octet.
        TimeString  An RFC 3339 [4] compliant ASCII string expressed
                    in Coordinated Universal Time (UTC) time.
        VersionNum  OctetArray composed of 2 Integer typed values
                    where the initial Integer contains the major
                   version and the second contains the minor
                   version.
    
    3.7. PA-TNC Message Header Format
    
      This section describes the format and semantics of the PA-TNC
      header.  Every PA-TNC message MUST start with a PA-TNC header.
      The PA-TNC header provides a common context applying to all of
      the attributes contained within the PA-TNC payload.  The payload
      consists of a sequence of assessment attributes described in
      section 4.2.
    
    
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 14]
    

    Internet-Draft              PA-TNC              October 2008
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Message Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Version
    
        This field indicates the version of the format for the PA-TNC
        message.  This version is intended to allow for evolution of
        the PA-TNC message header and payload in a manner that can
        easily be detected by message recipients.
    
        PA-TNC message senders MUST set this field to 0x01 for all
        PA-TNC messages that comply with formats and requirements
        described in version 1.0 of this specification.
        Implementations responding to a PA-TNC message containing a
        supported version SHOULD use the same Version number to
        minimize the risk of version incompatibility.
    
        Message senders MAY send an empty PA-TNC message with the
        Version value set to 0 in order to discover the PA-TNC
        protocol versions supported by peer recipients, for more
        information see PA-TNC Error Code description in section
        4.2.8.   Message recipients MUST NOT support version 0 and
        MUST NOT interpret the contents (after the Version field) of
        a PA-TNC message containing a version number that the
        recipient does not support.  Message recipients MUST respond
        to a PA-TNC message with an unsupported version by sending a
        Version Not Supported error code in a PA-TNC Error attribute.
        PA-TNC message initiators supporting multiple PA-TNC protocol
        versions SHOULD be able to alter which version of PA-TNC
        message they send based on prior message exchanges with a
        particular peer Posture Collector or Posture Validator.
    
      Reserved
    
        Reserved for future use.  This field MUST be set to 0 on
        transmission and ignored upon reception.
    
      Message Identifier
    
        This field contains a value that uniquely identifies this
        message, differentiating it from others sent by a particular
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 15]
    

    Internet-Draft              PA-TNC              October 2008
    
        PA-TNC message sender within this assessment.  This value can
        be included in a response message to indicate which message
        was received and caused the response.  For example, this
        field is included in the PA-TNC error messages so the party
        who receives the error message can determine which of the
        messages they had sent caused the error.
    
        PA-TNC message senders MUST NOT send the same message
        identifier more than once during an assessment.  Message
        identifiers may be randomly generated or sequenced as long as
        values are not repeated during an assessment message
        exchange.  PA-TNC message recipients are not required to
        check for duplicate message identifiers.
    
    4. PA-TNC Attributes
    
      This section defines the PA-TNC attributes that can be carried
      within a PA-TNC message.  The initial section defines the
      standard attribute header that appears at the start of each
      attribute in a PA-TNC message.  The second section defines each
      of the IETF Standard PA-TNC attributes and the final section
      discusses how vendor-defined PA-TNC attributes can be used
      within a PA-TNC message.  Vendor-defined PA-TNC attributes use
      the vendor's SMI Private Enterprise Number in the Attribute Type
      field.
    
      A PA-TNC message MUST contain a PA-TNC header (defined in
      section 3.7. followed by a sequence of zero or more PA-TNC
      attributes.  All PA-TNC attributes MUST begin with a standard
      PA-TNC attribute header, as defined in section 4.1.  The
      contents of PA-TNC attributes vary widely, depending on their
      attribute type. Section 4.2. defines the IETF Standard PA-TNC
      Attributes. Section 4.3. discusses how vendor-specific PA-TNC
      attributes can be defined.
    
    4.1. PA-TNC Attribute Header
    
      Following the PA-TNC message header is a sequence of zero or
      more attributes.  All PA-TNC attributes MUST begin with the
      standard PA-TNC attribute header defined in this subsection.
      Each attribute described in this specification is represented by
      a TLV tuple.  The TLV tuple includes an attribute identifier
      comprised of the Vendor ID and Attribute Type (type), the TLV
      tuple's overall length and finally the attribute's value.  The
      use of TLV representation was chosen due to its flexibility and
      extensibility and use in other standards.  Recipients of an
      attribute can use the attribute type fields to determine the
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 16]
    

    Internet-Draft              PA-TNC              October 2008
    
      precise syntax and semantics of the attribute value field and
      the length to skip over an unrecognized attribute.  The length
      field is also beneficial when a variable length attribute value
      is provided.
    
      The TLV format does not contain an explicit TLV format version
      number, so every attribute included in a particular PA-TNC
      message MUST use the same TLV format.  Using the PA-TNC message
      version number to indicate the format of all TLV attributes
      within a PA-TNC message allows for future versioning of the TLV
      format in a manner detectable by PA-TNC message recipients.
      Similarly, requiring all TLV attribute formats to be the same
      within a PA-TNC message also assures that recipients compliant
      with a particular PA-TNC message version can at least parse
      every attribute header and use the length to skip over
      unrecognized attributes.  Finally all attribute TLVs within a
      PA-TNC message MUST pertain to the same implementation of the
      component.  This restriction is relevant when a single Posture
      Collector is reporting on multiple implementations of a
      component, so must send multiple PA-TNC messages each including
      only the attributes describing a single implementation.  For
      more information on how Posture Collectors should handle
      multiple implementations see section 3.3.
    
      Every PA-TNC 1.0 compliant TLV attribute MUST use the following
      TLV format:
    
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Flags     |          PA-TNC Attribute Vendor ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     PA-TNC Attribute Type                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    PA-TNC Attribute Length                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Attribute Value (Variable Length)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Flags
    
        This field defines flags impacting the processing of the
        associated attribute.
    
        Bit 0 (0x80) is the NOSKIP flag.  Any Posture Collector or
        Posture Validator that receives an attribute with this flag
        set to 1 but does not support this attribute MUST NOT process
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 17]
    

    Internet-Draft              PA-TNC              October 2008
    
        any part of the PA-TNC message and SHOULD respond with an
        Attribute Type Not Supported error in a PA-TNC error message.
        In order to avoid taking action on a subset of the attributes
        only to later find an unsupported attribute with the NOSKIP
        flag set, recipients of a multi-attribute PA-TNC message
        might need to scan all of the attributes prior to acting upon
        any attribute.
    
        When the NOSKIP flag is set to 0, recipients SHOULD skip any
        unsupported attributes and continue processing the next
        attribute.
    
        Bit 1-7 are reserved for future use.  These bits MUST be set
        to 0 on transmission and ignored upon reception.
    
      PA-TNC Attribute Vendor ID
    
        This field indicates the owner of the name space associated
        with the PA-TNC Attribute Type.  This is accomplished by
        specifying the 24 bit SMI Private Enterprise Number Vendor ID
        of the party who owns the Attribute Type name space.  IETF
        Standard PA-TNC Attribute Types MUST use zero (0) in this
        field.
    
        The PA-TNC Attribute Vendor ID 0xffffff is reserved.  Posture
        Collectors and Posture Verifiers MUST NOT send PA-TNC
        messages in which the PA-TNC Attribute Vendor ID has this
        reserved value (0xffffff).  If a Posture Collector or Posture
        Verifier receives a message in which the PA-TNC Attribute
        Vendor ID has this reserved value (0xffffff), it SHOULD
        respond with an Invalid Parameter error code in a PA-TNC
        Error attribute.
    
      PA-TNC Attribute Type
    
        This field defines the type of the attribute included in the
        Attribute Value field. This field is qualified by the PA-TNC
        Attribute Vendor ID field so that a particular PA-TNC
        Attribute Type value (e.g. 327) has a completely different
        meaning depending on the value in the PA-TNC Attribute Vendor
        ID field.
    
        If the PA-TNC Attribute Vendor ID field has the value zero
        (0) then the PA-TNC Attribute Type field contains an IETF
        Standard PA-TNC Attribute Type, as listed in the IANA
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 18]
    

    Internet-Draft              PA-TNC              October 2008
    
        registry. Section 4.2. of this specification defines the
        initial set of IETF Standard PA-TNC Attribute Types.
        The PA-TNC Attribute Type 0xffffffff is reserved.  Posture
        Collectors and Posture Verifiers MUST NOT send PA-TNC
        messages in which the PA-TNC Attribute Type has this reserved
        value (0xffffffff).  If a Posture Collector or Posture
        Verifier receives a message in which the PA-TNC Attribute
        Type has this reserved value (0xffffffff), it SHOULD respond
        with an Invalid Parameter error code in a PA-TNC Error
        attribute.
    
      PA-TNC Attribute Length
    
        This field contains the length in octets of the entire PA-TNC
        Attribute including the PA-TNC Attribute Header (the fields
        Flags, PA-TNC Attribute Vendor ID, PA-TNC Attribute Type, and
        PA-TNC Attribute Length).  Therefore, this value MUST always
        be at least 12.  Any Posture Collector or Posture Verifier
        that receives a message with a PA-TNC Attribute Length field
        whose value is less than 12 SHOULD respond with an Invalid
        Parameter PA-TNC error code.
    
        Implementations that do not support the specified PA-TNC
        Attribute Type can use this length to skip over this
        attribute to the next attribute.  Note that while this field
        is 4 octets the maximum usable attribute length is likely to
        be less than 2^32-1 due to limitations of the underlying
        protocol stack specifically PB-TNC's length field includes 32
        bytes of other headers which reduce the maximum size
        available to PA-TNC since they both use 4 octet length
        fields.
    
      Attribute Value
    
        This field varies depending on the particular type of
        attribute being expressed.  The contents of this field for
        each of the IETF Standard PA-TNC Attribute Types are defined
        in section 4.2.
    
    4.2. IETF Standard PA-TNC Attribute Types
    
      This section defines an initial set of IETF Standard PA-TNC
      Attribute Types.  These Attribute Types MUST always be used with
      a PA-TNC Vendor ID of zero (0).  If these PA-TNC Attribute Type
      values are used with a different PA-TNC Vendor ID, they have a
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 19]
    

    Internet-Draft              PA-TNC              October 2008
    
      completely different meaning that is not defined in this
      specification.
    
      The following table briefly describes each attribute and defines
      the numeric value to be used in the PA-TNC Attribute Type field
      of the PA-TNC Attribute Header.  Later subsections provide
      detailed specifications for each PA-TNC Attribute Value.
    
      Number Name                 Description
      ------ ----                 -----------
      0     Testing              Reserved for use in
                                 specification examples,
                                 experimentation and testing.
      1     Attribute Request    Contains a list of attribute
                                 type values defining the
                                 attributes desired from the
                                 Posture Collectors.
      2     Product Information  Manufacturer and product
                                 information for the component.
      3     Numeric Version      Numeric version of the
                                 component.
      4     String Version       String version of the
                                 component.
    
      5     Operational Status   Describes whether the component
                                 is running on the endpoint.
      6     Port Filter          Lists the set of ports (e.g.
                                 TCP port 80 for HTTP) that are
                                 allowed or blocked on the
                                 endpoint.
      7     Installed Packages   List of software packages
                                 installed on endpoint that
                                 provide the requested
                                 component.
      8     PA-TNC Error         PA-TNC message or attribute
                                 processing error.
      9     Assessment Result    Result of the assessment
                                 performed by a Posture
                                 Validator.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 20]
    

    Internet-Draft              PA-TNC              October 2008
    
      10    Remediation          Instructions for remediation
            Instructions         generated by a Posture
                                 Validator.
      11    Forwarding Enabled   Indicates whether packet
                                 forwarding has been enabled
                                 between different interfaces on
                                 the endpoint.
      12    Factory Default      Indicates whether the endpoint
            Password             has a factory default password
                                 enabled.
    
    The following subsections discuss the usage, format and semantics
    of the Attribute Value field for each IETF Standard PA-TNC
    Attribute Type.
    
    4.2.1. Attribute Request
    
      This PA-TNC Attribute Type allows a Posture Validator to request
      certain attributes from the registered set of Posture
      Collectors.
    
      All Posture Collectors that implement any of the IETF Standard
      PA Subtypes defined in this specification SHOULD support
      receiving and processing this attribute type for at least those
      PA subtypes.  Posture Collectors that receive and process this
      attribute MAY choose to send all, a subset or none of the
      requested attributes but MUST NOT send attributes that were not
      requested (except error attributes).  All Posture Validators
      that implement any of the IETF Standard PA Subtypes defined in
      this specification SHOULD support sending this attribute type
      for at least those PA subtypes.
    
      Posture Verifiers MUST NOT include this attribute type in an
      Attribute Request attribute. It does not make sense for a
      Posture Verifier to request that a Posture Collector send an
      Attribute Request attribute.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 1.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 21]
    

    Internet-Draft              PA-TNC              October 2008
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
      Note that this diagram shows two attribute types. The actual
      number of attribute types included in an Attribute Request
      attribute can vary from one to a large number (limited only by
      the maximum message and length supported by the underlying PT
      transport protocol). However, each Attribute Request MUST
      contain at least one attribute type.  Because the length of a
      PA-TNC Attribute Vendor ID paired with a PA-TNC Attribute Type
      and a one octet Reserved field is always 8 octets, the number of
      requested attributes can be easily computed using the PA-TNC
      Attribute Length field by subtracting the number of octets in
      the PA-TNC Attribute Header and dividing by 8.  If the PA-TNC
      Attribute Length field is invalid, Posture Collectors SHOULD
      respond with an Invalid Parameter PA-TNC error code.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Reserved    |           PA-TNC Attribute Vendor ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      PA-TNC Attribute Type                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Reserved    |           PA-TNC Attribute Vendor ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      PA-TNC Attribute Type                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Reserved
    
        Reserved for future use.  This field MUST be set to 0 on
        transmission and ignored upon reception.
    
      PA-TNC Attribute Vendor ID
    
        This field contains the SMI Private Enterprise Number of the
        organization that controls the name space for the following
        PA-TNC Attribute Type.  This field enables IETF Standard PA-
        TNC Attributes and vendor-defined PA-TNC Attributes to be
        used without potential collisions.
    
        Any IETF Standard PA-TNC Attribute Types defined in section
        4.2. MUST use zero (0) in this field.  Vendor-defined
    
    Sangster & Narayan     Expires April 6, 2009          [Page 22]
    

    Internet-Draft              PA-TNC              October 2008
    
        attributes MUST use the SMI Private Enterprise Number of the
        organization that defined the attribute.
    
      PA-TNC Attribute Type
    
        The PA-TNC Attribute Type field (together with the PA-TNC
        Vendor ID field) indicates the specific attribute requested.
        Some IETF Standard PA-TNC Attribute Types MUST NOT be
        requested using this field (e.g. requesting a PA-TNC Error
        attribute). This is explicitly indicated in the description
        of those PA-TNC Attribute Types.  Any Posture Collector or
        Posture Validator that receives an Attribute Request
        containing one of the prohibited Attribute Types SHOULD
        respond with an Invalid Parameter error in a PA-TNC error
        message.
    
    4.2.2. Product Information
    
      This PA-TNC Attribute Type contains identifying information
      about a product that implements the component specified in the
      PA Subtype field, as described in section 3.5.  For example, if
      the PA Subtype is Anti-Virus, this attribute would contain
      information identifying an anti-virus product installed on the
      endpoint.
    
      All Posture Collectors that implement any of the IETF Standard
      PA Subtypes defined in this specification MUST support sending
      this attribute type, at least for those PA subtypes.  Whether a
      particular Posture Collector actually sends this attribute type
      SHOULD still be governed by local privacy and security policies.
      All Posture Validators that implement any of the IETF Standard
      PA Subtypes defined in this specification MUST support receiving
      this attribute type, at least for those PA subtypes.  Posture
      Validators MUST NOT send this attribute type.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 2.  The value in the PA-TNC Attribute Length field
      will vary, depending on the length of the Product Name field.
      However, the value in the PA-TNC Attribute Length field MUST be
      at least 17 because this is the length of the fixed size fields
      in the PA-TNC Attribute Header and the fixed size fields in this
      attribute type.  If the PA-TNC Attribute Length field is less
      than the size of these fixed length fields, implementations
      SHOULD respond with an Invalid Parameter PA-TNC error code.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 23]
    

    Internet-Draft              PA-TNC              October 2008
    
      This attribute type includes both numeric and textual
      identifiers for the organization that created the product (the
      "product creator") and for the product itself. For automated
      processing, numeric identifiers are superior because they are
      less ambiguous and more efficient. However, numeric identifiers
      are only available if the product creator has assigned them.
      Therefore, a textual identifier is also included. This textual
      identifier has the additional benefit that it may be easier for
      humans to read (although this benefit is minimal since the
      primary purpose of this attribute is automated assessment).
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Product Vendor ID               |  Product ID   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Product ID   |         Product Name (Variable Length)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Product Vendor ID
    
        This field contains the SMI Private Enterprise Number for the
        product creator.  If the SMI PEN for the product creator is
        unknown or if the product creator does not have an SMI PEN,
        the Product Vendor ID field MUST be set to 0 and the identity
        of the product creator SHOULD be included in the Product Name
        along with the name of the product.
    
      Product ID
    
        This field identifies the product using a numeric identifier
        assigned by the product creator.  If this Product ID value is
        unknown or if the product creator has not assigned such a
        value, this field MUST be set to 0. If the Product Vendor ID
        is 0, this field MUST be set to 0.  In any case, the name of
        the product SHOULD be included in the Product Name field.
        Note that a particular Product ID value (e.g. 635) will have
        completely different meanings depending on the Product Vendor
        ID.  Each Product Vendor ID defines a different space of
        Product ID values.  Product creators are encouraged to
        publish lists of Product ID values for their products.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 24]
    

    Internet-Draft              PA-TNC              October 2008
    
      Product Name
    
        This variable length field contains a UTF-8 [2] string
        identifying the product (e.g. "Symantec Norton AntiVirus(TM)
        2008") in enough detail to unambiguously distinguish it from
        other products from the product creator.  Products whose
        creator is known, but does not have a registered SMI Private
        Enterprise Number, SHOULD be represented using a combination
        of the creator name and full product name (e.g. "Ubuntu(R)
        IPtables" for the IPtables firewall in the Ubuntu
        distribution of Linux).  If the product creator's SMI Private
        Enterprise Number is included in the Product Vendor ID field,
        the product creator's name may be omitted from this field.
        The length of this field can be determined by starting with
        the value in the PA-TNC Attribute Length field in the PA-TNC
        Attribute Header and subtracting the size of the fixed length
        fields in that header (12) and the size of the fixed length
        fields in this attribute (5).  If the PA-TNC Attribute Length
        field is less than the size of these fixed length fields,
        implementations SHOULD respond with an Invalid Parameter PA-
        TNC error code.
    
    4.2.3. Numeric Version
    
      This PA-TNC Attribute Type contains numeric version information
      for a product on the endpoint that implements the component
      specified in the PA Subtype field, as described in section 3.5.
      For example, if the PA Subtype is Operating System, this
      attribute would contain numeric version information for the
      operating system installed on the endpoint. The version
      information in this attribute is associated with a particular
      product, so Posture Validators are expected to also possess the
      corresponding Product Information attribute when interpreting
      this attribute.
    
      All Posture Collectors that implement the IETF Standard PA
      Subtype for Operating System SHOULD support sending this
      attribute type, at least for the Operating System PA subtype.
      Other Posture Collectors MAY support sending this attribute
      type.  Whether a particular Posture Collector actually sends
      this attribute type SHOULD still be governed by local privacy
      and security policies.  All Posture Validators that implement
      the IETF Standard PA Subtype for Operating System SHOULD support
      receiving this attribute type, at least for the Operating System
      PA subtype.  Other Posture Validators MAY support receiving this
      attribute type.  A Posture Validator that does not support
    
    Sangster & Narayan     Expires April 6, 2009          [Page 25]
    

    Internet-Draft              PA-TNC              October 2008
    
      receiving this attribute type SHOULD simply ignore attributes
      with this type.  Posture Validators MUST NOT send this attribute
      type.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 3.  The value in the PA-TNC Attribute Length field
      MUST be 28.  If the PA-TNC Attribute Length field is less than
      the size of these fixed length fields, implementations SHOULD
      respond with an Invalid Parameter PA-TNC error code.
      This attribute type includes numeric values for the product
      version information, enabling Posture Validators to do
      comparative operations on the version.  Some Posture Collectors
      may not be able to determine some or all of this information for
      a product.  However, this attribute can be especially useful for
      describing the version of the operating system, where numeric
      version numbers are generally available.
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Major Version Number                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Minor Version Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Build Number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Service Pack Major       |      Service Pack Minor       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Major Version Number
    
        This field contains the major version number for the product,
        if applicable. If unused or unknown, this field SHOULD be set
        to 0.
    
      Minor Version Number
        This field contains the minor version number for the product,
        if applicable. If unused or unknown, this field SHOULD be set
        to 0.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 26]
    

    Internet-Draft              PA-TNC              October 2008
    
      Build Number
    
        This field contains the build number for the product, if
        applicable.  This may provide more granularity than the minor
        version number, as many builds may occur leading up to an
        official release, and all these builds may share a single
        major and minor version number.  If unused or unknown, this
        field SHOULD be set to 0.
    
      Service Pack Major
    
        This field contains the major version number of the service
        pack for the product, if applicable.  If unused or unknown,
        this field SHOULD be set to 0.
    
      Service Pack Minor
    
        This field contains the minor version number of the service
        pack for the product, if applicable. If unused or unknown,
        this field SHOULD be set to 0.
    
    4.2.4. String Version
    
      This PA-TNC Attribute Type contains string version information
      for a product on the endpoint that implements the component
      specified in the PA Subtype field, as described in section 3.5.
      For example, if the PA Subtype is Firewall, this attribute would
      contain string version information for a host-based firewall
      product installed on the endpoint (if any).  The version
      information in this attribute is associated with a particular
      product, so Posture Validators are expected to also possess the
      corresponding Product Information attribute when interpreting
      this attribute.
    
      All Posture Collectors that implement any of the IETF Standard
      PA Subtypes defined in this document MUST support sending this
      attribute type, at least for those PA subtypes.  Other Posture
      Collectors MAY support sending this attribute type.  Whether a
      particular Posture Collector actually sends this attribute type
      SHOULD still be governed by local privacy and security policies.
      All Posture Validators that implement any of the IETF Standard
      PA Subtypes defined in this document MUST support receiving this
      attribute type, at least for those PA subtypes.  Other Posture
      Validators MAY support receiving this attribute type.  Posture
      Validators MUST NOT send this attribute type.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 27]
    

    Internet-Draft              PA-TNC              October 2008
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 4.  The value in the PA-TNC Attribute Length field
      will vary, depending on the length of the Component Version
      Number, Internal Build Number, and Configuration Version Number
      fields. However, the value in the PA-TNC Attribute Length field
      MUST be at least 15 because this is the length of the fixed size
      fields in the PA-TNC Attribute Header and the fixed size fields
      in this attribute type.  If the PA-TNC Attribute Length field is
      less than the size of these fixed length fields or does not
      match the length indicated by the sum of the fixed length and
      variable length fields, implementations SHOULD respond with an
      Invalid Parameter PA-TNC error code.
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Version Len  |   Product Version Number (Variable Length)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Build Num Len |   Internal Build Number (Variable Length)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Config. Len  | Configuration Version Number (Variable Length)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Version Len
    
        This field defines the number of octets in the Product
        Version Number field.  If the product version number is
        unavailable or unknown, this field MUST be set to 0 and the
        Product Version Number field will be zero length (effectively
        not present).
    
      Product Version Number
    
        This field contains a UTF-8 string identifying the version of
        the component (e.g. "1.12.23.114").  This field MUST be sized
        to fit the version string and MUST NOT include extra octets
        for padding or NUL character termination.
        Various products use a wide range of different formats and
        semantics for version strings.  Some use alphabetic
        characters, white space, and punctuation.  Some consider
        version "1.21" to be later than version "1.3" and some
    
    Sangster & Narayan     Expires April 6, 2009          [Page 28]
    

    Internet-Draft              PA-TNC              October 2008
    
        earlier.  Therefore, the syntax and semantics of this string
        are not defined.
    
      Build Num Len
    
        This field defines the number of octets in the Internal Build
        Number field.  For products where the internal build number
        is unavailable or unknown, this field MUST be set to 0 and
        the Internal Build Number field will be zero length
        (effectively not present).
    
      Internal Build Number
    
        This field contains a UTF-8 string identifying the
        engineering build number of the product.  This field MUST be
        sized to fit the build number string and MUST NOT include
        extra octets for padding or NUL character termination.  The
        syntax and semantics of this string are not defined.
    
      Config. Len
    
        This field defines the number of octets in the Configuration
        Version Number field.  If the product version number is
        unavailable or unknown, this field MUST be set to 0 and the
        Product Version Number field will be zero length (effectively
        not present).
    
      Configuration Version Number
    
        This field contains a UTF-8 string identifying the version of
        the configuration used by the component.  This version SHOULD
        represent the overall configuration version even if several
        configuration policy files or settings are used.  Posture
        Collectors MAY include multiple version numbers in this
        single string if a single version is not practical.  This
        field MUST be sized to fit the version string and MUST NOT
        include extra octets for padding or NUL character
        termination.
    
        Various products use a wide range of different formats for
        version strings.  Some use alphabetic characters, white
        space, and punctuation.  Some consider version "1.21" to be
        later than version "1.3" and some earlier.  In addition, some
        Posture Collectors may place multiple configuration version
        numbers in this single string. Therefore, the syntax and
        semantics of this string are not defined.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 29]
    

    Internet-Draft              PA-TNC              October 2008
    
    4.2.5. Operational Status
    
      This PA-TNC Attribute Type describes the operational status of a
      product that can implement the component specified in the PA
      Subtype field, as described in section 3.5. For example, if the
      PA Subtype is Anti-Spyware, this attribute would contain
      information about the operational status of a host-based anti-
      spyware product that may or may not be installed on the
      endpoint.
    
      Posture Collectors that implement the IETF Standard PA Subtype
      for Operating System or VPN MAY support sending this attribute
      type for those PA subtypes.  Posture Collectors that implement
      other IETF Standard PA Subtypes defined in this specification
      SHOULD support sending this attribute type for those PA
      subtypes.  Other Posture Collectors MAY support sending this
      attribute type.  Whether a particular Posture Collector actually
      sends this attribute type SHOULD still be governed by local
      privacy and security policies.  Posture Validators that
      implement the IETF Standard PA Subtype for Operating System or
      VPN MAY support receiving this attribute type, at least for
      those PA subtypes.  Posture Validators that implement other IETF
      Standard PA Subtypes defined in this specification SHOULD
      support receiving this attribute type, at least for those PA
      subtypes.  Other Posture Validators MAY support receiving this
      attribute type.  A Posture Validator that does not support
      receiving this attribute type SHOULD simply ignore attributes
      with this type.  Posture Validators MUST NOT send this attribute
      type.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 5.  The value in the PA-TNC Attribute Length field
      MUST be 36.  If the PA-TNC Attribute Length field does not have
      this value, implementations SHOULD respond with an Invalid
      Parameter PA-TNC error code.
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 30]
    

    Internet-Draft              PA-TNC              October 2008
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Status     |     Result    |         Reserved              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Last Use                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Last Use (continued)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Last Use (continued)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Last Use (continued)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Last Use (continued)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Status
    
        This field gives the operational status of the product.  The
        following table lists the values currently defined for this
        field.  As described in section 8. the IANA maintains a
        registry of valid values for this field so that new values
        can be defined.
    
         Value     Description
         -----     -----------
         0         Unknown or other
         1         Not installed
         2         Installed but not operational
         3         Operational
    
        If a Posture Validator receives a value for this field that
        it does not recognize, it SHOULD treat this value as
        equivalent to the value 0.
    
      Result
    
        This field contains the result of the last use of the
        product.  The following table lists the values currently
        defined for this field.  As described in section 8. the IANA
        maintains a registry of valid values for this field so that
        new values can be defined.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 31]
    

    Internet-Draft              PA-TNC              October 2008
    
         Value     Description
         -----     -----------
         0         Unknown or other
         1         Successful use with no errors detected
         2         Successful use with one or more errors detected
         3         Unsuccessful use (e.g. aborted)
    
        Posture Collectors SHOULD set this field to 0 if the Status
        field contains a value of 1 (Not installed) or 2 (Installed
        but not operational).  If a Posture Validator receives a
        value for this field that it does not recognize, it SHOULD
        treat this value as equivalent to the value 0.
    
      Reserved
    
        This field is reserved for future use.  The field MUST be set
        to 0 on transmission and ignored upon reception.
    
      Last Use
    
        This field contains the date and time of the last use of the
        component.  The Last Use date and time MUST be represented as
        an RFC 3339 [4] compliant ASCII string in Coordinated
        Universal Time (UTC) time with the additional restrictions
        that the 't' delimiter and the 'z' suffix MUST be capitalized
        and fractional seconds (time-secfrac) MUST NOT be included.
        Leap seconds are permitted and Posture Validators MUST
        support them. The last use string MUST NOT be NUL terminated
        or padded in any way.  If the last use time is not known, not
        applicable, or cannot be represented in this format, the
        Posture Collector MUST set this field to the value "0000-00-
        00T00:00:00Z" (allowing this field to be fixed length). Not
        that this particular reserved value is NOT a valid RFC 3339
        date and time and MUST NOT be used for any other purpose in
        this field.
    
        This encoding produces a string that is easy to read, parse,
        and interpret.  The format (more precisely defined in RFC
        3339) is YYYY-MM-DDTHH:MM:SSZ, resulting in one and only one
        representation for each second in UTC time from year 0000 to
        year 9999.  For example, 9:05:00AM EST (GMT-0500) on January
        19, 1995 can be represented as "1995-01-19T14:05:00Z".  The
        length of this field is always 20 octets.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 32]
    

    Internet-Draft              PA-TNC              October 2008
    
    4.2.6. Port Filter
    
      This PA-TNC Attribute Type provides the list of port numbers and
      associated protocols (e.g. TCP and UDP) that are currently
      blocked or allowed by a host-based firewall on the endpoint.
      Posture Collectors that implement the IETF Standard PA Subtype
      for Firewall or VPN SHOULD support sending this attribute type
      for those PA subtypes.  Posture Collectors that implement other
      IETF Standard PA Subtypes defined in this specification MUST NOT
      support sending this attribute type for those PA subtypes.
      Other Posture Collectors MAY support sending this attribute
      type, if it is appropriate to their PA subtype.  Whether a
      particular Posture Collector actually sends this attribute type
      SHOULD still be governed by local privacy and security policies.
      Posture Validators that implement the IETF Standard PA Subtype
      for Firewall or VPN SHOULD support receiving this attribute
      type, at least for those PA subtypes.  Posture Validators that
      implement other IETF Standard PA Subtypes defined in this
      specification MUST NOT support receiving this attribute type for
      those PA subtypes.  Other Posture Validators MAY support
      receiving this attribute type.  A Posture Validator that does
      not support receiving this attribute type SHOULD simply ignore
      attributes with this type.  Posture Validators MUST NOT send
      this attribute type.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 6.
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
      Note that this diagram shows two Protocol/Port Number pairs. The
      actual number of Protocol/Port Number pairs included in a Port
      Filter attribute can vary from one to a large number (limited
      only by the maximum message and length supported by the
      underlying PT transport protocol). However, each Port Filter
      attribute MUST contain at least one Protocol/Port Number pair.
      Because the length of a Protocol/Port Number pair with the
      Reserved field and B flag is always 4 octets, the number of
      Protocol/Port Number pairs can be easily computed using the PA-
      TNC Attribute Length field by subtracting the number of octets
      in the PA-TNC Attribute Header and dividing by 4.  If the PA-TNC
      Attribute Length field is invalid, Posture Validators SHOULD
      respond with an Invalid Parameter PA-TNC error code.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 33]
    

    Internet-Draft              PA-TNC              October 2008
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Reserved  |B|    Protocol   |         Port Number           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Reserved  |B|    Protocol   |         Port Number           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Reserved
    
        This field is reserved for future use.  It MUST be set to 0
        on transmission and ignored upon reception.
    
      B Flag (Blocked or Allowed Port)
    
        This single bit field indicates whether the following port is
        blocked or allowed.  This bit MUST be set to 1 if the
        protocol and port combination is blocked.  Otherwise this
        field MUST be set to 0.  This field was provided to allow for
        more abbreviated reporting of the port filtering policy (e.g.
        when all ports are blocked except a few, the Posture
        Collector can just list the few that are allowed).
        Posture Collectors MUST NOT provide a mixed list of block and
        non-blocked ports for a particular protocol.  To be more
        precise, a Posture Collector MUST NOT include two
        Protocol/Port Number pairs in a single Port Filter attribute
        where the protocol number is the same but the B flag is
        different.  Also, Posture Collectors MUST NOT list the same
        Protocol and Port Number combination twice in a Port List
        attribute.
    
        Posture Collectors MAY list all blocked ports for one
        protocol and all allowed ports for a different protocol in a
        single Port List attribute, using the B flag to indicate
        whether each entry is blocked.  For example, a Posture
        Collector might list all the blocked TCP ports but only list
        the allowed UDP ports.  However it MUST NOT list some blocked
        TCP ports and some other allowed TCP ports.
    
      Protocol
    
        This field contains the protocol number being blocked or
        allowed. The values used in this field are the same ones used
        in the IPv4 Protocol and IPv6 Next Header fields.  The IANA
        already maintains a registry of these values.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 34]
    

    Internet-Draft              PA-TNC              October 2008
    
      Port Number
    
        This field contains the port number being blocked or allowed.
        The values used in this field are specific to the protocol
        identified by the Protocol field.  The IANA maintains
        registries for TCP and UDP port numbers.
    
    4.2.7. Installed Packages
    
      This PA-TNC Attribute Type contains a list of the installed
      packages that comprise a product on the endpoint that implements
      the component specified in the PA Subtype field, as described in
      section 3.5.  This allows a Posture Validator to check which
      packages are installed for a particular product and which
      versions of those packages are installed.
    
      Posture Collectors that implement any of the IETF Standard PA
      Subtypes defined in this document SHOULD support sending this
      attribute type for those PA subtypes.  Other Posture Collectors
      MAY support sending this attribute type, if it is appropriate to
      their PA subtype.  Whether a particular Posture Collector
      actually sends this attribute type SHOULD still be governed by
      local privacy and security policies.  Posture Validators that
      implement any of the IETF Standard PA Subtypes defined in this
      document SHOULD support receiving this attribute type, at least
      for those PA subtypes.  Other Posture Validators MAY support
      receiving this attribute type.  A Posture Validator that does
      not support receiving this attribute type SHOULD simply ignore
      attributes with this type.  Posture Validators MUST NOT send
      this attribute type.
    
      This attribute type can be quite long, especially for the
      Operating System PA subtype. This can cause problems, especially
      with 802.1X and other limited transport protocols. Therefore,
      Posture Collectors SHOULD NOT send this attribute unless
      specifically requested to do so using the Attribute Request
      attribute or otherwise configured to do so. Also, Posture
      Validators SHOULD NOT request this attribute unless the
      transport protocol in use can support the large amount of data
      that may be sent in response.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 7.  The value in the PA-TNC Attribute Length field
      will vary, depending on the number of packages and the length of
      the Package Name and Package Version Number fields for those
      packages. However, the value in the PA-TNC Attribute Length
    
    Sangster & Narayan     Expires April 6, 2009          [Page 35]
    

    Internet-Draft              PA-TNC              October 2008
    
      field MUST be at least 16 because this is the length of the
      fixed size fields in the PA-TNC Attribute Header and the fixed
      size fields in this attribute type.  If the PA-TNC Attribute
      Length field is less than the size of these fixed length fields
      or does not match the length indicated by the sum of the fixed
      length and variable length fields, implementations SHOULD
      respond with an Invalid Parameter PA-TNC error code.
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
      Note that this diagram shows an attribute containing information
      on one package. The actual number of package descriptions
      included in an Installed Packages attribute is indicated by the
      Package Count field. This value may vary from zero to a large
      number (up to 65535, if the underlying PT transport protocol can
      support that many). If this number is not sufficient,
      specialized patch management software should be employed which
      can simply report compliance with a pre-established patch
      policy.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Reserved             |         Package Count         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Pkg Name Len  |        Package Name (Variable Length)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Version Len  |    Package Version Number (Variable Length)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Reserved
    
        This field is reserved for future use.  The field MUST be set
        to 0 on transmission and ignored upon reception.
    
      Package Count
    
        This field is an unsigned 16-bit integer that indicates the
        number of packages listed in this attribute.  For each
        package so indicated, a Pkg Name Len, Package Name, Version
        Len, and Package Version Number field is included in the
        attribute.
    
      Pkg Name Len
    
    Sangster & Narayan     Expires April 6, 2009          [Page 36]
    

    Internet-Draft              PA-TNC              October 2008
    
        This field is an unsigned 8-bit integer that indicates the
        length of the Package Name field in octets. This field may be
        zero if a Package Name is not available.
    
      Package Name
    
        This field contains the name of the package associated with
        the product.  This field is a UTF-8 encoded character string
        whose octet length is given by the Pkg Name Len field. This
        field MUST NOT include extra octets for padding or NUL
        character termination.  The syntax and semantics of this name
        are not specified in this document, since they may vary
        across products and/or operating systems. Posture Collectors
        MAY list two packages with the same name in a single
        Installed Packages attribute. The meaning of doing so is not
        defined here.
    
      Version Len
    
        This field is an unsigned 8-bit integer that indicates the
        length of the Package Version Number field in octets. This
        field may be zero if a Package Version Number is not
        available.
    
      Package Version Number
    
        This field contains the version string for the package named
        in the previous Package Name field.  This field is a UTF-8
        encoded character string whose octet length is given by the
        Version Len field. This field MUST NOT include extra octets
        for padding or NUL character termination.  The syntax and
        semantics of this version string are not specified in this
        document, since they may vary across products and/or
        operating systems. Posture Collectors MAY list two packages
        with the same Package Version Number (and even the same
        Package Name and Package Version Number) in a single
        Installed Packages attribute. The meaning of doing so is not
        defined here.
    
    4.2.8. PA-TNC Error
    
      This PA-TNC Attribute Type contains an error code and
      supplemental information regarding an error pertaining to PA-
      TNC.
    
      All Posture Collectors and Posture Validators that implement any
      of the IETF Standard PA Subtypes defined in this specification
    
    Sangster & Narayan     Expires April 6, 2009          [Page 37]
    

    Internet-Draft              PA-TNC              October 2008
    
      MUST support sending and receiving this attribute type, at least
      for those PA subtypes.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 8.  The value in the PA-TNC Attribute Length field
      will vary, depending on the length of the Error Information
      field. However, the value in the PA-TNC Attribute Length field
      MUST be at least 20  because this is the length of the fixed
      size fields in the PA-TNC Attribute Header and the fixed size
      fields in this attribute type.
    
      A PA-TNC error code SHOULD be sent with the same PA Message
      Vendor ID and PA Subtype used by the PA-TNC message that caused
      the error so that the error code is sent to the party who sent
      the offending PA-TNC message. Other measures (such as setting
      PB-TNC's EXCL flag and Posture Collector Identifier or Posture
      Validator Identifier fields) SHOULD also be taken to attempt to
      ensure that only the party who sent the offending message
      receives the error.
    
      When a PA-TNC error code is received, the recipient MUST NOT
      respond with a PA-TNC error code because this could result in an
      infinite loop of errors. Instead, the recipient MAY log the
      error, modify its behavior to attempt to avoid the error
      (attempting to avoid loops or long strings of errors), ignore
      the error, terminate the assessment, or take other action as
      appropriate (as long as it is consistent with the requirements
      of this specification).
    
      Posture Verifiers MUST NOT include this attribute type in an
      Attribute Request attribute. It does not make sense for a
      Posture Verifier to request that a Posture Collector send a PA-
      TNC Error attribute.
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
    
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 38]
    

    Internet-Draft              PA-TNC              October 2008
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |            PA-TNC Error Code Vendor ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        PA-TNC Error Code                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Error Information (Variable Length)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Reserved
    
        This field is reserved for future use.  This field MUST be
        set to 0 on transmission and ignored upon reception.
    
      PA-TNC Error Code Vendor ID
    
        This field contains the SMI Private Enterprise Number for the
        organization that defined the PA-TNC Error Code that is being
        used in the attribute.  For IETF Standard PA-TNC Error Code
        values this field MUST be set to zero (0).
    
      PA-TNC Error Code
    
        This field contains the PA-TNC Error Code being reported in
        this attribute. Note that a particular PA-TNC Error Code
        value will have completely different meanings depending on
        the PA-TNC Error Code Vendor ID. Each PA-TNC Error Code
        Vendor ID defines a different space of PA-TNC Error Code
        values.
    
        When the PA-TNC Error Code Vendor ID is set to zero (0), the
        PA-TNC Error Code is an IETF Standard PA-TNC Error Code. The
        IANA maintains a registry for these values. The following
        table lists the IETF Standard PA-TNC Error Codes defined in
        this specification:
    
         Value     Description
         -----     -----------
         0         Reserved
         1         Invalid Parameter
         2         Version Not Supported
         3         Attribute Type Not Supported
    
        The next few subsections of this document provide detailed
        definitions of these error codes.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 39]
    

    Internet-Draft              PA-TNC              October 2008
    
      Error Information
    
        This field provides additional context for the error.  The
        contents of this field vary based on the PA-TNC Error Code
        Vendor ID and PA-TNC Error Code. Therefore, whenever a PA-TNC
        Error Code is defined, the format of this field for that
        error code must also be defined. The definitions of IETF
        Standard PA-TNC Error Codes on the next few pages provide
        good examples of such definitions.
    
        The length of this field can be determined by the recipient
        using the PA-TNC Attribute Length field by subtracting the
        length of the fixed-length fields in the PA-TNC Attribute
        Header and the fixed-length fields in this attribute.
    
    4.2.8.1. Invalid Parameter Error Code
    
      The Invalid Parameter error code is an IETF Standard PA-TNC
      Error Code (value 1) that indicates that the sender of this
      error code has detected an invalid value in a PA-TNC message
      sent by the recipient of this error code in the current
      assessment.
    
      For this error code, the Error Information field contains the
      first 8 octets of the PA-TNC message that contained the invalid
      parameter and an offset indicating the position within that
      message of the invalid parameter.
    
      The following diagram illustrates the format and contents of the
      Error Information field for this error code.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Message Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Offset                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Version
    
        This field MUST contain an exact copy of the Version field in
        the PA-TNC Message Header of the PA-TNC message that caused
        this error.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 40]
    

    Internet-Draft              PA-TNC              October 2008
    
      Reserved
    
        This field MUST contain an exact copy of the Reserved field
        in the PA-TNC Message Header of the PA-TNC message that
        caused this error.
    
      Message Identifier
    
        This field MUST contain an exact copy of the Message
        Identifier field in the PA-TNC Message Header of the PA-TNC
        message that caused this error.
    
      Offset
    
        This field MUST contain an octet offset from the start of the
        PA-TNC Message Header of the PA-TNC message that caused this
        error to the start of the value that caused this error. For
        instance, if the first PA-TNC attribute in the message had an
        invalid PA-TNC Attribute Length (e.g. 0), this value would be
        16.
    
    4.2.8.2. Version Not Supported Error Code
    
      The Version Not Supported error code is an IETF Standard PA-TNC
      Error Code (value 2) that indicates that the sender of this
      error code does not support the PA-TNC version number included
      in the PA-TNC Message Header of a PA-TNC message sent by the
      recipient of this error code in the current assessment.
      For this error code, the Error Information field contains the
      first 8 octets of the PA-TNC message that contained the
      unsupported version as well as Max Version and Min Version
      fields that indicate which PA-TNC version numbers are supported
      by the sender of the error code.
    
      The sender MUST support all PA-TNC versions between the Min
      Version and the Max Version, inclusive (i.e. including the Min
      Version and the Max Version). When possible, recipients of this
      error code SHOULD send future messages to the Posture Collector
      or Posture Validator that originated this error message with a
      PA-TNC version number within the stated range.
    
      Any party that is sending the Version Not Supported error code
      SHOULD include that error code as the only PA-TNC attribute in a
      PA-TNC message with version number 1. All parties that send PA-
      TNC messages SHOULD be able to properly process a message that
      meets this description, even if they cannot process any other
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 41]
    

    Internet-Draft              PA-TNC              October 2008
    
      aspect of PA-TNC version 1. This ensures that a PA-TNC version
      exchange can proceed properly, no matter what versions of PA-TNC
      the parties implement.
    
      The following diagram illustrates the format and contents of the
      Error Information field for this error code.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |                Copy of Reserved               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Message Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Max Version  |  Min Version  |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Version
    
        This field MUST contain an exact copy of the Version field in
        the PA-TNC Message Header of the PA-TNC message that caused
        this error.
    
      Copy of Reserved
    
        This field MUST contain an exact copy of the Reserved field
        in the PA-TNC Message Header of the PA-TNC message that
        caused this error.
    
      Message Identifier
    
        This field MUST contain an exact copy of the Message
        Identifier field in the PA-TNC Message Header of the PA-TNC
        message that caused this error.
    
      Max Version
    
        This field MUST contain the maximum PA-TNC version supported
        by the sender of this error code.
    
      Min Version
    
        This field MUST contain the minimum PA-TNC version supported
        by the sender of this error code.
    
      Reserved
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 42]
    

    Internet-Draft              PA-TNC              October 2008
    
        Reserved for future use.  This field MUST be set to 0 on
        transmission and ignored upon reception.
    
    4.2.8.3. Attribute Type Not Supported Error Code
    
      The Attribute Type Not Supported error code is an IETF Standard
      PA-TNC Error Code (value 3) that indicates that the sender of
      this error code does not support the PA-TNC Attribute Type
      included in the Error Information field. This PA-TNC Attribute
      Type was included in a PA-TNC message sent by the recipient of
      this error code in the current assessment.
    
      For this error code, the Error Information field contains the
      first 8 octets of the PA-TNC message that contained the
      unsupported attribute type as well as a copy of the attribute
      type that caused the problem.
    
      The following diagram illustrates the format and contents of the
      Error Information field for this error code.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Message Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Flags     |          PA-TNC Attribute Vendor ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     PA-TNC Attribute Type                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Version
    
        This field MUST contain an exact copy of the Version field in
        the PA-TNC Message Header of the PA-TNC message that caused
        this error.
    
      Copy of Reserved
    
        This field MUST contain an exact copy of the Reserved field
        in the PA-TNC Message Header of the PA-TNC message that
        caused this error.
    
      Message Identifier
    
    Sangster & Narayan     Expires April 6, 2009          [Page 43]
    

    Internet-Draft              PA-TNC              October 2008
    
        This field MUST contain an exact copy of the Message
        Identifier field in the PA-TNC Message Header of the PA-TNC
        message that caused this error.
    
      Flags
    
        This field MUST contain an exact copy of the Flags field in
        the PA-TNC Attribute Header of the PA-TNC attribute that
        caused this error.
    
      PA-TNC Attribute Vendor ID
    
        This field MUST contain an exact copy of the PA-TNC Attribute
        Vendor ID field in the PA-TNC Attribute Header of the PA-TNC
        attribute that caused this error.
    
      PA-TNC Attribute Type
    
        This field MUST contain an exact copy of the PA-TNC Attribute
        Type field in the PA-TNC Attribute Header of the PA-TNC
        attribute that caused this error.
    
    4.2.9. Assessment Result
    
      This PA-TNC attribute contains the final assessment result from a
      particular Posture Validator.  This attribute might be returned to
      a Posture Collector for information purposes such as when an
      endpoint is compliant.  Similarly, the Assessment Result attribute
      could be sent to indicate a non-compliant result where specific
      actions are needed to bring an endpoint into compliance with the
      network's policies.  These actions could be defined in other PA-
      TNC attributes such as Remediation Instructions sent to the
      Posture Collector.
    
      All Posture Collectors that support an IETF standard PA Subtype
      defined in this specification SHOULD support receiving and
      processing the Assessment Result attribute.  All Posture
      Validators that implement an IETF standard PA Subtype defined in
      this specification SHOULD support sending the Assessment Result
      attribute.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 9.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 44]
    

    Internet-Draft              PA-TNC              October 2008
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Assessment Result                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Assessment Result
    
        This 32-bit field MUST contain one of the following values
    
        Value       Description
        -----       -----------
        0     Posture Validator assessed the endpoint component to
              be compliant with policy
        1     Posture Validator assessed the endpoint component to
              be non-compliant with policy but the difference from
              compliant was minor.
        2     Posture Validator assessed the endpoint component to
              be non-compliant with policy and the assessed
              difference was very significant.
        3     Posture Validator was unable to determine policy
              compliance of an endpoint component due to an error.
        4     Posture Validator was unable to determine whether the
              assessed endpoint component was compliant with policy
              based on the attributes provided by the Posture
              Collector(s)
    
    4.2.10. Remediation Instructions
    
      This PA-TNC attribute sent by the Posture Validator to the Posture
      Collector(s) contains remediation instructions for updating a
      particular component to make the endpoint compliant with the
      assessment policies.  A Posture Validator might choose to send
      more then one Remediation Instructions attributes in some
      circumstances (e.g. both a URI and a human readable message are
      necessary) to remediate one or more components.  This attribute
      supports the inclusion of either an IETF Standard or vendor
      specific remediation instruction.
    
    
      Sangster & Narayan     Expires April 6, 2009          [Page 45]
    

    Internet-Draft              PA-TNC              October 2008
    
      All Posture Collectors that implement an IETF standard PA
      Subtype defined in this specification SHOULD support receiving
      and processing the Remediation Instructions attribute.  All
      Posture Validators that implement an IETF standard PA Subtype
      defined in this specification SHOULD support sending this
      attribute type.  Posture Collectors and Posture Validators
      supporting other non-IETF standard components MAY support this
      attribute.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 10.
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |       Remediation Parameters Vendor ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Remediation Parameters Type                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Remediation Parameters (Variable Length)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Reserved (8 bits)
    
        The Reserved bits MUST be set to 0 on transmission and ignored
        on reception.
    
      Remediation Parameters Vendor ID (24 bits)
    
        The Remediation Parameters Vendor ID field identifies a vendor
        by using the SMI Private Enterprise Number (PEN).  Any
        organization can receive its own unique PEN from IANA, the
        Internet Assigned Numbers Authority.  The Remediation Parameters
        Vendor ID qualifies the Remediation Parameters Type field so
        that each vendor has 2^32 separate Remediation Parameters Types
        available for its use.  Remediation Parameters Types
        standardized by the IETF are always used with the value zero (0)
        in this field.
    
      Remediation Parameters Type (32 bits)
    
        The Remediation Parameters Type field identifies the different
        types of remediation instructions that can be contained in the
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 46]
    

    Internet-Draft              PA-TNC              October 2008
    
        Remediation Parameters field.  IANA maintains a registry of IETF
        Standard PA-TNC Remediation Parameters Types.  A list of IETF
        Standard PA-TNC Remediation Parameters Types defined in this
        specification appears later in this section.
    
        New vendor-specific remediation instructions can be created by
        adding new Remediation Parameters Types (those used with a non-
        zero Remediation Parameters vendor ID) without IETF or IANA
        involvement.
    
      Remediation Parameters (variable length)
    
        The Remediation Parameters field contains the actual remediation
        instructions for the Posture Collector.
    
    4.2.10.1. IETF Standard PA-TNC Remediation Parameters Types
    
      This subsection defines several PA-TNC Remediation Parameters
      Types that have been standardized by the IETF.
    
      Remediation-URI
    
        Posture Validators can include a Remediation-URI in the PA
        message by creating a Remediation Instructions attribute with:
    
            Remediation Parameters Vendor ID = 0
            Remediation Parameters Type = 1
            Remediation Parameters = URI
    
        The Remediation Parameters field in the Remediation Instructions
        attribute MUST contain a URI, as described in RFC 3986 [9].
        This URI SHOULD contain instructions to update a particular
        component so that it might result in the component being
        compliant with the policies in future assessments.
    
      Remediation-String
    
        Posture Validators can include a Remediation-String in the PA
        message by creating a Remediation Instructions attribute with:
    
            Remediation Parameters Vendor ID = 0
            Remediation Parameters Type = 2
            Remediation Parameters = UTF-8 encoded string
    
    Sangster & Narayan     Expires April 6, 2009          [Page 47]
    

    Internet-Draft              PA-TNC              October 2008
    
        The Remediation Parameters field in the Remediation Instructions
        attribute MUST contain a UTF-8 encoded string.  This string
        should contain human-readable instructions for remediation that
        MAY be displayed to the user by the Posture Collector.  The
        Remediation String SHOULD be localized in the user's preferred
        language when known and supported by the NEA Server.
    
    4.2.11. Forwarding Enabled
    
      This PA-TNC attribute indicates whether the endpoint is forwarding
      traffic between interfaces.  Endpoints that forward traffic
      between networks connected to multiple network interfaces may be
      considered non-compliant (and a security risk) in some enterprise
      network deployments.  For example, an endpoint with multiple
      connected network interfaces might allow traffic from an interface
      connected to a public network to be forwarded through another
      interface carrying a VPN session to a protected enterprise
      network.  This attribute is currently envisioned to be specific to
      reporting posture for the operating system component, however
      could be useful for other future types of components.
    
      Posture Collectors that implement the IETF standard PA Subtype
      for Operating System SHOULD support sending the Forwarding
      Enabled attribute.  Posture Collectors that do not implement the
      Operating System PA Subtype defined in this specification SHOULD
      NOT send the Forwarding Enabled attribute unless if it is
      appropriate to their PA Subtype.  Whether a particular Posture
      Collector actually sends this attribute type SHOULD still be
      governed by local privacy and security policies.  Posture
      Validators that implement the IETF standard PA Subtype for
      Operating System SHOULD support receiving the Forwarding Enabled
      attribute type.  Posture Validators supporting components other
      than Operating System MAY support receiving this attribute type
      if it is appropriate to their PA Subtype.  A Posture Validator
      that does not support receiving this attribute type SHOULD
      simply ignore attributes with this type.  Posture Validators
      MUST NOT send this attribute type.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 11.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 48]
    

    Internet-Draft              PA-TNC              October 2008
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Forwarding Enabled                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Forwarding Enabled
    
        This 32-bit field MUST contain one of the following values
    
        Value       Description
        -----       -----------
        0         Disabled - Endpoint is not forwarding traffic.
        1         Enabled - Endpoint is forwarding traffic.
        2         Unknown - Unable to determine whether endpoint is
                  forwarding traffic.
    
    4.2.12. Factory Default Password Enabled
    
      This PA-TNC attribute indicates whether the endpoint has a factory
      default password enabled for use.  Some types of endpoints
      include a default static password for used to gain privileged
      access to the endpoint. If this password is not changed or
      disabled before the endpoint is accessible on the network, it's
      often easy to compromise the endpoint.
    
      Posture Collectors that implement the IETF standard PA Subtype
      for Operating System SHOULD support sending the Factory Default
      Password Enabled attribute.  Posture Collectors that implement
      other IETF Standard PA Subtypes defined in this specification
      SHOULD NOT support sending this attribute type for those PA
      subtypes.  Other Posture Collectors MAY support sending this
      attribute type, if it is appropriate to their PA subtype.
      Whether a particular Posture Collector actually sends this
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 49]
    

    Internet-Draft              PA-TNC              October 2008
    
      attribute type SHOULD still be governed by local privacy and
      security policies.  Posture Validators that implement the IETF
      standard PA Subtype for Operating System SHOULD support
      receiving the Factory Default Password Enabled attribute.  Other
      Posture Validators MAY support receiving this attribute type.  A
      Posture Validator that does not support receiving this attribute
      type SHOULD simply ignore attributes with this type.  Posture
      Validators MUST NOT send this attribute type.
    
      For this attribute type, the PA-TNC Attribute Vendor ID field
      MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
      be set to 12.
    
      The following diagram illustrates the format and contents of the
      Attribute Value field for this attribute type.  The text after
      this diagram describes the fields shown here.
    
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Factory Default Password Enabled                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
      Factory Default Password Enabled
    
        This 32-bit field MUST contain one of the following values
    
        Value       Description
        -----       -----------
        0       Endpoint does not have a factory default password
                enabled.
        1       Endpoint has a factory default password enabled.
    
    4.3. Vendor-Defined Attributes
    
      This section discusses the use of vendor-defined attributes
      within PA-TNC.  The PA-TNC protocol was designed to allow for
      vendor-defined attributes to be used as a replacement where a
      standard attribute could be used.  In some cases even the
      standard attributes allow for vendor-defined information to be
      included.  It is envisioned that over time as particular vendor-
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 50]
    

    Internet-Draft              PA-TNC              October 2008
    
      defined attributes become popular, an equivalent standard
      attribute could be added allowing for broader interoperability.
      This specification does not define vendor-defined attributes,
      but rather highlights how such attributes can be used with PA-
      TNC without the potential for name space collisions or
      misinterpretations.  In order to avoid collisions, PA-TNC uses
      the well-established SMI Private Enterprise Numbers as Vendor
      IDs to define separate name spaces for important fields within a
      PA-TNC message.  For example, to ensure the uniqueness of
      attribute types while providing for vendor extensions, vendor-
      defined attribute types include the vendor's unique Vendor ID,
      to indicate the intended name space for the attribute type,
      followed by the attribute type.  IETF Standard PA-TNC Attribute
      Types use a Vendor ID of zero (0).
    
      SMI Private Enterprise Numbers are used to provide a separate
      identifier space for each vendor. The IANA provides a registry
      for SMI Private Enterprise Numbers. Any organization (including
      non-profit organizations, governmental bodies, etc.) can obtain
      one of these numbers at no charge and thousands of organizations
      have done so. Within this document, SMI Private Enterprise
      Numbers are known as "vendor IDs".
    
    5. 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.
    
    5.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.
    
    5.2. Evaluation Against Requirement C-2
    
      Requirement C-2 says:
    
    Sangster & Narayan     Expires April 6, 2009          [Page 51]
    

    Internet-Draft              PA-TNC              October 2008
    
      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.
    
    5.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 can be provided through PT security or
      through the use of PA-TNC security, which is defined in a
      separate specification: PA-TNC Security [8]. Therefore, this
      base specification for PA-TNC does not include any security
      capabilities. Since this requirement only applies to NEA
      protocols that include security capabilities, this base
      specification for PA-TNC meets this requirement.
    
    5.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.
    
    5.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
    
    Sangster & Narayan     Expires April 6, 2009          [Page 52]
    

    Internet-Draft              PA-TNC              October 2008
    
           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.
    
    5.6. Evaluation Against Requirement C-6
    
      Requirement C-6 says:
    
      C-6  NEA protocols MUST be highly scalable; the protocols MUST
           support many Posture Collectors on a large number of NEA
           Clients to be assessed by numerous Posture Validators
           residing on multiple NEA Servers.
    
      PA-TNC meets this requirement.  PA-TNC supports an unlimited
      number of Posture Collectors, Posture Validators, NEA Clients,
      and NEA Servers.  It also is quite scalable in many other
      aspects as well.  A PA-TNC message can contain up to 2^32-1
      octets and about 2^28 PA-TNC attributes.  Each organization with
      an SMI Private Enterprise Number is entitled to define up to
      2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor-
      specific PA-TNC Product IDs, and 2^32 vendor-specific PA-TNC
      Error Codes. Each attribute can contain almost 2^32 octets.  It
      is generally not advisable or necessary to send this much data
      in a NEA assessment, but still PA-TNC is highly scalable and
      meets requirement C-6 easily.
    
    5.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
    
    Sangster & Narayan     Expires April 6, 2009          [Page 53]
    

    Internet-Draft              PA-TNC              October 2008
    
      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).
    
    5.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 PA-TNC security or 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.
    
    5.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 fields defined here do not
      include any strings intended for display to a user. They 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 can be adapted to the
      user's language preferences using the PB-TNC protocol's ability
      to exchange information about those preferences in a standard
      manner.  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.
    
    5.10. Evaluation Against Requirement C-10
    
      Requirement C-10 says:
    
    Sangster & Narayan     Expires April 6, 2009          [Page 54]
    

    Internet-Draft              PA-TNC              October 2008
    
      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.
    
    5.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 roundtrips, 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 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 to not send or use
      smaller attributes (including assertions from previous
      assessments) when faced with a very constrained network
      connection.
    
    5.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.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 55]
    

    Internet-Draft              PA-TNC              October 2008
    
      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 IETF Standard
      PA-TNC Attribute Types with new values added by IETF Consensus,
      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.
    
    5.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 name spaces.
    
      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 name spaces.
    
    5.14. Evaluation Against Requirement PA-3
    
      Requirement PA-3 says:
    
      PA-3 The PA protocol MUST enable a Posture Validator to make
           one or more requests for attributes from a Posture
           Collector within a single assessment.  This enables the
           Posture Validator to reassess the posture of a particular
           endpoint feature or to request additional posture
           including from other parts of the endpoint.
    
      PA-TNC meets this requirement.  The Attribute Request attribute
      type is an IETF Standard PA-TNC Attribute Type that permits a
      Posture Validator to send to one or more Posture Collectors a
      request for one or more attributes. This attribute may be sent
      at any point in the posture assessment process and may in fact
      be sent more than once if the Posture Validator needs to first
    
    Sangster & Narayan     Expires April 6, 2009          [Page 56]
    

    Internet-Draft              PA-TNC              October 2008
    
      determine the type of operating system and then request certain
      attributes specific to that operating system, for example.
    
    5.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.
    
    5.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 meets this requirement when a PA-TNC Security mechanism
      is used, such as PA-TNC Security with CMS.  The specifications
      for those mechanisms should be consulted for a complete analysis
      of their security properties.
    
      PA-TNC Security is an optional addition to PA-TNC because
      different products and deployments may require different
      security mechanisms. For example, one product might integrate
      Posture Validators, the Posture Broker Server, and the Posture
      Transport Server into a single entity. In that case, PA-TNC
      security may not be needed. PT security may be enough. Another
      deployment may employ remote Posture Validators in the same
      trust domain as the Posture Broker Server. In that case, a TLS
      session between the Posture Broker Server and the Posture
      Validators may suffice. A third deployment may include a Posture
      Broker Server that is not trusted to see PA-TNC messages, at
      least for some Posture Validators. In that case, PA-TNC security
      may be desirable. Even there, some deployments may wish to use
      PKI (Public Key Infrastructure) for security, while others may
      wish to use Kerberos or another mechanism.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 57]
    

    Internet-Draft              PA-TNC              October 2008
    
    5.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 and in the PA-TNC Security with CMS specification.
    
    6. Security Considerations
    
      This section discusses the major types of potential security
      threats relevant to the PA-TNC message protocol and summarizes
      the expected security protections that should be offered by PA-
      TNC security protocols.  PA-TNC security protocols are described
      in separate specifications which layer upon the base PA-TNC
      protocol described in this specification.  It is envisioned that
      additional attribute types will be defined to facilitate the
      exchange of security capabilities, keys, and security protected
      attributes.  Ultimately, the NEA deployer decides which security
      protection is most appropriate for a particular deployment
      environment.  The security protections discussed in this section
      highlight the need for PA-TNC security protocol implementations
      to be capable of offering the feature.
    
    6.1. Trust Relationships
    
      In order to understand where security countermeasures are
      necessary, this section starts with a discussion of where the
      TNC architecture envisions some trust relationships between the
      processing elements of the PA-TNC protocol.  Some deployments
      may wish to reduce the amount of assumed trust by using a PA-TNC
      security protocol to protect the PA-TNC messages.  The following
      sub-sections discuss the trust properties associated with each
      portion of the NEA reference model directly involved with the
      processing of the PA-TNC protocol.
    
    6.1.1. Posture Collector
    
      The Posture Collectors are trusted by Posture Validators to:
    
      o Collect valid information about the component type associated
        with the Posture Collector
    
    Sangster & Narayan     Expires April 6, 2009          [Page 58]
    

    Internet-Draft              PA-TNC              October 2008
    
      o Report upon collected information consistent with local
        security and privacy policies
      o Accurately report information associated with the type of
        component for the PA-TNC message
      o Not act maliciously to the Posture Broker Server and Posture
        Validators, including attacks such as Denial Of Service
    
    6.1.2. Posture Validator
    
      The Posture Validators are trusted by Posture Collectors to:
    
      o Only request information necessary to assess the security
        state of the endpoint
      o Make assessment decisions based on deployer defined policies
      o Discard collected information consistent with data retention
        and privacy policies
      o Not act maliciously to the Posture Broker Server and Posture
        Collectors, including attacks such as Denial Of Service
    
    6.1.3. Posture Broker Client, Posture Broker Server
    
      The Posture Broker Client and Posture Broker Server are trusted
      by the Posture Collector and Posture Validator to:
    
      o Provide a reliable transport for PA-TNC messages
      o Deliver messages for a particular PA Subtype only to those
        Posture Collectors and Posture Validators that have
        registered for them
      o Not disclose any provided attributes to unauthorized parties
      o Not act maliciously to drop messages, duplicate messages, or
        flood the Posture Collectors and Posture Validators with
        unnecessary messages
      o Not observe, fabricate, or alter the contents of a PA-TNC
        message (this trust can be minimized with a PA-TNC security
        protocol)
    
    Sangster & Narayan     Expires April 6, 2009          [Page 59]
    

    Internet-Draft              PA-TNC              October 2008
    
      o Properly place Posture Collector and Posture Validator
        identifiers into the PB-TNC protocol, deliver those
        identifiers to Posture Collectors and Posture Validators as
        needed, and manage exclusive delivery to a particular Posture
        Collector or Posture Validator
      o Properly expose authentication information from PT security
        so that Posture Collectors and Posture Validators can use
        this to make policy decisions
    
    6.2. Security Threats
    
      Beyond the trusted relationships assumed in section 6.1. the PA-
      TNC protocol faces a number of potential security attacks that
      could require targeted security countermeasures.  PA-TNC
      security protocol specifications MUST state if and how the
      security protocol will safeguard against these types of attack.
      Generally the PA-TNC protocol, without the presence of security
      countermeasures, relies upon the underlying PT protocol to
      protect the messages from attack when traveling over the
      network.  Once the message resides on the Posture Broker Client
      or Posture Broker Server, it is trusted to be properly and
      safely delivered to the appropriate Posture Collectors and
      Posture Validators.  However, in some deployments the PA-TNC
      messages need to travel over network hops that are not protected
      by PT or require more assurance that only the appropriate
      Posture Collector or Posture Validator has received the message.
      In these cases, end to end PA-TNC message protection might be
      required.  The following sub-sections focus on the potential
      threats where end to end protection might be desired and thus
      when the use of the PA-TNC security protocol becomes beneficial.
    
    6.2.1. Attribute Theft
    
      When PA-TNC messages are sent over unprotected network links or
      spanning local software stacks that are not trusted, the
      contents of the PA-TNC messages may be subject to information
      theft by an intermediary party.  This theft could result in
      information being recorded for future use or analysis by the
      adversary.  Attributes observed by eavesdroppers could contain
      information that exposes potential weaknesses in the security of
      the endpoint, or system fingerprinting information easing the
      ability of the attacker to employ attacks more likely to be
      successful against the endpoint.  The eavesdropper might also
      learn information about the endpoint or network policies that
      either singularly or collectively is considered sensitive
    
    Sangster & Narayan     Expires April 6, 2009          [Page 60]
    

    Internet-Draft              PA-TNC              October 2008
    
      information (e.g. certain endpoints are lacking patches, or
      particular sub-networks have more lenient policies).  PA-TNC
      attributes are not intended to carry privacy-sensitive
      information, but should some exist in a message, the adversary
      could come into possession of the information which could be
      used for other financial gain.
    
    6.2.2. Message Fabrication
    
      Attackers on the network or present within the NEA system could
      introduce fabricated PA-TNC messages intending to trick or
      create a denial of service against aspects of an assessment.
      This could occur if an active attacker could launch a man-in-
      the-middle (MiTM) attack by proxying the PA-TNC messages and was
      able to replace undesired messages with ones easing future
      attack upon the endpoint.  Consider a scenario where PT security
      protection is not used and the Posture Broker Server proxies all
      assessment traffic to a remote Posture Broker Server.  The proxy
      could eavesdrop and replace assessment results attributes,
      tricking the endpoint into thinking it has passed an assessment,
      when in fact it has not and requires remediation.  Because the
      Posture Collector has no way to verify that attributes were
      actually created by an authentic Posture Validator, it is unable
      to detect the falsified attribute or message.
    
    6.2.3. Attribute Modification
    
      This attack could allow an active attacker capable of
      intercepting a message to modify a PA-TNC message attribute to a
      desired value to ease the compromise of an endpoint.  Without
      the ability for message recipients to detect whether a received
      message contains the same content as what was originally sent,
      active attackers can stealthily modify the attribute exchange.
      For example, an attacker might wish to change the contents of
      the firewall component's version string attribute to disguise
      the fact that the firewall is running an old, vulnerable
      version.  The attacker would change the version string sent by
      the firewall Posture Collector to the current version number, so
      the Posture Validator's assessment passes while leaving the
      endpoint vulnerable to attack.  Similarly, an attacker could
      achieve widespread denial of service by altering large numbers
      of assessments' version string attributes to an old value so
      they repeatedly fail assessments even after a successful
      remediation.  Upon receiving the lower value, the Posture
      Validator would continue to believe that the endpoint is running
      old, potentially vulnerable versions of the firewall that does
    
    Sangster & Narayan     Expires April 6, 2009          [Page 61]
    

    Internet-Draft              PA-TNC              October 2008
    
      not meet network compliance policy, so therefore the endpoint
      would not be allowed to join the network.
    
    6.2.4. Attribute Replay
    
      Another potential attack against an unprotected PA-TNC message
      attribute exchange is to exploit the lack of a strong binding
      between the attributes sent during an assessment to the specific
      endpoint.  Without a strong binding of the endpoint to the
      measurement information, an attacker could record the attributes
      sent during an assessment of a compliant endpoint and later
      replay those attributes so that a non-compliant endpoint can now
      gain access to the network or protected resource.  This attack
      could be employed by a network MiTM that is able to eavesdrop
      and proxy message exchanges, or by using local rogue agents on
      the endpoints.  Assessments lacking some form of freshness
      exchange could be subject to replay of prior assessment data,
      even if it no longer reflects the current state of the endpoint.
    
    6.2.5. Attribute Insertion
    
      Similar to the attribute modification attacks, an adversary
      wishing to include one or more attributes or PA-TNC messages
      inside a valid assessment may be able to insert the attributes
      or messages without detection is possible by the recipient.
      Even if authentication of the parties is present during a PA-TNC
      exchange, if no per-message and per-session integrity protection
      is present, an attacker can add information to the assessment,
      possibly causing incorrect assessment results.  For example, an
      attacker could add attributes to the front of a PA-TNC message
      to cause an assessment to succeed even for a non-compliant
      endpoint, particularly if it knew that the recipient ignored
      repeated attributes within a message.  Similarly, if a Posture
      Collector or Posture Validator always generated an error if it
      saw unexpected attributes, the attacker could cause failures and
      denial of service by adding attributes or messages to an
      exchange.
    
    6.2.6. Denial of Service
    
      A variety of types of denial of service attacks are possible
      against the PA-TNC message exchange if left unprotected to
      untrusted parties along the communication path between the
      Posture Collector and Posture Validator.   Normally, the PT
      exchange is bi-directionally authenticated which helps to
      prevent a MiTM on the network from becoming an active proxy, but
      transparent message routing gateways may still exist on the
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 62]
    

    Internet-Draft              PA-TNC              October 2008
    
      communication path and can modify the integrity of the message
      exchange unless adequate integrity protection is provided.  If
      the MiTM or other entities on the network can send messages to
      the Posture Broker Client or Posture Broker Server that appear
      to be part of an assessment, these messages could confuse the
      Posture Collector and Posture Validator or cause them to perform
      unnecessary work or take incorrect action.  Several example
      denial of service situations are described in section 6.2.3. and
      6.2.5.  Many potential denial of service examples exist,
      including flooding messages to Posture Collector or Posture
      Validator, sending very large messages containing many
      attributes, and repeatedly asking for resource intensive
      operations.
    
    7. Privacy Considerations
    
      The PA-TNC protocol is designed to allow for controlled
      disclosure of security relevant information about an endpoint,
      specifically for the purpose of enabling an assessment of the
      endpoint's compliance with network policy.  The purpose of this
      protocol is to provide visibility into the state of the
      protective mechanisms on the endpoint, in order for the Posture
      Validators and Posture Broker Server to determine whether the
      endpoint is up to date and thus has the best chance of being
      resilient in the face of malware threats.  One risk associated
      with providing visibility into the contents of an endpoint is
      the increased chance for exposure of privacy sensitive
      information without the consent of the user.
    
      While this protocol does provide the Posture Validator the
      ability to request specific information about the endpoint, the
      protocol is not open ended--bounding the Posture Validator to
      only query specific information (attributes) about specific
      security features (component types) of the endpoint.  Each PA-
      TNC message is explicitly about a single component from the list
      of components in section 3.5.  These components include a list
      of security-related aspects of the endpoint that affect the
      ability of the endpoint to resist attacks and thus are of
      interest during an assessment.  Discretionary components used by
      the user to create or view content are not on the list, as they
      are more likely to have access to privacy sensitive information.
      Similarly, PA-TNC messages contain a set of attributes which
      describe the particular component.  Each attribute contains
      generic information (e.g. product information or versions) about
      the component, so it is unlikely to include any user specific or
      identifying information.  This combination of limited set of
      security related components with non-user specific attributes
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 63]
    

    Internet-Draft              PA-TNC              October 2008
    
      greatly reduces the risk of exposure of privacy sensitive
      information.  Vendors that choose to define additional component
      types and/or attributes within their name space are encouraged
      to provide similar constraints.
    
      Even with the bounding of standard attribute information to
      specific components, it is possible that individuals might wish
      to share less information with different networks they wish to
      access.  For example, a user may wish to share more information
      when connecting or being reassessed by the user's employer
      network than what would be made available to the local coffee
      shop wireless network.  While these situations do not impact the
      protocol itself, they do suggest that Posture Collector
      implementations should consider supporting a privacy filter
      allowing the user and/or system owner to restrict access to
      certain attributes based upon the target network.  The
      underlying PT protocol authenticates the network's Posture
      Broker Server at the start of an assessment, so identity can be
      made available to the Posture Collector and per-network privacy
      filtering is possible.  Network owners should make available a
      list of the attributes they require to perform an assessment and
      any privacy policy they enforce when handling the data.  Users
      wishing to use a more restricted privacy filter on the endpoint
      may risk not being able to pass an assessment and thus not gain
      access to the requested network or resource.
    
    8. IANA Considerations
    
      This section defines the contents of four new IANA IETF standard
      registries: PA-TNC Subtypes (defined in PB-TNC), PA-TNC
      Attribute Types, PA-TNC Error Codes and PA-TNC Remediation
      Parameter Types.  This section explains how these registries
      work.  Also, this specification defines the IETF Standard PA
      Subtypes.  These assignments will be added to the registry for
      IETF Standard PA Subtypes when this document is approved by the
      IESG as an RFC.
    
      Section 8.1. defines the new IETF standard PA Subtypes. Sections
      8.2. and 8.3. provide guidance to the IANA in creating and
      managing the two new IANA registries defined by this
      specification.
    
    8.1. IETF Standard PA-TNC Subtypes
    
      Section 3.5. of this specification defines several new IETF
      standard PA Subtypes.  Here is a list of these assignments:
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 64]
    

    Internet-Draft              PA-TNC              October 2008
    
      Number    Name
      ------    ----
      0        Testing
      1        Operating System
      2        Anti-Virus
      3        Anti-Spyware
      4        Anti-Malware
      5        Firewall
      6        IDPS
      7        VPN
      8        NEA Client
    
      Once this document becomes an RFC, these IETF standard PA
      Subtypes should be added to the registry for IETF standard PA-
      TNC Subtypes defined in the PB-TNC specification. The RFC number
      assigned to this document should be associated with these
      assignments.
    
    8.2. Registry for IETF Standard PA-TNC Attribute Types
    
      The name for this registry is "IETF Standard PA-TNC Attribute
      Types".  Each entry in this registry should include a human-
      readable name, a decimal integer value between 0 and 2^32-1, and
      a reference to an RFC where the contents of this attribute type
      are defined.  This RFC must define the meaning of this PA-TNC
      attribute type and the format and semantics of the PA-TNC
      Attribute Value field for PA-TNC attributes that include the
      designated numeric value in the PA-TNC Attribute Type field and
      the value 0 in the PA-TNC Attribute Vendor ID field.
      Entries to this registry may only be added by IETF Consensus, as
      defined in RFC 2434 [3].  That is, they can only be added in an
      RFC approved by the IESG.
    
      The following entries for this registry are defined in this
      document.  Once this document becomes an RFC, they should become
      the initial entries in the registry for IETF Standard PA-TNC
      Attribute Types.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 65]
    

    Internet-Draft              PA-TNC              October 2008
    
      Value       Name                       Defining RFC
      -----       ----                       ------------
      0       Testing                   RFC # Assigned to this I-D
      1       Attribute Request         RFC # Assigned to this I-D
      2       Product Information       RFC # Assigned to this I-D
      3       Numeric Version           RFC # Assigned to this I-D
      4       String Version            RFC # Assigned to this I-D
      5       Operational Status        RFC # Assigned to this I-D
      6       Port Filter               RFC # Assigned to this I-D
      7       Installed Packages        RFC # Assigned to this I-D
      8       PA-TNC Error              RFC # Assigned to this I-D
    
    8.3. Registry for IETF Standard PA-TNC Error Codes
    
      The name for this registry is "IETF Standard PA-TNC Error
      Codes".  Each entry in this registry should include a human-
      readable name, a decimal integer value between 0 and 2^32-1, and
      a reference to an RFC where this error code is defined.  This
      RFC must define the meaning of this error code and the format
      and semantics of the Error Information field for PA-TNC
      attributes that have a PA-TNC Vendor ID of 0, a PA-TNC Attribute
      Type of PA-TNC Error, the designated numeric value in the PA-TNC
      Error Code field, and the value 0 in the PA-TNC Error Code
      Vendor ID field.
    
      Entries to this registry may only be added by IETF Consensus, as
      defined in RFC 2434.  That is, they can only be added in an RFC
      approved by the IESG.
    
      The following entries for this registry are defined in this
      document.  Once this document becomes an RFC, they should become
      the initial entries in the registry for IETF Standard PA-TNC
      Error Codes.
    
      Value       Name                      Defining RFC
      -----       ----                      ------------
      1       Invalid Parameter         RFC # Assigned to this I-D
      2       Version Not Supported     RFC # Assigned to this I-D
      3       Attribute Type Not Supported RFC # Assigned to this I-D
    
    8.4. Registry for IETF Standard Remediation Parameter Types
    
      The name for this registry is "IETF Standard PA-TNC Remediation
      Parameter Types".  Each entry in this registry should include a
      human-readable name, a decimal integer value between 1 and 2^32-
      1, and a reference to an RFC where the contents of this
      remediation parameter type are defined.  This RFC must define
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 66]
    

    Internet-Draft              PA-TNC              October 2008
    
      the meaning of this PA-TNC Remediation Parameter Type and the
      format and semantics of the PA-TNC Remediation Parameter field
      for PA-TNC attributes that include the designated numeric value
      in the PA-TNC Remediation Parameter Type field and the value 0
      in the PA-TNC Remediation Parameters Vendor ID field.
    
      Entries to this registry may only be added by IETF Consensus, as
      defined in RFC 2434 [3].  That is, they can only be added in an
      RFC approved by the IESG.
    
      The following entries for this registry are defined in this
      document.  Once this document becomes an RFC, they should become
      the initial entries in the registry for IETF Standard PA-TNC
      Remediation Parameter Types.
    
      Value       Name                       Defining RFC
      -----       ----                       ------------
      1       URI                      RFC # Assigned to this I-D
      2       Remediation String       RFC # Assigned to this I-D
    
    9. Acknowledgments
    
      The authors of this draft 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:
      Stuart Bailey, Roger Chickering, Lauren Giroux, Charles
      Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg
      Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa
      Lorenzin, Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio
      Sanchez, Brad Upson, and Han Yin.
    
      This document was prepared using 2-Word-v2.0.template.dot.
    
    10. References
    
    10.1. Normative References
    
      [1]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.
      [2]  F. Yergeau, "UTF-8, a transformation format of ISO 10646",
           RFC 3629, November 2003.
      [3]  Alvestrand, H. and T. Narten, "Guidelines for Writing an
           IANA Considerations Section in RFCs", RFC 5226, May
           2008.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 67]
    

    Internet-Draft              PA-TNC              October 2008
    
      [4]  Klyne, G. and C. Newman, "Date and Time on the Internet:
           Timestamps", RFC 3339, July 2002.
      [5]  Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture
           Broker Protocol (PB) Compatible with TNC", draft-ietf-nea-
           pb-tnc-01.txt, Work In Progress, July 2008.
    
    10.2. Informative References
    
      [6]  Trusted Computing Group, "IF-M: TLV Binding", February
           2008.
      [7]  Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
           Tardo, "Network Endpoint Assessment (NEA): Overview and
           Requirements", RFC 5209, June 2008.
      [8]  Sangster, P., "PA-TNC Security: A Posture Attribute (PA)
           Security Protocol Compatible with TNC", draft-sangster-
           nea-pa-tnc-security-00.txt, Work In Progress, February
           2008.
      [9]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", RFC 3986, January
           2005.
    
    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 which 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|
    
    Sangster & Narayan     Expires April 6, 2009          [Page 68]
    

    Internet-Draft              PA-TNC              October 2008
    
      +--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
         |         |   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  |<-------------------|
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 69]
    

    Internet-Draft              PA-TNC              October 2008
    
         |         |           | Result  |                    |
         |         |           |<--------|          |         |
         |         | OS Reslt  |         |          |         |
         |         |<----------|         |          |         |
         | VndrX Patch Result  |         |          |         |
         |<--------------------|         |          |         |
    
    A.1.1. Message Contents
    
      This section shows the contents of the key fields in each of the
      PA messages exchanged in this use case.  When necessary
      additional commentary is provided to explain why certain fields
      contain the shown values.  Note that many of the flows shown are
      between components on the same system so no message contents are
      shown.
    
      A.1.1.1. N/W Join
    
      This flow represents the event that causes the PBC to decide to
      start an assessment of the endpoint in order to gain access to
      the network.  This is merely an event and does not include a
      message being sent.
    
      A.1.1.2. Request Posture (Req Post.)
    
      This flow illustrates an invocation of the OS and patch posture
      collectors requesting particular posture attributes to be sent.
      Because this use case is triggered locally the contents of this
      flow aren't specified by NEA.
    
      A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)
    
      This flow contains the PA message from the Patch Posture
      Collector:
    
      Vendor X Patch Posture PA Message  {
         Attribute HDR {Message ID}
         Attribute 1 {
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 70]
    

    Internet-Draft              PA-TNC              October 2008
    
            vendor-id=1 (vendor X)
            type=1 (Vendor X namespace attribute)
            length
            Value = {
               VendorXAttribute1=123
            }
         }
    
         Attribute 2 {
            vendor-id=1 (vendor X)
            type=2 (Vendor X namespace attribute)
            length
            Value = {
               VendorXAttribute2=456
            }
         }
      }
    
      A.1.1.4. OS Posture
    
      This flow contains the PA message from the OS Posture Collector:
    
      OS Posture PA Message  {
         Attribute HDR {Message ID}
         Attribute 1 {
            vendor-id=0
            type=2 (product information)
            length
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 71]
    

    Internet-Draft              PA-TNC              October 2008
    
            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
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 72]
    

    Internet-Draft              PA-TNC              October 2008
    
      received.  Because this flow happens locally within the NEA
      server, NEA does not specify the message contents.
      A.1.1.7. OS Posture Result (OS Reslt)
    
      This flow contains the PA message (Posture Assessment Result)
      from the OS Posture Validator
    
      OS Posture Result PA Message {
         Attribute HDR {Message ID}
            Attribute 1 {
                 vendor-id=0
                 type=9 (assessment-result)
                 length
                 Value = {
                    assessment-result=0 (compliant)
                 }
           }
       }
    
      A.1.1.8. Vendor X Patch Result (VndrX Patch Result)
    
      This flow contains the PA message (Posture Assessment Result)
      from the Vendor X Patch Posture Validator
    
      Patch Vendor X Posture Result PA Message {
         Attribute HDR {Message ID}
            Attribute 1 {
                 vendor-id=0
                 type=9 (assessment-result)
                 length
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 73]
    

    Internet-Draft              PA-TNC              October 2008
    
                 Value = {
                    assessment-result=0 (compliant)
                 }
            }
       }
    
      A.1.1.9. Assessment Result (Assess Result)
    
      This flow contains the PB message containing the system
      assessment result computed by the Posture Broker Server and the
      PA messages from the Patch and OS Posture Validators; the
      message content is described in the PB-TNC specification.
    
      A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)
    
      These flows illustrate an invocation of the OS and Vendor X
      Patch Posture Collectors to receive the posture assessment
      results.  Because this flow is triggered locally, NEA does not
      specify the contents of this flow.
    
    A.2. Server initiated Assessment with Remediation
    
      This scenario involves the assessment of an endpoint initiated
      by the NEA Server. The assessment is triggered by the Posture
      Broker Server and involves collection of Anti-Virus attributes
      for two Anti-Virus components running on the endpoint. The
      endpoint is assessed to be compliant by one of the vendor
      (Vendor X) anti-virus Posture Validators and non-complaint by
      the other vendor (Vendor Y) anti-virus Posture Validator.  Based
      upon the Posture Broker Server's policy, this results in a non-
      compliant system assessment decision to be returned by the
      Posture Broker Server. The Posture Broker Server also returns
      remediation instructions for the endpoint as part of the
      response.
    
      +--------+  +-------+ +---------+ +--------+ +-------+ +--------+
      | Vndr Y |  | Vndr X| |   Std.  | |  Std.  | | Vndr X| | Vndr Y |
      |  AV PC |  | AV PC | |   PBC   | |  PBS   | | AV PV | |  AV PV |
      +----+---+  +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 74]
    

    Internet-Draft              PA-TNC              October 2008
    
          |          |           | N/W Join|          |          |
          |          |           | ------->|          |          |
          |          |           |         |  Create  |          |
          |          |           |         |Post. Req |          |
          |          |           |         |--------->|          |
          |          |           |         |Create Posture Req   |
          |          |           |         |----------+--------->|
          |          |           |         |Vndr Y AV Posture Req|
          |          |           |         |<---------+----------|
          |          |           |         |Vndr X AV |          |
          |          |           |         |Post. Req |          |
          |          |           | Posture |<---------|          |
          |          |           | Request |          |          |
          |          | Vndr X AV |<--------|          |          |
          |          | Post. Req |         |          |          |
          |          |<----------|         |          |          |
          |      Vndr Y AV       |         |          |          |
          |     Posture Req      |         |          |          |
          +<---------+-----------|         |          |          |
          |  Vndr Y AV Posture   |         |          |          |
          +----------+---------->|         |          |          |
          |          | Vndr X AV |         |          |          |
          |          |  Posture  |         |          |          |
          |          |---------->| Posture |          |          |
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 75]
    

    Internet-Draft              PA-TNC              October 2008
    
          |          |           |Response |          |          |
          |          |           |-------->|          |          |
          |          |           |         |  Verify  |          |
          |          |           |         |  Posture |          |
          |          |           |         |--------->|          |
          |          |           |         |     Verify Posture  |
          |          |           |         |----------+--------->|
          |          |           |         |Vndr Y AV Post Result|
          |          |           |         |<---------+----------|
          |          |           |         |Vndr X AV |          |
          |          |           |         |Post Reslt|          |
          |          |           |  Assess |<---------|          |
          |          |           |  Result |          |          |
          |          | Vndr X AV |<--------|          |          |
          |          |Post Reslt |<--------|          |          |
          |          |<----------|         |          |          |
          | Vndr Y AV Post Reslt |         |          |          |
          +<---------+-----------|         |          |          |
    
    A.2.1. Message Contents
    
      This section shows the contents of the key fields in each of the
      PA messages exchanged in this use case.  When necessary
      additional commentary is provided to explain why certain fields
      contain the shown values.  Note that many of the flows shown are
      between components on the same system so no message contents are
      shown.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 76]
    

    Internet-Draft              PA-TNC              October 2008
    
      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)
                  }
             }
      }
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 77]
    

    Internet-Draft              PA-TNC              October 2008
    
      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.
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 78]
    

    Internet-Draft              PA-TNC              October 2008
    
      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
               }
            }
        }
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 79]
    

    Internet-Draft              PA-TNC              October 2008
    
      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)
                }
            }
        }
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 80]
    

    Internet-Draft              PA-TNC              October 2008
    
      A.2.1.9. Posture Response
    
      This flow contains the PB message containing the PA messages
      from the Vendor X and Vendor Y Anti-Virus Posture Collectors;
      the message content is described in the PB-TNC specification.
    
      A.2.1.10. Verify Posture
    
      This flow illustrates an invocation of the Vendor X and Vendor Y
      Anti-Virus Posture Validators requesting verification of the
      posture attributes received.  Because this flow happens locally
      within the NEA server, NEA does not specify the message
      contents.
    
      A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post Result)
    
      This flow contains the PA message (Posture Assessment Result)
      from the Vendor Y Anti-Virus Posture Validator
    
      Vendor Y AV Posture Result PA Message {
         Attribute HDR {Message ID}
           Attribute 1 {
              vendor-id=0
              type=9 (assessment-result)
              length
              Value = {
                 assessment-result=0 (compliant)
              }
           }
        }
    
      A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post Reslt)
    
      This flow contains the PA message (Posture Assessment Result)
      from the Vendor X Anti-Virus Posture Validator
    
      Vendor X AV Posture Result PA Message {
    
    Sangster & Narayan     Expires April 6, 2009          [Page 81]
    

    Internet-Draft              PA-TNC              October 2008
    
          Attribute HDR {Message ID}
            Attribute 1 {
               vendor-id=0
               type=9 (assessment-result)
               length
               Value = {
                  assessment-result=1 (non-compliant)
               }
            }
       }
    
      A.2.1.13. Assessment Result (Assess Result)
    
      This flow contains the PB message containing the system
      assessment result computed by the Posture Broker Server and the
      PA messages from the Vendor X and Vendor Y Anti-Virus Posture
      Validators; the message content is described in the PB-TNC
      specification.
    
      A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post
      Reslt)
    
      These flows illustrate an invocation of the Vendor X and Vendor
      Y Anti-Virus Posture Collectors to receive the posture
      assessment results.  Because this flow is triggered locally, NEA
      does not specify the contents of this flow.
    
    A.3. Client triggered re-assessment
    
      This scenario involves the re-assessment 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
    
    Sangster & Narayan     Expires April 6, 2009          [Page 82]
    

    Internet-Draft              PA-TNC              October 2008
    
      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 and vendor  Y's
      namespaces.  This use case does not leverage vendor defined
      attributes.  The assessment involves verification of the standard
      VPN posture attributes by the standard VPN Posture Validator that
      results in a non-compliant assessment result.
    
      This use case relies on the use of multiple Posture Collector IDs
      for a single Posture Collector as described in section 3.3 of the
      PA-TNC specification.  In this example, the Posture Collector will
      obtain two Posture Collector IDs to a single Posture Collector
      (Standard VPN PC) and the Posture Collector will generate two
      separate PA messages each using a different ID to report the
      posture for Vendor X and Vendor Y VPN Clients.  The Posture Broker
      Client will associate the assigned IDs in the PB message sent to
      the NEA Server.  This entire behavior will be completely opaque to
      the NEA Server, which will handle the PB message as if there were
      two VPN Posture Collectors on the NEA Client.
    
      +--------+  +-------+ +---------+ +--------+ +-------+ +--------+
      |Vndr X  |  |Vndr Y | |Standard | |Standard| |Standrd| |Standard|
      |VPNClnt |  |VPNClnt| | VPN PC  | |  PBC   | |  PBS  | | VPN PV |
      +----+---+  +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
      Enble|          |           |         |          |          |
      ---->|          |           |         |          |          |
           |  VPN Status Change   |         |          |          |
           |--------------------->| Posture |          |          |
           |          |           | Change  |          |          |
           |          |           |-------->|          |          |
           |          |           |Req. Post|          |          |
           |          |           |<--------|          |          |
           |          |Ins/Rq Info|         |          |          |
           |          |<----------|         |          |          |
           | Inspect/Request Info |         |          |          |
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 83]
    

    Internet-Draft              PA-TNC              October 2008
    
           |<---------+-----------|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.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 84]
    

    Internet-Draft              PA-TNC              October 2008
    
      A.3.1.1. Enable VPN Client (Enble)
    
      This flow represents the end user triggered event of starting
      the VPN Client software from Vendor X.  This is merely an event
      and does not include a message being sent.
    
      A.3.1.2. Notify Status Change (VPN Status Change)
    
      This flow represents the detection of the active state of the
      Vendor X VPN Client software by the VPN Posture Collector.  This
      is merely an event and does not include a message being sent.
    
      A.3.1.3. Notify Posture Change (Posture Change)
    
      This flow represents the notification of the VPN posture change
      sent from the VPN Posture Collector to the Standard Posture
      Broker Client.  This is merely an event and does not include a
      message being sent.
    
      A.3.1.4. Request Posture (Req. Post)
    
      This flow illustrates an invocation of the VPN Posture Collector
      requesting particular posture attributes to be sent.  Because
      this use case is triggered locally, NEA does not specify the
      contents of this flow.
    
      A.3.1.5. Inspect/Request Info (Ins/Rq Info)
    
      This flow illustrates the acquisition of the posture information
      by the VPN Posture Collector from the Vendor X and Vendor Y VPN
      Client components.  Because this flow is triggered locally, NEA
      does not specify the message contents.
    
      A.3.1.6. Vendor X VPN Posture (VPNX Post)
    
      This flow contains the PA message from the VPN Posture Collector
      describing the Vendor X VPN Client's posture:
    
      Vendor X VPN Posture PA Message {
         Attribute HDR {Message ID}
           Attribute 1 {
                 vendor-id=0
                 type=2 (product information)
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 85]
    

    Internet-Draft              PA-TNC              October 2008
    
                 length
                 Value = {
                    product-vendor-id=9876 (vendor X)
                    product-id=567 (VPN client identifier for Vndr X)
                    product-name="Vendor X VPN Client"
                  }
            }
    
            Attribute 2 {
                 vendor-id=0
                 type=5 (operational status)
                 length
                 Value = {
                   Status=3 (Operational)
                   Result=1 (Successful use with no errors detected)
                   last Use="2008-07-07T12:00:00Z"
                 }
            }
    
      A.3.1.7. Vendor Y VPN Posture (VPNY Post)
    
      This flow contains the PA message from the VPN Posture Collector
      including the Vendor Y VPN Client's posture:
    
      Vendor Y VPN Posture PA Message{
         Attribute HDR {Message ID}
             Attribute 1 {
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 86]
    

    Internet-Draft              PA-TNC              October 2008
    
                 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.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 87]
    

    Internet-Draft              PA-TNC              October 2008
    
      A.3.1.9. Verify Posture (Vrfy Post.)
    
      This flow illustrates an invocation of the VPN Posture Validator
      requesting verification of the posture attributes received.
      Because this flow happens locally within the NEA server, NEA
      does not specify the message contents.
    
      A.3.1.10. VPN Posture Result (VPN PRslt)
    
      This flow contains the PA message (Posture Assessment Result)
      from the VPN Posture Validator
    
      VPN Posture Result PA Message {
         Attribute HDR {Message ID}
            Attribute 1 {
                 vendor-id=0
                 type=9 (assessment-result)
                 length
                 Value = {
                    assessment-result=1 (non-compliant)
                 }
            }
       }
    
      A.3.1.11. Assessment Result (Assess Result)
    
      This flow contains the PB message containing the system
      assessment result computed by the Posture Broker Server and the
      PA messages from the VPN Posture Validator; the message content
      is described in the PB-TNC specification.
    
      A.3.1.12. Posture Result (VPN PRslt)
    
      This flow illustrates an invocation of the VPN Posture Collector
      to receive the posture assessment result.  Because this flow is
      triggered locally, NEA does not specify the contents of this
      flow.
    
    Sangster & Narayan     Expires April 6, 2009          [Page 88]
    

    Internet-Draft              PA-TNC              October 2008
    
    Author's Address
      Kaushik Narayan
      Cisco Systems Inc.
      10 West Tasman Drive
      San Jose, CA 95134
      Phone +1 408 526-8168
      Email: kaushik@cisco.com
    
      Paul Sangster
      Symantec Corporation
      6825 Citrine Drive
      Carlsbad, CA 92009 USA
      Phone: +1.760.438.5656
      Email: Paul_Sangster@symantec.com
    
    Intellectual Property Statement
    
      The IETF takes no position regarding the validity or scope of
      any Intellectual Property Rights or other rights that might be
      claimed to pertain to the implementation or use of the
      technology described in this document or the extent to which any
      license under such rights might or might not be available; nor
      does it represent that it has made any independent effort to
      identify any such rights.  Information on the procedures with
      respect to rights in RFC documents can be found in BCP 78 and
      BCP 79.
    
      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the
      use of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR
      repository at http://www.ietf.org/ipr.
    
      The IETF invites any interested party to bring to its attention
      any copyrights, patents or patent applications, or other
      proprietary rights that may cover technology that may be
      required to implement this standard.  Please address the
      information to the IETF at ietf-ipr@ietf.org.
    
    Disclaimer of Validity
    
      This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
    
    Sangster & Narayan     Expires April 6, 2009          [Page 89]
    

    Internet-Draft              PA-TNC              October 2008
    
      THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
      ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
      ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
      INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
      OR FITNESS FOR A PARTICULAR PURPOSE.
    
    Copyright Statement
    
      Copyright (C) The IETF Trust (2008).
      This document is subject to the rights, licenses and
      restrictions contained in BCP 78, and except as set forth
      therein, the authors retain all their rights.
    
    Acknowledgment
    
      Funding for the RFC Editor function is currently provided by the
      Internet Society.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Sangster & Narayan     Expires April 6, 2009          [Page 90]
    

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/