[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: September 2009                               Cisco Systems
                                                      March 6, 2009


    PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC
                    draft-ietf-nea-pa-tnc-03.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 6, 2009.

Copyright Notice





Sangster & Narayan    Expires September 6, 2009           [Page 1]

Internet-Draft                  PA-TNC                   March 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.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described
   in RFC 2119 [1].

Table of Contents

   1. Introduction......................................... 5
      1.1. Relationship to Trusted Network Connect.............. 5
      1.2. Prerequisites.................................... 5
      1.3. Message Diagram Conventions........................ 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............................ 8
      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 .......................... 17
      4.2. IETF Standard PA-TNC Attribute Types................ 20
         4.2.1. Attribute Request........................... 22
         4.2.2. Product Information.......................... 24
         4.2.3. Numeric Version............................. 26


Sangster & Narayan    Expires September 6, 2009           [Page 2]

Internet-Draft                  PA-TNC                   March 2009


         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
            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 Parameter 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............................ 66
            A.1.1.1. N/W Join............................... 66
            A.1.1.2. Request Posture (Req Post.)............... 66
            A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture). 66
            A.1.1.4. OS Posture............................. 67
            A.1.1.5. Posture Report.......................... 68
            A.1.1.6. Verify Posture.......................... 68


Sangster & Narayan    Expires September 6, 2009           [Page 3]

Internet-Draft                  PA-TNC                   March 2009


            A.1.1.7. OS Posture Result (OS Reslt).............. 68
            A.1.1.8. Vendor X Patch Result (VndrX Patch Result)... 69
            A.1.1.9. Assessment Result (Assess Result).......... 69
            A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)70
      A.2. Server initiated Assessment with Remediation......... 70
         A.2.1. Message Contents............................ 72
            A.2.1.1. N/W Join............................... 72
            A.2.1.2. Create Posture Request (Create Posture Req.). 72
            A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture Req)
            ............................................. 72
            A.2.1.4. Vendor X AV Posture Request (Vndr X AV Post. Req)73
            A.2.1.5. Posture Request......................... 74
            A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV Post
            Req)......................................... 74
            A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture)..... 74
            A.2.1.8. Vendor X AV Posture (Vndr X AV Posture)..... 75
            A.2.1.9. Posture Response........................ 76
            A.2.1.10. Verify Posture......................... 76
            A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post Result)
            ............................................. 76
            A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post Reslt)
            ............................................. 77
            A.2.1.13. Assessment Result (Assess Result)......... 78
            A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV
            Post Reslt) ................................... 78
      A.3. Client triggered re-assessment..................... 78
         A.3.1. Message Contents............................ 80
            A.3.1.1. Enable VPN Client (Enble)................. 80
            A.3.1.2. Notify Status Change (VPN Status Change).... 80
            A.3.1.3. Notify Posture Change (Posture Change)...... 80
            A.3.1.4. Request Posture (Req. Post)............... 80
            A.3.1.5. Inspect/Request Info (Ins/Rq Info)......... 81
            A.3.1.6. Vendor X VPN Posture (VPNX Post)........... 81
            A.3.1.7. Vendor Y VPN Posture (VPNY Post)........... 82
            A.3.1.8. Posture Report.......................... 83
            A.3.1.9. Verify Posture (Vrfy Post.)............... 83
            A.3.1.10. VPN Posture Result (VPN PRslt)............ 83
            A.3.1.11. Assessment Result (Assess Result)......... 84
            A.3.1.12. Posture Result (VPN PRslt)............... 84
      B.1. Evaluation Against Requirements C-1................. 84
      B.2. Evaluation Against Requirements C-2................. 85
      B.3. Evaluation Against Requirements C-3................. 85
      B.4. Evaluation Against Requirements C-4................. 85
      B.5. Evaluation Against Requirements C-5................. 85
      B.6. Evaluation Against Requirements C-6................. 86
      B.7. Evaluation Against Requirements C-7................. 86
      B.8. Evaluation Against Requirements C-8................. 87


Sangster & Narayan    Expires September 6, 2009           [Page 4]

Internet-Draft                  PA-TNC                   March 2009


      B.9. Evaluation Against Requirements C-9................. 87
      B.10. Evaluation Against Requirements C-10............... 87
      B.11. Evaluation Against Requirements C-11............... 88
      B.12. Evaluation Against Requirements PA-1............... 88
      B.13. Evaluation Against Requirements PA-2............... 89
      B.14. Evaluation Against Requirements PA-3............... 89
      B.15. Evaluation Against Requirements PA-4............... 90
      B.16. Evaluation Against Requirements PA-5............... 90
      B.17. Evaluation Against Requirements PA-6............... 90
   Authors' Addresses..................................... 91
   Intellectual Property Statement .......................... 91
   Disclaimer of Validity.................................. 91

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


Sangster & Narayan    Expires September 6, 2009           [Page 5]

Internet-Draft                  PA-TNC                   March 2009


   reference model described in the NEA Overview and Requirements
   specification.  The reader is assumed to be thoroughly familiar
   with that document.  No familiarity with TCG specifications is
   assumed.

1.3. Message Diagram Conventions

   This specification defines the syntax of PA-TNC messages using
   diagrams.  Each diagram depicts the format and size of each
   field in bits.  Implementations MUST send the bits in each
   diagram as they are shown, traversing the diagram from top to
   bottom and then from left to right within each line (which
   represents a 32-bit quantity).  Multi-byte fields representing
   numeric values must be sent in network (big endian) byte order.

   Descriptions of bit field (e.g. flag) values are described
   referring to the position of the bit within the field.  These
   bit positions are numbered from the most significant bit through
   the least significant bit so a one octet field with only bit 0
   set has the value 0x80.

2. Design Considerations

   This section discusses some of the key design considerations for
   the PA protocol.

2.1. Standard Attribute Namespace for Interoperability

   The PA protocol requires the use of two categories of
   namespaces: component types (AKA PA Subtypes) and attributes.
   Each of these namespace categories needs to contain well known,
   interoperable names with defined syntax and semantics co-
   existing with names for vendor defined private extensions.
   Similarly, each namespace category needs to be readily
   extensible without repeated coordination yet avoids naming
   conflicts.

   The PA-TNC and PB-TNC protocols provide for multiple orthogonal
   namespaces for each category that exist without overlap by
   including a SMI Private Enterprise Number (PEN) field to
   identify the definer of namespace of the associated field.  This
   allows the IETF NEA WG to define a set of standard component
   types and attribute types while allowing vendors to each create
   additional names outside of the IETF standard namespace.  Over
   time, vendor defined names might be proposed for standardization
   and thus migration into the IETF namespace.



Sangster & Narayan    Expires September 6, 2009           [Page 6]

Internet-Draft                  PA-TNC                   March 2009


   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'
   vendor defined attributes.  This Posture Collector might
   therefore be able to interoperate with Posture Validators from
   multiple vendors.  Conversely, a simple Posture Collector might


Sangster & Narayan    Expires September 6, 2009           [Page 7]

Internet-Draft                  PA-TNC                   March 2009


   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.

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


Sangster & Narayan    Expires September 6, 2009           [Page 8]

Internet-Draft                  PA-TNC                   March 2009


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


Sangster & Narayan    Expires September 6, 2009           [Page 9]

Internet-Draft                  PA-TNC                   March 2009


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


Sangster & Narayan    Expires September 6, 2009          [Page 10]

Internet-Draft                  PA-TNC                   March 2009


   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
   registered to receive operating system messages would not
   receive those attributes, as the messages would only be
   delivered to those registered for firewall messages.



Sangster & Narayan    Expires September 6, 2009          [Page 11]

Internet-Draft                  PA-TNC                   March 2009


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


Sangster & Narayan    Expires September 6, 2009          [Page 12]

Internet-Draft                  PA-TNC                   March 2009


   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

   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


Sangster & Narayan    Expires September 6, 2009          [Page 13]

Internet-Draft                  PA-TNC                   March 2009


   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 September 6, 2009          [Page 14]

Internet-Draft                  PA-TNC                   March 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 formats and requirements
      described in version 1.0 of this specification.
      Implementations responding to a PA-TNC message containing a
      supported version SHOULD use the same Version number to
      minimize the risk of version incompatibility.

      Message senders MAY send an empty PA-TNC message with the
      Version value set to 0 in order to discover the PA-TNC
      protocol versions supported by peer recipients, for more
      information see PA-TNC Error Code description in section
      4.2.8.   Message recipients MUST NOT support version 0 and
      MUST NOT interpret the contents (after the Version field) of
      a PA-TNC message containing a version number that the
      recipient does not support.  Message recipients MUST respond
      to a PA-TNC message with an unsupported version by sending a
      Version Not Supported error code in a PA-TNC Error attribute.

      PA-TNC message initiators supporting multiple PA-TNC protocol
      versions SHOULD be able to alter which version of PA-TNC
      message they send based on prior message exchanges with a
      particular peer Posture Collector or Posture Validator.



Sangster & Narayan    Expires September 6, 2009          [Page 15]

Internet-Draft                  PA-TNC                   March 2009


   Reserved

      Reserved for future use.  This field MUST be set to 0 on
      transmission and ignored upon reception.

   Message Identifier

      This field contains a value that uniquely identifies this
      message, differentiating it from others sent by a particular
      PA-TNC message sender within this assessment.  This value can
      be included in a response message to indicate which message
      was received and caused the response.  For example, this
      field is included in the PA-TNC error messages so the party
      who receives the error message can determine which of the
      messages they had sent caused the error.

      PA-TNC message senders MUST NOT send the same message
      identifier more than once during an assessment.  Message
      identifiers may be randomly generated or sequenced as long as
      values are not repeated during an assessment message
      exchange.  PA-TNC message recipients are not required to
      check for duplicate message identifiers.

4. PA-TNC Attributes

   This section defines the PA-TNC attributes that can be carried
   within a PA-TNC message.  The initial section defines the
   standard attribute header that appears at the start of each
   attribute in a PA-TNC message.  The second section defines each
   of the IETF Standard PA-TNC attributes and the final section
   discusses how vendor-defined PA-TNC attributes can be used
   within a PA-TNC message.  Vendor-defined PA-TNC attributes use
   the vendor's SMI Private Enterprise Number in the Attribute Type
   field.

   A PA-TNC message MUST contain a PA-TNC header (defined in
   section 3.7. followed by a sequence of zero or more PA-TNC
   attributes.  All PA-TNC attributes MUST begin with a standard
   PA-TNC attribute header, as defined in section 4.1.  The
   contents of PA-TNC attributes vary widely, depending on their
   attribute type. Section 4.2. defines the IETF Standard PA-TNC
   Attributes. Section 4.3. discusses how vendor-specific PA-TNC
   attributes can be defined.






Sangster & Narayan    Expires September 6, 2009          [Page 16]

Internet-Draft                  PA-TNC                   March 2009


4.1. PA-TNC Attribute Header

   Following the PA-TNC message header is a sequence of zero or
   more attributes.  All PA-TNC attributes MUST begin with the
   standard PA-TNC attribute header defined in this subsection.
   Each attribute described in this specification is represented by
   a TLV tuple.  The TLV tuple includes an attribute identifier
   comprised of the Vendor ID and Attribute Type (type), the TLV
   tuple's overall length and finally the attribute's value.  The
   use of TLV representation was chosen due to its flexibility and
   extensibility and use in other standards.  Recipients of an
   attribute can use the attribute type fields to determine the
   precise syntax and semantics of the attribute value field and
   the length to skip over an unrecognized attribute.  The length
   field is also beneficial when a variable length attribute value
   is provided.

   The TLV format does not contain an explicit TLV format version
   number, so every attribute included in a particular PA-TNC
   message MUST use the same TLV format.  Using the PA-TNC message
   version number to indicate the format of all TLV attributes
   within a PA-TNC message allows for future versioning of the TLV
   format in a manner detectable by PA-TNC message recipients.
   Similarly, requiring all TLV attribute formats to be the same
   within a PA-TNC message also assures that recipients compliant
   with a particular PA-TNC message version can at least parse
   every attribute header and use the length to skip over
   unrecognized attributes.  Finally all attribute TLVs within a
   PA-TNC message MUST pertain to the same implementation of the
   component.  This restriction is relevant when a single Posture
   Collector is reporting on multiple implementations of a
   component, so must send multiple PA-TNC messages each including
   only the attributes describing a single implementation.  For
   more information on how Posture Collectors should handle
   multiple implementations see section 3.3.

   Every PA-TNC 1.0 compliant TLV attribute MUST use the following
   TLV format:











Sangster & Narayan    Expires September 6, 2009          [Page 17]

Internet-Draft                  PA-TNC                   March 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |          PA-TNC Attribute Vendor ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     PA-TNC Attribute Type                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    PA-TNC Attribute Length                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Attribute Value (Variable Length)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags

      This field defines flags impacting the processing of the
      associated attribute.

      Bit 0 (0x80) is the NOSKIP flag.  Any Posture Collector or
      Posture Validator that receives an attribute with this flag
      set to 1 but does not support this attribute MUST NOT process
      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


Sangster & Narayan    Expires September 6, 2009          [Page 18]

Internet-Draft                  PA-TNC                   March 2009


      messages in which the PA-TNC Attribute Vendor ID has this
      reserved value (0xffffff).  If a Posture Collector or Posture
      Verifier receives a message in which the PA-TNC Attribute
      Vendor ID has this reserved value (0xffffff), it SHOULD
      respond with an Invalid Parameter error code in a PA-TNC
      Error attribute.

   PA-TNC Attribute Type

      This field defines the type of the attribute included in the
      Attribute Value field. This field is qualified by the PA-TNC
      Attribute Vendor ID field so that a particular PA-TNC
      Attribute Type value (e.g. 327) has a completely different
      meaning depending on the value in the PA-TNC Attribute Vendor
      ID field.  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


Sangster & Narayan    Expires September 6, 2009          [Page 19]

Internet-Draft                  PA-TNC                   March 2009


      that receives a message with a PA-TNC Attribute Length field
      whose value is less than 12 SHOULD respond with an Invalid
      Parameter PA-TNC error code.

      Implementations that do not support the specified PA-TNC
      Attribute Type can use this length to skip over this
      attribute to the next attribute.  Note that while this field
      is 4 octets the maximum usable attribute length is likely to
      be less than 2^32-1 due to limitations of the underlying
      protocol stack specifically PB-TNC's length field includes 32
      bytes of other headers which reduce the maximum size
      available to PA-TNC since they both use 4 octet length
      fields.

   Attribute Value

      This field varies depending on the particular type of
      attribute being expressed.  The contents of this field for
      each of the IETF Standard PA-TNC Attribute Types are defined
      in section 4.2.

4.2. IETF Standard PA-TNC Attribute Types

   This section defines an initial set of IETF Standard PA-TNC
   Attribute Types.  These Attribute Types MUST always be used with
   a PA-TNC Vendor ID of zero (0).  If these PA-TNC Attribute Type
   values are used with a different PA-TNC Vendor ID, they have a
   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.




Sangster & Narayan    Expires September 6, 2009          [Page 20]

Internet-Draft                  PA-TNC                   March 2009


   2       Product Information      Manufacturer and product
                                    information for the component.

   3       Numeric Version          Numeric version of the
                                    component.

   4       String Version           String version of the
                                    component.

   5       Operational Status       Describes whether the component
                                    is running on the endpoint.

   6       Port Filter              Lists the set of ports (e.g.
                                    TCP port 80 for HTTP) that are
                                    allowed or blocked on the
                                    endpoint.

   7       Installed Packages       List of software packages
                                    installed on endpoint that
                                    provide the requested
                                    component.

   8       PA-TNC Error             PA-TNC message or attribute
                                    processing error.

   9       Assessment Result        Result of the assessment
                                    performed by a Posture
                                    Validator.

   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.


Sangster & Narayan    Expires September 6, 2009          [Page 21]

Internet-Draft                  PA-TNC                   March 2009


4.2.1. Attribute Request

   This PA-TNC Attribute Type allows a Posture Validator to request
   certain attributes from the registered set of Posture
   Collectors.

   All Posture Collectors that implement any of the IETF Standard
   PA Subtypes defined in this specification SHOULD support
   receiving and processing this attribute type for at least those
   PA subtypes.  Posture Collectors that receive and process this
   attribute MAY choose to send all, a subset or none of the
   requested attributes but MUST NOT send attributes that were not
   requested (except error attributes).  All Posture Validators
   that implement any of the IETF Standard PA Subtypes defined in
   this specification SHOULD support sending this attribute type
   for at least those PA subtypes.

   Posture Verifiers MUST NOT include this attribute type in an
   Attribute Request attribute. It does not make sense for a
   Posture Verifier to request that a Posture Collector send an
   Attribute Request attribute.

   For this attribute type, the PA-TNC Attribute Vendor ID field
   MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
   be set to 1.

   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.






Sangster & Narayan    Expires September 6, 2009          [Page 22]

Internet-Draft                  PA-TNC                   March 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    |           PA-TNC Attribute Vendor ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      PA-TNC Attribute Type                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |           PA-TNC Attribute Vendor ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      PA-TNC Attribute Type                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Reserved

      Reserved for future use.  This field MUST be set to 0 on
      transmission and ignored upon reception.

   PA-TNC Attribute Vendor ID

      This field contains the SMI Private Enterprise Number of the
      organization that controls the name space for the following
      PA-TNC Attribute Type.  This field enables IETF Standard PA-
      TNC Attributes and vendor-defined PA-TNC Attributes to be
      used without potential collisions.

      Any IETF Standard PA-TNC Attribute Types defined in section
      4.2. MUST use zero (0) in this field.  Vendor-defined
      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.






Sangster & Narayan    Expires September 6, 2009          [Page 23]

Internet-Draft                  PA-TNC                   March 2009


4.2.2. Product Information

   This PA-TNC Attribute Type contains identifying information
   about a product that implements the component specified in the
   PA Subtype field, as described in section 3.5.  For example, if
   the PA Subtype is Anti-Virus, this attribute would contain
   information identifying an anti-virus product installed on the
   endpoint.

   All Posture Collectors that implement any of the IETF Standard
   PA Subtypes defined in this specification MUST support sending
   this attribute type, at least for those PA subtypes.  Whether a
   particular Posture Collector actually sends this attribute type
   SHOULD still be governed by local privacy and security policies.
   All Posture Validators that implement any of the IETF Standard
   PA Subtypes defined in this specification MUST support receiving
   this attribute type, at least for those PA subtypes.  Posture
   Validators MUST NOT send this attribute type.

   For this attribute type, the PA-TNC Attribute Vendor ID field
   MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
   be set to 2.  The value in the PA-TNC Attribute Length field
   will vary, depending on the length of the Product Name field.
   However, the value in the PA-TNC Attribute Length field MUST be
   at least 17 because this is the length of the fixed size fields
   in the PA-TNC Attribute Header and the fixed size fields in this
   attribute type.  If the PA-TNC Attribute Length field is less
   than the size of these fixed length fields, implementations
   SHOULD respond with an Invalid Parameter PA-TNC error code.

   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.





Sangster & Narayan    Expires September 6, 2009          [Page 24]

Internet-Draft                  PA-TNC                   March 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Product Vendor ID               |  Product ID   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Product ID   |         Product Name (Variable Length)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Product Vendor ID

      This field contains the SMI Private Enterprise Number for the
      product creator.  If the SMI PEN for the product creator is
      unknown or if the product creator does not have an SMI PEN,
      the Product Vendor ID field MUST be set to 0 and the identity
      of the product creator SHOULD be included in the Product Name
      along with the name of the product.

   Product ID

      This field identifies the product using a numeric identifier
      assigned by the product creator.  If this Product ID value is
      unknown or if the product creator has not assigned such a
      value, this field MUST be set to 0. If the Product Vendor ID
      is 0, this field MUST be set to 0.  In any case, the name of
      the product SHOULD be included in the Product Name field.

      Note that a particular Product ID value (e.g. 635) will have
      completely different meanings depending on the Product Vendor
      ID.  Each Product Vendor ID defines a different space of
      Product ID values.  Product creators are encouraged to
      publish lists of Product ID values for their products.

   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.



Sangster & Narayan    Expires September 6, 2009          [Page 25]

Internet-Draft                  PA-TNC                   March 2009


      The length of this field can be determined by starting with
      the value in the PA-TNC Attribute Length field in the PA-TNC
      Attribute Header and subtracting the size of the fixed length
      fields in that header (12) and the size of the fixed length
      fields in this attribute (5).  If the PA-TNC Attribute Length
      field is less than the size of these fixed length fields,
      implementations SHOULD respond with an Invalid Parameter PA-
      TNC error code.

4.2.3. Numeric Version

   This PA-TNC Attribute Type contains numeric version information
   for a product on the endpoint that implements the component
   specified in the PA Subtype field, as described in section 3.5.
   For example, if the PA Subtype is Operating System, this
   attribute would contain numeric version information for the
   operating system installed on the endpoint. The version
   information in this attribute is associated with a particular
   product, so Posture Validators are expected to also possess the
   corresponding Product Information attribute when interpreting
   this attribute.

   All Posture Collectors that implement the IETF Standard PA
   Subtype for Operating System SHOULD support sending this
   attribute type, at least for the Operating System PA subtype.
   Other Posture Collectors MAY support sending this attribute
   type.  Whether a particular Posture Collector actually sends
   this attribute type SHOULD still be governed by local privacy
   and security policies.  All Posture Validators that implement
   the IETF Standard PA Subtype for Operating System SHOULD support
   receiving this attribute type, at least for the Operating System
   PA subtype.  Other Posture Validators MAY support receiving this
   attribute type.  A Posture Validator that does not support
   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


Sangster & Narayan    Expires September 6, 2009          [Page 26]

Internet-Draft                  PA-TNC                   March 2009


   may not be able to determine some or all of this information for
   a product.  However, this attribute can be especially useful for
   describing the version of the operating system, where numeric
   version numbers are generally available.

   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after
   this diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Major Version Number                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Minor Version Number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Build Number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Service Pack Major       |      Service Pack Minor       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Major Version Number

      This field contains the major version number for the product,
      if applicable. If unused or unknown, this field SHOULD be set
      to 0.

   Minor Version Number

      This field contains the minor version number for the product,
      if applicable. If unused or unknown, this field SHOULD be set
      to 0.

   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.


Sangster & Narayan    Expires September 6, 2009          [Page 27]

Internet-Draft                  PA-TNC                   March 2009


   Service Pack Minor

      This field contains the minor version number of the service
      pack for the product, if applicable. If unused or unknown,
      this field SHOULD be set to 0.

4.2.4. String Version

   This PA-TNC Attribute Type contains string version information
   for a product on the endpoint that implements the component
   specified in the PA Subtype field, as described in section 3.5.
   For example, if the PA Subtype is Firewall, this attribute would
   contain string version information for a host-based firewall
   product installed on the endpoint (if any).  The version
   information in this attribute is associated with a particular
   product, so Posture Validators are expected to also possess the
   corresponding Product Information attribute when interpreting
   this attribute.

   All Posture Collectors that implement any of the IETF Standard
   PA Subtypes defined in this document MUST support sending this
   attribute type, at least for those PA subtypes.  Other Posture
   Collectors MAY support sending this attribute type.  Whether a
   particular Posture Collector actually sends this attribute type
   SHOULD still be governed by local privacy and security policies.
   All Posture Validators that implement any of the IETF Standard
   PA Subtypes defined in this document MUST support receiving this
   attribute type, at least for those PA subtypes.  Other Posture
   Validators MAY support receiving this attribute type.  Posture
   Validators MUST NOT send this attribute type.

   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.





Sangster & Narayan    Expires September 6, 2009          [Page 28]

Internet-Draft                  PA-TNC                   March 2009


   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after
   this diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Version Len  |   Product Version Number (Variable Length)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Build Num Len |   Internal Build Number (Variable Length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Config. Len  | Configuration Version Number (Variable Length)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version Len

      This field defines the number of octets in the Product
      Version Number field.  If the product version number is
      unavailable or unknown, this field MUST be set to 0 and the
      Product Version Number field will be zero length (effectively
      not present).

   Product Version Number

      This field contains a UTF-8 string identifying the version of
      the component (e.g. "1.12.23.114").  This field MUST be sized
      to fit the version string and MUST NOT include extra octets
      for padding or NUL character termination.

      Various products use a wide range of different formats and
      semantics for version strings.  Some use alphabetic
      characters, white space, and punctuation.  Some consider
      version "1.21" to be later than version "1.3" and some
      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




Sangster & Narayan    Expires September 6, 2009          [Page 29]

Internet-Draft                  PA-TNC                   March 2009


      This field contains a UTF-8 string identifying the
      engineering build number of the product.  This field MUST be
      sized to fit the build number string and MUST NOT include
      extra octets for padding or NUL character termination.  The
      syntax and semantics of this string are not defined.

   Config. Len

      This field defines the number of octets in the Configuration
      Version Number field.  If the product version number is
      unavailable or unknown, this field MUST be set to 0 and the
      Product Version Number field will be zero length (effectively
      not present).

   Configuration Version Number

      This field contains a UTF-8 string identifying the version of
      the configuration used by the component.  This version SHOULD
      represent the overall configuration version even if several
      configuration policy files or settings are used.  Posture
      Collectors MAY include multiple version numbers in this
      single string if a single version is not practical.  This
      field MUST be sized to fit the version string and MUST NOT
      include extra octets for padding or NUL character
      termination.

      Various products use a wide range of different formats for
      version strings.  Some use alphabetic characters, white
      space, and punctuation.  Some consider version "1.21" to be
      later than version "1.3" and some earlier.  In addition, some
      Posture Collectors may place multiple configuration version
      numbers in this single string. Therefore, the syntax and
      semantics of this string are not defined.

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


Sangster & Narayan    Expires September 6, 2009          [Page 30]

Internet-Draft                  PA-TNC                   March 2009


   other IETF Standard PA Subtypes defined in this specification
   SHOULD support sending this attribute type for those PA
   subtypes.  Other Posture Collectors MAY support sending this
   attribute type.  Whether a particular Posture Collector actually
   sends this attribute type SHOULD still be governed by local
   privacy and security policies.  Posture Validators that
   implement the IETF Standard PA Subtype for Operating System or
   VPN MAY support receiving this attribute type, at least for
   those PA subtypes.  Posture Validators that implement other IETF
   Standard PA Subtypes defined in this specification SHOULD
   support receiving this attribute type, at least for those PA
   subtypes.  Other Posture Validators MAY support receiving this
   attribute type.  A Posture Validator that does not support
   receiving this attribute type SHOULD simply ignore attributes
   with this type.  Posture Validators MUST NOT send this attribute
   type.

   For this attribute type, the PA-TNC Attribute Vendor ID field
   MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
   be set to 5.  The value in the PA-TNC Attribute Length field
   MUST be 36.  If the PA-TNC Attribute Length field does not have
   this value, implementations SHOULD respond with an Invalid
   Parameter PA-TNC error code.

   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after
   this diagram describes the fields shown here.

                        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




Sangster & Narayan    Expires September 6, 2009          [Page 31]

Internet-Draft                  PA-TNC                   March 2009


      This field gives the operational status of the product.  The
      following table lists the values currently defined for this
      field.

      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.


Sangster & Narayan    Expires September 6, 2009          [Page 32]

Internet-Draft                  PA-TNC                   March 2009


      Leap seconds are permitted and Posture Validators MUST
      support them. The last use string MUST NOT be NUL terminated
      or padded in any way.  If the last use time is not known, not
      applicable, or cannot be represented in this format, the
      Posture Collector MUST set this field to the value "0000-00-
      00T00:00:00Z" (allowing this field to be fixed length). Not
      that this particular reserved value is NOT a valid RFC 3339
      date and time and MUST NOT be used for any other purpose in
      this field.

      This encoding produces a string that is easy to read, parse,
      and interpret.  The format (more precisely defined in RFC
      3339) is YYYY-MM-DDTHH:MM:SSZ, resulting in one and only one
      representation for each second in UTC time from year 0000 to
      year 9999.  For example, 9:05:00AM EST (GMT-0500) on January
      19, 1995 can be represented as "1995-01-19T14:05:00Z".  The
      length of this field is always 20 octets.

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.


Sangster & Narayan    Expires September 6, 2009          [Page 33]

Internet-Draft                  PA-TNC                   March 2009


   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after
   this diagram describes the fields shown here.

   Note that this diagram shows two Protocol/Port Number pairs. The
   actual number of Protocol/Port Number pairs included in a Port
   Filter attribute can vary from one to a large number (limited
   only by the maximum message and length supported by the
   underlying PT transport protocol). However, each Port Filter
   attribute MUST contain at least one Protocol/Port Number pair.
   Because the length of a Protocol/Port Number pair with the
   Reserved field and B flag is always 4 octets, the number of
   Protocol/Port Number pairs can be easily computed using the PA-
   TNC Attribute Length field by subtracting the number of octets
   in the PA-TNC Attribute Header and dividing by 4.  If the PA-TNC
   Attribute Length field is invalid, Posture Validators SHOULD
   respond with an Invalid Parameter PA-TNC error code.

                        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


Sangster & Narayan    Expires September 6, 2009          [Page 34]

Internet-Draft                  PA-TNC                   March 2009


      Protocol and Port Number combination twice in a Port List
      attribute.

      Posture Collectors MAY list all blocked ports for one
      protocol and all allowed ports for a different protocol in a
      single Port List attribute, using the B flag to indicate
      whether each entry is blocked.  For example, a Posture
      Collector might list all the blocked TCP ports but only list
      the allowed UDP ports.  However it MUST NOT list some blocked
      TCP ports and some other allowed TCP ports.

   Protocol

      This field contains the protocol number being blocked or
      allowed. The values used in this field are the same ones used
      in the IPv4 Protocol and IPv6 Next Header fields.  The IANA
      already maintains a registry of these values.

   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



Sangster & Narayan    Expires September 6, 2009          [Page 35]

Internet-Draft                  PA-TNC                   March 2009


   attributes with this type.  Posture Validators MUST NOT send
   this attribute type.

   This attribute type can be quite long, especially for the
   Operating System PA subtype. This can cause problems, especially
   with 802.1X and other limited transport protocols. Therefore,
   Posture Collectors SHOULD NOT send this attribute unless
   specifically requested to do so using the Attribute Request
   attribute or otherwise configured to do so. Also, Posture
   Validators SHOULD NOT request this attribute unless the
   transport protocol in use can support the large amount of data
   that may be sent in response.

   For this attribute type, the PA-TNC Attribute Vendor ID field
   MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
   be set to 7.  The value in the PA-TNC Attribute Length field
   will vary, depending on the number of packages and the length of
   the Package Name and Package Version Number fields for those
   packages. However, the value in the PA-TNC Attribute Length
   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 September 6, 2009          [Page 36]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 37]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 38]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 39]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 40]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 41]

Internet-Draft                  PA-TNC                   March 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
   SHOULD include that error code as the only PA-TNC attribute in a
   PA-TNC message with version number 1. All parties that send PA-
   TNC messages SHOULD be able to properly process a message that
   meets this description, even if they cannot process any other
   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 September 6, 2009          [Page 42]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 43]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 44]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 45]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 46]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 47]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 48]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 49]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 50]

Internet-Draft                  PA-TNC                   March 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 a factory default password enabled.

     1       Endpoint has a factory default password enabled.








Sangster & Narayan    Expires September 6, 2009          [Page 51]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 52]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 53]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 54]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 55]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 56]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 57]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 58]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 59]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 60]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 61]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 62]

Internet-Draft                  PA-TNC                   March 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 September 6, 2009          [Page 63]

Internet-Draft                  PA-TNC                   March 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 |         |          |         |



Sangster & Narayan    Expires September 6, 2009          [Page 64]

Internet-Draft                  PA-TNC                   March 2009


      |-------------------->|         |          |         |

      |         |OS Posture |         |          |         |

      |         |---------->|         |          |         |

      |         |           | Posture |          |         |

      |         |           | Report  |          |         |

      |         |           |-------->|          |         |

      |         |           |         |  Verify  |         |

      |         |           |         |  Posture |         |

      |         |           |         |--------->          |

      |         |           |         |          | Verify  |

      |         |           |         |          | Posture |

      |         |           |         |------------------->|

      |         |           |         | OS Reslt |         |

      |         |           |         |<---------|         |

      |         |           |         | VndrX Patch Result |

      |         |           | Assess  |<-------------------|

      |         |           | Result  |                    |

      |         |           |<--------|          |         |

      |         | OS Reslt  |         |          |         |

      |         |<----------|         |          |         |

      | VndrX Patch Result  |         |          |         |

      |<--------------------|         |          |         |






Sangster & Narayan    Expires September 6, 2009          [Page 65]

Internet-Draft                  PA-TNC                   March 2009


A.1.1. Message Contents

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

A.1.1.1. N/W Join

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

A.1.1.2. Request Posture (Req Post.)

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

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

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

   Vendor X Patch Posture PA Message  {

      Attribute HDR {Message ID}

      Attribute 1 {

         vendor-id=1 (vendor X)

         type=1 (Vendor X namespace attribute)

         length

         Value = {

            VendorXAttribute1=123

         }

      }


Sangster & Narayan    Expires September 6, 2009          [Page 66]

Internet-Draft                  PA-TNC                   March 2009


      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


Sangster & Narayan    Expires September 6, 2009          [Page 67]

Internet-Draft                  PA-TNC                   March 2009


         type=3 (numeric version)

         length

         Value = {

            major-version=6     -- Vista is version 6.0

            minor-version=0

            build-number=456789

            service-pack-major=0   -- No service packs

            service-pack-minor=0

         }

      }

   }

A.1.1.5. Posture Report

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

A.1.1.6. Verify Posture

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

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


Sangster & Narayan    Expires September 6, 2009          [Page 68]

Internet-Draft                  PA-TNC                   March 2009


              type=9 (assessment-result)

              length

              Value = {

                 assessment-result=0 (compliant)

              }

        }

    }

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

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

   Patch Vendor X Posture Result PA Message {

      Attribute HDR {Message ID}

         Attribute 1 {

              vendor-id=0

              type=9 (assessment-result)

              length

              Value = {

                 assessment-result=0 (compliant)

              }

         }

    }

A.1.1.9. Assessment Result (Assess Result)

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


Sangster & Narayan    Expires September 6, 2009          [Page 69]

Internet-Draft                  PA-TNC                   March 2009


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  |

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


Sangster & Narayan    Expires September 6, 2009          [Page 70]

Internet-Draft                  PA-TNC                   March 2009


        |          |           |         |Vndr X AV |          |

        |          |           |         |Post. Req |          |

        |          |           | Posture |<---------|          |

        |          |           | Request |          |          |

        |          | Vndr X AV |<--------|          |          |

        |          | Post. Req |         |          |          |

        |          |<----------|         |          |          |

        |      Vndr Y AV       |         |          |          |

        |     Posture Req      |         |          |          |

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

        |  Vndr Y AV Posture   |         |          |          |

        +----------+---------->|         |          |          |

        |          | Vndr X AV |         |          |          |

        |          |  Posture  |         |          |          |

        |          |---------->| Posture |          |          |

        |          |           |Response |          |          |

        |          |           |-------->|          |          |

        |          |           |         |  Verify  |          |

        |          |           |         |  Posture |          |

        |          |           |         |--------->|          |

        |          |           |         |     Verify Posture  |

        |          |           |         |----------+--------->|

        |          |           |         |Vndr Y AV Post Result|

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


Sangster & Narayan    Expires September 6, 2009          [Page 71]

Internet-Draft                  PA-TNC                   March 2009


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

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


Sangster & Narayan    Expires September 6, 2009          [Page 72]

Internet-Draft                  PA-TNC                   March 2009


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



Sangster & Narayan    Expires September 6, 2009          [Page 73]

Internet-Draft                  PA-TNC                   March 2009


                 Vendor-id=1 (Vendor X)

                 Type=1 (Vendor X attribute, Scan-Engine-Version)

                 Vendor-id=0 (IETF Standard)

                 Type=5 (Standard, Operational-Status)

               }

          }

    }

A.2.1.5. Posture Request

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

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

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

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



Sangster & Narayan    Expires September 6, 2009          [Page 74]

Internet-Draft                  PA-TNC                   March 2009


               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 {

      Attribute HDR {Message ID}

         Attribute 1 {

            vendor-id=1

            type=1 (vendor X attribute, Scan-Engine-Version)

            length

            Value = {



Sangster & Narayan    Expires September 6, 2009          [Page 75]

Internet-Draft                  PA-TNC                   March 2009


               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



Sangster & Narayan    Expires September 6, 2009          [Page 76]

Internet-Draft                  PA-TNC                   March 2009


   Vendor Y AV Posture Result PA Message {

      Attribute HDR {Message ID}

        Attribute 1 {

           vendor-id=0

           type=9 (assessment-result)

           length

           Value = {

              assessment-result=0 (compliant)

           }

        }

     }

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

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

   Vendor X AV Posture Result PA Message {

       Attribute HDR {Message ID}

         Attribute 1 {

            vendor-id=0

            type=9 (assessment-result)

            length

            Value = {

               assessment-result=1 (non-compliant)

            }

         }



Sangster & Narayan    Expires September 6, 2009          [Page 77]

Internet-Draft                  PA-TNC                   March 2009


    }

A.2.1.13. Assessment Result (Assess Result)

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

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

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

A.3. Client triggered re-assessment

   This scenario involves the re-assessment of an endpoint as a result of
   enabling a software component on the endpoint. The endpoint has two
   VPN client software components, one from vendor X for the user's home
   network and other from vendor Y for the network that the endpoint is
   currently accessing.  The assessment is triggered when the user tries
   to use the Vendor X VPN client; this is a violation of the assessment
   policy.  The Posture Broker Client triggers the posture assessment
   when it receives a notification from the VPN Posture Collector about
   the change to 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.



Sangster & Narayan    Expires September 6, 2009          [Page 78]

Internet-Draft                  PA-TNC                   March 2009


   +--------+  +-------+ +---------+ +--------+ +-------+ +--------+

   |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 September 6, 2009          [Page 79]

Internet-Draft                  PA-TNC                   March 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



Sangster & Narayan    Expires September 6, 2009          [Page 80]

Internet-Draft                  PA-TNC                   March 2009


   this use case is triggered locally, NEA does not specify the
   contents of this flow.

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

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

A.3.1.6. Vendor X VPN Posture (VPNX Post)

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

   Vendor X VPN Posture PA Message{

      Attribute HDR {Message ID}

        Attribute 1 {

              vendor-id=0

              type=2 (product information)

              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



Sangster & Narayan    Expires September 6, 2009          [Page 81]

Internet-Draft                  PA-TNC                   March 2009


              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

              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



Sangster & Narayan    Expires September 6, 2009          [Page 82]

Internet-Draft                  PA-TNC                   March 2009


              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)


Sangster & Narayan    Expires September 6, 2009          [Page 83]

Internet-Draft                  PA-TNC                   March 2009


              length

              Value = {

                 assessment-result=1 (non-compliant)

              }

         }

    }

A.3.1.11. Assessment Result (Assess Result)

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

A.3.1.12. Posture Result (VPN PRslt)

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

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.





Sangster & Narayan    Expires September 6, 2009          [Page 84]

Internet-Draft                  PA-TNC                   March 2009


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.

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:


Sangster & Narayan    Expires September 6, 2009          [Page 85]

Internet-Draft                  PA-TNC                   March 2009


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

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

B.6. Evaluation Against 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


Sangster & Narayan    Expires September 6, 2009          [Page 86]

Internet-Draft                  PA-TNC                   March 2009


   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:

   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:


Sangster & Narayan    Expires September 6, 2009          [Page 87]

Internet-Draft                  PA-TNC                   March 2009


   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:

   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,


Sangster & Narayan    Expires September 6, 2009          [Page 88]

Internet-Draft                  PA-TNC                   March 2009


   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:

   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.


Sangster & Narayan    Expires September 6, 2009          [Page 89]

Internet-Draft                  PA-TNC                   March 2009


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.

   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:


Sangster & Narayan    Expires September 6, 2009          [Page 90]

Internet-Draft                  PA-TNC                   March 2009


   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.

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 September 6, 2009          [Page 91]


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