[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-nea-pa-tnc

     Network Working Group                                   P. Sangster
     Internet Draft                                 Symantec Corporation
     Intended status: Proposed Standard
     Expires: August 2008
     
                                                       February 18, 2008
     
         PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC
                        draft-sangster-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 August 7, 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 August 7, 2008             [Page 1]
     

     Internet-Draft                  PA-TNC                February 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.............................9
           2.4. IETF Standard PA Subtypes.............................9
           2.5. PA-TNC Message Header Format.........................10
        3. PA-TNC Attributes.........................................12
           3.1. PA-TNC Attribute Header..............................12
           3.2. IETF Standard PA-TNC Attribute Types.................16
              3.2.1. Attribute Request...............................18
              3.2.2. Product Information.............................20
              3.2.3. Numeric Version.................................22
              3.2.4. String Version..................................24
              3.2.5. Operational Status..............................27
              3.2.6. Port Filter.....................................30
              3.2.7. Installed Packages..............................32
              3.2.8. PA-TNC Error....................................35
                 3.2.8.1. Definition of Invalid Parameter Error Code.38
                 3.2.8.2. Definition of Version Not Supported Error
                          Code.......................................39
                 3.2.8.3. Definition of Attribute Type Not Supported
                          Error Code.................................41
           3.3. Vendor-Defined Attributes............................43
        4. Evaluation Against NEA Requirements.......................43
           4.1. Evaluation Against Requirement C-1...................44
           4.2. Evaluation Against Requirement C-2...................44
           4.3. Evaluation Against Requirement C-3...................44
           4.4. Evaluation Against Requirement C-4...................44
           4.5. Evaluation Against Requirement C-5...................45
           4.6. Evaluation Against Requirement C-6...................45
           4.7. Evaluation Against Requirement C-7...................46
           4.8. Evaluation Against Requirement C-8...................46
           4.9. Evaluation Against Requirement C-9...................46
     
     
     Sangster                Expires August 7, 2008             [Page 2]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           4.10. Evaluation Against Requirement C-10.................47
           4.11. Evaluation Against Requirement PA-1.................47
           4.12. Evaluation Against Requirement PA-2.................48
           4.13. Evaluation Against Requirement PA-3.................48
           4.14. Evaluation Against Requirement PA-4.................48
           4.15. Evaluation Against Requirement PA-5.................49
           4.16. Evaluation Against Requirement PA-6.................49
        5. Security Considerations...................................50
           5.1. Trust Relationships..................................50
              5.1.1. Posture Collector...............................50
              5.1.2. Posture Validator...............................51
              5.1.3. Posture Broker Client, Posture Broker Server,
                     and PB-TNC......................................51
           5.2. Security Threats.....................................52
              5.2.1. Attribute Theft.................................52
              5.2.2. Message Fabrication.............................53
              5.2.3. Attribute Modification..........................53
              5.2.4. Attribute Replay................................53
              5.2.5. Attribute Insertion.............................54
              5.2.6. Denial of Service...............................54
        6. Privacy Considerations....................................55
        7. IANA Considerations.......................................56
           7.1. New IETF Standard PA Subtypes........................56
           7.2. Registry for IETF Standard PA-TNC Attribute Types....57
           7.3. Registry for IETF Standard PA-TNC Error Codes........58
        8. Acknowledgments...........................................59
        9. References................................................59
           9.1. Normative References.................................59
           9.2. Informative References...............................59
        Author's Address.............................................60
        Intellectual Property Statement..............................60
        Disclaimer of Validity.......................................61
     
     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 August 7, 2008             [Page 3]
     

     Internet-Draft                  PA-TNC                February 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 August 7, 2008             [Page 4]
     

     Internet-Draft                  PA-TNC                February 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 August 7, 2008             [Page 5]
     

     Internet-Draft                  PA-TNC                February 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 August 7, 2008             [Page 6]
     

     Internet-Draft                  PA-TNC                February 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 August 7, 2008             [Page 7]
     

     Internet-Draft                  PA-TNC                February 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
     
     
     Sangster                Expires August 7, 2008             [Page 8]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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-
        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
     
     
     Sangster                Expires August 7, 2008             [Page 9]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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
     
        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
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 10]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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.
     
           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
     
     
     Sangster                Expires August 7, 2008            [Page 11]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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.
        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
     
     
     Sangster                Expires August 7, 2008            [Page 12]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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:
     
                           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
     
     
     Sangster                Expires August 7, 2008            [Page 13]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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
     
           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
     
     
     
     Sangster                Expires August 7, 2008            [Page 14]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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
           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
     
     
     Sangster                Expires August 7, 2008            [Page 15]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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
           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
     
     
     
     Sangster                Expires August 7, 2008            [Page 16]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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.
     
        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.
     
     
     Sangster                Expires August 7, 2008            [Page 17]
     

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

     Internet-Draft                  PA-TNC                February 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    |           PA-TNC Attribute Vendor ID          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      PA-TNC Attribute Type                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Reserved    |           PA-TNC Attribute Vendor ID          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      PA-TNC Attribute Type                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Reserved
     
           Reserved for future use.  This field MUST be set to 0 on
           transmission and ignored upon reception.
     
        PA-TNC Attribute Vendor ID
     
           This field contains the SMI Private Enterprise Number of the
           organization that controls the name space for the following
           PA-TNC Attribute Type.  This field enables IETF Standard PA-
           TNC Attributes and vendor-defined PA-TNC Attributes to be
           used without potential collisions.
     
           Any IETF Standard PA-TNC Attribute Types defined in section
           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
     
     
     Sangster                Expires August 7, 2008            [Page 19]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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.
        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).
     
     
     Sangster                Expires August 7, 2008            [Page 20]
     

     Internet-Draft                  PA-TNC                February 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.
     
                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Product Vendor ID               |  Product ID   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Product ID   |         Product Name (Variable Length)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Product Vendor ID
     
           This field contains the SMI Private Enterprise Number for the
           product creator.  If the SMI PEN for the product creator is
           unknown or if the product creator does not have an SMI PEN,
           the Product Vendor ID field MUST be set to 0 and the identity
           of the product creator SHOULD be included in the Product Name
           along with the name of the product.
     
        Product ID
     
           This field identifies the product using a numeric identifier
           assigned by the product creator.  If this Product ID value is
           unknown or if the product creator has not assigned such a
           value, this field MUST be set to 0. If the Product Vendor ID
           is 0, this field MUST be set to 0. In any case, the name of
           the product SHOULD be included in the Product Name field.
     
           Note that a particular Product ID value (e.g. 635) will have
           completely different meanings depending on the Product Vendor
           ID. Each Product Vendor ID defines a different space of
           Product ID values. Product creators are encouraged to publish
           lists of Product ID values for their products.
     
        Product Name
     
           This variable length field contains a UTF-8 [2] string
           identifying the product (e.g. "Symantec Norton AntiVirus(TM)
           2008") in enough detail to unambiguously distinguish it from
     
     
     Sangster                Expires August 7, 2008            [Page 21]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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.
     
        All Posture Collectors that implement the IETF Standard PA
        Subtype for Operating System SHOULD support sending this
        attribute type, at least for the Operating System PA subtype.
        Other Posture Collectors MAY support sending this attribute
        type.  Whether a particular Posture Collector actually sends
        this attribute type SHOULD still be governed by local privacy
        and security policies.  All Posture Validators that implement
        the IETF Standard PA Subtype for Operating System SHOULD support
        receiving this attribute type, at least for the Operating System
        PA subtype.  Other Posture Validators MAY support receiving this
        attribute type.  A Posture Validator that does not support
        receiving this attribute type SHOULD simply ignore attributes
        with this type.  Posture Validators MUST NOT send this attribute
        type.
     
     
     
     Sangster                Expires August 7, 2008            [Page 22]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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.
     
                            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.
     
     
     
     Sangster                Expires August 7, 2008            [Page 23]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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.
     
     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
     
     
     Sangster                Expires August 7, 2008            [Page 24]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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.
     
                            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
     
     
     
     Sangster                Expires August 7, 2008            [Page 25]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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.
     
        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
     
     
     Sangster                Expires August 7, 2008            [Page 26]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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
        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
     
     
     Sangster                Expires August 7, 2008            [Page 27]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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 August 7, 2008            [Page 28]
     

     Internet-Draft                  PA-TNC                February 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 August 7, 2008            [Page 29]
     

     Internet-Draft                  PA-TNC                February 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 August 7, 2008            [Page 30]
     

     Internet-Draft                  PA-TNC                February 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).
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 31]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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
           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
     
     
     Sangster                Expires August 7, 2008            [Page 32]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        implement any of the IETF Standard PA Subtypes defined in this
        document SHOULD support receiving this attribute type, at least
        for those PA subtypes.  Other Posture Validators MAY support
        receiving this attribute type.  A Posture Validator that does
        not support receiving this attribute type SHOULD simply ignore
        attributes with this type.  Posture Validators MUST NOT send
        this attribute type.
     
        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 August 7, 2008            [Page 33]
     

     Internet-Draft                  PA-TNC                February 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
     
     
     
     Sangster                Expires August 7, 2008            [Page 34]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           Installed Packages attribute. The meaning of doing so is not
           defined here.
     
        Version Len
     
           This field is an unsigned 8-bit integer that indicates the
           length of the Package Version Number field in octets. This
           field may be zero if a Package Version Number is not
           available.
     
        Package Version Number
     
           This field contains the version string for the package named
           in the previous Package Name field.  This field is a UTF-8
           encoded character string whose octet length is given by the
           Version Len field. This field MUST NOT include extra octets
           for padding or NUL character termination.  The syntax and
           semantics of this version string are not specified in this
           document, since they may vary across products and/or
           operating systems. Posture Collectors 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.
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 35]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        A PA-TNC error code SHOULD be sent with the same PA Message
        Vendor ID and PA Subtype used by the PA-TNC message that caused
        the error so that the error code is sent to the party who sent
        the offending PA-TNC message. Other measures (such as setting
        PB-TNC's EXCL flag and Posture Collector Identifier or Posture
        Validator Identifier fields) SHOULD also be taken to attempt to
        ensure that only the party who sent the offending message
        receives the error.
     
        When a PA-TNC error code is received, the recipient MUST NOT
        respond with a PA-TNC error code because this could result in an
        infinite loop of errors. Instead, the recipient MAY log the
        error, modify its behavior to attempt to avoid the error
        (attempting to avoid loops or long strings of errors), ignore
        the error, terminate the assessment, or take other action as
        appropriate (as long as it is consistent with the requirements
        of this specification).
     
        Posture 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
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 36]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           This field is reserved for future use.  This field MUST be
           set to 0 on transmission and ignored upon reception.
     
        PA-TNC Error Code Vendor ID
     
           This field contains the SMI Private Enterprise Number for the
           organization that defined the PA-TNC Error Code that is being
           used in the attribute.  For IETF Standard PA-TNC Error Code
           values this field MUST be set to zero (0).
     
        PA-TNC Error Code
     
           This field contains the PA-TNC Error Code being reported in
           this attribute. Note that a particular PA-TNC Error Code
           value will have completely different meanings depending on
           the PA-TNC Error Code Vendor ID. Each PA-TNC Error Code
           Vendor ID defines a different space of PA-TNC Error Code
           values.
     
           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
     
     
     Sangster                Expires August 7, 2008            [Page 37]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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.
     
        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
     
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 38]
     

     Internet-Draft                  PA-TNC                February 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.
     
        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
        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
     
     
     
     Sangster                Expires August 7, 2008            [Page 39]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        exchange can proceed properly, no matter what versions of PA-TNC
        the parties implement.
     
        The following diagram illustrates the format and contents of the
        Error Information field for this error code.  The text after
        this diagram describes the fields shown here.
     
                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Version    |                Copy of Reserved               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Message Identifier                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Max Version  |  Min Version  |            Reserved           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Version
     
           This field MUST contain an exact copy of the Version field in
           the PA-TNC Message Header of the PA-TNC message that caused
           this error.
     
        Copy of Reserved
     
           This field MUST contain an exact copy of the Reserved field
           in the PA-TNC Message Header of the PA-TNC message that
           caused this error.
     
        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.
     
     
     
     Sangster                Expires August 7, 2008            [Page 40]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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 August 7, 2008            [Page 41]
     

     Internet-Draft                  PA-TNC                February 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
     
     
     
     Sangster                Expires August 7, 2008            [Page 42]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
           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.
     
     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
     
     
     Sangster                Expires August 7, 2008            [Page 43]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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.
     
        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:
     
     
     
     Sangster                Expires August 7, 2008            [Page 44]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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.
     
     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
     
     
     Sangster                Expires August 7, 2008            [Page 45]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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.
     
        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.
     
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 46]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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.
     
     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.
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 47]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
     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.
        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
     
     
     Sangster                Expires August 7, 2008            [Page 48]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
              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.
     
        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
     
     
     Sangster                Expires August 7, 2008            [Page 49]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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
        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
     
     
     
     Sangster                Expires August 7, 2008            [Page 50]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
     5.1.2. Posture Validator
     
        The Posture Validators are trusted by Posture Collectors to:
     
        o  Only request information necessary to assess the security
           state of the endpoint
     
        o  Make assessment decisions based on deployer defined policies
     
        o  Discard collected information consistent with data retention
           and privacy policies
     
        o  Not act maliciously to the Posture Broker Server and Posture
           Collectors, including attacks such as Denial Of Service
     
     5.1.3. Posture Broker Client, Posture Broker Server, 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
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 51]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
     5.2. Security Threats
     
        Beyond the trusted relationships assumed in section 5.1, the PA-
        TNC protocol faces a number of potential security attacks that
        could require targeted security countermeasures.  PA-TNC
        security protocol specifications MUST state if and how the
        security protocol will safeguard against these types of attack.
     
        Generally the PA-TNC protocol, without the presence of security
        countermeasures, relies upon the underlying PT protocol to
        protect the messages from attack when traveling over the
        network.  Once the message resides on the Posture Broker Client
        or Posture Broker Server, it is trusted to be properly and
        safely delivered to the appropriate Posture Collectors and
        Posture Validators.  However, in some deployments the PA-TNC
        messages need to travel over network hops that are not protected
        by PT or require more assurance that only the appropriate
        Posture Collector or Posture Validator has received the message.
        In these cases, end to end PA-TNC message protection might be
        required.  The following sub-sections focus on the potential
        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.
     
     
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 52]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
     5.2.2. Message Fabrication
     
        Attackers on the network or present within the NEA system could
        introduce fabricated PA-TNC messages intending to trick or
        create a denial of service against aspects of an assessment.
        This could occur if an active attacker could launch a man-in-
        the-middle (MiTM) attack by proxying the PA-TNC messages and was
        able to replace undesired messages with ones easing future
        attack upon the endpoint.  Consider a scenario where PT security
        protection is not used, and the Posture Broker Server proxies
        all assessment traffic to a remote Posture Broker Server.  The
        proxy could eavesdrop and replace assessment results attributes,
        tricking the endpoint into thinking it has passed an assessment,
        when in fact it has not and requires remediation.  Because the
        Posture Collector has no way to verify that attributes were
        actually created by an authentic Posture Validator, it is unable
        to detect the falsified attribute or message.
     
     5.2.3. Attribute Modification
     
        This attack could allow an active attacker capable of
        intercepting a message to modify a PA-TNC message attribute to a
        desired value to ease the compromise of an endpoint.  Without
        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
     
     
     Sangster                Expires August 7, 2008            [Page 53]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        endpoint.  Without a strong binding of the endpoint to the
        measurement information, an attacker could record the attributes
        sent during an assessment of a compliant endpoint and later
        replay those attributes so that a non-compliant endpoint can now
        gain access to the network or protected resource.  This attack
        could be employed by a network MiTM that is able to eavesdrop
        and proxy message exchanges, or by using local rogue agents on
        the endpoints.  Assessments lacking some form of freshness
        exchange could be subject to replay of prior assessment data,
        even if it no longer reflects the current state of the endpoint.
     
     5.2.5. Attribute Insertion
     
        Similar to the attribute modification attacks, an adversary
        wishing to include one or more attributes or PA-TNC messages
        inside a valid assessment may be able to insert the attributes
        or messages without detection is possible by the recipient.
        Even if authentication of the parties is present during a PA-TNC
        exchange, if no per-message and per-session integrity protection
        is present, an attacker can add information to the assessment,
        possibly causing incorrect assessment results.  For example, an
        attacker could add attributes to the front of a PA-TNC message
        to cause an assessment to succeed even for a non-compliant
        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
     
     
     Sangster                Expires August 7, 2008            [Page 54]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        5.2.5.  Many potential denial of service examples exist,
        including flooding messages to Posture Collector or Posture
        Validator, sending very large messages containing many
        attributes, and repeatedly asking for resource intensive
        operations.
     
     6. Privacy Considerations
     
        The PA-TNC protocol is designed to allow for controlled
        disclosure of security relevant information about an endpoint,
        specifically for the purpose of enabling an assessment of the
        endpoint's compliance with network policy.  The purpose of this
        protocol is to provide visibility into the state of the
        protective mechanisms on the endpoint, in order for the Posture
        Validators and Posture Broker Server to determine whether the
        endpoint is up to date and thus has the best chance of being
        resilient in the face of malware threats.  One risk associated
        with providing visibility into the contents of an endpoint is
        the increased chance for exposure of privacy sensitive
        information without the consent of the user.
     
        While this protocol does provide the Posture Validator the
        ability to request specific information about the endpoint, the
        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
     
     
     Sangster                Expires August 7, 2008            [Page 55]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        access.  For example, a user may wish to share more information
        when connecting or being reassessed by the user's employer
        network than what would be made available to the local coffee
        shop wireless network.  While these situations do not impact the
        protocol itself, they do suggest that Posture Collector
        implementations should consider supporting a privacy filter
        allowing the user and/or system owner to restrict access to
        certain attributes based upon the target network.  The
        underlying PT protocol authenticates the network's Posture
        Broker Server at the start of an assessment, so identity can be
        made available to the Posture Collector and per-network privacy
        filtering is possible.  Network owners should make available a
        list of the attributes they require to perform an assessment and
        any privacy policy they enforce when handling the data.  Users
        wishing to use a more restricted privacy filter on the endpoint
        may risk not being able to pass an assessment and thus not gain
        access to the requested network or resource.
     
     7. IANA Considerations
     
        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
     
     
     Sangster                Expires August 7, 2008            [Page 56]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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
        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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Sangster                Expires August 7, 2008            [Page 57]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        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 August 7, 2008            [Page 58]
     

     Internet-Draft                  PA-TNC                February 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 # For 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-sahita-
              nea-pb-00.txt, Work In Progress, February 2008.
     
     9.2. Informative References
     
        [6]   Trusted Computing Group, "IF-M: TLV Binding", February
              2008.
     
     
     Sangster                Expires August 7, 2008            [Page 59]
     

     Internet-Draft                  PA-TNC                February 2008
     
     
        [7]   Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
              Tardo, "Network Endpoint Assessment (NEA): Overview and
              Requirements", draft-ietf-nea-requirements-05.txt, Work In
              Progress, November 2007.
     
        [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 August 7, 2008            [Page 60]
     

     Internet-Draft                  PA-TNC                February 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 August 7, 2008            [Page 61]
     

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