Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5792

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

Pages: 83
Proposed Standard
Errata
Part 1 of 4 – Pages 1 to 13
None   None   Next

Top   ToC   RFC5792 - 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.
Top   ToC   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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   RFC5792 - 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 Section