[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: October 2009                                 Cisco Systems
                                                       April 16, 2009
  
  
      PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC
                       draft-ietf-nea-pa-tnc-04.txt
  
  
  Status of this Memo
  
     This Internet-Draft is submitted to IETF in full conformance
     with the provisions of BCP 78 and BCP 79.  This document may
     contain material from IETF Documents or IETF Contributions
     published or made publicly available before November 10, 2008.
     The person(s) controlling the copyright in some of this material
     may not have granted the IETF Trust the right to allow
     modifications of such material outside the IETF Standards
     Process.  Without obtaining an adequate license from the
     person(s) controlling the copyright in such materials, this
     document may not be modified outside the IETF Standards Process,
     and derivative works of it may not be created outside the IETF
     Standards Process, except to format it for publication as an RFC
     or to translate it into languages other than English.
  
     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 August 16, 2009.
  
  Copyright Notice
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009            [Page 1]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     Copyright (c) 2009 IETF Trust and the persons identified as the
     document authors. All rights reserved.
  
     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents in effect on the date of
     publication of this document (http://trustee.ietf.org/license-
     info). Please review these documents carefully, as they describe
     your rights and restrictions with respect to this document.
  
  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.
  
  Table of Contents
  
     1. Introduction...................................................5
        1.1. Relationship to Trusted Network Connect...................5
        1.2. Prerequisites.............................................5
        1.3. Message Diagram Conventions...............................6
        1.4. Conventions Used in this Document.........................6
     2. Design Considerations..........................................6
        2.1. Standard Attribute Namespace for Interoperability.........6
        2.2. Vendor Defined Namespace for Differentiation and Agility..7
        2.3. Use of TLV Based Encoding for Efficiency..................8
     3. PA-TNC Message Protocol........................................8
        3.1. PA-TNC Messaging Model....................................9
        3.2. PA-TNC Relationship to PB-TNC............................10
        3.3. PA-PB Posture Collector and Posture Validator Identifiers12
        3.4. PA-TNC Messages in PB-TNC................................12
        3.5. IETF Standard PA Subtypes................................13
        3.6. PA-TNC Field Types.......................................14
        3.7. PA-TNC Message Header Format.............................15
     4. PA-TNC Attributes.............................................16
        4.1. PA-TNC Attribute Header..................................16
        4.2. IETF Standard PA-TNC Attribute Types.....................20
           4.2.1. Attribute Request...................................21
           4.2.2. Product Information.................................23
           4.2.3. Numeric Version.....................................25
           4.2.4. String Version......................................28
           4.2.5. Operational Status..................................30
           4.2.6. Port Filter.........................................33
           4.2.7. Installed Packages..................................35
           4.2.8. PA-TNC Error........................................38
              4.2.8.1. Invalid Parameter Error Code...................40
  
  
  Sangster & Narayan     Expires October 16, 2009            [Page 2]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
              4.2.8.2. Version Not Supported Error Code...............42
              4.2.8.3. Attribute Type Not Supported Error Code........43
           4.2.9. Assessment Result...................................45
           4.2.10. Remediation Instructions...........................46
              4.2.10.1. IETF Standard PA-TNC Remediation Parameters
                        Types.........................................48
           4.2.11. Forwarding Enabled.................................49
           4.2.12. Factory Default Password Enabled...................50
        4.3. Vendor-Defined Attributes................................52
     5. Security Considerations.......................................52
        5.1. Trust Relationships......................................53
           5.1.1. Posture Collector...................................53
           5.1.2. Posture Validator...................................53
           5.1.3. Posture Broker Client, Posture Broker Server........53
        5.2. Security Threats.........................................54
           5.2.1. Attribute Theft.....................................55
           5.2.2. Message Fabrication.................................55
           5.2.3. Attribute Modification..............................55
           5.2.4. Attribute Replay....................................56
           5.2.5. Attribute Insertion.................................56
           5.2.6. Denial of Service...................................57
     6. Privacy Considerations........................................57
     7. IANA Considerations...........................................58
        7.1. Designated Expert Guidelines.............................59
        7.2. PA Subtypes..............................................60
        7.3. Registry for PA-TNC Attribute Types......................61
        7.4. Registry for PA-TNC Error Codes..........................61
        7.5. Registry for PA-TNC Remediation Parameters Types.........62
     8. Acknowledgments...............................................63
     9. References....................................................63
        9.1. Normative References.....................................63
        9.2. Informative References...................................63
     Appendix A: Use Cases............................................64
        A.1. Initial Client triggered assessment......................64
           A.1.1. Message Contents....................................65
              A.1.1.1. N/W Join.......................................65
              A.1.1.2. Request Posture (Req Post.)....................65
              A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)...65
              A.1.1.4. OS Posture.....................................66
              A.1.1.5. Posture Report.................................67
              A.1.1.6. Verify Posture.................................67
              A.1.1.7. OS Posture Result (OS Reslt)...................67
              A.1.1.8. Vendor X Patch Result (VndrX Patch Result).....67
              A.1.1.9. Assessment Result (Assess Result)..............68
              A.1.1.10. Posture Result (OS PRslt & Vndr X Post
                        PResult)......................................68
        A.2. Server initiated Assessment with Remediation.............68
           A.2.1. Message Contents....................................69
  
  
  Sangster & Narayan     Expires October 16, 2009            [Page 3]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
              A.2.1.1. N/W Join.......................................69
              A.2.1.2. Create Posture Request (Create Posture Req.)...70
              A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture
                       Req)...........................................70
              A.2.1.4. Vendor X AV Posture Request (Vndr X AV Post.
                       Req)...........................................70
              A.2.1.5. Posture Request................................71
              A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV
                       Post Req)......................................71
              A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture)........71
              A.2.1.8. Vendor X AV Posture (Vndr X AV Posture)........71
              A.2.1.9. Posture Response...............................72
              A.2.1.10. Verify Posture................................72
              A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post
                        Result).......................................72
              A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post
                        Reslt)........................................73
              A.2.1.13. Assessment Result (Assess Result).............73
              A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y
                        AV Post Reslt)................................73
        A.3. Client triggered re-assessment...........................73
           A.3.1. Message Contents....................................75
              A.3.1.1. Enable VPN Client (Enble)......................75
              A.3.1.2. Notify Status Change (VPN Status Change).......75
              A.3.1.3. Notify Posture Change (Posture Change).........75
              A.3.1.4. Request Posture (Req. Post)....................75
              A.3.1.5. Inspect/Request Info (Ins/Rq Info).............76
              A.3.1.6. Vendor X VPN Posture (VPNX Post)...............76
              A.3.1.7. Vendor Y VPN Posture (VPNY Post)...............76
              A.3.1.8. Posture Report.................................77
              A.3.1.9. Verify Posture (Vrfy Post.)....................77
              A.3.1.10. VPN Posture Result (VPN PRslt)................77
              A.3.1.11. Assessment Result (Assess Result).............78
              A.3.1.12. Posture Result (VPN PRslt)....................78
        B.1. Evaluation Against Requirements C-1......................78
        B.2. Evaluation Against Requirements C-2......................78
        B.3. Evaluation Against Requirements C-3......................79
        B.4. Evaluation Against Requirements C-4......................79
        B.5. Evaluation Against Requirements C-5......................79
        B.6. Evaluation Against Requirements C-6......................80
        B.7. Evaluation Against Requirements C-7......................80
        B.8. Evaluation Against Requirements C-8......................80
        B.9. Evaluation Against Requirements C-9......................81
        B.10. Evaluation Against Requirements C-10....................81
        B.11. Evaluation Against Requirements C-11....................81
        B.12. Evaluation Against Requirements PA-1....................82
        B.13. Evaluation Against Requirements PA-2....................82
        B.14. Evaluation Against Requirements PA-3....................83
  
  
  Sangster & Narayan     Expires October 16, 2009            [Page 4]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
        B.15. Evaluation Against Requirements PA-4....................83
        B.16. Evaluation Against Requirements PA-5....................84
        B.17. Evaluation Against Requirements PA-6....................84
     Authors' Addresses...............................................85
  
  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.
  
  
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009            [Page 5]
  

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

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

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

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

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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.
  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         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 of a 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
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 11]
  

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

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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.  Posture Collectors and Posture
     Validators MUST NOT require support for particular vendor-
     specific PA subtypes and MUST interoperate with other parties
     despite any differences in the set of vendor-specific PA
     subtypes supported (although they MAY permit administrators to
     configure them to require support for specific PA subtypes).
  
  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
     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.
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 14]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
  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.
  
                          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 this specification.
        Implementations responding to a PA-TNC message containing a
        supported version MUST use the same Version number to
        minimize the risk of version incompatibility.  Message
        recipients MUST respond to a PA-TNC message containing an
        unsupported version by sending a Version Not Supported error
        in a PA-TNC Error attribute that is the only PA-TNC attribute
        in a PA-TNC message with version number 1.
  
        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
  
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 15]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
        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
        PA-TNC message sender within this assessment.  This value can
        be included in the payload of a response message to indicate
        which message was received and caused the response.  This
        value is included in the payload of 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.
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 16]
  

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

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
        ID field.  Posture Collectors and Posture Validators MUST NOT
        require support for particular vendor-specific PA-TNC
        Attribute Types and MUST interoperate with other parties
        despite any differences in the set of vendor-specific PA-TNC
        Attribute Types supported (although they MAY permit
        administrators to configure them to require support for
        specific PA-TNC attribute types).
  
        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
        registry.  IANA maintains a registry of PA-TNC Attribute
        Types.  Entries in this registry are added by Expert Review
        with Specification Required, following the guidelines in
        section 7.  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.
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 19]
  

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
                                      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.
  
     10      Remediation Instructions Instructions for remediation
                                      generated by a Posture
                                      Validator.
  
     11      Forwarding Enabled       Indicates whether packet
                                      forwarding has been enabled
                                      between different interfaces on
                                      the endpoint.
  
     12      Factory Default Password Indicates whether the endpoint
                                      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
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 21]
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
        values.  Posture Collectors and Posture Validators MUST NOT
        require support for particular vendor-specific PA-TNC Error
        Codes and MUST interoperate with other parties despite any
        differences in the set of vendor-specific PA-TNC Error Codes
        supported (although they MAY permit administrators to
        configure them to require support for specific PA-TNC error
        codes).
  
        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. IANA
        maintains a registry of PA-TNC Error Codes.  Entries in this
        registry are added by Expert Review with Specification
        Required, following the guidelines in section 7.
  
        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.
  
     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
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 40]
  

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
        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
     MUST 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 MUST be able to properly process a message that
     meets this description, even if they cannot process any other
     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.
  
  
  
  
  
  
  
  
  
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 42]
  

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

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
        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.
  
     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 October 16, 2009           [Page 45]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
                          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.
  
     All Posture Collectors that implement an IETF standard PA
     Subtype defined in this specification SHOULD support receiving
     and processing the Remediation Instructions attribute.  All
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 46]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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 Remediation Parameters field.  IANA
        maintains a registry of PA-TNC Remediation Parameters Types.
        Entries in this registry are added by Expert Review with
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 47]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
        Specification Required, following the guidelines in section
        7. 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.  Posture Collectors and Posture Validators
        MUST NOT require support for particular vendor-specific PA-
        TNC Remediation Parameters Types and MUST interoperate with
        other parties despite any differences in the set of vendor-
        specific PA-TNC Remediation Parameters Types supported
        (although they MAY permit administrators to configure them to
        require support for specific PA-TNC remediation parameter
        types).
  
     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.
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 48]
  

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

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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
     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 factory default password enabled.
  
         1    Endpoint has a factory default password enabled.
  
  
  
  
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 51]
  

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
  5.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.
  
  5.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
  
     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
  
  5.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
  
  5.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:
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 53]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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)
  
     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
  
  5.2. Security Threats
  
     Beyond the trusted relationships assumed in section 5.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
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 54]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     threats where end to end protection might be desired and thus
     when the use of the PA-TNC security protocol becomes beneficial.
  
  5.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
     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.
  
  5.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.
  
  5.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
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 55]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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
     not meet network compliance policy, so therefore the endpoint
     would not be allowed to join the network.
  
  5.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.
  
  5.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
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 56]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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.
  
  5.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
     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 5.2.3. and
     5.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.
  
  6. 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
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 57]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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
     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.
  
  7. IANA Considerations
  
     This section defines the contents of three new IANA registries:
     PA-TNC Attribute Types, PA-TNC Error Codes and PA-TNC
     Remediation Parameters Types.  This section explains how these
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 58]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     registries work.  Also, this specification defines several new
     PA Subtypes for use with PA-TNC.
  
     All of the registries defined in this document support IETF
     standard values and vendor-defined values.  To explain this
     phenomenon, we will use the PA-TNC Attribute Type as an example
     but the other three registries work the same way. Whenever a PA-
     TNC Attribute Type appears on a network, it is always
     accompanied by an SMI Private Enterprise Number (PEN), also
     known as a vendor ID.  If this vendor ID is zero, the
     accompanying PA-TNC Attribute Type is an IETF standard value
     listed in the IANA registry for PA-TNC Attribute Types and its
     meaning is defined in the specification listed for that PA-TNC
     Attribute Type in that registry.  If the vendor ID is not zero,
     the meaning of the PA-TNC Attribute Type is defined by the
     vendor identified by the vendor ID (as listed in the IANA
     registry for SMI PENs). The identified vendor is encouraged but
     not required to register with IANA some or all of the PA-TNC
     Attribute Types used with their vendor ID and publish a
     specification for each of these values.
  
     This delegation of namespace is analogous to the technique used
     for OIDs.  It can result in interoperability problems if vendors
     require support for particular vendor-specific values.  However,
     such behavior is explicitly prohibited by this specification,
     which dictates that "Posture Collectors and Posture Validators
     MUST NOT require support for particular vendor-specific PA-TNC
     Attribute Types and MUST interoperate with other parties despite
     any differences in the set of vendor-specific PA-TNC Attribute
     Types supported (although they MAY permit administrators to
     configure them to require support for specific PA-TNC Attribute
     Types)." Similar requirements are included for PA Subtypes,
     Remediation Parameters Types, and PA-TNC Error Codes.
  
  7.1. Designated Expert Guidelines
  
     For all of the IANA registries defined by this specification,
     new values are added to the registry by Expert Review with
     Specification Required, using the Designated Expert process
     defined in RFC 5226 [3].
  
     This section provides guidance to designated experts so that
     they may make decisions using a philosophy appropriate for these
     registries.
  
     The registries defined in this document have plenty of values.
     In most cases, the IETF has approximately 2^32 values available
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 59]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     for it to define and each vendor the same number of values for
     its use.  Because there are so many values available, designated
     experts should not be terribly concerned about exhausting the
     set of values.
  
     Instead, designated experts should focus on the following
     requirements. All values in these IANA registries MUST be
     documented in a specification that is clear, permanently and
     publicly available, and likely to ensure interoperability. IETF
     standard values MUST be useful and not harmful to the Internet.
  
     Designated experts should encourage vendors to avoid defining
     similar but incompatible values and instead agree on a single
     IETF standard value.  However, it is beneficial to document
     existing practice.
  
     There are several ways to ensure that a specification is
     permanently and publicly available.  It may be published as an
     RFC. Alternatively, it may be published in another manner that
     makes it freely available to anyone.  However, in this latter
     case, the vendor MUST supply a copy to the IANA and authorize
     the IANA to archive this copy and make it freely available to
     all if at some point the document becomes no longer freely
     available to all through other channels.
  
     Section 7.2. defines the new PA Subtypes. The following three
     sections provide guidance to the IANA in creating and managing
     the new IANA registries defined by this specification.
  
  7.2. PA Subtypes
  
     Section 3.5. of this specification defines several new PA
     Subtypes that will be added to the PA Subtypes registry defined
     in the PB-TNC specification.  Here is a list of these
     assignments:
  
     PEN  Number     Name                  Defining Specification
     ---  ------     ----                  ----------------------
      0     0        Testing            RFC # Assigned to this I-D
      0     1        Operating System   RFC # Assigned to this I-D
      0     2        Anti-Virus         RFC # Assigned to this I-D
      0     3        Anti-Spyware       RFC # Assigned to this I-D
      0     4        Anti-Malware       RFC # Assigned to this I-D
      0     5        Firewall           RFC # Assigned to this I-D
      0     6        IDPS               RFC # Assigned to this I-D
      0     7        VPN                RFC # Assigned to this I-D
      0     8        NEA Client         RFC # Assigned to this I-D
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 60]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
  
     Once this document becomes an RFC, these PA Subtypes should be
     added to the registry for PA Subtypes defined in the PB-TNC
     specification. The RFC number assigned to this document should
     be associated with these assignments.
  
  7.3. Registry for PA-TNC Attribute Types
  
     The name for this registry is "PA-TNC Attribute Types".  Each
     entry in this registry should include a human-readable name, an
     SMI Private Enterprise Number, a decimal integer value between 0
     and 2^32-1, and a reference to the specification where the
     contents of this attribute type are defined.  This specification
     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 Private Enterprise
     Number in the PA-TNC Attribute Vendor ID field and the
     designated numeric value in the PA-TNC Attribute Type field.
  
     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 PA-TNC Attribute Types.
     Additional entries to this registry are added by Expert Review
     with Specification Required, following the guidelines in section
     7.1.
  
     PEN   Value       Name                 Defining Specification
     ---   -----       ----                 ----------------------
      0      0      Testing               RFC # Assigned to this I-D
      0      1      Attribute Request     RFC # Assigned to this I-D
      0      2      Product Information   RFC # Assigned to this I-D
      0      3      Numeric Version       RFC # Assigned to this I-D
      0      4      String Version        RFC # Assigned to this I-D
      0      5      Operational Status    RFC # Assigned to this I-D
      0      6      Port Filter           RFC # Assigned to this I-D
      0      7      Installed Packages    RFC # Assigned to this I-D
      0      8      PA-TNC Error          RFC # Assigned to this I-D
  
  7.4. Registry for PA-TNC Error Codes
  
     The name for this registry is "PA-TNC Error Codes".  Each entry
     in this registry should include a human-readable name, an SMI
     Private Enterprise Number, a decimal integer value between 0 and
     2^32-1, and a reference to the specification where this error
     code is defined.  This specification must define the meaning of
     this error code and the format and semantics of the Error
     Information field for PA-TNC attributes that have a PA-TNC
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 61]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     Vendor ID of 0, a PA-TNC Attribute Type of PA-TNC Error, the
     designated Private Enterprise Number in the PA-TNC Error Code
     Vendor ID field, and the designated numeric value in the PA-TNC
     Error Code field.
  
     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 PA-TNC Error Codes.
     Additional entries to this registry are added by Expert Review
     with Specification Required, following the guidelines in section
     7.1.
  
     PEN  Value     Name                      Defining Specification
     ---  -----     ----                      ----------------------
      0     1   Invalid Parameter         RFC # Assigned to this I-D
      0     2   Version Not Supported     RFC # Assigned to this I-D
      0     3   Attribute Type Not Supported RFC # Assigned to this I-D
  
  7.5. Registry for PA-TNC Remediation Parameters Types
  
     The name for this registry is "PA-TNC Remediation Parameters
     Types".  Each entry in this registry should include a human-
     readable name, an SMI Private Enterprise Number, a decimal
     integer value between 1 and 2^32-1, and a reference to the
     specification where the contents of this remediation parameters
     type are defined.  This specification must define the meaning of
     this PA-TNC Remediation Parameters Type and the format and
     semantics of the Remediation Parameters field for PA-TNC
     attributes that include the designated Private Enterprise Number
     in the Remediation Parameters Vendor ID field and the designated
     numeric value in the Remediation Parameters Type field.
  
     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 PA-TNC Remediation
     Parameters Types.  Additional entries to this registry are added
     by Expert Review with Specification Required, following the
     guidelines in section 7.1.
  
  
  
  
  
  
  
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 62]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     PEN   Value   Name                     Defining Specification
     ---   -----   ----                     ----------------------
      0      1    URI                    RFC # Assigned to this I-D
      0      2    Remediation String     RFC # Assigned to this I-D
  
  8. 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.
  
  9. References
  
  9.1. Normative References
  
     [1]   Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.
  
     [2]   F. Yergeau, "UTF-8, a transformation format of ISO 10646",
           RFC 3629, November 2003.
  
     [3]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", RFC 5226, May 2008.
  
     [4]   Klyne, G. and C. Newman, "Date and Time on the Internet:
           Timestamps", RFC 3339, July 2002.
  
     [5]   Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture
           Broker Protocol (PB) Compatible with TNC", draft-ietf-nea-
           pb-tnc-03.txt, Work In Progress, March 2009.
  
  9.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.
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 63]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     [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|
     +--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
        |         |   N/W Join|         |          |         |
        |         |     ----->|         |          |         |
        |         | Req Post. |         |          |         |
        |         |<----------|         |          |         |
        |         | Req Post. |         |          |         |
        |<--------------------|         |          |         |
        |Vndr X Patch Posture |         |          |         |
        |-------------------->|         |          |         |
        |         |OS Posture |         |          |         |
        |         |---------->|         |          |         |
        |         |           | Posture |          |         |
        |         |           | Report  |          |         |
        |         |           |-------->|          |         |
        |         |           |         |  Verify  |         |
        |         |           |         |  Posture |         |
        |         |           |         |--------->          |
        |         |           |         |          | Verify  |
        |         |           |         |          | Posture |
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 64]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
        |         |           |         |------------------->|
        |         |           |         | OS Reslt |         |
        |         |           |         |<---------|         |
        |         |           |         | VndrX Patch Result |
        |         |           | Assess  |<-------------------|
        |         |           | 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 {
           vendor-id=1 (vendor X)
           type=1 (Vendor X namespace attribute)
           length
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 65]
  

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
  A.1.1.5. Posture Report
  
     This flow contains the PB message containing the PA messages
     from the Patch and OS Posture Collectors; the message content is
     described in the PB-TNC specification.
  
  A.1.1.6. Verify Posture
  
     This flow illustrates an invocation of the OS and patch Posture
     Validators requesting verification of the posture attributes
     received.  Because this flow happens locally within the NEA
     server, NEA does not specify the message contents.
  
  A.1.1.7. OS Posture Result (OS Reslt)
  
     This flow contains the PA message (Posture Assessment Result)
     from the OS Posture Validator
  
     OS Posture Result PA Message {
        Attribute HDR {Message ID}
           Attribute 1 {
                vendor-id=0
                type=9 (assessment-result)
                length
                Value = {
                   assessment-result=0 (compliant)
                }
          }
      }
  
  A.1.1.8. Vendor X Patch Result (VndrX Patch Result)
  
     This flow contains the PA message (Posture Assessment Result)
     from the Vendor X Patch Posture Validator
  
     Patch Vendor X Posture Result PA Message {
        Attribute HDR {Message ID}
           Attribute 1 {
                vendor-id=0
                type=9 (assessment-result)
                length
                Value = {
                   assessment-result=0 (compliant)
                }
           }
      }
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 67]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
  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 |
     +----+---+  +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
          |          |           | N/W Join|          |          |
          |          |           | ------->|          |          |
          |          |           |         |  Create  |          |
          |          |           |         |Post. Req |          |
          |          |           |         |--------->|          |
          |          |           |         |Create Posture Req   |
          |          |           |         |----------+--------->|
          |          |           |         | Vndr Y AV Post Req  |
          |          |           |         |<---------+----------|
          |          |           |         |Vndr X AV |          |
          |          |           |         |Post. Req |          |
          |          |           | Posture |<---------|          |
          |          |           | Request |          |          |
          |          | Vndr X AV |<--------|          |          |
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 68]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
          |          | Post. Req |         |          |          |
          |          |<----------|         |          |          |
          |      Vndr Y AV       |         |          |          |
          |     Posture Req      |         |          |          |
          +<---------+-----------|         |          |          |
          |  Vndr Y AV Posture   |         |          |          |
          +----------+---------->|         |          |          |
          |          | Vndr X AV |         |          |          |
          |          |  Posture  |         |          |          |
          |          |---------->| Posture |          |          |
          |          |           |Response |          |          |
          |          |           |-------->|          |          |
          |          |           |         |  Verify  |          |
          |          |           |         |  Posture |          |
          |          |           |         |--------->|          |
          |          |           |         |     Verify Posture  |
          |          |           |         |----------+--------->|
          |          |           |         |Vndr Y AV Post Result|
          |          |           |         |<---------+----------|
          |          |           |         |Vndr X AV |          |
          |          |           |         |Post Reslt|          |
          |          |           |  Assess |<---------|          |
          |          |           |  Result |          |          |
          |          | Vndr X AV |<--------|          |          |
          |          |Post Reslt |<--------|          |          |
          |          |<----------|         |          |          |
          | Vndr Y AV Post Reslt |         |          |          |
          +<---------+-----------|         |          |          |
  
  
  A.2.1. Message Contents
  
     This section shows the contents of the key fields in each of the
     PA messages exchanged in this use case.  When necessary
     additional commentary is provided to explain why certain fields
     contain the shown values.  Note that many of the flows shown are
     between components on the same system so no message contents are
     shown.
  
  A.2.1.1. N/W Join
  
     This flow represents the event that causes the PBS to decide to
     start an assessment of the endpoint in order to gain access to
     the network.  This is merely an event and does not include a
     message being sent.
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 69]
  

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
  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.
  
  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
              }
           }
       }
  
  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 {
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 71]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
        Attribute HDR {Message ID}
           Attribute 1 {
              vendor-id=1
              type=1 (vendor X attribute, Scan-Engine-Version)
              length
              Value = {
                 scan-engine-version=1234
              }
           }
           Attribute 2 {
              vendor-id=0 (IETF Standard)
              type=5 (Standard, Operational-Status)
              length
              Value = {
                 status=2 (installed but non-operational)
                 result=0 (unknown)
                 last use="" (never used)
               }
           }
       }
  
  A.2.1.9. Posture Response
  
     This flow contains the PB message containing the PA messages
     from the Vendor X and Vendor Y Anti-Virus Posture Collectors;
     the message content is described in the PB-TNC specification.
  
  A.2.1.10. Verify Posture
  
     This flow illustrates an invocation of the Vendor X and Vendor Y
     Anti-Virus Posture Validators requesting verification of the
     posture attributes received.  Because this flow happens locally
     within the NEA server, NEA does not specify the message
     contents.
  
  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 = {
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 72]
  

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

  Internet-Draft                  PA-TNC                   April 2009
  
  
     Posture Broker Client triggers the posture assessment when it
     receives a notification from the VPN Posture Collector about the
     change to the operational state of the VPN component on the
     endpoint.  Note that the VPN Posture Collector may support
     standard attributes and some vendor defined attributes from
     vendor X 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 |         |          |          |
          |<---------+-----------|VPNX Post|          |          |
          |          |           |-------->|          |          |
          |          |           |VPNY Post|          |          |
          |          |           |-------->|          |          |
          |          |           |         | Posture  |          |
          |          |           |         |  Report  |          |
          |          |           |         |--------->|          |
          |          |           |         |          |Vrfy Post.|
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 74]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
          |          |           |         |          |--------->|
          |          |           |         |          |VPN PRslt |
          |          |           |         |  Assess  |<---------|
          |          |           |         |  Result  |          |
          |          |           |         |<---------|          |
          |          |           |VPN PRslt|          |          |
          |          |           |<--------|          |          |
  
  
  A.3.1. Message Contents
  
     This section shows the contents of the key fields in each of the
     PA messages exchanged in this use case.  When necessary
     additional commentary is provided to explain why certain fields
     contain the shown values.  Note that many of the flows shown are
     between components on the same system so no message contents are
     shown.
  
  A.3.1.1. Enable VPN Client (Enble)
  
     This flow represents the end user triggered event of starting
     the VPN Client software from Vendor X.  This is merely an event
     and does not include a message being sent.
  
  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.
  
  
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 75]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
  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)
                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 {
                vendor-id=0
                type=2 (product information)
                length
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 76]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
                Value = {
                   product-vendor-id=Vendor Y
                   product-id=234 (VPN client identifier for Vndr Y)
                   product-name="Vendor Y VPN Client"
                 }
           }
           Attribute 2 {
                vendor-id=0
                type=5 (operational status)
                length
                Value = {
                  Status=3 (Operational)
                  Result=1 (Successful use with no errors detected)
                  last Use="2008-07-07T14:05:00Z"
                }
           }
     }
  
  
  A.3.1.8. Posture Report
  
     This flow contains the PB message containing the PA message from
     the VPN Posture Collector; the message content is described in
     the PB-TNC specification.
  
  A.3.1.9. Verify Posture (Vrfy Post.)
  
     This flow illustrates an invocation of the VPN Posture Validator
     requesting verification of the posture attributes received.
     Because this flow happens locally within the NEA server, NEA
     does not specify the message contents.
  
  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)
                }
           }
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 77]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
      }
  
  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.
  
  Appendix B: Evaluation Against NEA Requirements
  
     This section evaluates the PA-TNC protocol against the
     requirements defined in the NEA Requirements document.  Each
     subsection considers a separate requirement from the NEA
     Requirements document.  Only common requirements (C-1 through C-
     10) and PA requirements (PA-1 through PA-6) are considered,
     since these are the only ones that apply to PA.
  
  B.1. Evaluation Against Requirements C-1
  
     Requirement C-1 says:
  
     C-1   NEA protocols MUST support multiple round trips between
     the NEA Client and NEA Server in a single assessment.
  
     PA-TNC meets this requirement.  It allows an unlimited number of
     round trips between the NEA Client and NEA Server.
  
  B.2. Evaluation Against Requirements C-2
  
     Requirement C-2 says:
  
     C-2   NEA protocols SHOULD provide a way for both the NEA Client
     and the NEA Server to initiate a posture assessment or
     reassessment as needed.
  
     PA-TNC meets this requirement.  PA-TNC is designed to work
     whether the NEA Client or the NEA Server initiates a posture
     assessment or reassessment.
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 78]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
  B.3. Evaluation Against Requirements 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.
  
  B.4. Evaluation Against Requirements C-4
  
     Requirement C-4 says:
  
     C-4   The PA and PB protocols MUST be capable of operating over
     any PT protocol.  For example, the PB protocol must provide a
     transport independent interface allowing the PA protocol to
     operate without change across a variety of network protocol
     environments (e.g. EAP/802.1X, PANA, TLS and IKE/IPsec).
  
     PA-TNC meets this requirement.  PA-TNC can operate over any PT
     protocol that meets the requirements for PT stated in the NEA
     Requirements document.  PA-TNC does not have any dependencies on
     specific details of the underlying PT protocol.
  
  B.5. Evaluation Against Requirements C-5
  
     Requirement C-5 says:
  
     C-5   The selection process for NEA protocols MUST evaluate and
     prefer the reuse of existing open standards that meet the
     requirements before defining new ones.  The goal of NEA is not
     to create additional alternative protocols where acceptable
     solutions already exist.
  
     Based on this requirement, PA-TNC should receive a strong
     preference.  PA-TNC is equivalent with IF-M 1.0, an open TCG
     specification.  Other specifications from TCG and other groups
     are also under development based on the IF-M 1.0 specification.
     Selecting PA-TNC as the basis for the PA protocol will ensure
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 79]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     compatibility with IF-M 1.0, with these other specifications,
     and with their implementations.
  
  B.6. Evaluation Against Requirements 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.
  
  B.7. Evaluation Against Requirements C-7
  
     Requirement C-7 says:
  
     C-7   The protocols MUST support efficient transport of a large
     number of attribute messages between the NEA Client and the NEA
     Server.
  
     PA-TNC meets this requirement.  Each PA-TNC message can contain
     about 2^28 PA-TNC attributes.  PA-TNC supports up to 2^32 round
     trips in a session so the maximum number of attribute messages
     that can be sent in a single session is actually about 2^50.
     However, it is generally inadvisable and unnecessary to send a
     large number of messages in a NEA assessment.  As for
     efficiency, PA-TNC adds only 12 octets of overhead per attribute
     and 8 octets per message (which is negligible on a per-attribute
     basis).
  
  B.8. Evaluation Against Requirements C-8
  
     Requirement C-8 says:
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 80]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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.
  
  B.9. Evaluation Against Requirements 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.
  
  B.10. Evaluation Against Requirements C-10
  
     Requirement C-10 says:
  
     C-10  NEA protocols MUST support encoding of strings in UTF-8
     format.
  
     PA-TNC meets this requirement.  All strings in the PA-TNC
     protocol are encoded in UTF-8 format.  This allows the protocol
     to support a wide range of languages efficiently.
  
  B.11. Evaluation Against Requirements C-11
  
     Requirement C-11 says:
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 81]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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.
  
  B.12. Evaluation Against Requirements PA-1
  
     Requirement PA-1 says:
  
     PA-1  The PA protocol MUST support communication of an
     extensible set of NEA standards defined attributes.  These
     attributes will be uniquely identifiable from non-standard
     attributes.
  
     PA-TNC meets this requirement.  Each attribute is identified
     with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.
     IETF Standard PA-TNC Attribute Types use a vendor ID of zero
     (0), in contrast with vendor-specific PA-TNC Attribute Types,
     which will use the vendor's SMI Private Enterprise Number as the
     vendor ID.  The IANA will maintain a registry of PA-TNC
     Attribute Types with new values added by Expert Review with
     Specification Required, as described in the IANA Considerations
     section of this specification.  Thus, the set of standard
     attribute types is extensible, but all standard attribute types
     are uniquely identifiable.
  
  B.13. Evaluation Against Requirements PA-2
  
     Requirement PA-2 says:
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 82]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     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.
  
  B.14. Evaluation Against Requirements 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
     determine the type of operating system and then request certain
     attributes specific to that operating system, for example.
  
  B.15. Evaluation Against Requirements 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.
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 83]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
     PA-TNC meets this requirement.  A Posture Validator can easily
     send attributes to one or more Posture Collectors.
  
  B.16. Evaluation Against Requirements 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.
  
  B.17. Evaluation Against Requirements 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.
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 84]
  

  Internet-Draft                  PA-TNC                   April 2009
  
  
  Authors' Addresses
  
     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
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Sangster & Narayan     Expires October 16, 2009           [Page 85]
  

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/