tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5792

 
 
 

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

Part 3 of 4, p. 31 to 58
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 31 
4.2.7.  Installed Packages

   This PA-TNC Attribute Type contains a list of the installed packages
   that comprise a product on the endpoint that implements the component
   specified in the PA Subtype field, as described in section 3.5.  This
   allows a Posture Validator to check which packages are installed for
   a particular product and which versions of those packages are
   installed.

   Posture Collectors that implement any of the IETF Standard PA
   Subtypes defined in this document SHOULD support sending this
   attribute type for those PA subtypes.  Other Posture Collectors MAY
   support sending this attribute type, if it is appropriate to their PA
   subtype.  Whether a particular Posture Collector actually sends this
   attribute type SHOULD still be governed by local privacy and security
   policies.  Posture Validators that implement any of the IETF Standard
   PA Subtypes defined in this document SHOULD support receiving this
   attribute type, at least for those PA subtypes.  Other Posture
   Validators MAY support receiving this attribute type.  A Posture
   Validator that does not support receiving this attribute type SHOULD
   simply ignore attributes with this type.  Posture Validators MUST NOT
   send this attribute type.

Top      Up      ToC       Page 32 
   This attribute type can be quite long, especially for the Operating
   System PA subtype.  This can cause problems, especially with 802.1X
   and other limited transport protocols.  Therefore, Posture Collectors
   SHOULD NOT send this attribute unless specifically requested to do so
   using the Attribute Request attribute or otherwise configured to do
   so.  Also, Posture Validators SHOULD NOT request this attribute
   unless the transport protocol in use can support the large amount of
   data that may be sent in response.

   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
   set to zero (0) and the PA-TNC Attribute Type field MUST be set to 7.
   The value in the PA-TNC Attribute Length field will vary, depending
   on the number of packages and the length of the Package Name and
   Package Version Number fields for those packages.  However, the value
   in the PA-TNC Attribute Length field MUST be at least 16 because this
   is the length of the fixed-length fields in the PA-TNC Attribute
   Header and the fixed-length fields in this attribute type.  If the
   PA-TNC Attribute Length field is less than the size of these fixed-
   length fields or does not match the length indicated by the sum of
   the fixed-length and variable-length fields, implementations SHOULD
   respond with an Invalid Parameter PA-TNC error code.

   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after this
   diagram describes the fields shown here.

   Note that this diagram shows an attribute containing information on
   one package.  The actual number of package descriptions included in
   an Installed Packages attribute is indicated by the Package Count
   field.  This value may vary from zero to a large number (up to 65535,
   if the underlying PT protocol can support that many).  If this number
   is not sufficient, specialized patch management software should be
   employed that can simply report compliance with a pre-established
   patch policy.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |         Package Count         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Pkg Name Len  |        Package Name (Variable Length)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Version Len  |    Package Version Number (Variable Length)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 33 
   Reserved

      This field is reserved for future use.  The field MUST be set to 0
      on transmission and ignored upon reception.

   Package Count

      This field is an unsigned 16-bit integer that indicates the number
      of packages listed in this attribute.  For each package so
      indicated, a Pkg Name Len, Package Name, Version Len, and Package
      Version Number field is included in the attribute.

   Pkg Name Len

      This field is an unsigned 8-bit integer that indicates the length
      of the Package Name field in octets.  This field may be zero if a
      Package Name is not available.

   Package Name

      This field contains the name of the package associated with the
      product.  This field is a UTF-8 encoded character string whose
      octet length is given by the Pkg Name Len field.  This field MUST
      NOT include extra octets for padding or NUL character termination.
      The syntax and semantics of this name are not specified in this
      document, since they may vary across products and/or operating
      systems.  Posture Collectors MAY list two packages with the same
      name in a single Installed Packages attribute.  The meaning of
      doing so is not defined here.

   Version Len

      This field is an unsigned 8-bit integer that indicates the length
      of the Package Version Number field in octets.  This field may be
      zero if a Package Version Number is not available.

   Package Version Number

      This field contains the version string for the package named in
      the previous Package Name field.  This field is a UTF-8 encoded
      character string whose octet length is given by the Version Len
      field.  This field MUST NOT include extra octets for padding or
      NUL character termination.  The syntax and semantics of this
      version string are not specified in this document, since they may
      vary across products and/or operating systems.  Posture Collectors

Top      Up      ToC       Page 34 
      MAY list two packages with the same Package Version Number (and
      even the same Package Name and Package Version Number) in a single
      Installed Packages attribute.  The meaning of doing so is not
      defined here.

4.2.8.  PA-TNC Error

   This PA-TNC Attribute Type contains an error code and supplemental
   information regarding an error pertaining to PA-TNC.

   All Posture Collectors and Posture Validators that implement any of
   the IETF Standard PA Subtypes defined in this specification MUST
   support sending and receiving this attribute type, at least for those
   PA subtypes.

   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
   set to zero (0) and the PA-TNC Attribute Type field MUST be set to 8.
   The value in the PA-TNC Attribute Length field will vary, depending
   on the length of the Error Information field.  However, the value in
   the PA-TNC Attribute Length field MUST be at least 20 because this is
   the length of the fixed-length fields in the PA-TNC Attribute Header
   and the fixed-length fields in this attribute type.

   A PA-TNC error code SHOULD be sent with the same PA Message Vendor ID
   and PA Subtype used by the PA-TNC message that caused the error so
   that the error code is sent to the party who sent the offending PA-
   TNC message.  Other measures (such as setting PB-TNC's EXCL flag and
   Posture Collector Identifier or Posture Validator Identifier fields)
   SHOULD also be taken to attempt to ensure that only the party who
   sent the offending message receives the error.

   When a PA-TNC error code is received, the recipient MUST NOT respond
   with a PA-TNC error code because this could result in an infinite
   loop of errors.  Instead, the recipient MAY log the error, modify its
   behavior to attempt to avoid the error (attempting to avoid loops or
   long strings of errors), ignore the error, terminate the assessment,
   or take other action as appropriate (as long as it is consistent with
   the requirements of this specification).

   Posture Validators MUST NOT include this attribute type in an
   Attribute Request attribute.  It does not make sense for a Posture
   Validator to request that a Posture Collector send a PA-TNC Error
   attribute.

Top      Up      ToC       Page 35 
   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after this
   diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |            PA-TNC Error Code Vendor ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PA-TNC Error Code                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Error Information (Variable Length)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved

      This field is reserved for future use.  This field MUST be set to
      0 on transmission and ignored upon reception.

   PA-TNC Error Code Vendor ID

      This field contains the SMI Private Enterprise Number for the
      organization that defined the PA-TNC Error Code that is being used
      in the attribute.  For IETF Standard PA-TNC Error Code values this
      field MUST be set to zero (0).

   PA-TNC Error Code

      This field contains the PA-TNC Error Code being reported in this
      attribute.  Note that a particular PA-TNC Error Code value will
      have completely different meanings depending on the PA-TNC Error
      Code Vendor ID.  Each PA-TNC Error Code Vendor ID defines a
      different space of PA-TNC Error Code values.  Posture Collectors
      and Posture Validators MUST NOT require support for particular
      vendor-specific PA-TNC Error Codes and MUST interoperate with
      other parties despite any differences in the set of vendor-
      specific PA-TNC Error Codes supported (although they MAY permit
      administrators to configure them to require support for specific
      PA-TNC Error Codes).

      When the PA-TNC Error Code Vendor ID is set to zero (0), the PA-
      TNC Error Code is an IETF Standard PA-TNC Error Code.  IANA
      maintains a registry of PA-TNC Error Codes.  Entries in this
      registry are added by Expert Review with Specification Required,
      following the guidelines in section 7.

Top      Up      ToC       Page 36 
      The following table lists the IETF Standard PA-TNC Error Codes
      defined in this specification:

      Integer   Description
      -------   -----------
      0         Reserved
      1         Invalid Parameter
      2         Version Not Supported
      3         Attribute Type Not Supported

      The next few subsections of this document provide detailed
      definitions of these error codes.

   Error Information

      This field provides additional context for the error.  The
      contents of this field vary based on the PA-TNC Error Code Vendor
      ID and PA-TNC Error Code.  Therefore, whenever a PA-TNC Error Code
      is defined, the format of this field for that error code must also
      be defined.  The definitions of IETF Standard PA-TNC Error Codes
      on the next few pages provide good examples of such definitions.

      The length of this field can be determined by the recipient using
      the PA-TNC Attribute Length field by subtracting the length of the
      fixed-length fields in the PA-TNC Attribute Header and the fixed-
      length fields in this attribute.

4.2.8.1.  Invalid Parameter Error Code

   The Invalid Parameter error code is an IETF Standard PA-TNC Error
   Code (value 1) that indicates that the sender of this error code has
   detected an invalid value in a PA-TNC message sent by the recipient
   of this error code in the current assessment.

   For this error code, the Error Information field contains the first 8
   octets of the PA-TNC message that contained the invalid parameter and
   an offset indicating the position within that message of the invalid
   parameter.

Top      Up      ToC       Page 37 
   The following diagram illustrates the format and contents of the
   Error Information field for this error code.  The text after this
   diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |            Copy of Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Offset                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version

      This field MUST contain an exact copy of the Version field in the
      PA-TNC Message Header of the PA-TNC message that caused this
      error.

   Copy of Reserved

      This field MUST contain an exact copy of the Reserved field in the
      PA-TNC Message Header of the PA-TNC message that caused this
      error.

   Message Identifier

      This field MUST contain an exact copy of the Message Identifier
      field in the PA-TNC Message Header of the PA-TNC message that
      caused this error.

   Offset

      This field MUST contain an octet offset from the start of the PA-
      TNC Message Header of the PA-TNC message that caused this error to
      the start of the value that caused this error.  For instance, if
      the first PA-TNC attribute in the message had an invalid PA-TNC
      Attribute Length (e.g., 0), this value would be 16.

4.2.8.2.  Version Not Supported Error Code

   The Version Not Supported error code is an IETF Standard PA-TNC Error
   Code (value 2) that indicates that the sender of this error code does
   not support the PA-TNC version number included in the PA-TNC Message
   Header of a PA-TNC message sent by the recipient of this error code
   in the current assessment.

Top      Up      ToC       Page 38 
   For this error code, the Error Information field contains the first 8
   octets of the PA-TNC message that contained the unsupported version
   as well as Max Version and Min Version fields that indicate which PA-
   TNC version numbers are supported by the sender of the error code.

   The sender MUST support all PA-TNC versions between the Min Version
   and the Max Version, inclusive (i.e., including the Min Version and
   the Max Version).  When possible, recipients of this error code
   SHOULD send future messages to the Posture Collector or Posture
   Validator that originated this error message with a PA-TNC version
   number within the stated range.

   Any party that is sending the Version Not Supported error code MUST
   include that error code as the only PA-TNC attribute in a PA-TNC
   message with version number 1.  All parties that send PA-TNC messages
   MUST be able to properly process a message that meets this
   description, even if they cannot process any other aspect of PA-TNC
   version 1.  This ensures that a PA-TNC version exchange can proceed
   properly, no matter what versions of PA-TNC the parties implement.

   The following diagram illustrates the format and contents of the
   Error Information field for this error code.  The text after this
   diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |                Copy of Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Max Version  |  Min Version  |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version

      This field MUST contain an exact copy of the Version field in the
      PA-TNC Message Header of the PA-TNC message that caused this
      error.

   Copy of Reserved

      This field MUST contain an exact copy of the Reserved field in the
      PA-TNC Message Header of the PA-TNC message that caused this
      error.

Top      Up      ToC       Page 39 
   Message Identifier

      This field MUST contain an exact copy of the Message Identifier
      field in the PA-TNC Message Header of the PA-TNC message that
      caused this error.

   Max Version

      This field MUST contain the maximum PA-TNC version supported by
      the sender of this error code.

   Min Version

      This field MUST contain the minimum PA-TNC version supported by
      the sender of this error code.

   Reserved

      Reserved for future use.  This field MUST be set to 0 on
      transmission and ignored upon reception.

4.2.8.3.  Attribute Type Not Supported Error Code

   The Attribute Type Not Supported error code is an IETF Standard PA-
   TNC Error Code (value 3) that indicates that the sender of this error
   code does not support the PA-TNC Attribute Type included in the Error
   Information field.  This PA-TNC Attribute Type was included in a PA-
   TNC message sent by the recipient of this error code in the current
   assessment.

   For this error code, the Error Information field contains the first 8
   octets of the PA-TNC message that contained the unsupported attribute
   type as well as a copy of the attribute type that caused the problem.

Top      Up      ToC       Page 40 
   The following diagram illustrates the format and contents of the
   Error Information field for this error code.  The text after this
   diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |            Copy of Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |          PA-TNC Attribute Vendor ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     PA-TNC Attribute Type                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version

      This field MUST contain an exact copy of the Version field in the
      PA-TNC Message Header of the PA-TNC message that caused this
      error.

   Copy of Reserved

      This field MUST contain an exact copy of the Reserved field in the
      PA-TNC Message Header of the PA-TNC message that caused this
      error.

   Message Identifier

      This field MUST contain an exact copy of the Message Identifier
      field in the PA-TNC Message Header of the PA-TNC message that
      caused this error.

   Flags

      This field MUST contain an exact copy of the Flags field in the
      PA-TNC Attribute Header of the PA-TNC attribute that caused this
      error.

   PA-TNC Attribute Vendor ID

      This field MUST contain an exact copy of the PA-TNC Attribute
      Vendor ID field in the PA-TNC Attribute Header of the PA-TNC
      attribute that caused this error.

Top      Up      ToC       Page 41 
   PA-TNC Attribute Type

      This field MUST contain an exact copy of the PA-TNC Attribute Type
      field in the PA-TNC Attribute Header of the PA-TNC attribute that
      caused this error.

4.2.9.  Assessment Result

   This PA-TNC attribute contains the final assessment result from a
   particular Posture Validator.  This attribute might be returned to a
   Posture Collector for information purposes such as when an endpoint
   is compliant.  Similarly, the Assessment Result attribute could be
   sent to indicate a non-compliant result where specific actions are
   needed to bring an endpoint into compliance with the network's
   policies.  These actions could be defined in other PA-TNC attributes
   such as Remediation Instructions sent to the Posture Collector.

   All Posture Collectors that support an IETF Standard PA Subtype
   defined in this specification SHOULD support receiving and processing
   the Assessment Result attribute.  All Posture Validators that
   implement an IETF Standard PA Subtype defined in this specification
   SHOULD support sending the Assessment Result attribute.

   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
   set to zero (0) and the PA-TNC Attribute Type field MUST be set to 9.

   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after this
   diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Assessment Result                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Assessment Result

      This 32-bit field MUST contain one of the following values;

       Value   Description
       -----   -----------
       0      Posture Validator assessed the endpoint component to
              be compliant with policy.

       1      Posture Validator assessed the endpoint component to
              be non-compliant with policy but the difference from
              compliant was minor.

Top      Up      ToC       Page 42 
       2      Posture Validator assessed the endpoint component to
              be non-compliant with policy and the assessed
              difference was very significant.

       3      Posture Validator was unable to determine policy
              compliance of an endpoint component due to an error.

       4      Posture Validator was unable to determine whether the
              assessed endpoint component was compliant with policy
              based on the attributes provided by the Posture
              Collector.

4.2.10.  Remediation Instructions

   This PA-TNC attribute sent by the Posture Validator to the Posture
   Collector contains remediation instructions for updating a particular
   component to make the endpoint compliant with the assessment
   policies.  A Posture Validator might choose to send more than one
   Remediation Instructions attribute in some circumstances (e.g., both
   a URI and a human-readable message are necessary) to remediate one or
   more components.  This attribute supports the inclusion of either an
   IETF standard or vendor-specific remediation instruction.

   All Posture Collectors that implement an IETF Standard PA Subtype
   defined in this specification SHOULD support receiving and processing
   the Remediation Instructions attribute.  All Posture Validators that
   implement an IETF Standard PA Subtype defined in this specification
   SHOULD support sending this attribute type.  Posture Collectors and
   Posture Validators supporting other non-IETF standard components MAY
   support this attribute.

   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
   set to zero (0) and the PA-TNC Attribute Type field MUST be set to
   10.

   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after this
   diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |       Remediation Parameters Vendor ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Remediation Parameters Type                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Remediation Parameters (Variable Length)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 43 
   Reserved (8 bits)

      The Reserved bits MUST be set to 0 on transmission and ignored on
      reception.

   Remediation Parameters Vendor ID (24 bits)

      The Remediation Parameters Vendor ID field identifies a vendor by
      using the SMI Private Enterprise Number (PEN).  Any organization
      can receive its own unique PEN from IANA, the Internet Assigned
      Numbers Authority.  The Remediation Parameters Vendor ID qualifies
      the Remediation Parameters Type field so that each vendor has 2^32
      separate Remediation Parameters Types available for its use.
      Remediation Parameters Types standardized by the IETF are always
      used with the value zero (0) in this field.

   Remediation Parameters Type (32 bits)

      The Remediation Parameters Type field identifies the different
      types of remediation instructions that can be contained in the
      Remediation Parameters field.  IANA maintains a registry of PA-TNC
      Remediation Parameters Types.  Entries in this registry are added
      by Expert Review with Specification Required, following the
      guidelines in section 7.  A list of IETF Standard PA-TNC
      Remediation Parameters Types defined in this specification appears
      later in this section.

      New vendor-specific remediation instructions can be created by
      adding new Remediation Parameters Types (those used with a non-
      zero Remediation Parameters vendor ID) without IETF or IANA
      involvement.  Posture Collectors and Posture Validators MUST NOT
      require support for particular vendor-specific PA-TNC Remediation
      Parameters Types and MUST interoperate with other parties despite
      any differences in the set of vendor-specific PA-TNC Remediation
      Parameters Types supported (although they MAY permit
      administrators to configure them to require support for specific
      PA-TNC remediation parameter types).

      The following table lists the IETF Standard PA-TNC Remediation
      Parameters Type values defined in this specification:

      Integer   Description
      -------   -----------
      0         Reserved
      1         Remediation URI
      2         Remediation String

Top      Up      ToC       Page 44 
      The next few subsections of this document provide detailed
      definitions of the contents of the Remediation Parameters field
      used with each Remediation Parameter Type.

   Remediation Parameters (variable length)

      The Remediation Parameters field contains the actual remediation
      instructions for the Posture Collector.

4.2.10.1.  Remediation URI Parameters Type

   The Remediation URI Parameters Type is an IETF Standard Remediation
   Parameters Type (value 1) that indicates that the sending Posture
   Validator is providing a URI to instructions on how to remediate the
   endpoint.

   The following diagram illustrates the format and contents of the
   Remediation Parameters field when carrying a Remediation URI
   parameter.  The text after this diagram describes the fields shown
   here.

                       1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Remediation URI (Variable Length)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Remediation URI

      The Remediation URI field MUST contain a URI, as described in RFC
      3986 [7].  This URI SHOULD contain instructions to update a
      particular component so that it might result in the component
      being compliant with the policies in future assessments.  Posture
      Collectors should validate that the URI and instructions come from
      a trustworthy source to avoid being tricked into performing
      damaging actions (see security considerations).

4.2.10.2.  Remediation String Parameters Type

   The Remediation String Parameters Type is an IETF Standard
   Remediation Parameters Type (value 2) that indicates that the sending
   Posture Validator is providing a human-readable string containing
   instructions on how to remediate the endpoint.

   The following diagram illustrates the format and contents of the
   Remediation Parameters field when the carrying a Remediation String
   parameter.  The text after this diagram describes the fields shown
   here.

Top      Up      ToC       Page 45 
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Remediation String Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Remediation String (Variable Length)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Lang Code Len |  Remediation String Lang Code (Variable Len)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Remediation String Length

      The Remediation String Length contains the length of the
      Remediation String field in octets.

   Remediation String

      The Remediation String field MUST contain a UTF-8 encoded string.
      This string contains human-readable instructions for remediation
      that MAY be displayed to the user by the Posture Collector.  NUL
      termination MUST NOT be included.  If a Posture Collector receives
      a Remediation String that does contain a NUL termination, it
      SHOULD send an Invalid Parameter error code.

   Lang Code Len (Remediation String Language Code Length)

      The Lang Code Len field contains the length of the Remediation
      String Language Code field in octets.

   Remediation String Lang Code

      The Remediation String Lang(uage) Code field contains a US-ASCII
      string composed of a well-formed RFC 4646 [6] language tag that
      indicates the language(s) used in the Remediation String in the
      Remediation Parameters field.  A zero-length string MAY be sent
      for this field (essentially omitting this field) to indicate that
      the language code for the remediation string is not known.

4.2.11.  Forwarding Enabled

   This PA-TNC attribute indicates whether the endpoint is forwarding
   traffic between interfaces.  Endpoints that forward traffic between
   networks connected to multiple network interfaces may be considered
   non-compliant (and a security risk) in some enterprise network
   deployments.  For example, an endpoint with multiple connected
   network interfaces might allow traffic from an interface connected to
   a public network to be forwarded through another interface carrying a
   VPN session to a protected enterprise network.  This attribute is

Top      Up      ToC       Page 46 
   currently envisioned to be specific to reporting posture for the
   operating system component; however, could be useful for other future
   types of components.

   Posture Collectors that implement the IETF Standard PA Subtype for
   Operating System SHOULD support sending the Forwarding Enabled
   attribute.  Posture Collectors that do not implement the Operating
   System PA Subtype defined in this specification SHOULD NOT send the
   Forwarding Enabled attribute unless it is appropriate to their PA
   Subtype.  Whether a particular Posture Collector actually sends this
   attribute type SHOULD still be governed by local privacy and security
   policies.  Posture Validators that implement the IETF Standard PA
   Subtype for Operating System SHOULD support receiving the Forwarding
   Enabled attribute type.  Posture Validators supporting components
   other than Operating System MAY support receiving this attribute type
   if it is appropriate to their PA Subtype.  A Posture Validator that
   does not support receiving this attribute type SHOULD simply ignore
   attributes with this type.  Posture Validators MUST NOT send this
   attribute type.

   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
   set to zero (0) and the PA-TNC Attribute Type field MUST be set to
   11.

   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after this
   diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Forwarding Enabled                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Forwarding Enabled

      This 32-bit field MUST contain one of the following values;

      Value   Description
      -----   -----------
        0       Disabled - Endpoint is not forwarding traffic.

        1       Enabled -  Endpoint is forwarding traffic.

        2       Unknown -  Unable to determine whether endpoint is
                           forwarding traffic

Top      Up      ToC       Page 47 
4.2.12.  Factory Default Password Enabled

   This PA-TNC attribute indicates whether the endpoint has a factory
   default password enabled for use.  Some types of endpoints include a
   default static password for used to gain privileged access to the
   endpoint.  If this password is not changed or disabled before the
   endpoint is accessible on the network, it's often easy to compromise
   the endpoint.

   Posture Collectors that implement the IETF Standard PA Subtype for
   Operating System SHOULD support sending the Factory Default Password
   Enabled attribute.  Posture Collectors that implement other IETF
   Standard PA Subtypes defined in this specification SHOULD NOT support
   sending this attribute type for those PA subtypes.  Other Posture
   Collectors MAY support sending this attribute type, if it is
   appropriate to their PA subtype.  Whether a particular Posture
   Collector actually sends this attribute type SHOULD still be governed
   by local privacy and security policies.  Posture Validators that
   implement the IETF Standard PA Subtype for Operating System SHOULD
   support receiving the Factory Default Password Enabled attribute.
   Other Posture Validators MAY support receiving this attribute type.
   A Posture Validator that does not support receiving this attribute
   type SHOULD simply ignore attributes with this type.  Posture
   Validators MUST NOT send this attribute type.

   For this attribute type, the PA-TNC Attribute Vendor ID field MUST be
   set to zero (0) and the PA-TNC Attribute Type field MUST be set to
   12.

   The following diagram illustrates the format and contents of the
   Attribute Value field for this attribute type.  The text after this
   diagram describes the fields shown here.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Factory Default Password Enabled                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Factory Default Password Enabled

      This 32-bit field MUST contain one of the following values;

      Value   Description
      -----   -----------
      0       Endpoint does not have factory default password enabled.

      1       Endpoint has a factory default password enabled.

Top      Up      ToC       Page 48 
4.3.  Vendor-Defined Attributes

   This section discusses the use of vendor-defined attributes within
   PA-TNC.  The PA-TNC protocol was designed to allow for vendor-defined
   attributes to be used as a replacement where a standard attribute
   could be used.  In some cases, even the standard attributes allow for
   vendor-defined information to be included.  It is envisioned that
   over time as particular vendor-defined attributes become popular, an
   equivalent standard attribute could be added allowing for broader
   interoperability.

   This specification does not define vendor-defined attributes, but
   rather highlights how such attributes can be used with PA-TNC without
   the potential for namespace collisions or misinterpretations.  In
   order to avoid collisions, PA-TNC uses the well-established SMI
   Private Enterprise Numbers as vendor IDs to define separate
   namespaces for important fields within a PA-TNC message.  For
   example, to ensure the uniqueness of attribute types while providing
   for vendor extensions, vendor-defined attribute types include the
   vendor's unique vendor ID, to indicate the intended namespace for the
   attribute type, followed by the attribute type.  IETF Standard PA-TNC
   Attribute Types use a vendor ID of zero (0).

   SMI Private Enterprise Numbers are used to provide a separate
   identifier space for each vendor.  The IANA provides a registry for
   SMI Private Enterprise Numbers.  Any organization (including non-
   profit organizations, governmental bodies, etc.) can obtain one of
   these numbers at no charge, and thousands of organizations have done
   so.  Within this document, SMI Private Enterprise Numbers are known
   as "vendor IDs".

5.  Security Considerations

   This section discusses the major potential types of security threats
   relevant to the PA-TNC message protocol.  It is envisioned that
   additional attribute types could be defined in the future to
   facilitate the exchange of security capabilities, keys, and security
   protected attributes if future use cases are adopted that require
   such protections.

5.1.  Trust Relationships

   In order to understand where security countermeasures are necessary,
   this section starts with a discussion of where the TNC architecture
   envisions some trust relationships between the processing elements of
   the PA-TNC protocol.  The following subsections discuss the trust
   properties associated with each portion of the NEA reference model
   directly involved with the processing of the PA-TNC protocol.

Top      Up      ToC       Page 49 
5.1.1.  Posture Collector

   The Posture Collectors are trusted by Posture Validators to:

   o  Collect valid information about the component type associated with
      the Posture Collector

   o  Report upon collected information consistent with local security
      and privacy policies

   o  Accurately report information associated with the type of
      component for the PA-TNC message

   o  Not act maliciously to the Posture Broker Server and Posture
      Validators, including attacks such as denial of service

5.1.2.  Posture Validator

   The Posture Validators are trusted by Posture Collectors to:

   o  Only request information necessary to assess the security state of
      the endpoint

   o  Make assessment decisions based on deployer-defined policies

   o  Discard collected information consistent with data retention and
      privacy policies

   o  Not act maliciously to the Posture Broker Server and Posture
      Collectors, including attacks such as denial of service

   o  Not send malicious remediation instructions that do not fix or
      that cause damage to the endpoint

5.1.3.  Posture Broker Client, Posture Broker Server

   The Posture Broker Client and Posture Broker Server are trusted by
   the Posture Collector and Posture Validator to:

   o  Provide a reliable transport for PA-TNC messages

   o  Deliver messages for a particular PA Subtype only to those Posture
      Collectors and Posture Validators that have registered for them

   o  Not disclose any provided attributes to unauthorized parties

Top      Up      ToC       Page 50 
   o  Not act maliciously to drop messages, duplicate messages, or flood
      Posture Collectors and Posture Validators with unnecessary
      messages

   o  Not observe, fabricate, or alter the contents of a PA-TNC message

   o  Properly place Posture Collector and Posture Validator identifiers
      into the PB-TNC protocol, deliver those identifiers to Posture
      Collectors and Posture Validators as needed, and manage exclusive
      delivery to a particular Posture Collector or Posture Validator
      when requested

   o  Properly expose authentication information from PT security so
      that Posture Collectors and Posture Validators can use the peer's
      identity information to safely make policy decisions

5.2.  Security Threats

   Beyond the trusted relationships assumed in section 5.1, the PA-TNC
   protocol faces a number of potential security attacks that could
   require security countermeasures.

   Generally, the PA-TNC protocol relies upon the underlying PT
   protocol's security to protect the messages from attack when
   traveling over the network.  Once the message resides on the Posture
   Broker Client or Posture Broker Server, the posture brokers are
   trusted to properly and safely deliver the messages to the
   appropriate Posture Collectors and Posture Validators.

5.2.1.  Attribute Theft

   When PA-TNC messages are sent over unprotected network links or
   spanning local software stacks that are not trusted, the contents of
   the PA-TNC messages may be subject to information theft by an
   intermediary party.  This theft could result in information being
   recorded for future use or analysis by the adversary.  Attributes
   observed by eavesdroppers could contain information that exposes
   potential weaknesses in the security of the endpoint, or system
   fingerprinting information easing the ability of the attacker to
   employ attacks more likely to be successful against the endpoint.
   The eavesdropper might also learn information about the endpoint or
   network policies that either singularly or collectively is considered
   sensitive information (e.g., certain endpoints are lacking patches,
   or particular sub-networks have more lenient policies).

   PA-TNC attributes are not intended to carry privacy-sensitive
   information, but should some exist in a message, the adversary could
   come into possession of the information, which could be used for

Top      Up      ToC       Page 51 
   financial gain.  Therefore, it is important that PT provide strong
   confidentiality protection to protect the message from eavesdroppers
   when being sent between the Posture Transport Client and Posture
   Transport Server.

5.2.2.  Message Fabrication

   Attackers on the network or present within the NEA system could
   introduce fabricated PA-TNC messages intending to trick or create a
   denial of service against aspects of an assessment.  For example, an
   adversary could attempt to send a falsified set of remediation
   instructions using the Remediation URI support in hopes of the
   Posture Collector automatically following the instructions.  Posture
   Collectors need to ensure that any requests to take actions on the
   endpoint (such as remediation instructions) received from Posture
   Validators are authentic and trustworthy using strong authentication
   and integrity protections offered by PT.  Posture Collectors should
   not blindly follow remediation instructions received from a trusted
   NEA Server.  At least for patches and other potentially dangerous
   actions, Posture Collectors should validate these actions (e.g., via
   user confirmation) before proceeding.

   Such an attack could occur if an active attacker launches a man-in-
   the-middle (MitM) attack by proxying the PA-TNC messages and was able
   to replace undesired messages with ones easing future attack upon the
   endpoint.  Consider a scenario where PT security protection is not
   used and the Posture Broker Server proxies all assessment traffic to
   a remote Posture Broker Server.  The proxy could eavesdrop and
   replace assessment results attributes, tricking the endpoint into
   thinking it has passed an assessment, when in fact it has not and
   requires remediation.  Because the Posture Collector has no way to
   verify that attributes were actually created by an authentic Posture
   Validator, it is unable to detect the falsified attribute or message.
   Therefore, it is important that PT provides strong authentication and
   integrity protection.

5.2.3.  Attribute Modification

   This attack could allow an active attacker capable of intercepting a
   message to modify a PA-TNC message attribute to a desired value to
   ease the compromise of an endpoint.  Without the ability for message
   recipients to detect whether a received message contains the same
   content as what was originally sent, active attackers can stealthily
   modify the attribute exchange.

   For example, an attacker might wish to change the contents of the
   firewall component's version string attribute to disguise the fact
   that the firewall is running an old, vulnerable version.  The

Top      Up      ToC       Page 52 
   attacker would change the version string sent by the firewall Posture
   Collector to the current version number, so the Posture Validator's
   assessment passes while leaving the endpoint vulnerable to attack.
   Similarly, an attacker could achieve widespread denial of service by
   altering large numbers of assessments' version string attributes to
   an old value so they repeatedly fail assessments even after a
   successful remediation.  Upon receiving the lower value, the Posture
   Validator would continue to believe that the endpoint is running old,
   potentially vulnerable versions of the firewall that does not meet
   network compliance policy, so therefore the endpoint would not be
   allowed to join the network.  Use of a PT protocol providing strong
   integrity protection and authentication is essential as
   countermeasures to these attacks.

5.2.4.  Attribute Replay

   Another potential attack against an unprotected PA-TNC message
   attribute exchange is to exploit the lack of a strong binding between
   the attributes sent during an assessment to the specific endpoint.
   Without a strong binding of the endpoint to the posture information,
   an attacker could record the attributes sent during an assessment of
   a compliant endpoint and later replay those attributes so that a non-
   compliant endpoint can now gain access to the network or protected
   resource.  This attack could be employed by a network MitM that is
   able to eavesdrop and proxy message exchanges, or by using local
   rogue agents on the endpoints.  Assessments lacking some form of
   freshness exchange could be subject to replay of prior assessment
   data, even if it no longer reflects the current state of the
   endpoint.  Use of a PT protocol providing strong integrity protection
   and authentication including a freshness exchange is necessary
   countermeasure to these attacks.

5.2.5.  Attribute Insertion

   Similar to the attribute modification attacks, an adversary wishing
   to include one or more attributes or PA-TNC messages inside a valid
   assessment may be able to insert the attributes or messages without
   detection by the recipient.  For example, an attacker could add
   attributes to the front of a PA-TNC message to cause an assessment to
   succeed even for a non-compliant endpoint, particularly if it knew
   that the recipient ignored repeated attributes within a message.
   Similarly, if a Posture Collector or Posture Validator always
   generated an error if it saw unexpected attributes, the attacker
   could cause failures and denial of service by adding attributes or
   messages to an exchange.  Use of a PT protocol providing strong
   authentication and integrity protection could prevent the adversary
   from inserting attributes into the assessment.

Top      Up      ToC       Page 53 
5.2.6.  Denial of Service

   A variety of types of denial-of-service attacks are possible against
   the PA-TNC message exchange if left unprotected from untrusted
   parties along the communication path between the Posture Collector
   and Posture Validator.  Normally, the PT exchange is bidirectionally
   authenticated, which helps to prevent a MitM on the network from
   becoming an active proxy, but transparent message routing gateways
   may still exist on the communication path and can modify the
   integrity of the message exchange unless adequate integrity
   protection is provided.  If the MitM or other entities on the network
   can send messages to the Posture Broker Client or Posture Broker
   Server that appear to be part of an assessment, these messages could
   confuse the Posture Collector and Posture Validator or cause them to
   perform unnecessary work or take incorrect action.  Several example
   denial-of-service situations are described in sections 5.2.3 and
   5.2.5.  Many potential denial-of-service examples exist, including
   flooding messages to the Posture Collector or Posture Validator,
   sending very large messages containing many attributes, and
   repeatedly asking for resource-intensive operations.

6.  Privacy Considerations

   The PA-TNC protocol is designed to allow for controlled disclosure of
   security-relevant information about an endpoint, specifically for the
   purpose of enabling an assessment of the endpoint's compliance with
   network policy.  The purpose of this protocol is to provide
   visibility into the state of the protective mechanisms on the
   endpoint, in order for the Posture Validators and Posture Broker
   Server to determine whether the endpoint is up to date and thus has
   the best chance of being resilient in the face of malware threats.
   One risk associated with providing visibility into the contents of an
   endpoint is the increased chance for exposure of privacy-sensitive
   information without the consent of the user.

   While this protocol does provide the Posture Validator the ability to
   request specific information about the endpoint, the protocol is not
   open ended, bounding the Posture Validator to only query specific
   information (attributes) about specific security features (component
   types) of the endpoint.  Each PA-TNC message is explicitly about a
   single component from the list of components in section 3.5.  These
   components include a list of security-related aspects of the endpoint
   that affect the ability of the endpoint to resist attacks and thus
   are of interest during an assessment.  Discretionary components used
   by the user to create or view content are not on the list, as they
   are more likely to have access to privacy-sensitive information.

Top      Up      ToC       Page 54 
   Similarly, PA-TNC messages contain a set of attributes that describe
   the particular component.  Each attribute contains generic
   information (e.g., product information or versions) about the
   component, so it is unlikely to include any user-specific or
   identifying information.  This combination of a limited set of
   security-related components with non-user-specific attributes greatly
   reduces the risk of exposure of privacy-sensitive information.
   Vendors that choose to define additional component types and/or
   attributes within their namespace are encouraged to provide similar
   constraints.

   Even with the bounding of standard attribute information to specific
   components, it is possible that individuals might wish to share less
   information with different networks they wish to access.  For
   example, a user may wish to share more information when connecting to
   or being reassessed by the user's employer network than what would be
   made available to the local coffee shop wireless network.  While
   these situations do not impact the protocol itself, they do suggest
   that Posture Collector implementations should consider supporting a
   privacy filter allowing the user and/or system owner to restrict
   access to certain attributes based upon the target network.

   The underlying PT protocol authenticates the network's Posture Broker
   Server at the start of an assessment, so identity can be made
   available to the Posture Collector and per-network privacy filtering
   is possible.  Network owners should make available a list of the
   attributes they require to perform an assessment and any privacy
   policy they enforce when handling the data.  Users wishing to use a
   more restricted privacy filter on the endpoint may risk not being
   able to pass an assessment and thus not gain access to the requested
   network or resource.

7.  IANA Considerations

   This section defines the contents of three new IANA registries: PA-
   TNC Attribute Types, PA-TNC Error Codes, and PA-TNC Remediation
   Parameters Types.  This section explains how these registries work.
   Also, this specification defines several new PA Subtypes for use with
   PA-TNC.

   All of the registries defined in this document support IETF standard
   values and vendor-defined values.  To explain this phenomenon, we
   will use the PA-TNC Attribute Type as an example, but the other three
   registries work the same way.  Whenever a PA-TNC Attribute Type
   appears on a network, it is always accompanied by an SMI Private
   Enterprise Number (PEN), also known as a vendor ID.  If this vendor
   ID is zero, the accompanying PA-TNC Attribute Type is an IETF
   standard value listed in the IANA registry for PA-TNC Attribute

Top      Up      ToC       Page 55 
   Types, and its meaning is defined in the specification listed for
   that PA-TNC Attribute Type in that registry.  If the vendor ID is not
   zero, the meaning of the PA-TNC Attribute Type is defined by the
   vendor identified by the vendor ID (as listed in the IANA registry
   for SMI PENs).  The identified vendor is encouraged but not required
   to register with IANA some or all of the PA-TNC Attribute Types used
   with their vendor ID and publish a specification for each of these
   values.

   This delegation of namespace is analogous to the technique used for
   OIDs.  It can result in interoperability problems if vendors require
   support for particular vendor-specific values.  However, such
   behavior is explicitly prohibited by this specification (in section
   4.1), which dictates that "Posture Collectors and Posture Validators
   MUST NOT require support for particular vendor-specific PA-TNC
   Attribute Types and MUST interoperate with other parties despite any
   differences in the set of vendor-specific PA-TNC Attribute Types
   supported (although they MAY permit administrators to configure them
   to require support for specific PA-TNC Attribute Types)".  Similar
   requirements are included for PA Subtypes, Remediation Parameters
   Types, and PA-TNC Error Codes.

7.1.  Designated Expert Guidelines

   For all of the IANA registries defined by this specification, new
   values are added to the registry by Expert Review with Specification
   Required, using the Designated Expert process defined in RFC 5226
   [3].

   This section provides guidance to designated experts so that they may
   make decisions using a philosophy appropriate for these registries.

   The registries defined in this document have plenty of values.  In
   most cases, the IETF has approximately 2^32 values available for it
   to define and each vendor the same number of values for its use.
   Because there are so many values available, designated experts should
   not be terribly concerned about exhausting the set of values.

   Instead, designated experts should focus on the following
   requirements.  All values in these IANA registries MUST be documented
   in a specification that is permanently and publicly available.  IETF
   standard values MUST also be useful, not harmful to the Internet, and
   defined in a manner that is clear and likely to ensure
   interoperability.

   Designated experts should encourage vendors to avoid defining similar
   but incompatible values and instead agree on a single IETF standard
   value.  However, it is beneficial to document existing practice.

Top      Up      ToC       Page 56 
   There are several ways to ensure that a specification is permanently
   and publicly available.  It may be published as an RFC.
   Alternatively, it may be published in another manner that makes it
   freely available to anyone.  However, in this latter case, the vendor
   MUST supply a copy to the IANA and authorize the IANA to archive this
   copy and make it freely available to all if at some point the
   document becomes no longer freely available to all through other
   channels.

   Section 7.2 defines the new PA Subtypes.  The following three
   sections provide guidance to the IANA in creating and managing the
   new IANA registries defined by this specification.

7.2.  PA Subtypes

   Section 3.5 of this specification defines several new PA Subtypes
   that have been added to the PA Subtypes registry defined in the PB-
   TNC specification.  Here is a list of these assignments:

   PEN  Integer      Name               Defining Specification
   ---  -------      ----               ----------------------
    0     0          Testing                    RFC 5792
    0     1          Operating System           RFC 5792
    0     2          Anti-Virus                 RFC 5792
    0     3          Anti-Spyware               RFC 5792
    0     4          Anti-Malware               RFC 5792
    0     5          Firewall                   RFC 5792
    0     6          IDPS                       RFC 5792
    0     7          VPN                        RFC 5792
    0     8          NEA Client                 RFC 5792

   These PA Subtypes have been added to the registry for PA Subtypes
   defined in the PB-TNC specification, with this RFC as the reference.

7.3.  Registry for PA-TNC Attribute Types

   The name for this registry is "PA-TNC Attribute Types".  Each entry
   in this registry should include a human-readable name, an SMI Private
   Enterprise Number, a decimal integer value between 0 and 2^32-1, and
   a reference to the specification where the contents of this attribute
   type are defined.  This specification must define the meaning of this
   PA-TNC attribute type and the format and semantics of the PA-TNC
   Attribute Value field for PA-TNC attributes that include the
   designated Private Enterprise Number in the PA-TNC Attribute Vendor
   ID field and the designated numeric value in the PA-TNC Attribute
   Type field.

Top      Up      ToC       Page 57 
   The following entries for this registry are defined in this document.
   They are the initial entries in the registry for PA-TNC Attribute
   Types.  Additional entries to this registry are added by Expert
   Review with Specification Required, following the guidelines in
   section 7.1.

   PEN   Integer    Name                 Defining Specification
   ---   -------    ----                 ----------------------
    0      0        Testing                      RFC 5792
    0      1        Attribute Request            RFC 5792
    0      2        Product Information          RFC 5792
    0      3        Numeric Version              RFC 5792
    0      4        String Version               RFC 5792
    0      5        Operational Status           RFC 5792
    0      6        Port Filter                  RFC 5792
    0      7        Installed Packages           RFC 5792
    0      8        PA-TNC Error                 RFC 5792
    0      9        Assessment Result            RFC 5792
    0     10        Remediation Instructions     RFC 5792
    0     11        Forwarding Enabled           RFC 5792
    0     12        Factory Default Password     RFC 5792
                    Enabled
    0 0xffffffff    Reserved                     RFC 5792

7.4.  Registry for PA-TNC Error Codes

   The name for this registry is "PA-TNC Error Codes".  Each entry in
   this registry should include a human-readable name, an SMI Private
   Enterprise Number, a decimal integer value between 0 and 2^32-1, and
   a reference to the specification where this error code is defined.
   This specification must define the meaning of this error code and the
   format and semantics of the Error Information field for PA-TNC
   attributes that have a PA-TNC vendor ID of 0, a PA-TNC Attribute Type
   of PA-TNC Error, the designated Private Enterprise Number in the PA-
   TNC Error Code Vendor ID field, and the designated numeric value in
   the PA-TNC Error Code field.

   The following entries for this registry are defined in this document.
   They are the initial entries in the registry for PA-TNC Error Codes.
   Additional entries to this registry are added by Expert Review with
   Specification Required, following the guidelines in section 7.1.

Top      Up      ToC       Page 58 
      PEN  Integer     Name                      Defining Specification
      ---  -------     ----                      ----------------------
       0     0         Reserved                          RFC 5792
       0     1         Invalid Parameter                 RFC 5792
       0     2         Version Not Supported             RFC 5792
       0     3         Attribute Type Not Supported      RFC 5792

7.5.  Registry for PA-TNC Remediation Parameters Types

   The name for this registry is "PA-TNC Remediation Parameters Types".
   Each entry in this registry should include a human-readable name, an
   SMI Private Enterprise Number, a decimal integer value between 1 and
   2^32-1, and a reference to the specification where the contents of
   this remediation parameters type are defined.  This specification
   must define the meaning of this PA-TNC Remediation Parameters Type
   and the format and semantics of the Remediation Parameters field for
   PA-TNC attributes that include the designated Private Enterprise
   Number in the Remediation Parameters Vendor ID field and the
   designated numeric value in the Remediation Parameters Type field.

   The following entries for this registry are defined in this document.
   They are the initial entries in the registry for PA-TNC Remediation
   Parameters Types.  Additional entries to this registry are added by
   Expert Review with Specification Required, following the guidelines
   in section 7.1.

   PEN   Integer   Name              Defining Specification
   ---   -------   ----              ----------------------
    0      0      Reserved                 RFC 5792
    0      1      URI                      RFC 5792
    0      2      Remediation String       RFC 5792

8.  Acknowledgments

   Thanks to the Trusted Computing Group for contributing the initial
   text [8] upon which this document was based.  The authors would also
   like to acknowledge the following people who have contributed to or
   provided substantial input on the preparation of this document or
   predecessors to it: Stuart Bailey, Roger Chickering, Lauren Giroux,
   Charles Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg
   Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa Lorenzin,
   Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio Sanchez, Brad Upson,
   and Han Yin.


Next RFC Part