[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-sangster-nea-pa-tnc) 00 01 02 03 04 05 06 RFC 5792

  Network Working Group                                   P. Sangster
  Internet Draft                                 Symantec Corporation
  Intended status: Proposed Standard                   April 11, 2008
  Expires: October 2008
  
  
      PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC
                      draft-ietf-nea-pa-tnc-00.txt
  
  
  Status of this Memo
  
     By submitting this Internet-Draft, each author represents that
     any applicable patent or other IPR claims of which he or she is
     aware have been or will be disclosed, and any of which he or she
     becomes aware will be disclosed, in accordance with Section 6 of
     BCP 79.
  
     Internet-Drafts are working documents of the Internet
     Engineering Task Force (IETF), its areas, and its working
     groups.  Note that other groups may also distribute working
     documents as Internet-Drafts.
  
     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as "work
     in progress."
  
     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt
  
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html
  
     This Internet-Draft will expire on October 5, 2008.
  
  Copyright Notice
  
     Copyright (C) The IETF Trust (2008).
  
  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.
  
  
  
  
  Sangster               Expires October 5, 2008            [Page 1]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  Conventions used in this document
  
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described
     in RFC 2119 [1].
  
  Table of Contents
  
     1. Introduction.............................................. 3
        1.1. Background on Trusted Computing Group................ 3
        1.2. Background on Trusted Network Connect................ 4
        1.3. Submission of This Document.......................... 4
        1.4. Prerequisites........................................ 4
        1.5. Message Diagram Conventions.......................... 5
     2. PA-TNC Message Protocol................................... 5
        2.1. PA-TNC Messaging Model............................... 5
        2.2. PA-TNC Relationship to PB-TNC........................ 6
        2.3. PA-TNC Messages in PB-TNC............................ 8
        2.4. IETF Standard PA Subtypes............................ 9
        2.5. PA-TNC Message Header Format.........................10
     3. PA-TNC Attributes.........................................11
        3.1. PA-TNC Attribute Header..............................12
        3.2. IETF Standard PA-TNC Attribute Types.................16
           3.2.1. Attribute Request...............................17
           3.2.2. Product Information.............................19
           3.2.3. Numeric Version.................................21
           3.2.4. String Version..................................24
           3.2.5. Operational Status..............................26
           3.2.6. Port Filter.....................................29
           3.2.7. Installed Packages..............................31
           3.2.8. PA-TNC Error....................................34
              3.2.8.1. Definition of Invalid Parameter Error Code 36
              3.2.8.2. Definition of Version Not Supported Error
              Code................................................37
              3.2.8.3. Definition of Attribute Type Not Supported
              Error Code..........................................39
        3.3. Vendor-Defined Attributes............................41
     4. Evaluation Against NEA Requirements.......................41
        4.1. Evaluation Against Requirement C-1...................41
        4.2. Evaluation Against Requirement C-2...................42
        4.3. Evaluation Against Requirement C-3...................42
        4.4. Evaluation Against Requirement C-4...................42
        4.5. Evaluation Against Requirement C-5...................43
        4.6. Evaluation Against Requirement C-6...................43
        4.7. Evaluation Against Requirement C-7...................43
        4.8. Evaluation Against Requirement C-8...................44
  
  
  Sangster               Expires October 5, 2008            [Page 2]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        4.9. Evaluation Against Requirement C-9...................44
        4.10. Evaluation Against Requirement C-10 ................45
        4.11. Evaluation Against Requirement PA-1 ................45
        4.12. Evaluation Against Requirement PA-2 ................45
        4.13. Evaluation Against Requirement PA-3 ................46
        4.14. Evaluation Against Requirement PA-4 ................46
        4.15. Evaluation Against Requirement PA-5 ................46
        4.16. Evaluation Against Requirement PA-6 ................47
     5. Security Considerations...................................47
        5.1. Trust Relationships..................................48
           5.1.1. Posture Collector...............................48
           5.1.2. Posture Validator...............................48
           5.1.3. Posture Broker Client, Posture Broker Server, and
           PB-TNC.................................................49
        5.2. Security Threats.....................................49
           5.2.1. Attribute Theft.................................50
           5.2.2. Message Fabrication.............................50
           5.2.3. Attribute Modification..........................51
           5.2.4. Attribute Replay................................51
           5.2.5. Attribute Insertion.............................51
           5.2.6. Denial of Service...............................52
     6. Privacy Considerations....................................52
     7. IANA Considerations.......................................54
        7.1. New IETF Standard PA Subtypes........................54
        7.2. Registry for IETF Standard PA-TNC Attribute Types....54
        7.3. Registry for IETF Standard PA-TNC Error Codes........55
     8. Acknowledgments ..........................................56
     9. References ...............................................56
        9.1. Normative References ................................56
        9.2. Informative References...............................56
     Author's Address.............................................57
     Intellectual Property Statement..............................57
     Disclaimer of Validity.......................................58
  
  1. Introduction
  
     This document specifies PA-TNC, a Posture Attribute Protocol
     (PA) identical to the Trusted Computing Group's IF-M 1.0
     protocol [6].  The document then evaluates PA-TNC against the
     requirements defined in the NEA Requirements specification [7].
  
  1.1. Background on Trusted Computing Group
  
     The Trusted Computing Group (TCG) is a consortium that develops
     specifications for trusted (secure) computing.  Since its
     formation in 2003, TCG has published specifications for a
     variety of technologies such as Trusted Platform Module (TPM),
  
  
  Sangster               Expires October 5, 2008            [Page 3]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     TCG Software Stack (TSS), Mobile Trusted Module (MTM), and
     Trusted Network Connect (TNC).
  
     TCG members include more than 175 organizations that design,
     build, sell, or use trusted computing technology.  Membership is
     open to any organization that signs the membership agreement and
     pays the annual membership fee.  Non-members are welcome to
     implement the TCG specifications.  Several open source
     implementers have done so.
  
  1.2. Background on Trusted Network Connect
  
     Starting in 2004, the TCG has defined and published the Trusted
     Network Connect (TNC) architecture and standards for network
     access control.  These standards enable multi-vendor
     interoperability at all points in the architecture and have been
     widely adopted and deployed.
  
  1.3. Submission of This Document
  
     The IETF has recently chartered the Network Endpoint Assessment
     (NEA) working group to develop several standards in the same
     area as TNC.  In order to avoid the development of multiple
     incompatible standards, the TCG is offering several of its TNC
     standards to the IETF as candidates for standardization in the
     IETF also.  This document is equivalent to TCG's IF-M 1.0.
  
     Consistent with IETF's requirements for standards track
     documents, the TCG has authorized the editors of this document
     to offer the specification to the IETF without restriction.  As
     with other Internet-Drafts, the IETF Trust owns the copyright to
     this document.  The IETF may modify this document, ignore it,
     publish it as an RFC, or take any other action.  If the IETF
     decides to adopt a later version of this document as an RFC, the
     TCG plans to publish a specification for an equivalent TNC
     protocol to ensure compatibility.
  
  1.4. 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 Requirements specification.
     The reader is assumed to be thoroughly familiar with that
     document.  No familiarity with TCG specifications is assumed.
  
  
  
  
  
  Sangster               Expires October 5, 2008            [Page 4]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  1.5. Message Diagram Conventions
  
     This specification defines the syntax of PA-TNC messages using
     diagrams.  Each diagram depicts the format and size of each
     field in bits.  Implementations MUST send the bits in each
     diagram as they are shown, traversing the diagram from top to
     bottom and then from left to right within each line (which
     represents a 32-bit quantity).  Multi-byte fields representing
     numeric values must be sent in network (big endian) byte order.
  
     Descriptions of bit field (e.g. flag) values are described
     referring to the position of the bit within the field.  These
     bit positions are numbered from the most significant bit through
     the least significant bit so a one octet field with only bit 0
     set has the value 0x80.
  
  2. 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 3.2.
  
  2.1. PA-TNC Messaging Model
  
     PA-TNC messages are carried by the PB-TNC protocol [5], which
     provides a multi-roundtrip reliable transport and end-to-end
     message delivery to subscribed (interested) parties using a
     variety of underlying network protocols.  PA-TNC is unaware of
     these underlying PT transport protocols being used below PB-TNC.
     The interested parties consist of Posture Collectors on the NEA
     Client and Posture Validators associated with the NEA Server
     that have registered to receive messages about particular types
     of components (e.g. anti-virus) during an assessment.  The PA-
     TNC messaging protocol operates synchronously within an
     assessment session, with Posture Collectors and Posture
     Validators taking turns sending one or more messages to each
     other.  Each PA-TNC message may contain one or more attributes
     associated with the functional component defined in the PB
     protocol.  Posture Collectors may only send PA-TNC messages to
     Posture Validators and vice versa.  No Posture Collector to
     Posture Collector or Posture Validator to Posture Validator
     messaging is allowed to occur.  Each Posture Collector or
     Posture Validator may send several PA-TNC messages in succession
     before indicating that it has completed its response to the
     Posture Broker Client or Posture Broker Server respectively.  As
     necessary, the Posture Broker Client and Posture Broker Server
  
  
  Sangster               Expires October 5, 2008            [Page 5]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     will batch these messages prior to sending them over the
     network.
  
     PB-TNC provides a publish/subscribe model of message exchange.
     This means that, at any given point in time, zero or more
     subscribers for a particular type of message may be present on a
     Posture Broker Client or Posture Broker Server. This is
     beneficial, since it allows one Posture Collector or Posture
     Validator to combine multiple functions (like anti-virus and
     personal firewall) by subscribing to both TNC standard component
     types.  It also allows multiple Posture Collectors or Posture
     Validators to support the same components, such as two anti-
     virus Posture Validators that are each used to manage their own
     respective anti-virus client software. However, this
     publish/subscribe model has some possible negative side effects.
     When a Posture Collector or Posture Validator initially sends a
     PA-TNC message, it does not know whether it will receive many,
     one, or no PA-TNC messages from the other side.  For many types
     of assessments, this is acceptable, but in some cases a more
     direct channel binding between a particular Posture Collector
     and Posture Validator pair is necessary.  For example, a Posture
     Validator may wish to provide remediation instructions to a
     particular Posture Collector that it knows is capable of
     remediating a non-compliant component.  This can be accomplished
     using the PB-TNC capability to limit distribution of a message
     to a single Posture Collector.
  
  2.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
  
  
  Sangster               Expires October 5, 2008            [Page 6]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     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 assures that
     only the appropriate Posture Collectors and Posture Validators
     that support a particular type of component will receive
     attributes related to that component. If a PA-TNC message
     contained a mix of attributes about different components and a
     message type of only one of those components, the message would
     only be delivered to parties interested in the component type
     included in the message type, so other interested recipients
     wouldn't see those attributes.
  
     The message type is comprised of 2 fields: a PA Message Vendor
     ID and a PA Subtype. The PA Message Vendor ID identifies the
     vendor or other organization that defined this message type. The
     PA Subtype identifies the message type more particularly within
     the set of message types defined by that vendor. This
     specification defines several IETF Standard PA Subtypes to be
     used with a PA Message Vendor ID of zero (0). Within this
     specification, the PA Subtype field is used to indicate the type
     of component (e.g. firewall) involved with the message's
     attributes.  Therefore for clarity the PA subtype will be
     referred to as the "component type" in this specification.
     Vendor-defined name spaces may use other semantics for the PA
     Subtype field as this is outside the scope of this
     specification.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Sangster               Expires October 5, 2008            [Page 7]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         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.
     For example, 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.
  
  2.3. PA-TNC Messages in PB-TNC
  
     As depicted in section 2.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 2.5) and the header
     for each of the PA-TNC attributes (specified in section 3.1)
     have a fixed type-length-value (TLV) format.  Each PA-TNC
     message MAY contain a mixture of standards-based and vendor-
  
  
  Sangster               Expires October 5, 2008            [Page 8]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     defined attributes identifiable using the type portion of the
     attribute header.  All Posture Collectors and Posture Validators
     compliant with this specification MUST be capable of processing
     multiple attributes in a received PA-TNC message. A Posture
     Collector or Posture Validator that receives a PA-TNC message
     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.
  
  2.4. 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. OS, anti-virus
     software, etc.). It also allows Posture Collectors and Posture
     Validators to specialize in a particular component (e.g.
     operating system) and only receive PA-TNC messages relevant to
     that component.
  
     Number   Name              Definition
     ------   ----              ----------
     0        Testing           Reserved for use in specification
                                examples, experimentation and
                                testing.
  
     1        Operating System  Operating system running on the
                                endpoint
  
     2        Anti-Virus        Host-based anti-virus software
  
     3        Anti-Spyware      Host-based anti-spyware software
  
     4        Anti-Malware      Host-based anti-malware (e.g. anti-
                                bot) software not included within
                                anti-virus or anti-spyware components
  
     5        Firewall          Host-based firewall
  
     6        IDPS              Host-based Intrusion Detection and/or
                                Prevention Software (IDPS)
  
     7        VPN               Host-based Virtual Private Networking
                                (VPN) software
  
  
  
  
  Sangster               Expires October 5, 2008            [Page 9]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     These PA subtypes must be used in a PB-PA message with a PA
     Message Vendor ID of zero (0) (as described in the PB-TNC
     specification [5]).  If these PA subtype values are used with a
     different PA Message Vendor ID, they have a completely different
     meaning that is not defined in this specification.
  
  2.5. 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 3.
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Version    |                    Reserved                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message Identifier                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Version
  
        This field indicates the version of the format for the PA-TNC
        message.  This version is intended to allow for evolution of
        the PA-TNC message header and payload in a manner that can
        easily be detected by message recipients.
  
        PA-TNC message senders MUST set this field to 0x01 for all
        PA-TNC messages that comply with formats and requirements
        described in version 1.0 of this specification.
        Implementations responding to a PA-TNC message containing a
        supported version SHOULD use the same Version number to
        minimize the risk of version incompatibility.
  
        Message senders MAY send an empty PA-TNC message with the
        Version value set to 0 in order to discover the PA-TNC
        protocol versions supported by peer recipients (see PA-TNC
        Error Code information in section 3.2.8).  Message recipients
        MUST NOT support version 0 and MUST NOT interpret the
        contents (after the Version field) of a PA-TNC message
        containing a version number that the recipient does not
        support.  Message recipients MUST respond to a PA-TNC message
        with an unsupported version by sending a Version Not
        Supported error code in a PA-TNC Error attribute.
  
  
  Sangster               Expires October 5, 2008           [Page 10]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        PA-TNC message initiators supporting multiple PA-TNC protocol
        versions SHOULD be able to alter which version of PA-TNC
        message they send based on prior message exchanges with a
        particular peer Posture Collector or Posture Validator.
  
     Reserved
  
        Reserved for future use.  This field MUST be set to 0 on
        transmission and ignored upon reception.
  
     Message Identifier
  
        This field contains a value that uniquely identifies this
        message, differentiating it from others sent by a particular
        PA-TNC message sender within this assessment.  This value can
        be included in a response message to indicate which message
        was received and caused the response.  For example, this
        field is included in the PA-TNC error messages so the party
        who receives the error message can determine which of the
        messages they had sent caused the error.
  
        PA-TNC message senders MUST NOT send the same message
        identifier more than once during an assessment.  Message
        identifiers may be randomly generated or sequenced as long as
        values are not repeated during an assessment message
        exchange.  PA-TNC message recipients are not required to
        check for duplicate message identifiers.
  
  3. 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 2.5) 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 3.1.  The contents
     of PA-TNC attributes vary widely, depending on their attribute
     type. Section 3.2 defines the IETF Standard PA-TNC Attributes.
  
  
  
  Sangster               Expires October 5, 2008           [Page 11]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     Section 3.3 discusses how vendor-specific PA-TNC attributes can
     be defined.
  
  3.1. PA-TNC Attribute Header
  
     Following the PA-TNC message header is a sequence of zero or
     more attributes.  All PA-TNC attributes MUST begin with the
     standard PA-TNC attribute header defined in this subsection.
     Each attribute described in this specification is represented by
     a TLV tuple.  The TLV tuple includes an attribute identifier
     comprised of the Vendor ID and Attribute Type (type), the TLV
     tuple's overall length and finally the attribute's value.  The
     use of TLV representation was chosen due to its flexibility and
     extensibility and use in other standards.  Recipients of an
     attribute can use the attribute type fields to determine the
     precise syntax and semantics of the attribute value field and
     the length to skip over an unrecognized attribute.  The length
     field is also beneficial when a variable length attribute value
     is provided.
  
     The TLV format does not contain an explicit TLV format version
     number, so every attribute included in a particular PA-TNC
     message MUST use the same TLV format.  Using the PA-TNC message
     version number to indicate the format of all TLV attributes
     within a PA-TNC message allows for future versioning of the TLV
     format in a manner detectable by PA-TNC message recipients.
     Similarly, requiring all TLV attribute formats to be the same
     within a PA-TNC message also assures that recipients compliant
     with a particular PA-TNC message version can at least parse
     every attribute header and use the length to skip over
     unrecognized attributes.  Every PA-TNC 1.0 compliant TLV
     attribute MUST use the following TLV format:
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 12]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
                         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                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Correlation ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Attribute Value (Variable Length)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Flags
  
        This field defines flags impacting the processing of the
        associated attribute.
  
        Bit 0 (0x80) is the NOSKIP flag. Any Posture Collector or
        Posture Validator that receives an attribute with this flag
        set to 1 but does not support this attribute MUST NOT process
        any part of the PA-TNC message and SHOULD respond with an
        Attribute Type Not Supported error in a PA-TNC error message.
  
        In order to avoid taking action on a subset of the attributes
        only to later find an unsupported attribute with the NOSKIP
        flag set, recipients of a multi-attribute PA-TNC message
        might need to scan all of the attributes prior to acting upon
        any attribute.
  
        When the NOSKIP flag is set to 0, recipients SHOULD skip any
        unsupported attributes and continue processing the next
        attribute.
  
        Bit 1 (0x40) is the Correlation ID (COR) flag. This flag
        indicates whether the optional Correlation ID value is
        included in the header. When set to 1, a 32 bit Correlation
        ID field is present.  Otherwise when set to 0, no Correlation
        ID is included.
  
        Bit 2-7 are reserved for future use.  These bits MUST be set
        to 0 on transmission and ignored upon reception.
  
     PA-TNC Attribute Vendor ID
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 13]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        This field indicates the owner of the name space associated
        with the PA-TNC Attribute Type.  This is accomplished by
        specifying the 24 bit SMI Private Enterprise Number Vendor ID
        of the party who owns the Attribute Type name space.  IETF
        Standard PA-TNC Attribute Types MUST use zero (0) in this
        field.
  
        The PA-TNC Attribute Vendor ID 0xffffff is reserved.  Posture
        Collectors and Posture Verifiers MUST NOT send PA-TNC
        messages in which the PA-TNC Attribute Vendor ID has this
        reserved value (0xffffff).  If a Posture Collector or Posture
        Verifier receives a message in which the PA-TNC Attribute
        Vendor ID has this reserved value (0xffffff), it SHOULD
        respond with an Invalid Parameter error code in a PA-TNC
        Error attribute.
  
     PA-TNC Attribute Type
  
        This field defines the type of the attribute included in the
        Attribute Value field. This field is qualified by the PA-TNC
        Attribute Vendor ID field so that a particular PA-TNC
        Attribute Type value (e.g. 327) has a completely different
        meaning depending on the value in the PA-TNC Attribute Vendor
        ID field.
  
        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. Section 3.2 of this specification defines the
        initial set of IETF Standard PA-TNC Attribute Types.
  
        The PA-TNC Attribute Type 0xffffffff is reserved.  Posture
        Collectors and Posture Verifiers MUST NOT send PA-TNC
        messages in which the PA-TNC Attribute Type has this reserved
        value (0xffffffff).  If a Posture Collector or Posture
        Verifier receives a message in which the PA-TNC Attribute
        Type has this reserved value (0xffffffff), it SHOULD respond
        with an Invalid Parameter error code in a PA-TNC Error
        attribute.
  
     PA-TNC Attribute Length
  
        This field contains the length in octets of the entire PA-TNC
        Attribute including the PA-TNC Attribute Header (the fields
        Flags, PA-TNC Attribute Vendor ID, PA-TNC Attribute Type, and
        PA-TNC Attribute Length).  Therefore, this value MUST always
        be at least 12 (16 if the Correlation ID is present).  Any
  
  
  Sangster               Expires October 5, 2008           [Page 14]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        Posture Collector or Posture Verifier that receives a message
        with a PA-TNC Attribute Length field whose value is less than
        12 (16 if the Correlation ID is present) SHOULD respond with
        an Invalid Parameter PA-TNC error code.
  
        Implementations that do not support the specified PA-TNC
        Attribute Type can use this length to skip over this
        attribute to the next attribute.  Note that while this field
        is 4 octets the maximum usable attribute length is likely to
        be less than 2^32-1 due to limitations of the underlying
        protocol stack.
  
     Correlation ID
  
        This optional field MUST be present when the COR flag is set
        to 1 and MUST NOT be present when the COR flag is set to 0.
        Normally, this field will not be present.  However, there are
        times when this field is necessary.
  
        Some Posture Collectors may wish to report on several
        products with the same component ID on an endpoint (e.g. two
        anti-malware software packages). In this case, the Posture
        Collector and Posture Validator need a way to identify the
        different products. For example, if a Posture Validator
        requests Product Information and Numeric Version attributes
        for the anti-malware component, this Posture Collector would
        produce two Product Information and two Numeric Version
        attributes, each attribute having a Correlation ID specific
        to the product being described.  The Product Information and
        Numeric Version attributes describing the same product would
        have the same Correlation ID.  This allows the Posture
        Validator to associate the Product Information and Numeric
        Version attributes that apply to a single product.  Because
        the Product Information and Numeric Version attribute
        requests might be requested at different times, it is
        important that the Posture Collector use a consistent value
        for each product upon which it is able to report.  A Posture
        Collector might create a persistent table of locally unique
        IDs (e.g. counters) for each product upon which it reports,
        for situations where a Correlation ID is necessary.
  
        Note that many Posture Collectors will not need to worry
        about Correlation IDs because they will only support
        reporting on one product per endpoint. If an endpoint has two
        anti-malware Posture Collectors installed that each support
        only one product and those Posture Collectors are reporting
        on two separate anti-malware products, the Correlation ID is
  
  
  Sangster               Expires October 5, 2008           [Page 15]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        not required.  This is because the Posture Validator can use
        the Posture Collector ID reported in the PB-TNC protocol to
        associate the attributes sent by each Posture Collector.
  
        When a single Posture Collector needs to send several
        attributes in a single assessment that pertain to separate
        products but have the same PA Message Vendor ID and PA
        Subtype, the Posture Collector MUST use the Correlation ID
        field.  The Correlation ID value MUST be constant per product
        for an entire PB-TNC session so that the Posture Validator
        can correlate attributes requested earlier about the same
        product. The Posture Validator MAY send attributes with a
        Correlation ID to identify the product to which they pertain.
  
     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 is defined
        in section 3.2.
  
  3.2. IETF Standard PA-TNC Attribute Types
  
     This section defines an initial set of IETF Standard PA-TNC
     Attribute Types.  These Attribute Types MUST always be used with
     a PA-TNC Vendor ID of zero (0).  If these PA-TNC Attribute Type
     values are used with a different PA-TNC Vendor ID, they have a
     completely different meaning that is not defined in this
     specification.
  
     The following table briefly describes each attribute and defines
     the numeric value to be used in the PA-TNC Attribute Type field
     of the PA-TNC Attribute Header.  Later subsections provide
     detailed specifications for each PA-TNC Attribute Value.
  
     Number  Name                     Description
     ------  ----                     -----------
     0       Testing                  Reserved for use in
                                      specification examples,
                                      experimentation and testing.
  
     1       Attribute Request        Contains a list of attribute
                                      type values defining the
                                      attributes desired from the
                                      Posture Collectors.
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 16]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     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.
  
     The following subsections discuss the usage, format and
     semantics of the Attribute Value field for each IETF Standard
     PA-TNC Attribute Type.
  
  3.2.1. Attribute Request
  
     This PA-TNC Attribute Type allows a Posture Validator to request
     certain attributes from the registered set of Posture
     Collectors.
  
     All Posture Collectors that implement any of the IETF Standard
     PA Subtypes defined in this specification SHOULD support
     receiving and processing this attribute type for at least those
     PA subtypes.  Posture Collectors that receive and process this
     attribute MAY choose to send all, a subset or none of the
     requested attributes but MUST NOT send attributes that were not
     requested (except error attributes).  All Posture Validators
     that implement any of the IETF Standard PA Subtypes defined in
     this specification SHOULD support sending this attribute type
     for at least those PA subtypes.
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 17]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     Posture Verifiers MUST NOT include this attribute type in an
     Attribute Request attribute. It does not make sense for a
     Posture Verifier to request that a Posture Collector send an
     Attribute Request attribute.
  
     For this attribute type, the PA-TNC Attribute Vendor ID field
     MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
     be set to 1.
  
     The following diagram illustrates the format and contents of the
     Attribute Value field for this attribute type.  The text after
     this diagram describes the fields shown here.
  
     Note that this diagram shows two attribute types. The actual
     number of attribute types included in an Attribute Request
     attribute can vary from one to a large number (limited only by
     the maximum message and length supported by the underlying PT
     transport protocol). However, each Attribute Request MUST
     contain at least one attribute type.  Because the length of a
     PA-TNC Attribute Vendor ID paired with a PA-TNC Attribute Type
     and a one octet Reserved field is always 8 octets, the number of
     requested attributes can be easily computed using the PA-TNC
     Attribute Length field by subtracting the number of octets in
     the PA-TNC Attribute Header and dividing by 8.  If the PA-TNC
     Attribute Length field is invalid, Posture Collectors SHOULD
     respond with an Invalid Parameter PA-TNC error code.
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved    |           PA-TNC Attribute Vendor ID          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      PA-TNC Attribute Type                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved    |           PA-TNC Attribute Vendor ID          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      PA-TNC Attribute Type                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  
     Reserved
  
        Reserved for future use.  This field MUST be set to 0 on
        transmission and ignored upon reception.
  
     PA-TNC Attribute Vendor ID
  
  
  
  Sangster               Expires October 5, 2008           [Page 18]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        This field contains the SMI Private Enterprise Number of the
        organization that controls the name space for the following
        PA-TNC Attribute Type.  This field enables IETF Standard PA-
        TNC Attributes and vendor-defined PA-TNC Attributes to be
        used without potential collisions.
  
        Any IETF Standard PA-TNC Attribute Types defined in section
        3.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.
  
  3.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 2.4.  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.
  
  
  Sangster               Expires October 5, 2008           [Page 19]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     However, the value in the PA-TNC Attribute Length field MUST be
     at least 17 (21 if the Correlation ID field is present) because
     this is the length of the fixed size fields in the PA-TNC
     Attribute Header and the fixed size fields in this attribute
     type.  If the PA-TNC Attribute Length field is less than the
     size of these fixed length fields, implementations SHOULD
     respond with an Invalid Parameter PA-TNC error code.
  
     This attribute type includes both numeric and textual
     identifiers for the organization that created the product (the
     "product creator") and for the product itself. For automated
     processing, numeric identifiers are superior because they are
     less ambiguous and more efficient. However, numeric identifiers
     are only available if the product creator has assigned them.
     Therefore, a textual identifier is also included. This textual
     identifier has the additional benefit that it may be easier for
     humans to read (although this benefit is minimal since the
     primary purpose of this attribute is automated assessment).
  
     The following diagram illustrates the format and contents of the
     Attribute Value field for this attribute type.  The text after
     this diagram describes the fields shown here.
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Product Vendor ID               |  Product ID   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Product ID   |         Product Name (Variable Length)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  
     Product Vendor ID
  
        This field contains the SMI Private Enterprise Number for the
        product creator.  If the SMI PEN for the product creator is
        unknown or if the product creator does not have an SMI PEN,
        the Product Vendor ID field MUST be set to 0 and the identity
        of the product creator SHOULD be included in the Product Name
        along with the name of the product.
  
     Product ID
  
        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
  
  
  Sangster               Expires October 5, 2008           [Page 20]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        is 0, this field MUST be set to 0. In any case, the name of
        the product SHOULD be included in the Product Name field.
  
        Note that a particular Product ID value (e.g. 635) will have
        completely different meanings depending on the Product Vendor
        ID. Each Product Vendor ID defines a different space of
        Product ID values. Product creators are encouraged to publish
        lists of Product ID values for their products.
  
     Product Name
  
        This variable length field contains a UTF-8 [2] string
        identifying the product (e.g. "Symantec Norton AntiVirus(TM)
        2008") in enough detail to unambiguously distinguish it from
        other products from the product creator.  Products whose
        creator is known, but does not have a registered SMI Private
        Enterprise Number, SHOULD be represented using a combination
        of the creator name and full product name (e.g. "Ubuntu(R)
        IPtables" for the IPtables firewall in the Ubuntu
        distribution of Linux).  If the product creator's SMI Private
        Enterprise Number is included in the Product Vendor ID field,
        the product creator's name may be omitted from this field.
  
        The length of this field can be determined by starting with
        the value in the PA-TNC Attribute Length field in the PA-TNC
        Attribute Header and subtracting the size of the fixed length
        fields in that header (12 or 16, depending on whether the
        Correlation ID is present) 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.
  
  3.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 2.4.
     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.
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 21]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     All Posture Collectors that implement the IETF Standard PA
     Subtype for Operating System SHOULD support sending this
     attribute type, at least for the Operating System PA subtype.
     Other Posture Collectors MAY support sending this attribute
     type.  Whether a particular Posture Collector actually sends
     this attribute type SHOULD still be governed by local privacy
     and security policies.  All Posture Validators that implement
     the IETF Standard PA Subtype for Operating System SHOULD support
     receiving this attribute type, at least for the Operating System
     PA subtype.  Other Posture Validators MAY support receiving this
     attribute type.  A Posture Validator that does not support
     receiving this attribute type SHOULD simply ignore attributes
     with this type.  Posture Validators MUST NOT send this attribute
     type.
  
     For this attribute type, the PA-TNC Attribute Vendor ID field
     MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
     be set to 3.  The value in the PA-TNC Attribute Length field
     MUST be 28 if the Correlation ID field is not present and 32 if
     it is present.  If the PA-TNC Attribute Length field is less
     than the size of these fixed length fields, implementations
     SHOULD respond with an Invalid Parameter PA-TNC error code.
  
     This attribute type includes numeric values for the product
     version information, enabling Posture Validators to do
     comparative operations on the version.  Some Posture Collectors
     may not be able to determine some or all of this information for
     a product.  However, this attribute can be especially useful for
     describing the version of the operating system, where numeric
     version numbers are generally available.
  
     The following diagram illustrates the format and contents of the
     Attribute Value field for this attribute type.  The text after
     this diagram describes the fields shown here.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 22]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Major Version Number                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Minor Version Number                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Build Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Service Pack Major       |      Service Pack Minor       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Major Version Number
  
        This field contains the major version number for the product,
        if applicable. If unused or unknown, this field SHOULD be set
        to 0.
  
     Minor Version Number
  
        This field contains the minor version number for the product,
        if applicable. If unused or unknown, this field SHOULD be set
        to 0.
  
     Build Number
  
        This field contains the build number for the product, if
        applicable.  This may provide more granularity than the minor
        version number, as many builds may occur leading up to an
        official release, and all these builds may share a single
        major and minor version number.  If unused or unknown, this
        field SHOULD be set to 0.
  
     Service Pack Major
  
        This field contains the major version number of the service
        pack for the product, if applicable.  If unused or unknown,
        this field SHOULD be set to 0.
  
     Service Pack Minor
  
        This field contains the minor version number of the service
        pack for the product, if applicable. If unused or unknown,
        this field SHOULD be set to 0.
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 23]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  3.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 2.4.
     For example, if the PA Subtype is Firewall, this attribute would
     contain string version information for a host-based firewall
     product installed on the endpoint (if any).  The version
     information in this attribute is associated with a particular
     product, so Posture Validators are expected to also possess the
     corresponding Product Information attribute when interpreting
     this attribute.
  
     All Posture Collectors that implement any of the IETF Standard
     PA Subtypes defined in this document MUST support sending this
     attribute type, at least for those PA subtypes.  Other Posture
     Collectors MAY support sending this attribute type.  Whether a
     particular Posture Collector actually sends this attribute type
     SHOULD still be governed by local privacy and security policies.
     All Posture Validators that implement any of the IETF Standard
     PA Subtypes defined in this document MUST support receiving this
     attribute type, at least for those PA subtypes.  Other Posture
     Validators MAY support receiving this attribute type.  Posture
     Validators MUST NOT send this attribute type.
  
     For this attribute type, the PA-TNC Attribute Vendor ID field
     MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
     be set to 4.  The value in the PA-TNC Attribute Length field
     will vary, depending on the length of the Component Version
     Number, Internal Build Number, and Configuration Version Number
     fields. However, the value in the PA-TNC Attribute Length field
     MUST be at least 15 (19 if the Correlation ID field is present)
     because this is the length of the fixed size fields in the PA-
     TNC Attribute Header and the fixed size fields in this attribute
     type.  If the PA-TNC Attribute Length field is less than the
     size of these fixed length fields or does not match the length
     indicated by the sum of the fixed length and variable length
     fields, implementations SHOULD respond with an Invalid Parameter
     PA-TNC error code.
  
     The following diagram illustrates the format and contents of the
     Attribute Value field for this attribute type.  The text after
     this diagram describes the fields shown here.
  
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 24]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version Len  |   Product Version Number (Variable Length)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Build Num Len |   Internal Build Number (Variable Length)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Config. Len  | Configuration Version Number (Variable Length)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Version Len
  
        This field defines the number of octets in the Product
        Version Number field.  If the product version number is
        unavailable or unknown, this field MUST be set to 0 and the
        Product Version Number field will be zero length (effectively
        not present).
  
     Product Version Number
  
        This field contains a UTF-8 string identifying the version of
        the component (e.g. "1.12.23.114").  This field MUST be sized
        to fit the version string and MUST NOT include extra octets
        for padding or NUL character termination.
  
        Various products use a wide range of different formats and
        semantics for version strings.  Some use alphabetic
        characters, white space, and punctuation.  Some consider
        version "1.21" to be later than version "1.3" and some
        earlier.  Therefore, the syntax and semantics of this string
        are not defined.
  
     Build Num Len
  
        This field defines the number of octets in the Internal Build
        Number field.  For products where the internal build number
        is unavailable or unknown, this field MUST be set to 0 and
        the Internal Build Number field will be zero length
        (effectively not present).
  
     Internal Build Number
  
        This field contains a UTF-8 string identifying the
        engineering build number of the product.  This field MUST be
        sized to fit the build number string and MUST NOT include
        extra octets for padding or NUL character termination.  The
        syntax and semantics of this string are not defined.
  
  
  Sangster               Expires October 5, 2008           [Page 25]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     Config. Len
  
        This field defines the number of octets in the Configuration
        Version Number field.  If the product version number is
        unavailable or unknown, this field MUST be set to 0 and the
        Product Version Number field will be zero length (effectively
        not present).
  
     Configuration Version Number
  
        This field contains a UTF-8 string identifying the version of
        the configuration used by the component.  This version SHOULD
        represent the overall configuration version even if several
        configuration policy files or settings are used.  Posture
        Collectors MAY include multiple version numbers in this
        single string if a single version is not practical.  This
        field MUST be sized to fit the version string and MUST NOT
        include extra octets for padding or NUL character
        termination.
  
        Various products use a wide range of different formats for
        version strings.  Some use alphabetic characters, white
        space, and punctuation.  Some consider version "1.21" to be
        later than version "1.3" and some earlier.  In addition, some
        Posture Collectors may place multiple configuration version
        numbers in this single string. Therefore, the syntax and
        semantics of this string are not defined.
  
  3.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 2.4.  For example, if the
     PA Subtype is Anti-Spyware, this attribute would contain
     information about the operational status of a host-based anti-
     spyware product that may or may not be installed on the
     endpoint.
  
     Posture Collectors that implement the IETF Standard PA Subtype
     for Operating System or VPN MAY support sending this attribute
     type for those PA subtypes.  Posture Collectors that implement
     other IETF Standard PA Subtypes defined in this specification
     SHOULD support sending this attribute type for those PA
     subtypes.  Other Posture Collectors MAY support sending this
     attribute type.  Whether a particular Posture Collector actually
     sends this attribute type SHOULD still be governed by local
     privacy and security policies.  Posture Validators that
  
  
  Sangster               Expires October 5, 2008           [Page 26]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     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 Correlation ID field is not present and 40 if
     it is present.  If the PA-TNC Attribute Length field does not
     have this value, implementations SHOULD respond with an Invalid
     Parameter PA-TNC error code.
  
     The following diagram illustrates the format and contents of the
     Attribute Value field for this attribute type.  The text after
     this diagram describes the fields shown here.
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Status     |     Result    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Last Use                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Last Use (continued)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Last Use (continued)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Last Use (continued)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Last Use (continued)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Status
  
        This field gives the operational status of the product.  The
        following table lists the values currently defined for this
        field.  As described in section 7, the IANA maintains a
        registry of valid values for this field so that new values
        can be defined.
  
  
  
  Sangster               Expires October 5, 2008           [Page 27]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        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.  As described in section 7, the IANA
        maintains a registry of valid values for this field so that
        new values can be defined.
  
        Value   Description
        -----   -----------
        0       Unknown or other
        1       Successful use with no errors detected
        2       Successful use with one or more errors detected
        3       Unsuccessful use (e.g. aborted)
  
        Posture Collectors SHOULD set this field to 0 if the Status
        field contains a value of 1 (Not installed) or 2 (Installed
        but not operational).  If a Posture Validator receives a
        value for this field that it does not recognize, it SHOULD
        treat this value as equivalent to the value 0.
  
     Reserved
  
        This field is reserved for future use.  The field MUST be set
        to 0 on transmission and ignored upon reception.
  
     Last Use
  
        This field contains the date and time of the last use of the
        component.  The Last Use date and time MUST be represented as
        an RFC 3339 [4] compliant ASCII string in Coordinated
        Universal Time (UTC) time with the additional restrictions
        that the 't' delimiter and the 'z' suffix MUST be capitalized
        and fractional seconds (time-secfrac) MUST NOT be included.
        Leap seconds are permitted and Posture Validators MUST
        support them. The last use string MUST NOT be NUL terminated
  
  
  Sangster               Expires October 5, 2008           [Page 28]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        or padded in any way.  If the last use time is not known, not
        applicable, or cannot be represented in this format, the
        Posture Collector MUST set this field to the value "0000-00-
        00T00:00:00Z" (allowing this field to be fixed length). Not
        that this particular reserved value is NOT a valid RFC 3339
        date and time and MUST NOT be used for any other purpose in
        this field.
  
        This encoding produces a string that is easy to read, parse,
        and interpret.  The format (more precisely defined in RFC
        3339) is YYYY-MM-DDTHH:MM:SSZ, resulting in one and only one
        representation for each second in UTC time from year 0000 to
        year 9999.  For example, 9:05:00AM EST (GMT-0500) on January
        19, 1995 can be represented as "1995-01-19T14:05:00Z".  The
        length of this field is always 20 octets.
  
  3.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               Expires October 5, 2008           [Page 29]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     The following diagram illustrates the format and contents of the
     Attribute Value field for this attribute type.  The text after
     this diagram describes the fields shown here.
  
     Note that this diagram shows two Protocol/Port Number pairs. The
     actual number of Protocol/Port Number pairs included in a Port
     Filter attribute can vary from one to a large number (limited
     only by the maximum message and length supported by the
     underlying PT transport protocol). However, each Port Filter
     attribute MUST contain at least one Protocol/Port Number pair.
     Because the length of a Protocol/Port Number pair with the
     Reserved field and B flag is always 4 octets, the number of
     Protocol/Port Number pairs can be easily computed using the PA-
     TNC Attribute Length field by subtracting the number of octets
     in the PA-TNC Attribute Header and dividing by 4.  If the PA-TNC
     Attribute Length field is invalid, Posture Validators SHOULD
     respond with an Invalid Parameter PA-TNC error code.
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved  |B|    Protocol   |         Port Number           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved  |B|    Protocol   |         Port Number           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Reserved
  
        This field is reserved for future use.  It MUST be set to 0
        on transmission and ignored upon reception.
  
     B Flag (Blocked or Allowed Port)
  
        This single bit field indicates whether the following port is
        blocked or allowed.  This bit MUST be set to 1 if the
        protocol and port combination is blocked.  Otherwise this
        field MUST be set to 0.  This field was provided to allow for
        more abbreviated reporting of the port filtering policy (e.g.
        when all ports are blocked except a few, the Posture
        Collector can just list the few that are allowed).
  
        Posture Collectors MUST NOT provide a mixed list of block and
        non-blocked ports for a particular protocol.  To be more
        precise, a Posture Collector MUST NOT include two
        Protocol/Port Number pairs in a single Port List attribute
        where the protocol number is the same but the B flag is
        different.  Also, Posture Collectors MUST NOT list the same
  
  
  Sangster               Expires October 5, 2008           [Page 30]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        Protocol and Port Number combination twice in a Port List
        attribute.
  
        Posture Collectors MAY list all blocked ports for one
        protocol and all allowed ports for a different protocol in a
        single Port List attribute, using the B flag to indicate
        whether each entry is blocked.  For example, a Posture
        Collector might list all the blocked TCP ports but only list
        the allowed UDP ports.  However it MUST NOT list some blocked
        TCP ports and some other allowed TCP ports.
  
     Protocol
  
        This field contains the protocol number being blocked or
        allowed. The values used in this field are the same ones used
        in the IPv4 Protocol and IPv6 Next Header fields.  The IANA
        already maintains a registry of these values.
  
     Port Number
  
        This field contains the port number being blocked or allowed.
        The values used in this field are specific to the protocol
        identified by the Protocol field.  The IANA maintains
        registries for TCP and UDP port numbers.
  
  3.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 2.4.  This allows a Posture Validator to check which
     packages are installed for a particular product and which
     versions of those packages are installed.
  
     Posture Collectors that implement any of the IETF Standard PA
     Subtypes defined in this document SHOULD support sending this
     attribute type for those PA subtypes.  Other Posture Collectors
     MAY support sending this attribute type, if it is appropriate to
     their PA subtype.  Whether a particular Posture Collector
     actually sends this attribute type SHOULD still be governed by
     local privacy and security policies.  Posture Validators that
     implement any of the IETF Standard PA Subtypes defined in this
     document SHOULD support receiving this attribute type, at least
     for those PA subtypes.  Other Posture Validators MAY support
     receiving this attribute type.  A Posture Validator that does
     not support receiving this attribute type SHOULD simply ignore
  
  
  
  Sangster               Expires October 5, 2008           [Page 31]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     attributes with this type.  Posture Validators MUST NOT send
     this attribute type.
  
     This attribute type can be quite long, especially for the
     Operating System PA subtype. This can cause problems, especially
     with 802.1X and other limited transport protocols. Therefore,
     Posture Collectors SHOULD NOT send this attribute unless
     specifically requested to do so using the Attribute Request
     attribute or otherwise configured to do so. Also, Posture
     Validators SHOULD NOT request this attribute unless the
     transport protocol in use can support the large amount of data
     that may be sent in response.
  
     For this attribute type, the PA-TNC Attribute Vendor ID field
     MUST be set to zero (0) and the PA-TNC Attribute Type field MUST
     be set to 7.  The value in the PA-TNC Attribute Length field
     will vary, depending on the number of packages and the length of
     the Package Name and Package Version Number fields for those
     packages. However, the value in the PA-TNC Attribute Length
     field MUST be at least 16 (20 if the Correlation ID field is
     present) because this is the length of the fixed size fields in
     the PA-TNC Attribute Header and the fixed size fields in this
     attribute type.  If the PA-TNC Attribute Length field is less
     than the size of these fixed length fields or does not match the
     length indicated by the sum of the fixed length and variable
     length fields, implementations SHOULD respond with an Invalid
     Parameter PA-TNC error code.
  
     The following diagram illustrates the format and contents of the
     Attribute Value field for this attribute type.  The text after
     this diagram describes the fields shown here.
  
     Note that this diagram shows an attribute containing information
     on one package. The actual number of package descriptions
     included in an Installed Packages attribute is indicated by the
     Package Count field. This value may vary from zero to a large
     number (up to 65535, if the underlying PT transport protocol can
     support that many). If this number is not sufficient,
     specialized patch management software should be employed which
     can simply report compliance with a pre-established patch
     policy.
  
  
  
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 32]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Reserved             |         Package Count         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Pkg Name Len  |        Package Name (Variable Length)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version Len  |    Package Version Number (Variable Length)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Reserved
  
        This field is reserved for future use.  The field MUST be set
        to 0 on transmission and ignored upon reception.
  
     Package Count
  
        This field is an unsigned 16-bit integer that indicates the
        number of packages listed in this attribute.  For each
        package so indicated, a Pkg Name Len, Package Name, Version
        Len, and Package Version Number field is included in the
        attribute.
  
     Pkg Name Len
  
        This field is an unsigned 8-bit integer that indicates the
        length of the Package Name field in octets. This field may be
        zero if a Package Name is not available.
  
     Package Name
  
        This field contains the name of the package associated with
        the product.  This field is a UTF-8 encoded character string
        whose octet length is given by the Pkg Name Len field. This
        field MUST NOT include extra octets for padding or NUL
        character termination.  The syntax and semantics of this name
        are not specified in this document, since they may vary
        across products and/or operating systems. Posture Collectors
        MAY list two packages with the same name in a single
        Installed Packages attribute. The meaning of doing so is not
        defined here.
  
     Version Len
  
        This field is an unsigned 8-bit integer that indicates the
        length of the Package Version Number field in octets. This
  
  
  
  Sangster               Expires October 5, 2008           [Page 33]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        field may be zero if a Package Version Number is not
        available.
  
     Package Version Number
  
        This field contains the version string for the package named
        in the previous Package Name field.  This field is a UTF-8
        encoded character string whose octet length is given by the
        Version Len field. This field MUST NOT include extra octets
        for padding or NUL character termination.  The syntax and
        semantics of this version string are not specified in this
        document, since they may vary across products and/or
        operating systems. Posture Collectors MAY list two packages
        with the same Package Version Number (and even the same
        Package Name and Package Version Number) in a single
        Installed Packages attribute. The meaning of doing so is not
        defined here.
  
  3.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 (24 if the Correlation ID field is present)
     because this is the length of the fixed size fields in the PA-
     TNC Attribute Header and the fixed size fields in this attribute
     type.
  
     A PA-TNC error code SHOULD be sent with the same PA Message
     Vendor ID and PA Subtype used by the PA-TNC message that caused
     the error so that the error code is sent to the party who sent
     the offending PA-TNC message. Other measures (such as setting
     PB-TNC's EXCL flag and Posture Collector Identifier or Posture
     Validator Identifier fields) SHOULD also be taken to attempt to
     ensure that only the party who sent the offending message
     receives the error.
  
  
  Sangster               Expires October 5, 2008           [Page 34]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     When a PA-TNC error code is received, the recipient MUST NOT
     respond with a PA-TNC error code because this could result in an
     infinite loop of errors. Instead, the recipient MAY log the
     error, modify its behavior to attempt to avoid the error
     (attempting to avoid loops or long strings of errors), ignore
     the error, terminate the assessment, or take other action as
     appropriate (as long as it is consistent with the requirements
     of this specification).
  
     Posture Verifiers MUST NOT include this attribute type in an
     Attribute Request attribute. It does not make sense for a
     Posture Verifier to request that a Posture Collector send a PA-
     TNC Error attribute.
  
     The following diagram illustrates the format and contents of the
     Attribute Value field for this attribute type.  The text after
     this diagram describes the fields shown here.
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved   |            PA-TNC Error Code Vendor ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        PA-TNC Error Code                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Error Information (Variable Length)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Reserved
  
        This field is reserved for future use.  This field MUST be
        set to 0 on transmission and ignored upon reception.
  
     PA-TNC Error Code Vendor ID
  
        This field contains the SMI Private Enterprise Number for the
        organization that defined the PA-TNC Error Code that is being
        used in the attribute.  For IETF Standard PA-TNC Error Code
        values this field MUST be set to zero (0).
  
     PA-TNC Error Code
  
        This field contains the PA-TNC Error Code being reported in
        this attribute. Note that a particular PA-TNC Error Code
        value will have completely different meanings depending on
        the PA-TNC Error Code Vendor ID. Each PA-TNC Error Code
  
  
  
  Sangster               Expires October 5, 2008           [Page 35]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        Vendor ID defines a different space of PA-TNC Error Code
        values.
  
        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. The
        IANA maintains a registry for these values. The following
        table lists the IETF Standard PA-TNC Error Codes defined in
        this specification:
  
        Value   Description
        -----   -----------
        0       Reserved
        1       Invalid Parameter
        2       Version Not Supported
        3       Attribute Type Not Supported
  
        The next few subsections of this document provide detailed
        definitions of these error codes.
  
     Error Information
  
        This field provides additional context for the error.  The
        contents of this field vary based on the PA-TNC Error Code
        Vendor ID and PA-TNC Error Code. Therefore, whenever a PA-TNC
        Error Code is defined, the format of this field for that
        error code must also be defined. The definitions of IETF
        Standard PA-TNC Error Codes on the next few pages provide
        good examples of such definitions.
  
        The length of this field can be determined by the recipient
        using the PA-TNC Attribute Length field by subtracting the
        length of the fixed-length fields in the PA-TNC Attribute
        Header and the fixed-length fields in this attribute.
  
  3.2.8.1. Definition of 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               Expires October 5, 2008           [Page 36]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     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.
  
  3.2.8.2. Definition of 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
  
  
  
  Sangster               Expires October 5, 2008           [Page 37]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     in the PA-TNC Message Header of a PA-TNC message sent by the
     recipient of this error code in the current assessment.
  
     For this error code, the Error Information field contains the
     first 8 octets of the PA-TNC message that contained the
     unsupported version as well as Max Version and Min Version
     fields that indicate which PA-TNC version numbers are supported
     by the sender of the error code.
  
     The sender MUST support all PA-TNC versions between the Min
     Version and the Max Version, inclusive (i.e. including the Min
     Version and the Max Version). When possible, recipients of this
     error code SHOULD send future messages to the Posture Collector
     or Posture Validator that originated this error message with a
     PA-TNC version number within the stated range.
  
     Any party that is sending the Version Not Supported error code
     SHOULD include that error code as the only PA-TNC attribute in a
     PA-TNC message with version number 1. All parties that send PA-
     TNC messages SHOULD be able to properly process a message that
     meets this description, even if they cannot process any other
     aspect of PA-TNC version 1. This ensures that a PA-TNC version
     exchange can proceed properly, no matter what versions of PA-TNC
     the parties implement.
  
     The following diagram illustrates the format and contents of the
     Error Information field for this error code.  The text after
     this diagram describes the fields shown here.
  
                          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
  
  
  
  Sangster               Expires October 5, 2008           [Page 38]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
        This field MUST contain an exact copy of the Reserved field
        in the PA-TNC Message Header of the PA-TNC message that
        caused this error.
  
     Message Identifier
  
        This field MUST contain an exact copy of the Message
        Identifier field in the PA-TNC Message Header of the PA-TNC
        message that caused this error.
  
     Max Version
  
        This field MUST contain the maximum PA-TNC version supported
        by the sender of this error code.
  
     Min Version
  
        This field MUST contain the minimum PA-TNC version supported
        by the sender of this error code.
  
     Reserved
  
        Reserved for future use.  This field MUST be set to 0 on
        transmission and ignored upon reception.
  
  3.2.8.3. Definition of 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.
  
     The following diagram illustrates the format and contents of the
     Error Information field for this error code.  The text after
     this diagram describes the fields shown here.
  
  
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 39]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Version    |                    Reserved                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message Identifier                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |          PA-TNC Attribute Vendor ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     PA-TNC Attribute Type                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
     Version
  
        This field MUST contain an exact copy of the Version field in
        the PA-TNC Message Header of the PA-TNC message that caused
        this error.
  
     Copy of Reserved
  
        This field MUST contain an exact copy of the Reserved field
        in the PA-TNC Message Header of the PA-TNC message that
        caused this error.
  
     Message Identifier
  
        This field MUST contain an exact copy of the Message
        Identifier field in the PA-TNC Message Header of the PA-TNC
        message that caused this error.
  
     Flags
  
        This field MUST contain an exact copy of the Flags field in
        the PA-TNC Attribute Header of the PA-TNC attribute that
        caused this error.
  
     PA-TNC Attribute Vendor ID
  
        This field MUST contain an exact copy of the PA-TNC Attribute
        Vendor ID field in the PA-TNC Attribute Header of the PA-TNC
        attribute that caused this error.
  
     PA-TNC Attribute Type
  
        This field MUST contain an exact copy of the PA-TNC Attribute
        Type field in the PA-TNC Attribute Header of the PA-TNC
        attribute that caused this error.
  
  
  Sangster               Expires October 5, 2008           [Page 40]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  3.3. Vendor-Defined Attributes
  
     This section discusses the use of vendor-defined attributes
     within PA-TNC.  The PA-TNC protocol was designed to allow for
     vendor-defined attributes to be used as a replacement where a
     standard attribute could be used.  In some cases even the
     standard attributes allow for vendor-defined information to be
     included.  It is envisioned that over time as particular vendor-
     defined attributes become popular, an equivalent standard
     attribute could be added allowing for broader interoperability.
  
     This specification does not define vendor-defined attributes,
     but rather highlights how such attributes can be used with PA-
     TNC without the potential for name space collisions or
     misinterpretations.  In order to avoid collisions, PA-TNC uses
     the well-established SMI Private Enterprise Numbers as Vendor
     IDs to define separate name spaces for important fields within a
     PA-TNC message.  For example, to ensure the uniqueness of
     attribute types while providing for vendor extensions, vendor-
     defined attribute types include the vendor's unique Vendor ID,
     to indicate the intended name space for the attribute type,
     followed by the attribute type.  IETF Standard PA-TNC Attribute
     Types use a Vendor ID of zero (0).
  
     SMI Private Enterprise Numbers are used to provide a separate
     identifier space for each vendor. The IANA provides a registry
     for SMI Private Enterprise Numbers. Any organization (including
     non-profit organizations, governmental bodies, etc.) can obtain
     one of these numbers at no charge and thousands of organizations
     have done so. Within this document, SMI Private Enterprise
     Numbers are known as "vendor IDs".
  
  4. 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.
  
  4.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.
  
  
  Sangster               Expires October 5, 2008           [Page 41]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     PA-TNC meets this requirement.  It allows an unlimited number of
     round trips between the NEA Client and NEA Server.
  
  4.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.
  
  4.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 can be provided through PT security or
     through the use of PA-TNC security, which is defined in a
     separate specification: PA-TNC Security [8]. Therefore, this
     base specification for PA-TNC does not include any security
     capabilities. Since this requirement only applies to NEA
     protocols that include security capabilities, this base
     specification for PA-TNC meets this requirement.
  
  4.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.
  
  
  Sangster               Expires October 5, 2008           [Page 42]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  4.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.
  
  4.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-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.
  
  4.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.
  
  
  Sangster               Expires October 5, 2008           [Page 43]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     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).
  
  4.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 typical PA-TNC exchange will
     involve one or two round trips with less than 500 octets of PA-
     TNC messages. Of course, use of PA-TNC security or vendor-
     specific PA-TNC attribute types could expand the assessment.
     However, PA-TNC itself imposes an overhead of only 8 octets per
     PA-TNC message and 12 octets per attribute.
  
  4.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 fields defined here do not
     include any strings intended for display to a user. They are
     intended for logging and programmatic comparisons.
  
     If any vendor-specific PA-TNC attribute types or future IETF
     Standard PA-TNC Attribute Types include strings that are
     intended for display to a user, they can be adapted to the
     user's language preferences using the PB-TNC protocol's ability
     to exchange information about those preferences in a standard
     manner.  The Posture Broker Server will need to expose the
     user's preferences to the Posture Validators through whatever
     API or protocol is used to connect those components. However,
     that is all out of scope for this specification.
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 44]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  4.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.
  
  4.11. 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 IETF Standard
     PA-TNC Attribute Types with new values added by IETF Consensus,
     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.
  
  4.12. 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 name spaces.
  
     PA-TNC meets this requirement.  Each attribute is identified
     with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type.
     Vendor-defined PA-TNC Attribute Types use the vendor's SMI
     Private Enterprise Number as the PA-TNC Attribute Vendor ID.
     Each vendor can define up to 2^32 PA-TNC Attribute Types, using
     its own internal processes to manage its set of attribute types.
  
  
  Sangster               Expires October 5, 2008           [Page 45]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     The IANA is not involved, other than the initial assignment of
     the vendor's SMI Private Enterprise Number.  Thus, the set of
     vendor-specific attributes is segmented into uniquely
     identifiable vendor-specific name spaces.
  
  4.13. 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.
  
     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.
  
  4.14. 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.
  
  4.15. 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.
  
  
  Sangster               Expires October 5, 2008           [Page 46]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     PA-TNC meets this requirement when a PA-TNC Security mechanism
     is used, such as PA-TNC Security with CMS.  The specifications
     for those mechanisms should be consulted for a complete analysis
     of their security properties.
  
     PA-TNC Security is an optional addition to PA-TNC because
     different products and deployments may require different
     security mechanisms. For example, one product might integrate
     Posture Validators, the Posture Broker Server, and the Posture
     Transport Server into a single entity. In that case, PA-TNC
     security may not be needed. PT security may be enough. Another
     deployment may employ remote Posture Validators in the same
     trust domain as the Posture Broker Server. In that case, a TLS
     session between the Posture Broker Server and the Posture
     Validators may suffice. A third deployment may include a Posture
     Broker Server that is not trusted to see PA-TNC messages, at
     least for some Posture Validators. In that case, PA-TNC security
     may be desirable. Even there, some deployments may wish to use
     PKI (Public Key Infrastructure) for security, while others may
     wish to use Kerberos or another mechanism.
  
  4.16. 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 and in the PA-TNC Security with CMS specification.
  
  5. Security Considerations
  
     This section discusses the major types of potential security
     threats relevant to the PA-TNC message protocol and summarizes
     the expected security protections that should be offered by PA-
     TNC security protocols.  PA-TNC security protocols are described
     in separate specifications which layer upon the base PA-TNC
     protocol described in this specification.  It is envisioned that
     additional attribute types will be defined to facilitate the
     exchange of security capabilities, keys, and security protected
     attributes.  Ultimately, the NEA deployer decides which security
     protection is most appropriate for a particular deployment
     environment.  The security protections discussed in this section
  
  
  Sangster               Expires October 5, 2008           [Page 47]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     highlight the need for PA-TNC security protocol implementations
     to be capable of offering the feature.
  
  5.1. Trust Relationships
  
     In order to understand where security countermeasures are
     necessary, this section starts with a discussion of where the
     TNC architecture envisions some trust relationships between the
     processing elements of the PA-TNC protocol.  Some deployments
     may wish to reduce the amount of assumed trust by using a PA-TNC
     security protocol to protect the PA-TNC messages.  The following
     sub-sections discuss the trust properties associated with each
     portion of the NEA reference model directly involved with the
     processing of the PA-TNC protocol.
  
  5.1.1. Posture Collector
  
     The Posture Collectors are trusted by Posture Validators to:
  
     o  Collect valid information about the component type associated
        with the Posture Collector
  
     o  Report upon collected information consistent with local
        security and privacy policies
  
     o  Accurately report information associated with the type of
        component for the PA-TNC message
  
     o  Not act maliciously to the Posture Broker Server and Posture
        Validators, including attacks such as Denial Of Service
  
  5.1.2. Posture Validator
  
     The Posture Validators are trusted by Posture Collectors to:
  
     o  Only request information necessary to assess the security
        state of the endpoint
  
     o  Make assessment decisions based on deployer defined policies
  
     o  Discard collected information consistent with data retention
        and privacy policies
  
     o  Not act maliciously to the Posture Broker Server and Posture
        Collectors, including attacks such as Denial Of Service
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 48]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  5.1.3. Posture Broker Client, Posture Broker Server, and PB-TNC
  
     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
  
     o  Not act maliciously to drop messages, duplicate messages, or
        flood the Posture Collectors and Posture Validators with
        unnecessary messages
  
     o  Not observe, fabricate, or alter the contents of a PA-TNC
        message (this trust can be minimized with a PA-TNC security
        protocol)
  
     o  Properly place Posture Collector and Posture Validator
        identifiers into the PB-TNC protocol, deliver those
        identifiers to Posture Collectors and Posture Validators as
        needed, and manage exclusive delivery to a particular Posture
        Collector or Posture Validator
  
     o  Properly expose authentication information from PT security
        so that Posture Collectors and Posture Validators can use
        this to make policy decisions
  
  5.2. Security Threats
  
     Beyond the trusted relationships assumed in section 5.1, the PA-
     TNC protocol faces a number of potential security attacks that
     could require targeted security countermeasures.  PA-TNC
     security protocol specifications MUST state if and how the
     security protocol will safeguard against these types of attack.
  
     Generally the PA-TNC protocol, without the presence of security
     countermeasures, relies upon the underlying PT protocol to
     protect the messages from attack when traveling over the
     network.  Once the message resides on the Posture Broker Client
     or Posture Broker Server, it is trusted to be properly and
     safely delivered to the appropriate Posture Collectors and
     Posture Validators.  However, in some deployments the PA-TNC
     messages need to travel over network hops that are not protected
  
  
  Sangster               Expires October 5, 2008           [Page 49]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     by PT or require more assurance that only the appropriate
     Posture Collector or Posture Validator has received the message.
     In these cases, end to end PA-TNC message protection might be
     required.  The following sub-sections focus on the potential
     threats where end to end protection might be desired and thus
     when the use of the PA-TNC security protocol becomes beneficial.
  
  5.2.1. Attribute Theft
  
     When PA-TNC messages are sent over unprotected network links or
     spanning local software stacks that are not trusted, the
     contents of the PA-TNC messages may be subject to information
     theft by an intermediary party.  This theft could result in
     information being recorded for future use or analysis by the
     adversary.  Attributes observed by eavesdroppers could contain
     information that exposes potential weaknesses in the security of
     the endpoint, or system fingerprinting information easing the
     ability of the attacker to employ attacks more likely to be
     successful against the endpoint.  The eavesdropper might also
     learn information about the endpoint or network policies that
     either singularly or collectively is considered sensitive
     information (e.g. certain endpoints are lacking patches, or
     particular sub-networks have more lenient policies).  PA-TNC
     attributes are not intended to carry privacy-sensitive
     information, but should some exist in a message, the adversary
     could come into possession of the information which could be
     used for other financial gain.
  
  5.2.2. Message Fabrication
  
     Attackers on the network or present within the NEA system could
     introduce fabricated PA-TNC messages intending to trick or
     create a denial of service against aspects of an assessment.
     This could occur if an active attacker could launch a man-in-
     the-middle (MiTM) attack by proxying the PA-TNC messages and was
     able to replace undesired messages with ones easing future
     attack upon the endpoint.  Consider a scenario where PT security
     protection is not used, and the Posture Broker Server proxies
     all assessment traffic to a remote Posture Broker Server.  The
     proxy could eavesdrop and replace assessment results attributes,
     tricking the endpoint into thinking it has passed an assessment,
     when in fact it has not and requires remediation.  Because the
     Posture Collector has no way to verify that attributes were
     actually created by an authentic Posture Validator, it is unable
     to detect the falsified attribute or message.
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 50]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  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 attacker would change the version string sent by
     the firewall Posture Collector to the current version number, so
     the Posture Validator's assessment passes while leaving the
     endpoint vulnerable to attack.  Similarly, an attacker could
     achieve widespread denial of service by altering large numbers
     of assessments' version string attributes to an old value so
     they repeatedly fail assessments even after a successful
     remediation.  Upon receiving the lower value, the Posture
     Validator would continue to believe that the endpoint is running
     old, potentially vulnerable versions of the firewall that does
     not meet network compliance policy, so therefore the endpoint
     would not be allowed to join the network.
  
  5.2.4. Attribute Replay
  
     Another potential attack against an unprotected PA-TNC message
     attribute exchange is to exploit the lack of a strong binding
     between the attributes sent during an assessment to the specific
     endpoint.  Without a strong binding of the endpoint to the
     measurement information, an attacker could record the attributes
     sent during an assessment of a compliant endpoint and later
     replay those attributes so that a non-compliant endpoint can now
     gain access to the network or protected resource.  This attack
     could be employed by a network MiTM that is able to eavesdrop
     and proxy message exchanges, or by using local rogue agents on
     the endpoints.  Assessments lacking some form of freshness
     exchange could be subject to replay of prior assessment data,
     even if it no longer reflects the current state of the endpoint.
  
  5.2.5. Attribute Insertion
  
     Similar to the attribute modification attacks, an adversary
     wishing to include one or more attributes or PA-TNC messages
     inside a valid assessment may be able to insert the attributes
     or messages without detection is possible by the recipient.
     Even if authentication of the parties is present during a PA-TNC
  
  
  Sangster               Expires October 5, 2008           [Page 51]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     exchange, if no per-message and per-session integrity protection
     is present, an attacker can add information to the assessment,
     possibly causing incorrect assessment results.  For example, an
     attacker could add attributes to the front of a PA-TNC message
     to cause an assessment to succeed even for a non-compliant
     endpoint, particularly if it knew that the recipient ignored
     repeated attributes within a message.  Similarly, if a Posture
     Collector or Posture Validator always generated an error if it
     saw unexpected attributes, the attacker could cause failures and
     denial of service by adding attributes or messages to an
     exchange.
  
  5.2.6. Denial of Service
  
     A variety of types of denial of service attacks are possible
     against the PA-TNC message exchange if left unprotected to
     untrusted parties along the communication path between the
     Posture Collector and Posture Validator.   Normally, the PT
     exchange is bi-directionally authenticated which helps to
     prevent a MiTM on the network from becoming an active proxy, but
     transparent message routing gateways may still exist on the
     communication path and can modify the integrity of the message
     exchange unless adequate integrity protection is provided.  If
     the MiTM or other entities on the network can send messages to
     the Posture Broker Client or Posture Broker Server that appear
     to be part of an assessment, these messages could confuse the
     Posture Collector and Posture Validator or cause them to perform
     unnecessary work or take incorrect action.  Several example
     denial of service situations are described in section 5.2.3 and
     5.2.5.  Many potential denial of service examples exist,
     including flooding messages to Posture Collector or Posture
     Validator, sending very large messages containing many
     attributes, and repeatedly asking for resource intensive
     operations.
  
  6. Privacy Considerations
  
     The PA-TNC protocol is designed to allow for controlled
     disclosure of security relevant information about an endpoint,
     specifically for the purpose of enabling an assessment of the
     endpoint's compliance with network policy.  The purpose of this
     protocol is to provide visibility into the state of the
     protective mechanisms on the endpoint, in order for the Posture
     Validators and Posture Broker Server to determine whether the
     endpoint is up to date and thus has the best chance of being
     resilient in the face of malware threats.  One risk associated
     with providing visibility into the contents of an endpoint is
  
  
  Sangster               Expires October 5, 2008           [Page 52]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     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 2.4.  These components include a list
     of security-related aspects of the endpoint that affect the
     ability of the endpoint to resist attacks and thus are of
     interest during an assessment.  Discretionary components used by
     the user to create or view content are not on the list, as they
     are more likely to have access to privacy sensitive information.
     Similarly, PA-TNC messages contain a set of attributes which
     describe the particular component.  Each attribute contains
     generic information (e.g. product information or versions) about
     the component, so it is unlikely to include any user specific or
     identifying information.  This combination of limited set of
     security related components with non-user specific attributes
     greatly reduces the risk of exposure of privacy sensitive
     information.  Vendors that choose to define additional component
     types and/or attributes within their name space are encouraged
     to provide similar constraints.
  
     Even with the bounding of standard attribute information to
     specific components, it is possible that individuals might wish
     to share less information with different networks they wish to
     access.  For example, a user may wish to share more information
     when connecting or being reassessed by the user's employer
     network than what would be made available to the local coffee
     shop wireless network.  While these situations do not impact the
     protocol itself, they do suggest that Posture Collector
     implementations should consider supporting a privacy filter
     allowing the user and/or system owner to restrict access to
     certain attributes based upon the target network.  The
     underlying PT protocol authenticates the network's Posture
     Broker Server at the start of an assessment, so identity can be
     made available to the Posture Collector and per-network privacy
     filtering is possible.  Network owners should make available a
     list of the attributes they require to perform an assessment and
     any privacy policy they enforce when handling the data.  Users
     wishing to use a more restricted privacy filter on the endpoint
     may risk not being able to pass an assessment and thus not gain
     access to the requested network or resource.
  
  
  
  Sangster               Expires October 5, 2008           [Page 53]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  7. IANA Considerations
  
     Two new IANA registries are defined by this specification: IETF
     Standard PA-TNC Attribute Types and IETF Standard PA-TNC Error
     Codes.  This section explains how these registries work. Also,
     this specification defines nine new IETF Standard PA Subtypes.
     These assignments will be added to the registry for IETF
     Standard PA Subtypes when this document is approved by the IESG
     as an RFC.
  
     Section 7.1 defines the new IETF Standard PA Subtypes. Sections
     7.2 and 7.3 provide guidance to the IANA in creating and
     managing the two new IANA registries defined by this
     specification.
  
  7.1. New IETF Standard PA Subtypes
  
     Section 2.4 of this specification defines several new IETF
     Standard PA Subtypes. Here is a list of these assignments:
  
     Number   Name
     ------   ----
     0        Testing
     1        Operating System
     2        Anti-Virus
     3        Anti-Spyware
     4        Anti-Malware
     5        Firewall
     6        IDPS
     7        VPN
  
     Once this document becomes an RFC, these IETF Standard PA
     Subtypes should be added to the registry for IETF Standard PA
     Subtypes defined in the PB-TNC specification. The RFC number
     assigned to this document should be associated with these
     assignments.
  
  7.2. Registry for IETF Standard PA-TNC Attribute Types
  
     The name for this registry is "IETF Standard PA-TNC Attribute
     Types".  Each entry in this registry should include a human-
     readable name, a decimal integer value between 0 and 2^32-1, and
     a reference to an RFC where the contents of this attribute type
     are defined.  This RFC 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
  
  
  
  Sangster               Expires October 5, 2008           [Page 54]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     designated numeric value in the PA-TNC Attribute Type field and
     the value 0 in the PA-TNC Attribute Vendor ID field.
  
     Entries to this registry may only be added by IETF Consensus, as
     defined in RFC 2434 [3].  That is, they can only be added in an
     RFC approved by the IESG.
  
     The following entries for this registry are defined in this
     document.  Once this document becomes an RFC, they should become
     the initial entries in the registry for IETF Standard PA-TNC
     Attribute Types.
  
     Integer Value  Name                      Defining RFC
     -------------  ----                      ------------
     0              Testing                   RFC # Assigned to this I-D
     1              Attribute Request         RFC # Assigned to this I-D
     2              Product Information       RFC # Assigned to this I-D
     3              Numeric Version           RFC # Assigned to this I-D
     4              String Version            RFC # Assigned to this I-D
     5              Operational Status        RFC # Assigned to this I-D
     6              Port Filter               RFC # Assigned to this I-D
     7              Installed Packages        RFC # Assigned to this I-D
     8              PA-TNC Error              RFC # Assigned to this I-D
  
  7.3. Registry for IETF Standard PA-TNC Error Codes
  
     The name for this registry is "IETF Standard PA-TNC Error
     Codes".  Each entry in this registry should include a human-
     readable name, a decimal integer value between 0 and 2^32-1, and
     a reference to an RFC where this error code is defined.  This
     RFC 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 numeric value in the PA-TNC
     Error Code field, and the value 0 in the PA-TNC Error Code
     Vendor ID field.
  
     Entries to this registry may only be added by IETF Consensus, as
     defined in RFC 2434.  That is, they can only be added in an RFC
     approved by the IESG.
  
     The following entries for this registry are defined in this
     document.  Once this document becomes an RFC, they should become
     the initial entries in the registry for IETF Standard PA-TNC
     Error Codes.
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 55]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     Integer Value  Name                      Defining RFC
     -------------  ----                      ------------
     1              Invalid Parameter         RFC # Assigned to this I-D
     2              Version Not Supported     RFC # Assigned to this I-D
     3           Attribute Type Not Supported RFC # Assigned to this I-D
  
  8. Acknowledgments
  
     The authors of this draft would like to acknowledge the
     following people who have contributed to or provided substantial
     input on the preparation of this document or predecessors to it:
     Stuart Bailey, Roger Chickering, Lauren Giroux, Charles
     Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg
     Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa
     Lorenzin, Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio
     Sanchez, Brad Upson, and Han Yin.
  
     This document was prepared using 2-Word-v2.0.template.dot.
  
  9. References
  
  9.1. Normative References
  
     [1]   Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.
  
     [2]   F. Yergeau, "UTF-8, a transformation format of ISO 10646",
           RFC 3629, November 2003.
  
     [3]   Alvestrand, H. and T. Narten, "Guidelines for Writing an
           IANA Considerations Section in RFCs", RFC 2434, October
           1998.
  
     [4]   Klyne, G. and C. Newman, "Date and Time on the Internet:
           Timestamps", RFC 3339, July 2002.
  
     [5]   Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture
           Broker Protocol (PB) Compatible with TNC", draft-ietf-nea-
           pb-tnc-00.txt, Work In Progress, April 2008.
  
  9.2. Informative References
  
     [6]   Trusted Computing Group, "IF-M: TLV Binding", February
           2008.
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 56]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
     [7]   Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
           Tardo, "Network Endpoint Assessment (NEA): Overview and
           Requirements", draft-ietf-nea-requirements-06.txt, Work In
           Progress, February 2008.
  
     [8]   Sangster, P., "PA-TNC Security: A Posture Attribute (PA)
           Security Protocol Compatible with TNC", draft-sangster-
           nea-pa-tnc-security-00.txt, Work In Progress, February
           2008.
  
  Author's Address
  
     Paul Sangster
     Symantec Corporation
     6825 Citrine Drive
     Carlsbad, CA 92009 USA
     Phone: +1.760.438.5656
     Email: Paul_Sangster@symantec.com
  
  
  Intellectual Property Statement
  
     The IETF takes no position regarding the validity or scope of
     any Intellectual Property Rights or other rights that might be
     claimed to pertain to the implementation or use of the
     technology described in this document or the extent to which any
     license under such rights might or might not be available; nor
     does it represent that it has made any independent effort to
     identify any such rights.  Information on the procedures with
     respect to rights in RFC documents can be found in BCP 78 and
     BCP 79.
  
     Copies of IPR disclosures made to the IETF Secretariat and any
     assurances of licenses to be made available, or the result of an
     attempt made to obtain a general license or permission for the
     use of such proprietary rights by implementers or users of this
     specification can be obtained from the IETF on-line IPR
     repository at http://www.ietf.org/ipr.
  
     The IETF invites any interested party to bring to its attention
     any copyrights, patents or patent applications, or other
     proprietary rights that may cover technology that may be
     required to implement this standard.  Please address the
     information to the IETF at ietf-ipr@ietf.org.
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 57]
  

  Internet-Draft                  PA-TNC                   April 2008
  
  
  Disclaimer of Validity
  
     This document and the information contained herein are provided
     on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
     THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
     ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
     ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
     INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
     OR FITNESS FOR A PARTICULAR PURPOSE.
  
  Copyright Statement
  
     Copyright (C) The IETF Trust (2008).
  
     This document is subject to the rights, licenses and
     restrictions contained in BCP 78, and except as set forth
     therein, the authors retain all their rights.
  
  Acknowledgment
  
     Funding for the RFC Editor function is currently provided by the
     Internet Society.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Sangster               Expires October 5, 2008           [Page 58]
  

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