tech-invite   World Map     

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

RFC 5792

 Errata 
Proposed STD
Pages: 83
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: NEA

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

Part 1 of 4, p. 1 to 13
None       Next RFC Part

 


Top       ToC       Page 1 
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.

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

Top      ToC       Page 3 
           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

Top      ToC       Page 4 
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-

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
   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).

Top      ToC       Page 7 
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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
   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

Top      ToC       Page 11 
   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

Top      ToC       Page 12 
   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.

Top      ToC       Page 13 
   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.



(page 13 continued on part 2)

Next RFC Part