doc: Add RFC documents

1 files changed, 4651 insertions, 0 deletions

diff --git a/doc/rfc/rfc5792.txt b/doc/rfc/rfc5792.txt
new file mode 100644
index 0000000..54a21d2
--- /dev/null
+++ b/doc/rfc/rfc5792.txt
@@ -0,0 +1,4651 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       P. Sangster
+Request for Comments: 5792                          Symantec Corporation
+Category: Standards Track                                     K. Narayan
+ISSN: 2070-1721                                            Cisco Systems
+                                                              March 2010
+
+
+          PA-TNC: A Posture Attribute (PA) Protocol Compatible
+                   with Trusted Network Connect (TNC)
+
+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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5792.
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                    [Page 1]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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.
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Prerequisites ..............................................4
+      1.2. Message Diagram Conventions ................................4
+      1.3. Conventions Used in This Document ..........................4
+   2. Design Considerations ...........................................4
+      2.1. Standard Attribute Namespace for Interoperability ..........4
+      2.2. Vendor-Defined Namespace for Differentiation and Agility ...5
+      2.3. Use of TLV-Based Encoding for Efficiency ...................6
+   3. PA-TNC Message Protocol .........................................7
+      3.1. PA-TNC Messaging Model .....................................7
+      3.2. PA-TNC Relationship to PB-TNC ..............................8
+      3.3. PB-PA Posture Collector and Posture Validator
+           Identifiers ...............................................10
+      3.4. PA-TNC Messages in PB-TNC .................................10
+      3.5. IETF Standard PA Subtypes .................................11
+      3.6. PA-TNC Message Header Format ..............................12
+   4. PA-TNC Attributes ..............................................13
+      4.1.  PA-TNC Attribute Header ..................................13
+      4.2.  IETF Standard PA-TNC Attribute Types .....................17
+           4.2.1. Attribute Request ..................................18
+           4.2.2. Product Information ................................20
+           4.2.3. Numeric Version ....................................22
+           4.2.4. String Version .....................................24
+           4.2.5. Operational Status .................................26
+           4.2.6. Port Filter ........................................29
+           4.2.7. Installed Packages .................................31
+           4.2.8. PA-TNC Error .......................................34
+           4.2.9. Assessment Result ..................................41
+           4.2.10. Remediation Instructions ..........................42
+           4.2.11. Forwarding Enabled ................................45
+           4.2.12. Factory Default Password Enabled ..................47
+      4.3.  Vendor-Defined Attributes ................................48
+   5. Security Considerations ........................................48
+      5.1. Trust Relationships .......................................48
+
+
+
+Sangster & Narayan           Standards Track                    [Page 2]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+           5.1.1. Posture Collector ..................................49
+           5.1.2. Posture Validator ..................................49
+           5.1.3. Posture Broker Client, Posture Broker Server .......49
+      5.2. Security Threats ..........................................50
+           5.2.1. Attribute Theft ....................................50
+           5.2.2. Message Fabrication ................................51
+           5.2.3. Attribute Modification .............................51
+           5.2.4. Attribute Replay ...................................52
+           5.2.5. Attribute Insertion ................................52
+           5.2.6. Denial of Service ..................................53
+   6. Privacy Considerations .........................................53
+   7. IANA Considerations ............................................54
+      7.1. Designated Expert Guidelines ..............................55
+      7.2. PA Subtypes ...............................................56
+      7.3. Registry for PA-TNC Attribute Types .......................56
+      7.4. Registry for PA-TNC Error Codes ...........................57
+      7.5. Registry for PA-TNC Remediation Parameters Types ..........58
+   8. Acknowledgments ................................................58
+   9. References .....................................................59
+      9.1. Normative References ......................................59
+      9.2. Informative References ....................................59
+   Appendix A. Use Cases .............................................60
+      A.1. Initial Client-Triggered Assessment .......................60
+      A.2. Server-Initiated Assessment with Remediation ..............64
+      A.3. Client-Triggered Reassessment .............................71
+   Appendix B. Evaluation against NEA Requirements ...................77
+      B.1. Evaluation against Requirements C-1 .......................77
+      B.2. Evaluation against Requirements C-2 .......................77
+      B.3. Evaluation against Requirements C-3 .......................77
+      B.4. Evaluation against Requirements C-4 .......................78
+      B.5. Evaluation against Requirements C-5 .......................78
+      B.6. Evaluation against Requirements C-6 .......................78
+      B.7. Evaluation against Requirements C-7 .......................79
+      B.8. Evaluation against Requirements C-8 .......................79
+      B.9. Evaluation against Requirements C-9 .......................79
+      B.10. Evaluation against Requirements C-10 .....................80
+      B.11. Evaluation against Requirements C-11 .....................80
+      B.12. Evaluation against Requirements PA-1 .....................81
+      B.13. Evaluation against Requirements PA-2 .....................81
+      B.14. Evaluation against Requirements PA-3 .....................81
+      B.15. Evaluation against Requirements PA-4 .....................82
+      B.16. Evaluation against Requirements PA-5 .....................82
+      B.17. Evaluation against Requirements PA-6 .....................83
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                    [Page 3]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+1.  Introduction
+
+   This document specifies PA-TNC, a Posture Attribute (PA) Protocol
+   identical to the Trusted Computing Group's IF-M 1.0 protocol [8].
+   The document then evaluates PA-TNC against the requirements defined
+   in the Network Endpoint Assessment (NEA) Requirements specification
+   [9].
+
+1.1.  Prerequisites
+
+   This document does not define an architecture or reference model.
+   Instead, it defines a protocol that works within the reference model
+   described in the NEA Overview and Requirements specification.  The
+   reader is assumed to be thoroughly familiar with that document.  No
+   familiarity with TCG specifications is assumed.
+
+1.2.  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 1-octet field with only bit 0 set has the value 0x80.
+
+1.3.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+2.  Design Considerations
+
+   This section discusses some of the key design considerations for the
+   PA protocol.
+
+2.1.  Standard Attribute Namespace for Interoperability
+
+   The PA protocol requires the use of two categories of namespaces:
+   component types (AKA PA subtypes) and attributes.  Each of these
+   namespace categories needs to contain well-known, interoperable names
+   with defined syntax and semantics co-existing with names for vendor-
+
+
+
+Sangster & Narayan           Standards Track                    [Page 4]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 Structure of Management Information (SMI) Private Enterprise Number
+   (PEN) field to identify the definer of namespace of the associated
+   field.  This allows the IETF NEA WG to define a set of standard
+   component types and attribute types while allowing vendors to each
+   create additional names outside of the IETF standard namespace.  Over
+   time, vendor-defined names might be proposed for standardization and
+   thus migration into the IETF namespace.
+
+   The PB-TNC protocol defines an IETF standard namespace (using
+   vendor-id=0) that allows for definition of standard component types
+   (e.g., Operating System, Firewall, Anti-Virus) using the PA Subtype
+   field (see section 3.2).  Similarly, PA-TNC defines a set of standard
+   attributes in section 4.2 that represent the most common capabilities
+   (attributes) of these types of components across a variety of vendor
+   implementations.  The standard namespace allows NEA deployments with
+   both open source and vendor-provided NEA implementations to support a
+   consistent set of policies across their environment based on these
+   standard attributes.  The standard attributes can be used with a
+   variety of endpoints (hosts, printers, mobile devices) that are
+   running 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 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 allow
+   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.
+
+
+
+
+Sangster & Narayan           Standards Track                    [Page 5]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 than one vendor-id namespace).  For
+   instance, an open source anti-virus Posture Collector might be
+   written that supports all of the IETF standard attributes used to
+   describe a local anti-virus component and a subset of multiple anti-
+   virus manufacturers' vendor-defined attributes.  This Posture
+   Collector might therefore be able to interoperate with Posture
+   Validators from multiple vendors.  Conversely, a simple Posture
+   Collector might be written to ignore any vendor-defined attributes
+   requested and only return standard attributes that it supports.  If
+   the vendor-provided Posture Validator's policy allows for this subset
+   to be considered compliant, then these simple Posture Collectors can
+   be used to perform a successful assessment.
+
+2.3.  Use of TLV-Based Encoding for Efficiency
+
+   The PA-TNC protocol has chosen to employ a binary encoding using a
+   type-length-value (TLV) structure.  TLV encoding was preferred over
+   the use of a textual encoding format such as XML to provide a more
+   efficient utilization of the potentially constrained bandwidth
+   available between the NEA Client and NEA Server (see NEA Overview and
+   Architecture [9]).  Efficiency was a primary criterion 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 Posture Transport (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).
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                    [Page 6]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+3.  PA-TNC Message Protocol
+
+   This section discusses the use of the PA-TNC message and its
+   attributes, and specifies the syntax and semantics for the PA-TNC
+   message header.  The details of each attribute included within the
+   PA-TNC payload are specified in section 4.2.
+
+3.1.  PA-TNC Messaging Model
+
+   PA-TNC messages are carried by the PB-TNC protocol [5], which
+   provides a multi-roundtrip reliable transport and end-to-end message
+   delivery to subscribed (interested) parties using a variety of
+   underlying network protocols.  PA-TNC is unaware of these underlying
+   PT 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
+   Posture Broker (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 batch of messages 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.
+
+
+
+
+
+Sangster & Narayan           Standards Track                    [Page 7]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   However, this publish/subscribe model has some possible negative side
+   effects.  When a Posture Collector or Posture Validator initially
+   sends a PA-TNC message, it does not know whether it will receive
+   many, one, or no PA-TNC messages from the other side.  For many types
+   of assessments, this is acceptable, but in some cases a more direct
+   channel binding between a particular Posture Collector and Posture
+   Validator pair is necessary.  For example, a Posture Validator may
+   wish to provide remediation instructions to a particular Posture
+   Collector that it knows is capable of remediating a non-compliant
+   component.  This can be accomplished using the exclusive delivery PB-
+   TNC capability to limit distribution of a message to a single Posture
+   Collector by including the target Posture Collector Identifier in the
+   PB-PA header.  For more information on the PB-PA header, see section
+   4.5 of the PB-TNC specification.
+
+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.
+
+
+
+
+
+Sangster & Narayan           Standards Track                    [Page 8]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   The message type is composed of two fields: a PA Message Vendor ID
+   and a PA Subtype.  The PA Message Vendor ID identifies the vendor or
+   other organization that defined this message type.  The PA Subtype
+   identifies the message type more specifically within the set of
+   message types defined by that vendor.  This specification defines
+   several IETF Standard PA Subtypes to be used with a PA Message Vendor
+   ID of zero (0).  Within this specification, the PA Subtype field is
+   used to indicate the type of component (e.g., firewall) involved with
+   the message's attributes.  Therefore, for clarity, the PA subtype
+   will be referred to as the "component type" in this specification.
+   Vendor-defined namespaces 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.
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                    [Page 9]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   If the above message contained both firewall and operating system
+   attributes inside a PA-TNC message with a component type of firewall,
+   then any Posture Collector and Posture Validator registered to
+   receive operating system messages would not receive those attributes,
+   as the messages would only be delivered to those registered for
+   firewall messages.
+
+3.3.  PB-PA Posture Collector and Posture Validator Identifiers
+
+   The PB-PA 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 PB-PA 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 PB-PA 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
+
+
+
+Sangster & Narayan           Standards Track                   [Page 10]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   Posture Validators compliant with this specification MUST be capable
+   of processing multiple attributes in a received PA-TNC message.  A
+   Posture Collector or Posture Validator that receives a PA-TNC message
+   can use the attribute header's length field to skip any attributes
+   that it does not understand, unless the attribute is marked as
+   mandatory to process.
+
+3.5.  IETF Standard PA Subtypes
+
+   This section defines several IETF Standard PA Subtypes.  Each PA
+   subtype defined here identifies a specific component relevant to the
+   endpoint's posture.  This allows a small set of generic PA-TNC
+   attributes (e.g., Product Information) to be used to describe a large
+   number of different components (e.g., operating system, anti-virus,
+   etc.).  It also allows Posture Collectors and Posture Validators to
+   specialize in a particular component and only receive PA-TNC messages
+   relevant to that component.
+
+   Value    Integer           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 Network
+                              (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
+
+
+
+Sangster & Narayan           Standards Track                   [Page 11]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   values are used with a different PA Message Vendor ID, they have a
+   completely different meaning that is not defined in this
+   specification.  Posture Collectors and Posture Validators MUST NOT
+   require support for particular vendor-specific PA subtypes and MUST
+   interoperate with other parties despite any differences in the set of
+   vendor-specific PA subtypes supported (although they MAY permit
+   administrators to configure them to require support for specific PA
+   subtypes).
+
+3.6.  PA-TNC Message Header Format
+
+   This section describes the format and semantics of the PA-TNC header.
+   Every PA-TNC message MUST start with a PA-TNC header.  The PA-TNC
+   header provides a common context applying to all of the attributes
+   contained within the PA-TNC payload.  The payload consists of a
+   sequence of assessment attributes described in section 4.2.
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Version    |                    Reserved                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Message Identifier                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Version
+
+      This field indicates the version of the format for the PA-TNC
+      message.  This version is intended to allow for evolution of the
+      PA-TNC message header and payload in a manner that can easily be
+      detected by message recipients.
+
+      PA-TNC message senders MUST set this field to 0x01 for all PA-TNC
+      messages that comply with this specification.  Implementations
+      responding to a PA-TNC message containing a supported version MUST
+      use the same version number to minimize the risk of version
+      incompatibility.  Message recipients MUST respond to a PA-TNC
+      message containing an unsupported version by sending a Version Not
+      Supported error in a PA-TNC Error attribute that is the only PA-
+      TNC attribute in a PA-TNC message with version number 1.
+
+      PA-TNC message initiators supporting multiple PA-TNC protocol
+      versions SHOULD be able to alter which version of PA-TNC message
+      they send based on prior message exchanges with a particular peer
+      Posture Collector or Posture Validator.
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 12]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 the
+      payload of a response message to indicate which message was
+      received and caused the response.  This value is included in the
+      payload of PA-TNC error messages so the party who receives the
+      error message can determine which of the messages they had sent
+      caused the error.
+
+      PA-TNC message senders MUST NOT send the same message identifier
+      more than once during an assessment.  Message identifiers may be
+      randomly generated or sequenced as long as values are not repeated
+      during an assessment message exchange.  PA-TNC message recipients
+      are not required to check for duplicate message identifiers.
+
+4.  PA-TNC Attributes
+
+   This section defines the PA-TNC attributes that can be carried within
+   a PA-TNC message.  The initial section defines the standard attribute
+   header that appears at the start of each attribute in a PA-TNC
+   message.  The second section defines each of the IETF Standard PA-TNC
+   Attributes and the final section discusses how vendor-defined PA-TNC
+   attributes can be used within a PA-TNC message.  Vendor-defined PA-
+   TNC attributes use the vendor's SMI Private Enterprise Number in the
+   Attribute Type field.
+
+   A PA-TNC message MUST contain a PA-TNC header (defined in section
+   3.6.  followed by a sequence of zero or more PA-TNC attributes.  All
+   PA-TNC attributes MUST begin with a standard PA-TNC attribute header,
+   as defined in section 4.1.  The contents of PA-TNC attributes vary
+   widely, depending on their attribute type.  Section 4.2 defines the
+   IETF Standard PA-TNC Attributes.  Section 4.3 discusses how vendor-
+   specific PA-TNC attributes can be defined.
+
+4.1.  PA-TNC Attribute Header
+
+   Following the PA-TNC message header is a sequence of zero or more
+   attributes.  All PA-TNC attributes MUST begin with the standard PA-
+   TNC attribute header defined in this subsection.  Each attribute
+   described in this specification is represented by a TLV tuple.  The
+   TLV tuple includes an attribute identifier comprised of the Vendor ID
+
+
+
+Sangster & Narayan           Standards Track                   [Page 13]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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
+   ensures that recipients compliant with a particular PA-TNC message
+   version can at least parse every attribute header and use the length
+   to skip over unrecognized attributes.  Finally, all attribute TLVs
+   within a PA-TNC message MUST pertain to the same implementation of
+   the component.  This restriction is relevant when a single Posture
+   Collector is reporting on multiple implementations of a component, so
+   must send multiple PA-TNC messages each including only the attributes
+   describing a single implementation.  For more information on how
+   Posture Collectors should handle multiple implementations, see
+   section 3.3.
+
+   Every PA-TNC-compliant TLV attribute MUST use the following TLV
+   format:
+                       1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Flags     |          PA-TNC Attribute Vendor ID           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     PA-TNC Attribute Type                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    PA-TNC Attribute Length                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Attribute Value (Variable Length)             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Flags
+
+      This field defines flags impacting the processing of the
+      associated attribute.
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 14]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      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 namespace 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 namespace.  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 Validators MUST NOT send PA-TNC messages in
+      which the PA-TNC Attribute Vendor ID has this reserved value
+      (0xffffff).  If a Posture Collector or Posture Validator 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).
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 15]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      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 Validators MUST NOT send PA-TNC messages in
+      which the PA-TNC Attribute Type has this reserved value
+      (0xffffffff).  If a Posture Collector or Posture Validator
+      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 Validator 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.  Similarly, if a Posture Collector or Posture Validator
+      receives a PA-TNC message for an Attribute Type that has a well-
+      known Attribute Value length (e.g., fixed-length attribute value)
+      and the Attribute Length indicates a different value (greater or
+      less than the expected value), the recipient 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 less than 2^32-1 due to limitations of
+      the underlying protocol stack.  Specifically, PB-TNC TLV header's
+      Batch Length field is also 32 bits in length.  Therefore, the
+      maximum batch that PB-TNC can carry is 2^32-1, so the largest PA-
+      TNC message carried by PB-TNC must be less than 2^32-1 - size of
+      the PB-TNC header (see section 4.1 of PB-TNC for more details).
+
+   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.
+
+
+
+Sangster & Narayan           Standards Track                   [Page 16]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+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  Integer                  Description
+   ------  -------                  -----------
+   0       Testing                  Reserved for use in
+                                    specification examples,
+                                    experimentation, and testing.
+
+   1       Attribute Request        Contains a list of attribute
+                                    type values defining the
+                                    attributes desired from the
+                                    Posture Collectors.
+
+   2       Product Information      Manufacturer and product
+                                    information for the component.
+
+   3       Numeric Version          Numeric version of the
+                                    component.
+
+   4       String Version           String version of the
+                                    component.
+
+   5       Operational Status       Describes whether the component
+                                    is running on the endpoint.
+
+   6       Port Filter              Lists the set of ports (e.g.,
+                                    TCP port 80 for HTTP) that are
+                                    allowed or blocked on the
+                                    endpoint.
+
+   7       Installed Packages       List of software packages
+                                    installed on endpoint that
+                                    provide the requested
+                                    component.
+
+   8       PA-TNC Error             PA-TNC message or attribute
+                                    processing error.
+
+
+
+Sangster & Narayan           Standards Track                   [Page 17]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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
+           Enabled                  has a factory default password
+                                    enabled.
+
+   The following subsections discuss the usage, format, and semantics of
+   the Attribute Value field for each IETF Standard PA-TNC Attribute
+   Type.
+
+4.2.1.  Attribute Request
+
+   This PA-TNC Attribute Type allows a Posture Validator to request
+   certain attributes from the registered set of Posture Collectors.
+
+   All Posture Collectors that implement any of the IETF Standard PA
+   Subtypes defined in this specification SHOULD support receiving and
+   processing this attribute type for at least those PA subtypes.  This
+   requirement is only a "should" because there are deployment scenarios
+   (e.g., see section A.1) where the Posture Collectors proactively send
+   a set of attributes at the start of an assessment (e.g., based upon
+   local policy), so does not need to support Posture Validator
+   requested attributes.  Posture Collectors that receive but do not
+   support the Attribute Request attribute MUST respond with an
+   Attribute Type Not Supported PA-TNC error code.  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 Validators MUST NOT include this attribute type in an
+   Attribute Request attribute.  It does not make sense for a Posture
+   Validator to request that a Posture Collector send an Attribute
+   Request attribute.
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 18]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 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 1-octet Reserved field is always 8 octets, the
+   number of requested attributes can be easily computed using the PA-
+   TNC Attribute Length field by subtracting the number of octets in the
+   PA-TNC Attribute Header and dividing by 8.  If the PA-TNC Attribute
+   Length field is invalid, Posture Collectors SHOULD respond with an
+   Invalid Parameter PA-TNC error code.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Reserved    |           PA-TNC Attribute Vendor ID          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      PA-TNC Attribute Type                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Reserved    |           PA-TNC Attribute Vendor ID          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      PA-TNC Attribute Type                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Reserved
+
+      Reserved for future use.  This field MUST be set to 0 on
+      transmission and ignored upon reception.
+
+   PA-TNC Attribute Vendor ID
+
+      This field contains the SMI Private Enterprise Number of the
+      organization that controls the namespace 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.
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 19]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      Any IETF Standard PA-TNC Attribute Types defined in section 4.2
+      MUST use zero (0) in this field.  Vendor-defined attributes MUST
+      use the SMI Private Enterprise Number of the organization that
+      defined the attribute.
+
+   PA-TNC Attribute Type
+
+      The PA-TNC Attribute Type field (together with the PA-TNC Vendor
+      ID field) indicates the specific attribute requested.  Some IETF
+      Standard PA-TNC Attribute Types MUST NOT be requested using this
+      field (e.g., requesting a PA-TNC Error attribute).  This is
+      explicitly indicated in the description of those PA-TNC Attribute
+      Types.  Any Posture Collector or Posture Validator that receives
+      an Attribute Request containing one of the prohibited Attribute
+      Types SHOULD respond with an Invalid Parameter error in a PA-TNC
+      error message.
+
+4.2.2.  Product Information
+
+   This PA-TNC Attribute Type contains identifying information about a
+   product that implements the component specified in the PA Subtype
+   field, as described in section 3.5.  For example, if the PA Subtype
+   is Anti-Virus, this attribute would contain information identifying
+   an anti-virus product installed on the endpoint.
+
+   All Posture Collectors that implement any of the IETF Standard PA
+   Subtypes defined in this specification MUST support sending this
+   attribute type, at least for those PA subtypes.  Whether a particular
+   Posture Collector actually sends this attribute type SHOULD still be
+   governed by local privacy and security policies.  All Posture
+   Validators that implement any of the IETF Standard PA Subtypes
+   defined in this specification MUST support receiving this attribute
+   type, at least for those PA subtypes.  Posture Validators MUST NOT
+   send this attribute type.
+
+   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-length fields in the PA-TNC Attribute Header and
+   the fixed-length fields in this attribute type.  If the PA-TNC
+   Attribute Length field is less than the size of these fixed-length
+   fields, implementations SHOULD respond with an Invalid Parameter PA-
+   TNC error code.
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 20]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   This attribute type includes both numeric and textual identifiers for
+   the organization that created the product (the "product creator") and
+   for the product itself.  For automated processing, numeric
+   identifiers are superior because they are less ambiguous and more
+   efficient.  However, numeric identifiers are only available if the
+   product creator has assigned them.  Therefore, a textual identifier
+   is also included.  This textual identifier has the additional benefit
+   that it may be easier for humans to read (although this benefit is
+   minimal since the primary purpose of this attribute is automated
+   assessment).
+
+   The following diagram illustrates the format and contents of the
+   Attribute Value field for this attribute type.  The text after this
+   diagram describes the fields shown here.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               Product Vendor ID               |  Product ID   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Product ID   |         Product Name (Variable Length)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Product Vendor ID
+
+      This field contains the SMI Private Enterprise Number for the
+      product creator.  If the SMI PEN for the product creator is
+      unknown or if the product creator does not have an SMI PEN, the
+      Product Vendor ID field MUST be set to 0 and the identity of the
+      product creator SHOULD be included in the Product Name along with
+      the name of the product.
+
+   Product ID
+
+      This field identifies the product using a numeric identifier
+      assigned by the product creator.  If this Product ID value is
+      unknown or if the product creator has not assigned such a value,
+      this field MUST be set to 0.  If the Product Vendor ID is 0, this
+      field MUST be set to 0.  In any case, the name of the product
+      SHOULD be included in the Product Name field.
+
+      Note that a particular Product ID value (e.g., 635) will have
+      completely different meanings depending on the Product Vendor ID.
+      Each Product Vendor ID defines a different space of Product ID
+      values.  Product creators are encouraged to publish lists of
+      Product ID values for their products.
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 21]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   Product Name
+
+      This variable-length field contains a UTF-8 [2] string identifying
+      the product (e.g., "Symantec Norton AntiVirus(TM) 2008") in enough
+      detail to unambiguously distinguish it from other products from
+      the product creator.  Products whose creator is known, but does
+      not have a registered SMI Private Enterprise Number, SHOULD be
+      represented using a combination of the creator name and full
+      product name (e.g., "Ubuntu(R) IPtables" for the IPtables firewall
+      in the Ubuntu distribution of Linux).  If the product creator's
+      SMI Private Enterprise Number is included in the Product Vendor ID
+      field, the product creator's name may be omitted from this field.
+
+      The length of this field can be determined by starting with the
+      value in the PA-TNC Attribute Length field in the PA-TNC Attribute
+      Header and subtracting the size of the fixed-length fields in that
+      header (12) and the size of the fixed-length fields in this
+      attribute (5).  If the PA-TNC Attribute Length field is less than
+      the size of these fixed-length fields, implementations SHOULD
+      respond with an Invalid Parameter PA-TNC error code.
+
+4.2.3. Numeric Version
+
+   This PA-TNC Attribute Type contains numeric version information for a
+   product on the endpoint that implements the component specified in
+   the PA Subtype field, as described in section 3.5.  For example, if
+   the PA Subtype is Operating System, this attribute would contain
+   numeric version information for the operating system installed on the
+   endpoint.  The version information in this attribute is associated
+   with a particular product, so Posture Validators are expected to also
+   possess the corresponding Product Information attribute when
+   interpreting this attribute.
+
+   All Posture Collectors that implement the IETF Standard PA Subtype
+   for Operating System SHOULD support sending this attribute type, at
+   least for the Operating System PA subtype.  Other Posture Collectors
+   MAY support sending this attribute type.  Whether a particular
+   Posture Collector actually sends this attribute type SHOULD still be
+   governed by local privacy and security policies.  All Posture
+   Validators that implement the IETF Standard PA Subtype for Operating
+   System SHOULD support receiving this attribute type, at least for the
+   Operating System PA subtype.  Other Posture Validators MAY support
+   receiving this attribute type.  A Posture Validator that does not
+   support receiving this attribute type SHOULD simply ignore attributes
+   with this type.  Posture Validators MUST NOT send this attribute
+   type.
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 22]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
+   set to zero (0) and the PA-TNC Attribute Type field MUST be set to 3.
+   The value in the PA-TNC Attribute Length field MUST be 28.  If the
+   PA-TNC Attribute Length field is less than the size of these fixed-
+   length fields, implementations SHOULD respond with an Invalid
+   Parameter PA-TNC error code.
+
+   This attribute type includes numeric values for the product version
+   information, enabling Posture Validators to do comparative operations
+   on the version.  Some Posture Collectors may not be able to determine
+   some or all of this information for a product.  However, this
+   attribute can be especially useful for describing the version of the
+   operating system, where numeric version numbers are generally
+   available.
+
+   The following diagram illustrates the format and contents of the
+   Attribute Value field for this attribute type.  The text after this
+   diagram describes the fields shown here.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Major Version Number                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Minor Version Number                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Build Number                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Service Pack Major       |      Service Pack Minor       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Major Version Number
+
+      This field contains the major version number for the product, if
+      applicable.  If unused or unknown, this field SHOULD be set to 0.
+
+   Minor Version Number
+
+      This field contains the minor version number for the product, if
+      applicable.  If unused or unknown, this field SHOULD be set to 0.
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 23]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   Build Number
+
+      This field contains the build number for the product, if
+      applicable.  This may provide more granularity than the minor
+      version number, as many builds may occur leading up to an official
+      release, and all these builds may share a single major and minor
+      version number.  If unused or unknown, this field SHOULD be set to
+      0.
+
+   Service Pack Major
+
+      This field contains the major version number of the service pack
+      for the product, if applicable.  If unused or unknown, this field
+      SHOULD be set to 0.
+
+   Service Pack Minor
+
+      This field contains the minor version number of the service pack
+      for the product, if applicable.  If unused or unknown, this field
+      SHOULD be set to 0.
+
+4.2.4.  String Version
+
+   This PA-TNC Attribute Type contains string version information for a
+   product on the endpoint that implements the component specified in
+   the PA Subtype field, as described in section 3.5.  For example, if
+   the PA Subtype is Firewall, this attribute would contain string
+   version information for a host-based firewall product installed on
+   the endpoint (if any).  The version information in this attribute is
+   associated with a particular product, so Posture Validators are
+   expected to also possess the corresponding Product Information
+   attribute when interpreting this attribute.
+
+   All Posture Collectors that implement any of the IETF Standard PA
+   Subtypes defined in this document MUST support sending this attribute
+   type, at least for those PA subtypes.  Other Posture Collectors MAY
+   support sending this attribute type.  Whether a particular Posture
+   Collector actually sends this attribute type SHOULD still be governed
+   by local privacy and security policies.  All Posture Validators that
+   implement any of the IETF Standard PA Subtypes defined in this
+   document MUST support receiving this attribute type, at least for
+   those PA subtypes.  Other Posture Validators MAY support receiving
+   this attribute type.  Posture Validators MUST NOT send this attribute
+   type.
+
+   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
+
+
+
+Sangster & Narayan           Standards Track                   [Page 24]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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-length fields in the PA-TNC Attribute Header and
+   the fixed-length fields in this attribute type.  If the PA-TNC
+   Attribute Length field is less than the size of these fixed-length
+   fields or does not match the length indicated by the sum of the
+   fixed-length and variable-length fields, implementations SHOULD
+   respond with an Invalid Parameter PA-TNC error code.
+
+   The following diagram illustrates the format and contents of the
+   Attribute Value field for this attribute type.  The text after this
+   diagram describes the fields shown here.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Version Len  |   Product Version Number (Variable Length)    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Build Num Len |   Internal Build Number (Variable Length)     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Config. Len  | Configuration Version Number (Variable Length)|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Version Len
+
+      This field defines the number of octets in the Product Version
+      Number field.  If the product version number is unavailable or
+      unknown, this field MUST be set to 0 and the Product Version
+      Number field will be zero length (effectively not present).
+
+   Product Version Number
+
+      This field contains a UTF-8 string identifying the version of the
+      component (e.g., "1.12.23.114").  This field MUST be sized to fit
+      the version string and MUST NOT include extra octets for padding
+      or NUL character termination.
+
+      Various products use a wide range of different formats and
+      semantics for version strings.  Some use alphabetic characters,
+      white space, and punctuation.  Some consider version "1.21" to be
+      later than version "1.3" and some earlier.  Therefore, the syntax
+      and semantics of this string are not defined.
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 25]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   Build Num Len
+
+      This field defines the number of octets in the Internal Build
+      Number field.  For products where the internal build number is
+      unavailable or unknown, this field MUST be set to 0 and the
+      Internal Build Number field will be zero length (effectively not
+      present).
+
+   Internal Build Number
+
+      This field contains a UTF-8 string identifying the engineering
+      build number of the product.  This field MUST be sized to fit the
+      build number string and MUST NOT include extra octets for padding
+      or NUL character termination.  The syntax and semantics of this
+      string are not defined.
+
+   Config. Len
+
+      This field defines the number of octets in the Configuration
+      Version Number field.  If the configuration version number is
+      unavailable or unknown, this field MUST be set to 0 and the
+      Configuration 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
+
+
+
+Sangster & Narayan           Standards Track                   [Page 26]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   Anti-Spyware, this attribute would contain information about the
+   operational status of a host-based anti-spyware product that may or
+   may not be installed on the endpoint.
+
+   Posture Collectors that implement the IETF Standard PA Subtype for
+   Operating System or VPN MAY support sending this attribute type for
+   those PA subtypes.  Posture Collectors that implement other IETF
+   Standard PA Subtypes defined in this specification SHOULD support
+   sending this attribute type for those PA subtypes.  Other Posture
+   Collectors MAY support sending this attribute type.  Whether a
+   particular Posture Collector actually sends this attribute type
+   SHOULD still be governed by local privacy and security policies.
+   Posture Validators that implement the IETF Standard PA Subtype for
+   Operating System or VPN MAY support receiving this attribute type, at
+   least for those PA subtypes.  Posture Validators that implement other
+   IETF Standard PA Subtypes defined in this specification SHOULD
+   support receiving this attribute type, at least for those PA
+   subtypes.  Other Posture Validators MAY support receiving this
+   attribute type.  A Posture Validator that does not support receiving
+   this attribute type SHOULD simply ignore attributes with this type.
+   Posture Validators MUST NOT send this attribute type.
+
+   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
+   set to zero (0) and the PA-TNC Attribute Type field MUST be set to 5.
+   The value in the PA-TNC Attribute Length field MUST be 36.  If the
+   PA-TNC Attribute Length field does not have this value,
+   implementations SHOULD respond with an Invalid Parameter PA-TNC error
+   code.
+
+   The following diagram illustrates the format and contents of the
+   Attribute Value field for this attribute type.  The text after this
+   diagram describes the fields shown here.
+
+                        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)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 27]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   Status
+
+      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           Standards Track                   [Page 28]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      This field conforms to the date-time ABNF production from section
+      5.6 of RFC 3339 with the above restrictions.  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).  Note 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           Standards Track                   [Page 29]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 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 blocked and
+      non-blocked ports for a particular protocol.  To be more precise,
+      a Posture Collector MUST NOT include two Protocol/Port Number
+      pairs in a single Port Filter attribute where the protocol number
+      is the same but the B flag is different.  Also, Posture Collectors
+      MUST NOT list the same Protocol and Port Number combination twice
+      in a Port List attribute.
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 30]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      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 transport protocol number (e.g., tcp is 6)
+      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 the Assigned Internet Protocol Numbers
+      registry of these values for use in this field.
+
+   Port Number
+
+      This field contains the transport protocol (e.g., tcp) 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 well-known and user-requested TCP
+      and UDP port numbers for use in this field.
+
+4.2.7.  Installed Packages
+
+   This PA-TNC Attribute Type contains a list of the installed packages
+   that comprise a product on the endpoint that implements the component
+   specified in the PA Subtype field, as described in section 3.5.  This
+   allows a Posture Validator to check which packages are installed for
+   a particular product and which versions of those packages are
+   installed.
+
+   Posture Collectors that implement any of the IETF Standard PA
+   Subtypes defined in this document SHOULD support sending this
+   attribute type for those PA subtypes.  Other Posture Collectors MAY
+   support sending this attribute type, if it is appropriate to their PA
+   subtype.  Whether a particular Posture Collector actually sends this
+   attribute type SHOULD still be governed by local privacy and security
+   policies.  Posture Validators that implement any of the IETF Standard
+   PA Subtypes defined in this document SHOULD support receiving this
+   attribute type, at least for those PA subtypes.  Other Posture
+   Validators MAY support receiving this attribute type.  A Posture
+   Validator that does not support receiving this attribute type SHOULD
+   simply ignore attributes with this type.  Posture Validators MUST NOT
+   send this attribute type.
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 31]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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-length fields in the PA-TNC Attribute
+   Header and the fixed-length 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 protocol can support that many).  If this number
+   is not sufficient, specialized patch management software should be
+   employed that can simply report compliance with a pre-established
+   patch policy.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Reserved             |         Package Count         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Pkg Name Len  |        Package Name (Variable Length)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Version Len  |    Package Version Number (Variable Length)   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 32]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 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
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 33]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      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-length fields in the PA-TNC Attribute Header
+   and the fixed-length fields in this attribute type.
+
+   A PA-TNC error code SHOULD be sent with the same PA Message Vendor ID
+   and PA Subtype used by the PA-TNC message that caused the error so
+   that the error code is sent to the party who sent the offending PA-
+   TNC message.  Other measures (such as setting PB-TNC's EXCL flag and
+   Posture Collector Identifier or Posture Validator Identifier fields)
+   SHOULD also be taken to attempt to ensure that only the party who
+   sent the offending message receives the error.
+
+   When a PA-TNC error code is received, the recipient MUST NOT respond
+   with a PA-TNC error code because this could result in an infinite
+   loop of errors.  Instead, the recipient MAY log the error, modify its
+   behavior to attempt to avoid the error (attempting to avoid loops or
+   long strings of errors), ignore the error, terminate the assessment,
+   or take other action as appropriate (as long as it is consistent with
+   the requirements of this specification).
+
+   Posture Validators MUST NOT include this attribute type in an
+   Attribute Request attribute.  It does not make sense for a Posture
+   Validator to request that a Posture Collector send a PA-TNC Error
+   attribute.
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 34]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 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.
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 35]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      The following table lists the IETF Standard PA-TNC Error Codes
+      defined in this specification:
+
+      Integer   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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 36]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   The following diagram illustrates the format and contents of the
+   Error Information field for this error code.  The text after this
+   diagram describes the fields shown here.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Version    |            Copy of Reserved                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Message Identifier                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             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.
+
+   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.
+
+   Offset
+
+      This field MUST contain an octet offset from the start of the PA-
+      TNC Message Header of the PA-TNC message that caused this error to
+      the start of the value that caused this error.  For instance, if
+      the first PA-TNC attribute in the message had an invalid PA-TNC
+      Attribute Length (e.g., 0), this value would be 16.
+
+4.2.8.2.  Version Not Supported Error Code
+
+   The Version Not Supported error code is an IETF Standard PA-TNC Error
+   Code (value 2) that indicates that the sender of this error code does
+   not support the PA-TNC version number included in the PA-TNC Message
+   Header of a PA-TNC message sent by the recipient of this error code
+   in the current assessment.
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 37]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   For this error code, the Error Information field contains the first 8
+   octets of the PA-TNC message that contained the unsupported version
+   as well as Max Version and Min Version fields that indicate which PA-
+   TNC version numbers are supported by the sender of the error code.
+
+   The sender MUST support all PA-TNC versions between the Min Version
+   and the Max Version, inclusive (i.e., including the Min Version and
+   the Max Version).  When possible, recipients of this error code
+   SHOULD send future messages to the Posture Collector or Posture
+   Validator that originated this error message with a PA-TNC version
+   number within the stated range.
+
+   Any party that is sending the Version Not Supported error code MUST
+   include that error code as the only PA-TNC attribute in a PA-TNC
+   message with version number 1.  All parties that send PA-TNC messages
+   MUST be able to properly process a message that meets this
+   description, even if they cannot process any other aspect of PA-TNC
+   version 1.  This ensures that a PA-TNC version exchange can proceed
+   properly, no matter what versions of PA-TNC the parties implement.
+
+   The following diagram illustrates the format and contents of the
+   Error Information field for this error code.  The text after this
+   diagram describes the fields shown here.
+
+                        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.
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 38]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 39]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   The following diagram illustrates the format and contents of the
+   Error Information field for this error code.  The text after this
+   diagram describes the fields shown here.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Version    |            Copy of Reserved                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Message Identifier                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     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
+
+      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.
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 40]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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.
+
+                        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.
+
+
+
+Sangster & Narayan           Standards Track                   [Page 41]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+       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.
+
+4.2.10.  Remediation Instructions
+
+   This PA-TNC attribute sent by the Posture Validator to the Posture
+   Collector 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 than one
+   Remediation Instructions attribute 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 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)           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 42]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 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).
+
+      The following table lists the IETF Standard PA-TNC Remediation
+      Parameters Type values defined in this specification:
+
+      Integer   Description
+      -------   -----------
+      0         Reserved
+      1         Remediation URI
+      2         Remediation String
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 43]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      The next few subsections of this document provide detailed
+      definitions of the contents of the Remediation Parameters field
+      used with each Remediation Parameter Type.
+
+   Remediation Parameters (variable length)
+
+      The Remediation Parameters field contains the actual remediation
+      instructions for the Posture Collector.
+
+4.2.10.1.  Remediation URI Parameters Type
+
+   The Remediation URI Parameters Type is an IETF Standard Remediation
+   Parameters Type (value 1) that indicates that the sending Posture
+   Validator is providing a URI to instructions on how to remediate the
+   endpoint.
+
+   The following diagram illustrates the format and contents of the
+   Remediation Parameters field when carrying a Remediation URI
+   parameter.  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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Remediation URI (Variable Length)             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Remediation URI
+
+      The Remediation URI field MUST contain a URI, as described in RFC
+      3986 [7].  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.  Posture
+      Collectors should validate that the URI and instructions come from
+      a trustworthy source to avoid being tricked into performing
+      damaging actions (see security considerations).
+
+4.2.10.2.  Remediation String Parameters Type
+
+   The Remediation String Parameters Type is an IETF Standard
+   Remediation Parameters Type (value 2) that indicates that the sending
+   Posture Validator is providing a human-readable string containing
+   instructions on how to remediate the endpoint.
+
+   The following diagram illustrates the format and contents of the
+   Remediation Parameters field when the carrying a Remediation String
+   parameter.  The text after this diagram describes the fields shown
+   here.
+
+
+
+Sangster & Narayan           Standards Track                   [Page 44]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+                       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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Remediation String Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                Remediation String (Variable Length)           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Lang Code Len |  Remediation String Lang Code (Variable Len)  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Remediation String Length
+
+      The Remediation String Length contains the length of the
+      Remediation String field in octets.
+
+   Remediation String
+
+      The Remediation String field MUST contain a UTF-8 encoded string.
+      This string contains human-readable instructions for remediation
+      that MAY be displayed to the user by the Posture Collector.  NUL
+      termination MUST NOT be included.  If a Posture Collector receives
+      a Remediation String that does contain a NUL termination, it
+      SHOULD send an Invalid Parameter error code.
+
+   Lang Code Len (Remediation String Language Code Length)
+
+      The Lang Code Len field contains the length of the Remediation
+      String Language Code field in octets.
+
+   Remediation String Lang Code
+
+      The Remediation String Lang(uage) Code field contains a US-ASCII
+      string composed of a well-formed RFC 4646 [6] language tag that
+      indicates the language(s) used in the Remediation String in the
+      Remediation Parameters field.  A zero-length string MAY be sent
+      for this field (essentially omitting this field) to indicate that
+      the language code for the remediation string is not known.
+
+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
+
+
+
+Sangster & Narayan           Standards Track                   [Page 45]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 it is appropriate to their PA
+   Subtype.  Whether a particular Posture Collector actually sends this
+   attribute type SHOULD still be governed by local privacy and security
+   policies.  Posture Validators that implement the IETF Standard PA
+   Subtype for Operating System SHOULD support receiving the Forwarding
+   Enabled attribute type.  Posture Validators supporting components
+   other than Operating System MAY support receiving this attribute type
+   if it is appropriate to their PA Subtype.  A Posture Validator that
+   does not support receiving this attribute type SHOULD simply ignore
+   attributes with this type.  Posture Validators MUST NOT send this
+   attribute type.
+
+   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
+   set to zero (0) and the PA-TNC Attribute Type field MUST be set to
+   11.
+
+   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
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 46]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+4.2.12.  Factory Default Password Enabled
+
+   This PA-TNC attribute indicates whether the endpoint has a factory
+   default password enabled for use.  Some types of endpoints include a
+   default static password for used to gain privileged access to the
+   endpoint.  If this password is not changed or disabled before the
+   endpoint is accessible on the network, it's often easy to compromise
+   the endpoint.
+
+   Posture Collectors that implement the IETF Standard PA Subtype for
+   Operating System SHOULD support sending the Factory Default Password
+   Enabled attribute.  Posture Collectors that implement other IETF
+   Standard PA Subtypes defined in this specification SHOULD NOT support
+   sending this attribute type for those PA subtypes.  Other Posture
+   Collectors MAY support sending this attribute type, if it is
+   appropriate to their PA subtype.  Whether a particular Posture
+   Collector actually sends this attribute type SHOULD still be governed
+   by local privacy and security policies.  Posture Validators that
+   implement the IETF Standard PA Subtype for Operating System SHOULD
+   support receiving the Factory Default Password Enabled attribute.
+   Other Posture Validators MAY support receiving this attribute type.
+   A Posture Validator that does not support receiving this attribute
+   type SHOULD simply ignore attributes with this type.  Posture
+   Validators MUST NOT send this attribute type.
+
+   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
+   set to zero (0) and the PA-TNC Attribute Type field MUST be set to
+   12.
+
+   The following diagram illustrates the format and contents of the
+   Attribute Value field for this attribute type.  The text after this
+   diagram describes the fields shown here.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Factory Default Password Enabled                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Factory Default Password Enabled
+
+      This 32-bit field MUST contain one of the following values;
+
+      Value   Description
+      -----   -----------
+      0       Endpoint does not have factory default password enabled.
+
+      1       Endpoint has a factory default password enabled.
+
+
+
+Sangster & Narayan           Standards Track                   [Page 47]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+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 namespace collisions or misinterpretations.  In
+   order to avoid collisions, PA-TNC uses the well-established SMI
+   Private Enterprise Numbers as vendor IDs to define separate
+   namespaces 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 namespace 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 potential types of security threats
+   relevant to the PA-TNC message protocol.  It is envisioned that
+   additional attribute types could be defined in the future to
+   facilitate the exchange of security capabilities, keys, and security
+   protected attributes if future use cases are adopted that require
+   such protections.
+
+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.  The following subsections discuss the trust
+   properties associated with each portion of the NEA reference model
+   directly involved with the processing of the PA-TNC protocol.
+
+
+
+Sangster & Narayan           Standards Track                   [Page 48]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+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
+
+   o  Not send malicious remediation instructions that do not fix or
+      that cause damage to the endpoint
+
+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:
+
+   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
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 49]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   o  Not act maliciously to drop messages, duplicate messages, or flood
+      Posture Collectors and Posture Validators with unnecessary
+      messages
+
+   o  Not observe, fabricate, or alter the contents of a PA-TNC message
+
+   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
+      when requested
+
+   o  Properly expose authentication information from PT security so
+      that Posture Collectors and Posture Validators can use the peer's
+      identity information to safely 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 security countermeasures.
+
+   Generally, the PA-TNC protocol relies upon the underlying PT
+   protocol's security to protect the messages from attack when
+   traveling over the network.  Once the message resides on the Posture
+   Broker Client or Posture Broker Server, the posture brokers are
+   trusted to properly and safely deliver the messages to the
+   appropriate Posture Collectors and Posture Validators.
+
+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
+
+
+
+Sangster & Narayan           Standards Track                   [Page 50]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   financial gain.  Therefore, it is important that PT provide strong
+   confidentiality protection to protect the message from eavesdroppers
+   when being sent between the Posture Transport Client and Posture
+   Transport Server.
+
+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.  For example, an
+   adversary could attempt to send a falsified set of remediation
+   instructions using the Remediation URI support in hopes of the
+   Posture Collector automatically following the instructions.  Posture
+   Collectors need to ensure that any requests to take actions on the
+   endpoint (such as remediation instructions) received from Posture
+   Validators are authentic and trustworthy using strong authentication
+   and integrity protections offered by PT.  Posture Collectors should
+   not blindly follow remediation instructions received from a trusted
+   NEA Server.  At least for patches and other potentially dangerous
+   actions, Posture Collectors should validate these actions (e.g., via
+   user confirmation) before proceeding.
+
+   Such an attack could occur if an active attacker launches 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.
+   Therefore, it is important that PT provides strong authentication and
+   integrity protection.
+
+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 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
+
+
+
+Sangster & Narayan           Standards Track                   [Page 51]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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.  Use of a PT protocol providing strong
+   integrity protection and authentication is essential as
+   countermeasures to these attacks.
+
+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 posture 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.  Use of a PT protocol providing strong integrity protection
+   and authentication including a freshness exchange is necessary
+   countermeasure to these attacks.
+
+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 by the recipient.  For example, an attacker could add
+   attributes to the front of a PA-TNC message to cause an assessment to
+   succeed even for a non-compliant endpoint, particularly if it knew
+   that the recipient ignored repeated attributes within a message.
+   Similarly, if a Posture Collector or Posture Validator always
+   generated an error if it saw unexpected attributes, the attacker
+   could cause failures and denial of service by adding attributes or
+   messages to an exchange.  Use of a PT protocol providing strong
+   authentication and integrity protection could prevent the adversary
+   from inserting attributes into the assessment.
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 52]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+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 from untrusted
+   parties along the communication path between the Posture Collector
+   and Posture Validator.  Normally, the PT exchange is bidirectionally
+   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 sections 5.2.3 and
+   5.2.5.  Many potential denial-of-service examples exist, including
+   flooding messages to the 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 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.
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 53]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   Similarly, PA-TNC messages contain a set of attributes that 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 a 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 namespace 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 to
+   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 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
+
+
+
+Sangster & Narayan           Standards Track                   [Page 54]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 (in section
+   4.1), 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 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 permanently and publicly available.  IETF
+   standard values MUST also be useful, not harmful to the Internet, and
+   defined in a manner that is clear and likely to ensure
+   interoperability.
+
+   Designated experts should encourage vendors to avoid defining similar
+   but incompatible values and instead agree on a single IETF standard
+   value.  However, it is beneficial to document existing practice.
+
+
+
+Sangster & Narayan           Standards Track                   [Page 55]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   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 have been added to the PA Subtypes registry defined in the PB-
+   TNC specification.  Here is a list of these assignments:
+
+   PEN  Integer      Name               Defining Specification
+   ---  -------      ----               ----------------------
+    0     0          Testing                    RFC 5792
+    0     1          Operating System           RFC 5792
+    0     2          Anti-Virus                 RFC 5792
+    0     3          Anti-Spyware               RFC 5792
+    0     4          Anti-Malware               RFC 5792
+    0     5          Firewall                   RFC 5792
+    0     6          IDPS                       RFC 5792
+    0     7          VPN                        RFC 5792
+    0     8          NEA Client                 RFC 5792
+
+   These PA Subtypes have been added to the registry for PA Subtypes
+   defined in the PB-TNC specification, with this RFC as the reference.
+
+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.
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 56]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   The following entries for this registry are defined in this document.
+   They are 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   Integer    Name                 Defining Specification
+   ---   -------    ----                 ----------------------
+    0      0        Testing                      RFC 5792
+    0      1        Attribute Request            RFC 5792
+    0      2        Product Information          RFC 5792
+    0      3        Numeric Version              RFC 5792
+    0      4        String Version               RFC 5792
+    0      5        Operational Status           RFC 5792
+    0      6        Port Filter                  RFC 5792
+    0      7        Installed Packages           RFC 5792
+    0      8        PA-TNC Error                 RFC 5792
+    0      9        Assessment Result            RFC 5792
+    0     10        Remediation Instructions     RFC 5792
+    0     11        Forwarding Enabled           RFC 5792
+    0     12        Factory Default Password     RFC 5792
+                    Enabled
+    0 0xffffffff    Reserved                     RFC 5792
+
+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 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.
+   They are 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.
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 57]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+      PEN  Integer     Name                      Defining Specification
+      ---  -------     ----                      ----------------------
+       0     0         Reserved                          RFC 5792
+       0     1         Invalid Parameter                 RFC 5792
+       0     2         Version Not Supported             RFC 5792
+       0     3         Attribute Type Not Supported      RFC 5792
+
+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.
+   They are 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.
+
+   PEN   Integer   Name              Defining Specification
+   ---   -------   ----              ----------------------
+    0      0      Reserved                 RFC 5792
+    0      1      URI                      RFC 5792
+    0      2      Remediation String       RFC 5792
+
+8.  Acknowledgments
+
+   Thanks to the Trusted Computing Group for contributing the initial
+   text [8] upon which this document was based.  The authors would also
+   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.
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 58]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+         63, RFC 3629, November 2003.
+
+   [3]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
+
+   [4]   Klyne, G. and C. Newman, "Date and Time on the Internet:
+         Timestamps", RFC 3339, July 2002.
+
+   [5]   Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A
+         Posture Broker (PB) Protocol Compatible with Trusted Network
+         Connect (TNC)", RFC 5793, March 2010.
+
+   [6]   Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying
+         Languages", BCP 47, RFC 5646, September 2009.
+
+   [7]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+         January 2005.
+
+9.2.  Informative References
+
+   [8]   Trusted Computing Group, "IF-M: TLV Binding",
+         http://www.trustedcomputinggroup.org/resources/
+         tnc_ifm_tlv_binding_specification, February 2010.
+
+   [9]   Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
+         Tardo, "Network Endpoint Assessment (NEA): Overview and
+         Requirements", RFC 5209, June 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 59]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+Appendix A.  Use Cases
+
+A.1.  Initial Client-Triggered Assessment
+
+   This scenario involves the assessment of an endpoint initiated during
+   network join.  The assessment is triggered by the Posture Broker
+   Client (PBC) and involves collection of patch information from both
+   Standard Operating System (OS) Posture Collector and vendor-specific
+   Patch Posture Collector (PC).  The assessment by both the vendor-
+   specific Patch Posture Validator (PV) and Standard OS Posture
+   Validator result in a compliant assessment decision that results in a
+   compliant System Assessment Decision to be returned by the Posture
+   Broker Server (PBS).
+
+   +--------+ +-------+ +---------+ +--------+ +-------++--------+
+   | Vndr. X| |  Std. | |   Std.  | |  Std.  | | Std.  || Vndr. X|
+   |Patch PC| | OS PC | |   PBC   | |  PBS   | | OS PV ||Patch PV|
+   +--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
+      |         |   N/W Join|         |          |         |
+      |         |     ----->|         |          |         |
+      |         | Req Post. |         |          |         |
+      |         |<----------|         |          |         |
+      |         | Req Post. |         |          |         |
+      |<--------------------|         |          |         |
+      |Vndr X Patch Posture |         |          |         |
+      |-------------------->|         |          |         |
+      |         |OS Posture |         |          |         |
+      |         |---------->|         |          |         |
+      |         |           | Posture |          |         |
+      |         |           | Report  |          |         |
+      |         |           |-------->|          |         |
+      |         |           |         |  Verify  |         |
+      |         |           |         |  Posture |         |
+      |         |           |         |--------->          |
+      |         |           |         |          | Verify  |
+      |         |           |         |          | Posture |
+      |         |           |         |------------------->|
+      |         |           |         | OS Reslt |         |
+      |         |           |         |<---------|         |
+      |         |           |         | VndrX Patch Result |
+      |         |           | Assess  |<-------------------|
+      |         |           | Result  |                    |
+      |         |           |<--------|          |         |
+      |         | OS Reslt  |         |          |         |
+      |         |<----------|         |          |         |
+      | VndrX Patch Result  |         |          |         |
+      |<--------------------|         |          |         |
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 60]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.1.1.  Message Contents
+
+   This section shows the contents of the key fields in each of the PA
+   messages exchanged in this use case.  When necessary, additional
+   commentary is provided to explain why certain fields contain the
+   shown values.  Note that many of the flows shown are between
+   components on the same system so no message contents are shown.
+
+A.1.1.1.  N/W Join
+
+   This flow represents the event that causes the PBC to decide to start
+   an assessment of the endpoint in order to gain access to the network.
+   This is merely an event and does not include a message being sent.
+
+A.1.1.2.  Request Posture (Req Post.)
+
+   This flow illustrates an invocation of the OS and patch posture
+   collectors requesting particular posture attributes to be sent.
+   Because this use case is triggered locally, the contents of this flow
+   aren't specified by NEA.
+
+A.1.1.3.  Vendor X Patch Posture (VndrX Patch Posture)
+
+   This flow contains the PA message from the Patch Posture Collector:
+
+   Vendor X Patch Posture PA Message  {
+      Attribute HDR {Message ID}
+      Attribute 1 {
+         vendor-id=1 (vendor X)
+         type=1 (Vendor X namespace attribute)
+         length
+         Value = {
+            VendorXAttribute1=123
+         }
+      }
+      Attribute 2 {
+         vendor-id=1 (vendor X)
+         type=2 (Vendor X namespace attribute)
+         length
+         Value = {
+            VendorXAttribute2=456
+         }
+      }
+   }
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 61]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.1.1.4.  OS Posture
+
+   This flow contains the PA message from the OS Posture Collector:
+
+   OS Posture PA Message  {
+
+      Attribute HDR {Message ID}
+      Attribute 1 {
+         vendor-id=0
+         type=2 (product information)
+         length
+         Value = {
+            Product-vendor-id=311   -- Microsoft's PEN
+            Product-name="Windows Vista"
+         }
+      }
+      Attribute 2 {
+         vendor-id=0
+         type=3 (numeric version)
+         length
+         Value = {
+            major-version=6     -- Vista is version 6.0
+            minor-version=0
+            build-number=456789
+            service-pack-major=0   -- No service packs
+            service-pack-minor=0
+         }
+      }
+   }
+
+A.1.1.5.  Posture Report
+
+   This flow contains the PB message containing the PA messages from the
+   Patch and OS Posture Collectors; the message content is described in
+   the PB-TNC specification.
+
+A.1.1.6.  Verify Posture
+
+   This flow illustrates an invocation of the OS and patch Posture
+   Validators requesting verification of the posture attributes
+   received.  Because this flow happens locally within the NEA server,
+   NEA does not specify the message contents.
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 62]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.1.1.7.  OS Posture Result (OS Reslt)
+
+   This flow contains the PA message (Posture Assessment Result) from
+   the OS Posture Validator
+
+   OS Posture Result PA Message {
+      Attribute HDR {Message ID}
+         Attribute 1 {
+              vendor-id=0
+              type=9 (assessment-result)
+              length
+              Value = {
+                 assessment-result=0 (compliant)
+              }
+        }
+    }
+
+A.1.1.8.  Vendor X Patch Result (VndrX Patch Result)
+
+   This flow contains the PA message (Posture Assessment Result) from
+   the Vendor X Patch Posture Validator
+
+   Patch Vendor X Posture Result PA Message {
+      Attribute HDR {Message ID}
+         Attribute 1 {
+              vendor-id=0
+              type=9 (assessment-result)
+              length
+              Value = {
+                 assessment-result=0 (compliant)
+              }
+         }
+    }
+
+A.1.1.9.  Assessment Result (Assess Result)
+
+   This flow contains the PB message containing the system assessment
+   result computed by the Posture Broker Server and the PA messages from
+   the Patch and OS Posture Validators; the message content is described
+   in the PB-TNC specification.
+
+A.1.1.10.  Posture Result (OS PRslt & Vndr X Post PResult)
+
+   These flows illustrate an invocation of the OS and Vendor X Patch
+   Posture Collectors to receive the posture assessment results.
+   Because this flow is triggered locally, NEA does not specify the
+   contents of this flow.
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 63]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.2.  Server-Initiated Assessment with Remediation
+
+   This scenario involves the assessment of an endpoint initiated by the
+   NEA Server.  The assessment is triggered by the Posture Broker Server
+   and involves collection of Anti-Virus attributes for two Anti-Virus
+   components running on the endpoint.  The endpoint is assessed to be
+   compliant by one of the vendor (Vendor X) anti-virus Posture
+   Validators and non-compliant by the other vendor (Vendor Y) anti-
+   virus Posture Validator.  Based upon the Posture Broker Server's
+   policy, this results in a non-compliant system assessment decision to
+   be returned by the Posture Broker Server.  The Posture Broker Server
+   also returns remediation instructions for the endpoint as part of the
+   response.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 64]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   +--------+  +-------+ +---------+ +--------+ +-------+ +--------+
+   | Vndr Y |  | Vndr X| |   Std.  | |  Std.  | | Vndr X| | Vndr Y |
+   |  AV PC |  | AV PC | |   PBC   | |  PBS   | | AV PV | |  AV PV |
+   +----+---+  +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
+        |          |           | N/W Join|          |          |
+        |          |           | ------->|          |          |
+        |          |           |         |  Create  |          |
+        |          |           |         |Post. Req |          |
+        |          |           |         |--------->|          |
+        |          |           |         |Create Posture Req   |
+        |          |           |         |----------+--------->|
+        |          |           |         | Vndr Y AV Post Req  |
+        |          |           |         |<---------+----------|
+        |          |           |         |Vndr X AV |          |
+        |          |           |         |Post. Req |          |
+        |          |           | Posture |<---------|          |
+        |          |           | Request |          |          |
+        |          | Vndr X AV |<--------|          |          |
+        |          | Post. Req |         |          |          |
+        |          |<----------|         |          |          |
+        |      Vndr Y AV       |         |          |          |
+        |     Posture Req      |         |          |          |
+        +<---------+-----------|         |          |          |
+        |  Vndr Y AV Posture   |         |          |          |
+        +----------+---------->|         |          |          |
+        |          | Vndr X AV |         |          |          |
+        |          |  Posture  |         |          |          |
+        |          |---------->| Posture |          |          |
+        |          |           |Response |          |          |
+        |          |           |-------->|          |          |
+        |          |           |         |  Verify  |          |
+        |          |           |         |  Posture |          |
+        |          |           |         |--------->|          |
+        |          |           |         |     Verify Posture  |
+        |          |           |         |----------+--------->|
+        |          |           |         |Vndr Y AV Post Result|
+        |          |           |         |<---------+----------|
+        |          |           |         |Vndr X AV |          |
+        |          |           |         |Post Reslt|          |
+        |          |           |  Assess |<---------|          |
+        |          |           |  Result |          |          |
+        |          | Vndr X AV |<--------|          |          |
+        |          |Post Reslt |<--------|          |          |
+        |          |<----------|         |          |          |
+        | Vndr Y AV Post Reslt |         |          |          |
+        +<---------+-----------|         |          |          |
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 65]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.2.1.  Message Contents
+
+   This section shows the contents of the key fields in each of the PA
+   messages exchanged in this use case.  When necessary, additional
+   commentary is provided to explain why certain fields contain the
+   shown values.  Note that many of the flows shown are between
+   components on the same system so no message contents are shown.
+
+A.2.1.1.  N/W Join
+
+   This flow represents the event that causes the PBS to decide to start
+   an assessment of the endpoint in order to gain access to the network.
+   This is merely an event and does not include a message being sent.
+
+A.2.1.2.  Create Posture Request (Create Posture Req)
+
+   This flow illustrates an invocation of the Vendor X and Vendor Y
+   Anti-Virus Posture Validators enabling posture request attributes to
+   be created.  Because this use case is triggered locally, NEA does not
+   specify the contents of this flow.
+
+A.2.1.3.  Vendor Y AV Posture Request (Vndr Y AV Posture Req)
+
+   This flow contains the PA message (Posture Request) from the Vendor Y
+   Anti-Virus Posture Validator
+
+   Vendor Y AV Posture Request PA Message {
+       Attribute HDR {Message ID}
+          Attribute 1 {
+              vendor-id=0
+              type=1 (Attribute Request)
+              length
+              Value = {
+                 Vendor-id=0 (IETF Standard)
+                 Type=2 (Standard attribute, Product-Information)
+                 Vendor-id=1 (Vendor Y)
+                 Type=2 (Vendor Y attribute, Extended-Dat-Version)
+               }
+          }
+   }
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 66]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.2.1.4.  Vendor X AV Posture Request (Vndr X AV Post. Req)
+
+   This flow contains the PA message (Posture Request) from the Vendor X
+   Anti-Virus Posture Validator
+
+   Vendor X AV Posture Request PA Message {
+       Attribute HDR {Message ID}
+          Attribute 1 {
+              vendor-id=0
+              type=1 (Attribute Request)
+              length
+              Value = {
+                 Vendor-id=1 (Vendor X)
+                 Type=1 (Vendor X attribute, Scan-Engine-Version)
+                 Vendor-id=0 (IETF Standard)
+                 Type=5 (Standard, Operational-Status)
+              }
+          }
+    }
+
+A.2.1.5.  Posture Request
+
+   This flow contains the PB message containing the PA messages from the
+   Vendor X and Vendor Y Anti-Virus Posture Validators; the message
+   content is described in the PB-TNC specification.
+
+A.2.1.6.  Posture Request (Vndr X AV Post Req & Vndr Y AV Post Req)
+
+   These flows illustrate an invocation of the Vendor X and Vendor Y
+   Anti-Virus Posture Collectors to process the Posture Request and
+   return the particular posture attributes requested.  Because this
+   flow is triggered locally, NEA does not specify the contents of this
+   flow.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 67]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.2.1.7.  Vendor Y AV Posture (Vndr Y AV Posture)
+
+   This flow contains the PA message (response to the Posture Request)
+   from the Vendor Y Anti-Virus Posture Collector.
+
+   Vendor Y AV Posture PA Message {
+     Attribute HDR {Message ID}
+         Attribute 1 {
+            vendor-id=0 (IETF Standard)
+            Type=2 (Standard attribute, Product-Information)
+            length
+            Value = {
+               product-vendor-id=12345 (vendor Y)
+               product-id=987 (AV product id from vendor Y)
+               product-name="Vendor Y Anti-Virus"
+            }
+         }
+         Attribute 2 {
+            vendor-id=2 (vendor Y)
+            type=2 (vendor Y attribute, DAT-Version)
+            length
+            Value = {
+               DAT-version=5678
+            }
+         }
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 68]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.2.1.8.  Vendor X AV Posture (Vndr X AV Posture)
+
+   This flow contains the PA message (response to the Posture Request)
+   from the Vendor X Anti-Virus Posture Collector.
+
+   Vendor X AV Posture PA Message {
+      Attribute HDR {Message ID}
+         Attribute 1 {
+            vendor-id=1
+            type=1 (vendor X attribute, Scan-Engine-Version)
+            length
+            Value = {
+               scan-engine-version=1234
+            }
+         }
+         Attribute 2 {
+            vendor-id=0 (IETF Standard)
+            type=5 (Standard, Operational-Status)
+            length
+            Value = {
+               status=2 (installed but non-operational)
+               result=0 (unknown)
+               last use="" (never used)
+             }
+         }
+     }
+
+A.2.1.9.  Posture Response
+
+   This flow contains the PB message containing the PA messages from the
+   Vendor X and Vendor Y Anti-Virus Posture Collectors; the message
+   content is described in the PB-TNC specification.
+
+A.2.1.10.  Verify Posture
+
+   This flow illustrates an invocation of the Vendor X and Vendor Y
+   Anti-Virus Posture Validators requesting verification of the posture
+   attributes received.  Because this flow happens locally within the
+   NEA server, NEA does not specify the message contents.
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 69]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.2.1.11.  Vendor Y AV Posture Result (Vndr Y AV Post Result)
+
+   This flow contains the PA message (Posture Assessment Result) from
+   the Vendor Y Anti-Virus Posture Validator
+
+   Vendor Y AV Posture Result PA Message {
+      Attribute HDR {Message ID}
+        Attribute 1 {
+           vendor-id=0
+           type=9 (assessment-result)
+           length
+           Value = {
+              assessment-result=0 (compliant)
+           }
+        }
+     }
+
+A.2.1.12.  Vendor X AV Posture Result (Vndr X AV Post Reslt)
+
+   This flow contains the PA message (Posture Assessment Result) from
+   the Vendor X Anti-Virus Posture Validator
+
+   Vendor X AV Posture Result PA Message {
+       Attribute HDR {Message ID}
+         Attribute 1 {
+            vendor-id=0
+            type=9 (assessment-result)
+            length
+            Value = {
+               assessment-result=1 (non-compliant)
+            }
+         }
+    }
+
+A.2.1.13.  Assessment Result (Assess Result)
+
+   This flow contains the PB message containing the system assessment
+   result computed by the Posture Broker Server and the PA messages from
+   the Vendor X and Vendor Y Anti-Virus Posture Validators; the message
+   content is described in the PB-TNC specification.
+
+A.2.1.14.  Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post Reslt)
+
+   These flows illustrate an invocation of the Vendor X and Vendor Y
+   Anti-Virus Posture Collectors to receive the posture assessment
+   results.  Because this flow is triggered locally, NEA does not
+   specify the contents of this flow.
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 70]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.3.  Client-Triggered Reassessment
+
+   This scenario involves the reassessment of an endpoint as a result of
+   enabling a software component on the endpoint.  The endpoint has two
+   VPN client software components, one from vendor X for the user's home
+   network and other from vendor Y for the network that the endpoint is
+   currently accessing.  The assessment is triggered when the user tries
+   to use the Vendor X VPN client; this is a violation of the assessment
+   policy.  The Posture Broker Client triggers the posture assessment
+   when it receives a notification from the VPN Posture Collector about
+   the change to the operational state of the VPN component on the
+   endpoint.  Note that the VPN Posture Collector may support standard
+   attributes and some vendor-defined attributes from vendor X's and
+   vendor Y's namespaces.  This use case does not leverage vendor-
+   defined attributes.  The assessment involves verification of the
+   standard VPN posture attributes by the standard VPN Posture Validator
+   that results in a non-compliant assessment result.
+
+   This use case relies on the use of multiple Posture Collector IDs for
+   a single Posture Collector as described in section 3.3 of the PA-TNC
+   specification.  In this example, the Posture Collector will obtain
+   two Posture Collector IDs to a single Posture Collector (Standard VPN
+   PC) and the Posture Collector will generate two separate PA messages
+   each using a different ID to report the posture for Vendor X and
+   Vendor Y VPN Clients.  The Posture Broker Client will associate the
+   assigned IDs in the PB message sent to the NEA Server.  This entire
+   behavior will be completely opaque to the NEA Server, which will
+   handle the PB message as if there were two VPN Posture Collectors on
+   the NEA Client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 71]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   +--------+  +-------+ +---------+ +--------+ +--------+ +--------+
+   |Vndr X  |  |Vndr Y | |Standard | |Standard| |Standard| |Standard|
+   |VPNClnt |  |VPNClnt| | VPN PC  | |  PBC   | |  PBS   | | VPN PV |
+   +----+---+  +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
+   Enble|          |           |         |          |           |
+   ---->|          |           |         |          |           |
+        |  VPN Status Change   |         |          |           |
+        |--------------------->| Posture |          |           |
+        |          |           | Change  |          |           |
+        |          |           |-------->|          |           |
+        |          |           |Req. Post|          |           |
+        |          |           |<--------|          |           |
+        |          |Ins/Rq Info|         |          |           |
+        |          |<----------|         |          |           |
+        | Inspect/Request Info |         |          |           |
+        |<---------+-----------|VPNX Post|          |           |
+        |          |           |-------->|          |           |
+        |          |           |VPNY Post|          |           |
+        |          |           |-------->|          |           |
+        |          |           |         | Posture  |           |
+        |          |           |         |  Report  |           |
+        |          |           |         |--------->|           |
+        |          |           |         |          |Vrfy Post. |
+        |          |           |         |          |---------->|
+        |          |           |         |          |VPN PRslt  |
+        |          |           |         |  Assess  |<----------|
+        |          |           |         |  Result  |           |
+        |          |           |         |<---------|           |
+        |          |           |VPN PRslt|          |           |
+        |          |           |<--------|          |           |
+
+A.3.1.  Message Contents
+
+   This section shows the contents of the key fields in each of the PA
+   messages exchanged in this use case.  When necessary, additional
+   commentary is provided to explain why certain fields contain the
+   shown values.  Note that many of the flows shown are between
+   components on the same system so no message contents are shown.
+
+A.3.1.1.  Enable VPN Client (Enble)
+
+   This flow represents the end user triggered event of starting the VPN
+   Client software from Vendor X.  This is merely an event and does not
+   include a message being sent.
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 72]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.3.1.2.  Notify Status Change (VPN Status Change)
+
+   This flow represents the detection of the active state of the Vendor
+   X VPN Client software by the VPN Posture Collector.  This is merely
+   an event and does not include a message being sent.
+
+A.3.1.3.  Notify Posture Change (Posture Change)
+
+   This flow represents the notification of the VPN posture change sent
+   from the VPN Posture Collector to the Standard Posture Broker Client.
+   This is merely an event and does not include a message being sent.
+
+A.3.1.4.  Request Posture (Req. Post)
+
+   This flow illustrates an invocation of the VPN Posture Collector
+   requesting particular posture attributes to be sent.  Because this
+   use case is triggered locally, NEA does not specify the contents of
+   this flow.
+
+A.3.1.5.  Inspect/Request Info (Ins/Rq Info)
+
+   This flow illustrates the acquisition of the posture information by
+   the VPN Posture Collector from the Vendor X and Vendor Y VPN Client
+   components.  Because this flow is triggered locally, NEA does not
+   specify the message contents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 73]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.3.1.6.  Vendor X VPN Posture (VPNX Post)
+
+   This flow contains the PA message from the VPN Posture Collector
+   describing the Vendor X VPN Client's posture:
+
+   Vendor X VPN Posture PA Message{
+      Attribute HDR {Message ID}
+        Attribute 1 {
+              vendor-id=0
+              type=2 (product information)
+              length
+              Value = {
+                 product-vendor-id=9876 (vendor X)
+                 product-id=567 (VPN client identifier for Vndr X)
+                 product-name="Vendor X VPN Client"
+               }
+         }
+         Attribute 2 {
+              vendor-id=0
+              type=5 (operational status)
+              length
+              Value = {
+                 Status=3 (Operational)
+                 Result=1 (Successful use with no errors detected)
+                 last Use="2008-07-07T12:00:00Z"
+              }
+         }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 74]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.3.1.7.  Vendor Y VPN Posture (VPNY Post)
+
+   This flow contains the PA message from the VPN Posture Collector
+   including the Vendor Y VPN Client's posture:
+
+   Vendor Y VPN Posture PA Message{
+      Attribute HDR {Message ID}
+          Attribute 1 {
+              vendor-id=0
+              type=2 (product information)
+              length
+              Value = {
+                 product-vendor-id=Vendor Y
+                 product-id=234 (VPN client identifier for Vndr Y)
+                 product-name="Vendor Y VPN Client"
+               }
+         }
+         Attribute 2 {
+              vendor-id=0
+              type=5 (operational status)
+              length
+              Value = {
+                Status=3 (Operational)
+                Result=1 (Successful use with no errors detected)
+                last Use="2008-07-07T14:05:00Z"
+              }
+         }
+   }
+
+A.3.1.8.  Posture Report
+
+   This flow contains the PB message containing the PA message from the
+   VPN Posture Collector; the message content is described in the PB-TNC
+   specification.
+
+A.3.1.9.  Verify Posture (Vrfy Post.)
+
+   This flow illustrates an invocation of the VPN Posture Validator
+   requesting verification of the posture attributes received.  Because
+   this flow happens locally within the NEA Server, NEA does not specify
+   the message contents.
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 75]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+A.3.1.10.  VPN Posture Result (VPN PRslt)
+
+   This flow contains the PA message (Posture Assessment Result) from
+   the VPN Posture Validator
+
+   VPN Posture Result PA Message {
+      Attribute HDR {Message ID}
+         Attribute 1 {
+              vendor-id=0
+              type=9 (assessment-result)
+              length
+              Value = {
+                 assessment-result=1 (non-compliant)
+              }
+         }
+    }
+
+A.3.1.11.  Assessment Result (Assess Result)
+
+   This flow contains the PB message containing the system assessment
+   result computed by the Posture Broker Server and the PA messages from
+   the VPN Posture Validator; the message content is described in the
+   PB-TNC specification.
+
+A.3.1.12.  Posture Result (VPN PRslt)
+
+   This flow illustrates an invocation of the VPN Posture Collector to
+   receive the posture assessment result.  Because this flow is
+   triggered locally, NEA does not specify the contents of this flow.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 76]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+Appendix B.  Evaluation against NEA Requirements
+
+   This section evaluates the PA-TNC protocol against the requirements
+   defined in the NEA Requirements document.  Each subsection considers
+   a separate requirement from the NEA Requirements document.  Only
+   common requirements (C-1 through C-10) and PA requirements (PA-1
+   through PA-6) are considered, since these are the only ones that
+   apply to PA.
+
+B.1.  Evaluation against Requirement C-1
+
+   Requirement C-1 says:
+
+   C-1   NEA protocols MUST support multiple round trips between the NEA
+   Client and NEA Server in a single assessment.
+
+   PA-TNC meets this requirement.  It allows an unlimited number of
+   round trips between the NEA Client and NEA Server.
+
+B.2.  Evaluation against Requirement C-2
+
+   Requirement C-2 says:
+
+   C-2   NEA protocols SHOULD provide a way for both the NEA Client and
+   the NEA Server to initiate a posture assessment or reassessment as
+   needed.
+
+   PA-TNC meets this requirement.  PA-TNC is designed to work whether
+   the NEA Client or the NEA Server initiates a posture assessment or
+   reassessment.
+
+B.3.  Evaluation against Requirement C-3
+
+   Requirement C-3 says:
+
+   C-3   NEA protocols including security capabilities MUST be capable
+   of protecting against active and passive attacks by intermediaries
+   and endpoints including prevention from replay-based attacks.
+
+   Security for PA-TNC messages being sent over the network is provided
+   through PT protocol security.  Therefore, PA-TNC does not include any
+   security capabilities.  Since this requirement only applies to NEA
+   protocols "including security capabilities", this specification is
+   not subject to this requirement (see section 5.2).
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 77]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+B.4.  Evaluation against Requirement C-4
+
+   Requirement C-4 says:
+
+   C-4   The PA and PB protocols MUST be capable of operating over any
+   PT protocol.  For example, the PB protocol must provide a transport-
+   independent interface allowing the PA protocol to operate without
+   change across a variety of network protocol environments (e.g.,
+   EAP/802.1X, PANA, TLS and IKE/IPsec).
+
+   PA-TNC meets this requirement.  PA-TNC can operate over any PT
+   protocol that meets the requirements for PT stated in the NEA
+   Requirements document.  PA-TNC does not have any dependencies on
+   specific details of the underlying PT protocol.
+
+B.5.  Evaluation against Requirement C-5
+
+   Requirement C-5 says:
+
+   C-5   The selection process for NEA protocols MUST evaluate and
+   prefer the reuse of existing open standards that meet the
+   requirements before defining new ones.  The goal of NEA is not to
+   create additional alternative protocols where acceptable solutions
+   already exist.
+
+   Based on this requirement, PA-TNC should receive a strong preference.
+   PA-TNC is equivalent with IF-M 1.0, an open TCG specification.  Other
+   specifications from TCG and other groups are also under development
+   based on the IF-M 1.0 specification.  Selecting PA-TNC as the basis
+   for the PA protocol will ensure compatibility with IF-M 1.0, with
+   these other specifications, and with their implementations.
+
+B.6.  Evaluation against Requirement C-6
+
+   Requirement C-6 says:
+
+   C-6   NEA protocols MUST be highly scalable; the protocols MUST
+   support many Posture Collectors on a large number of NEA Clients to
+   be assessed by numerous Posture Validators residing on multiple NEA
+   Servers.
+
+   PA-TNC meets this requirement.  PA-TNC supports an unlimited number
+   of Posture Collectors, Posture Validators, NEA Clients, and NEA
+   Servers.  It also is quite scalable in many other aspects as well.  A
+   PA-TNC message can contain up to 2^32-1 octets and about 2^28 PA-TNC
+   attributes.  Each organization with an SMI Private Enterprise Number
+   is entitled to define up to 2^32 vendor-specific PA-TNC Attribute
+   Types, 2^16 vendor-specific PA-TNC Product IDs, and 2^32 vendor-
+
+
+
+Sangster & Narayan           Standards Track                   [Page 78]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   specific PA-TNC Error Codes.  Each attribute can contain almost 2^32
+   octets.  It is generally not advisable or necessary to send this much
+   data in a NEA assessment, but still PA-TNC is highly scalable and
+   meets requirement C-6 easily.
+
+B.7.  Evaluation against Requirement C-7
+
+   Requirement C-7 says:
+
+   C-7   The protocols MUST support efficient transport of a large
+   number of attribute messages between the NEA Client and the NEA
+   Server.
+
+   PA-TNC meets this requirement.  Each PA-TNC message can contain about
+   2^28 PA-TNC attributes.  PA-TNC supports up to 2^32 round trips in a
+   session so the maximum number of attribute messages that can be sent
+   in a single session is actually about 2^50.  However, it is generally
+   inadvisable and unnecessary to send a large number of messages in a
+   NEA assessment.  As for efficiency, PA-TNC adds only 12 octets of
+   overhead per attribute and 8 octets per message (which is negligible
+   on a per-attribute basis).
+
+B.8.  Evaluation against Requirement C-8
+
+   Requirement C-8 says:
+
+   C-8   NEA protocols MUST operate efficiently over low bandwidth or
+   high latency links.
+
+   PA-TNC meets this requirement.  A PA-TNC exchange is envisioned
+   (based on current deployment experience) to involve one or two round
+   trips with less than 500 octets of PA-TNC messages.  Of course, use
+   of vendor-specific PA-TNC attribute types could expand the
+   assessment.  However, PA-TNC itself imposes an overhead of only 8
+   octets per PA-TNC message and 12 octets per attribute.
+
+B.9.  Evaluation against Requirement C-9
+
+   Requirement C-9 says:
+
+   C-9   For any strings intended for display to a user, the protocols
+   MUST support adapting these strings to the user's language
+   preferences.
+
+   PA-TNC meets this requirement.  The only field included in a PB-TNC
+   attribute for display to the user includes a language tag that could
+   be selected based upon the user's PB-TNC negotiated preferred
+   language for the assessment (see section 4.10 of the PB-TNC
+
+
+
+Sangster & Narayan           Standards Track                   [Page 79]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   specification).  With this exception, all of the strings in the
+   standard PA-TNC attributes are intended for logging and programmatic
+   comparisons.
+
+   If any vendor-specific PA-TNC attribute types or future IETF Standard
+   PA-TNC Attribute Types include strings that are intended for display
+   to a user, they should be translated to the user's preferred
+   language.  The Posture Broker Server will need to expose the user's
+   preferences to the Posture Validators through whatever API or
+   protocol is used to connect those components.  However, that is all
+   out of scope for this specification.
+
+B.10.  Evaluation against Requirement C-10
+
+   Requirement C-10 says:
+
+   C-10  NEA protocols MUST support encoding of strings in UTF-8 format.
+
+   PA-TNC meets this requirement.  All strings in the PA-TNC protocol
+   are encoded in UTF-8 format.  This allows the protocol to support a
+   wide range of languages efficiently.
+
+B.11.  Evaluation against Requirement C-11
+
+   Requirement C-11 says:
+
+   C-11  Due to the potentially different transport characteristics
+   provided by the underlying candidate PT protocols, the NEA Client and
+   NEA Server MUST be capable of becoming aware of and adapting to the
+   limitations of the available PT protocol.  For example, some PT
+   protocol characteristics that might impact the operation of PA and PB
+   include restrictions on which end can initiate a NEA connection,
+   maximum data size in a message or full assessment, upper bound on
+   number of round trips, and ordering (duplex) of messages exchanged.
+   The selection process for the PT protocols MUST consider the
+   limitations the candidate PT protocol would impose upon the PA and PB
+   protocols.
+
+   PA-TNC meets this requirement.  The design of the PA-TNC protocol
+   emphasizes efficient transport of information in order to maximize
+   its usability in constrained PT environments.  Local APIs could allow
+   Posture Collectors and Posture Validators to discover when they are
+   operating in a less constrained deployment and then make use of more
+   verbose attributes.  Similarly, Posture Collectors could choose not
+   to send or use smaller attributes (including assertions from previous
+   assessments) when faced with a very constrained network connection.
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 80]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+B.12.  Evaluation against Requirement PA-1
+
+   Requirement PA-1 says:
+
+   PA-1  The PA protocol MUST support communication of an extensible set
+   of NEA standards-defined attributes.  These attributes will be
+   uniquely identifiable from non-standard attributes.
+
+   PA-TNC meets this requirement.  Each attribute is identified with a
+   PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.  IETF
+   Standard PA-TNC Attribute Types use a vendor ID of zero (0), in
+   contrast with vendor-specific PA-TNC Attribute Types, which will use
+   the vendor's SMI Private Enterprise Number as the vendor ID.  The
+   IANA will maintain a registry of PA-TNC Attribute Types with new
+   values added by Expert Review with Specification Required, as
+   described in the IANA Considerations section of this specification.
+   Thus, the set of standard attribute types is extensible, but all
+   standard attribute types are uniquely identifiable.
+
+B.13.  Evaluation against Requirement PA-2
+
+   Requirement PA-2 says:
+
+   PA-2  The PA protocol MUST support communication of an extensible set
+   of vendor-specific attributes.  These attributes will be segmented
+   into uniquely identifiable vendor-specific namespaces.
+
+   PA-TNC meets this requirement.  Each attribute is identified with a
+   PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.  Vendor-
+   defined PA-TNC Attribute Types use the vendor's SMI Private
+   Enterprise Number as the PA-TNC Attribute Vendor ID.  Each vendor can
+   define up to 2^32 PA-TNC Attribute Types, using its own internal
+   processes to manage its set of attribute types.
+
+   The IANA is not involved, other than the initial assignment of the
+   vendor's SMI Private Enterprise Number.  Thus, the set of vendor-
+   specific attributes is segmented into uniquely identifiable vendor-
+   specific namespaces.
+
+B.14.  Evaluation against Requirement PA-3
+
+   Requirement PA-3 says:
+
+   PA-3  The PA protocol MUST enable a Posture Validator to make one or
+   more requests for attributes from a Posture Collector within a single
+   assessment.  This enables the Posture Validator to reassess the
+   posture of a particular endpoint feature or to request additional
+   posture including from other parts of the endpoint.
+
+
+
+Sangster & Narayan           Standards Track                   [Page 81]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   PA-TNC meets this requirement.  The Attribute Request attribute type
+   is an IETF Standard PA-TNC Attribute Type that permits a Posture
+   Validator to send to one or more Posture Collectors a request for one
+   or more attributes.  This attribute may be sent at any point in the
+   posture assessment process and may in fact be sent more than once if
+   the Posture Validator needs to first determine the type of operating
+   system and then request certain attributes specific to that operating
+   system, for example.
+
+B.15.  Evaluation against Requirement PA-4
+
+   Requirement PA-4 says:
+
+   PA-4  The PA protocol MUST be capable of returning attributes from a
+   Posture Validator to a Posture Collector.  For example, this might
+   enable the Posture Collector to learn the specific reason for a
+   failed assessment and to aid in remediation and notification of the
+   system owner.
+
+   PA-TNC meets this requirement.  A Posture Validator can easily send
+   attributes to one or more Posture Collectors.
+
+B.16.  Evaluation against Requirement PA-5
+
+   Requirement PA-5 says:
+
+   PA-5  The PA protocol SHOULD provide authentication, integrity, and
+   confidentiality of attributes communicated between a Posture
+   Collector and Posture Validator.  This enables end-to-end security
+   across a NEA deployment that might involve traversal of several
+   systems or trust boundaries.
+
+   PA-TNC does not include an explicit PA-level security mechanism but
+   does lay a foundation allowing attribute-level security protections
+   to be added later.  As an existence proof, the NEA working group
+   considered an Internet-Draft proposal capable of encapsulating PA
+   attributes within a Cryptographic Message Syntax (CMS) security
+   wrapper in a new attribute type.  This proposal offered the
+   protections described in this requirement.  However, the NEA WG
+   decided that the use cases in scope for the working group did not
+   require PA-level security.  The use cases involving PA message
+   traversal of multiple systems or trust boundaries were considered out
+   of scope; therefore, a Posture Validator to Posture Collector end-to-
+   end security protection was considered not to be required.
+
+   Instead, PA-TNC attributes are protected by the PT layer
+   authentication, integrity, and confidentiality support.  This
+   protects the attributes communicated between the Posture Transport
+
+
+
+Sangster & Narayan           Standards Track                   [Page 82]
+
+RFC 5792                         PA-TNC                       March 2010
+
+
+   Client and Posture Transport Server.  Because the Posture Collector
+   is in the same address space as the Posture Broker Client and Posture
+   Transport Client and the Posture Validator is in the same address
+   space as the Posture Broker Server and Posture Transport Server, the
+   underlying broker and transport components are deemed trusted with
+   respect to not tampering with the PA messages (see trust model in
+   section 5.1 for details).  Encrypting the PA-TNC messages would not
+   prevent a hostile broker or transport component from attacking the
+   messages.
+
+B.17.  Evaluation against Requirement PA-6
+
+   Requirement PA-6 says:
+
+   PA-6  The PA protocol MUST be capable of carrying attributes that
+   contain non-binary and binary data including encrypted content.
+
+   PA-TNC meets this requirement.  PA-TNC attributes can contain non-
+   binary and binary data including encrypted content.  For examples,
+   see the attribute type definitions contained in this specification.
+
+Authors' Addresses
+
+   Paul Sangster
+   Symantec Corporation
+   6825 Citrine Drive
+   Carlsbad, CA 92009
+   USA
+   EMail: Paul_Sangster@symantec.com
+
+   Kaushik Narayan
+   Cisco Systems Inc.
+   10 West Tasman Drive
+   San Jose, CA 95134
+   USA
+   EMail: kaushik@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangster & Narayan           Standards Track                   [Page 83]
+