Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5792

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

Pages: 83
Proposed Standard
Errata
Part 3 of 4 – Pages 31 to 58
First   Prev   Next

Top   ToC   RFC5792 - Page 31   prevText

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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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   ToC   RFC5792 - 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 page on part 4)

Next Section