Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5793

PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)

Pages: 76
Proposed Standard
Errata
Part 2 of 3 – Pages 13 to 40
First   Prev   Next

Top   ToC   RFC5793 - Page 13   prevText

4. PB-TNC Protocol Specification

This section defines the syntax and semantics of the PB-TNC protocol fields. If a Posture Broker Client or Posture Broker Server receives a batch that violates the requirements of this specification, it MUST respond by sending a fatal Invalid Parameter error in a CLOSE batch unless this document specifies otherwise.

4.1. PB-TNC Header

Every PB-TNC batch MUST start with the following header. A PB-TNC batch MUST contain only one instance of this header followed by zero or more PB-TNC messages. The PB-TNC messages are defined in subsequent sections of this specification. 0 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 |D| Reserved | B-Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Batch Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (8 bits) This field indicates the version of the format for the PB-TNC message. This version is intended to allow for evolution of the PB-TNC protocol in a manner that can easily be detected by message recipients. This field MUST be set to 2 when the batch conforms to this specification. Later versions of PB-TNC may define other values for this field. The values 0x00, 0x09, 0x0a, 0x0d, 0x20, and 0x3c are reserved and cannot be used for any version of PB-TNC to ensure that PB-TNC can be easily distinguished from earlier posture broker protocols already in use. If a Posture Broker Client or Posture Broker Server receives a Version value that it does not support, it MUST respond with a PB- TNC batch with batch type CLOSE that contains only a fatal Version Not Supported error code and whose Version header field has the value 2. Implementations responding to a PB-TNC message containing a supported version MUST use the same Version number to minimize the risk of version incompatibility. PB-TNC message initiators that support multiple PB-TNC protocol versions SHOULD be able to alter which version of PB-TNC message they send based on prior message exchanges with a particular peer Posture Broker Client or Posture Broker Server.
Top   ToC   RFC5793 - Page 14
   Directionality (D) (1 bit)

      When a Posture Broker Client is sending this message, the
      Directionality bit MUST be set to 0.  When a Posture Broker Server
      is sending this message, the Directionality bit MUST be set to 1.
      This helps avoid any situation where two Posture Broker Clients or
      two Posture Broker Servers engage in a dialog.  It also helps with
      debugging.

   Reserved (19 bits)

      This field is reserved.  For this version of this specification,
      it MUST be set to 0 on transmission and ignored on reception.
      Future versions of this specification may allow senders to set
      some of these bits and recipients to interpret them.

   B-Type (Batch Type) (4 bits)

      This field is used to drive the state machine described in section
      3.2.  This field MUST have one of the values from the following
      table.  If any other value is received, the recipient MUST ignore
      the contents of the batch and send a fatal Invalid Parameter error
      code in a CLOSE batch.  If the value received is not permitted for
      the current state, according to the state machine in section 3.2.,
      the recipient MUST ignore the contents of the batch and send a
      fatal Unexpected Batch Type error code in a CLOSE batch.
Top   ToC   RFC5793 - Page 15
      Number   Name     Definition
      ------   ----     ----------

      1        CDATA    The Posture Broker Client may send a batch with
                        this Batch Type to convey messages to the
                        Posture Broker Server.  A Posture Broker Server
                        MUST NOT send this Batch Type.  A CDATA batch
                        may be empty (contain no messages) if the
                        Posture Broker Client has nothing to send.

      2        SDATA    The Posture Broker Server may send a batch with
                        this Batch Type to convey messages to the
                        Posture Broker Client.  A Posture Broker Client
                        MUST NOT send this Batch Type.  An SDATA batch
                        may be empty (contain no messages) if the
                        Posture Broker Server has nothing to send.

      3        RESULT   The Posture Broker Server may send a batch with
                        this Batch Type to indicate that it has
                        completed its evaluation.  The batch MUST
                        include a PB-Assessment-Result message and MAY
                        include a PB-Access-Recommendation message.

      4        CRETRY   The Posture Broker Client may send a batch with
                        this Batch Type to indicate that it wishes to
                        restart an exchange.  A Posture Broker Server
                        MUST NOT send this Batch Type.  A CRETRY batch
                        may be empty (contain no messages) if the
                        Posture Broker Client has nothing else to send.

      5        SRETRY  The Posture Broker Server may send a batch with
                       this Batch Type to indicate that it wishes to
                       restart the exchange.  A Posture Broker Client
                       MUST NOT send this Batch Type.  A SRETRY batch
                       may be empty (contain no messages) if the
                       Posture Broker Server has nothing else to send.

      6        CLOSE   The Posture Broker Server or Posture Broker
                       Client may send a batch with this Batch Type to
                       indicate that it is about to terminate the
                       underlying PT connection.  A CLOSE batch may be
                       empty (contain no messages) if there is nothing
                       to send.  However, if the termination is due to a
                       fatal error, then the CLOSE batch MUST contain a
                       PB-Error message.
Top   ToC   RFC5793 - Page 16
   Batch Length (32 bits)

      This length field contains the size of the full PB-TNC batch in
      octets.  This length includes the PB-TNC header and all the PB-TNC
      messages in the batch.  In other words, it includes the entire
      contents of the batch.  This field MUST contain at least the value
      8 for the fixed-length fields in this header.  Any Posture Broker
      Client or Posture Broker Server that receives a PB-TNC message
      with a PB-TNC Message Length field whose value is less than 8 MUST
      respond with a fatal Invalid Parameter error code in a CLOSE
      batch.

4.2. PB-TNC Message

All PB-TNC messages have the same overall structure, which is described in this section. Of course, the format and semantics of the PB-TNC Message Value field will vary, depending on the values of the PB-TNC Vendor ID and PB-TNC Message Type fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | PB-TNC Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PB-TNC Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PB-TNC Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PB-TNC Message Value (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags (8 bits) This field defines flags impacting the processing of this message. Bit 0 of this Flags field (the most significant bit) is known as the NOSKIP flag. If this flag is cleared (value 0), then the recipient (a Posture Broker Client or Posture Broker Server) may skip (ignore) this message if the message type is not understood or the recipient cannot or will not process the message as required in the definition of that message. If this flag is set (value 1), then recipients MUST NOT skip this attribute. This flag does not mean that all recipients must support this message. Instead, any recipient that receives a message with this flag set to 1 but cannot or will not process it as required MUST NOT act on any part of the PB-TNC batch. Instead, the recipient MUST respond with a fatal Unsupported Mandatory Message error code
Top   ToC   RFC5793 - Page 17
      in a CLOSE batch.  In order to avoid taking action on some
      messages in a batch only to later find an unsupported NOSKIP
      flagged message, recipients of a PB-TNC batch might choose to scan
      all of the messages in the batch prior to acting upon any of the
      messages, checking to determine whether one of them is an
      unsupported message with the NOSKIP flag set.

      The other bits in this Flags field are reserved.  For this version
      of PB-TNC, they MUST be set to 0 on transmission and ignored on
      reception.

   PB-TNC Vendor ID (24 bits)

      The PB-TNC 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.
      This Vendor ID qualifies the PB-TNC Message Type field so that
      each vendor has 2^32-1 separate message types available for their
      use.

      Message types standardized by the IETF use zero (0) in this field.
      The Vendor ID 0xffffff is reserved.  Posture Broker Clients and
      Posture Broker Servers MUST NOT send messages in which the Vendor
      ID has this reserved value (0xffffff).  If a Posture Broker Client
      or Posture Broker Server receives a message in which the PB-TNC
      Vendor ID has this reserved value (0xffffff), it MUST respond with
      a fatal Invalid Parameter error code in a CLOSE batch.

   PB-TNC Message Type (32 bits)

      The PB-TNC Message Type field identifies the type of the PB-TNC
      message contained in the PB-TNC Message Value field.  The PB-TNC
      message type 0xffffffff is reserved.  Posture Broker Clients and
      Posture Broker Servers MUST NOT send messages in which the PB-TNC
      Message Type field has this reserved value (0xffffffff).  If a
      Posture Broker Client or Posture Broker Server receives a message
      in which the PB-TNC Message Type field has this reserved value
      (0xffffffff), it MUST respond with a fatal Invalid Parameter error
      code in a CLOSE batch.  Unless otherwise prohibited in the
      definition of a particular PB-TNC message type (e.g., PB-Language-
      Preference), a single PB-TNC batch may contain multiple messages
      with the same message type and/or vendor ID.

      The IETF and any other organization with a PEN can define 2^32-1
      unique PB-TNC message types, as long as the organization's PEN is
      placed in the PB-TNC Vendor ID field of the message.  Since the
      PB-TNC message type is qualified by the vendor ID, there is no
Top   ToC   RFC5793 - Page 18
      risk of conflicts as long as each organization uses its own PEN
      for the vendor ID and manages its own set of 2^32-1 message type
      values.

      This document defines certain PB-TNC message types that, when used
      with the IETF SMI PEN (0), have standard meanings.  These are
      known as IETF Standard PB-TNC Message Types.  Some of these PB-TNC
      message types are mandatory and therefore MUST be implemented by
      all Posture Broker Client and Posture Broker Server
      implementations that claim compliance with this specification.
      For details on which PB-TNC message types are mandatory, see the
      description of these message types later in section 4.

      IANA maintains a registry of PB-TNC message types.  Entries in
      this registry are added by Expert Review with Specification
      Required, following the guidelines in section 6.1.

      New vendor-specific PB-TNC message types (those used with a non-
      zero PB-TNC vendor ID) may be defined and employed by vendors
      without IETF or IANA involvement.  However, Posture Broker Clients
      and Posture Broker Servers MUST NOT require support for particular
      vendor-specific PB-TNC message types and MUST interoperate with
      other parties despite any differences in the set of vendor-
      specific PB-TNC message types supported (although they MAY permit
      administrators to configure them to require support for specific
      PB-TNC message types).

      Note that the PB-TNC Message Type field is completely separate
      from the PA Subtype field.  The same value (e.g., 0) may have
      different meanings as a PB-TNC message type and as a PA subtype.

   PB-TNC Message Length (32 bits)

      This field specifies the length of this PB-TNC message in octets.
      It includes this header (the fields Flags, PB-TNC Vendor ID, PB-
      TNC Message Type, and PB-TNC Message Length).  Therefore, this
      value MUST always be at least 12.  Any Posture Broker Client or
      Posture Broker Server that receives a message with a PB-TNC
      Message Length field whose value is less than 12 MUST respond with
      a fatal Invalid Parameter error code in a CLOSE batch.

   PB-TNC Message Value (variable length)

      The syntax and semantics of this field vary, depending on the
      values in the PB-TNC Vendor ID and PB-TNC Message Type fields.
      The syntax and semantics of several standard messages are defined
      in subsequent sections of this specification.
Top   ToC   RFC5793 - Page 19

4.3. IETF Standard PB-TNC Message Types

The following table provides a reference list with brief descriptions of the IETF Standard PB-TNC Message Types defined in this specification. These PB-TNC message types must be used with a PB-TNC vendor ID of zero (0). If these PB-TNC message type values are used with a different PB-TNC vendor ID, they have a completely different meaning that is not defined in this specification. For more details on these message types, see the remainder of section 4. For IETF Standard PA Subtypes (which are completely different from PB-TNC message types), please refer to the PA-TNC specification [10]. Message Type Definition ------------ ---------- 0 PB-Experimental - reserved for experimental use 1 PB-PA - contains a PA message 2 PB-Assessment-Result - the overall assessment result computed by the Posture Broker Server 3 PB-Access-Recommendation - includes Posture Broker Server access recommendation 4 PB-Remediation-Parameters - includes Posture Broker Server remediation parameters 5 PB-Error - error indicator 6 PB-Language-Preference - sender's preferred language(s) for human-readable strings 7 PB-Reason-String - string explaining reason for Posture Broker Server access recommendation

4.4. PB-Experimental

The PB-Experimental PB-TNC message type is a PB-TNC message type (value 0) that has been set aside for experimental purposes. It may be used to test code or for other experimental purposes. It MUST NOT be used in a production environment or in a product. This meaning for this PB-TNC message type only applies if the PB-TNC Vendor ID field in the PB-TNC Message Header contains the value zero (0). If a different Vendor ID is contained in that field, the PB-TNC message type 0 has a completely different meaning not defined in this specification. The contents of the PB-TNC Message Length and PB-TNC Message Value fields for this PB-TNC message type are not specified. They may have almost any value, depending on what experiments are being conducted. Similarly, the Flags field for this message may have the NOSKIP bit set or cleared, depending on what experiments are being conducted. However, note that the PB-TNC Message Length field must have a value
Top   ToC   RFC5793 - Page 20
   of at least 12 since that is the total of the length of the fixed-
   length fields at the start of the PB-TNC message (the fields Flags,
   PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length).
   Any Posture Broker Client or Posture Broker Server that receives a
   message with a PB-TNC Message Length field whose value is invalid
   MUST respond with a fatal Invalid Parameter error code in a CLOSE
   batch.

   A Posture Broker Client or Posture Broker Server implementation
   intended for production use MUST NOT send a message with this Message
   Type with the value zero (0) as the vendor ID.  If it receives a
   message with this message type and with the value zero (0) as the
   vendor ID, it MUST ignore the message unless the NOSKIP bit is set,
   in which case it MUST respond with a fatal Unsupported Mandatory
   Message error code in a CLOSE batch.

4.5. PB-PA

The PB-TNC message type named PB-PA (value 1) contains one PA message. Many batches will contain several PB-PA messages, but some batches may not contain any messages of this type. All Posture Broker Client and Posture Broker Server implementations MUST implement support for this PB-TNC message type. Generally, this support will consist of forwarding the enclosed PA message to the appropriate Posture Collectors and Posture Validators. Specific requirements are contained later in the description of this message type. The type of the PA message contained in a PB-PA message is indicated by the PA Message Vendor ID and PA Subtype fields, as described later in this section. The PA-TNC specification [10] describes several standard PA message types that can be identified by the PA Message Vendor ID and PA Subtype values listed in the PA-TNC specification. Other PA message types may also be defined, as described in the description of the PA Subtype field later in this section. The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-PA message with the NOSKIP flag not set MUST ignore the message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. For the PB-PA message type, the PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 1. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 1 has a completely different meaning not defined in this specification.
Top   ToC   RFC5793 - Page 21
   The PB-TNC Message Length field MUST contain the length of the entire
   PB-TNC message, including the fixed-length fields at the start of the
   PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message
   Type, and PB-TNC Message Length), the fixed-length fields listed
   below (Flags, PA Message Vendor ID, PA Subtype, Posture Collector
   Identifier, and Posture Validator Identifier), and the PA Message
   Body.  Since the PA Message Body is variable length, the value in the
   PB-TNC Message Length field will vary also.  However, it MUST always
   be at least 24 to cover the fixed-length fields listed in the
   preceding sentences.  Any Posture Broker Client or Posture Broker
   Server that receives a PB-PA message with a PB-TNC Message Length
   field that has an invalid value MUST respond with a fatal Invalid
   Parameter error code in a CLOSE batch.

   The following diagram illustrates the format and contents of the PB-
   TNC Message Value field for this message type.  The text after this
   diagram describes the fields shown here.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Flags      |               PA Message Vendor ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           PA Subtype                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Posture Collector Identifier | Posture Validator Identifier  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 PA Message Body (Variable Length)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags (8 bits)

      This field contains flags relating to the PA message.

      Bit 0 of this flags field (the most significant bit) is known as
      the EXCL flag (for exclusive).  If the EXCL bit is cleared (value
      0), the Posture Broker Client or Posture Broker Server that
      receives this PB-TNC message SHOULD deliver the PA message
      contained in this PB-TNC message to all Posture Collectors or
      Posture Validators that have expressed an interest in PA messages
      with this PA Message Vendor ID and PA subtype.  If a Posture
      Broker Client receives a message with the EXCL flag set (value 1),
      the Posture Broker Client SHOULD deliver the PA message contained
      in this PB-TNC message only to the Posture Collector identified by
      the Posture Collector Identifier field.  However, if the
      identified Posture Collector has not expressed an interest in PA
      messages with this PA Message Vendor ID and PA subtype, the PA
Top   ToC   RFC5793 - Page 22
      message should be silently discarded.  Analogous requirements
      apply to a Posture Broker Server that receives a message with the
      EXCL flag set.

      The EXCL bit allows, for example, a Posture Validator to handle
      the circumstance where there are two Posture Collectors on the
      endpoint that are interested in a particular kind of PA messages
      and the Posture Validator has remediation instructions that only
      apply to one of those Posture Collectors.

      The other bits in this Flags field are reserved.  For this version
      of PB-TNC, they MUST be set to 0 on transmission and ignored on
      reception.

   PA Message Vendor ID (24 bits)

      The PA Message 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 PA Message Vendor ID qualifies the PA Subtype
      field so that each vendor has 2^32-1 separate PA subtypes
      available for its use.  PA subtypes standardized by the IETF are
      always used with a PA Message Vendor ID of the value zero (0) in
      this field.  The PA Message Vendor ID 0xffffff is reserved.  A
      Posture Broker Client or Posture Broker Server MUST NOT send
      messages in which the PA Message Vendor ID field has this reserved
      value (0xffffff).  If a Posture Broker Client or Posture Broker
      Server receives a message in which the PA Message Vendor ID has
      this reserved value (0xffffff), it MUST respond with a fatal
      Invalid Parameter error code in a CLOSE batch.

   PA Subtype (32 bits)

      The PA Subtype field identifies the type of the PA message
      contained in the PA Message Body field.  The PA subtype 0xffffffff
      is reserved.  A Posture Broker Client or Posture Broker Server
      MUST NOT send messages in which the PA Subtype field has this
      reserved value (0xffffffff).  If a Posture Broker Client or
      Posture Broker Server receives a message in which the PA Subtype
      has this reserved value (0xffffffff), it MUST respond with a fatal
      Invalid Parameter error code in a CLOSE batch.  A Posture Broker
      Client or Posture Broker Server MUST support having multiple PA
      messages in a single PB-TNC batch that have the same PA subtype
      and/or PA Message Vendor ID.

      IANA maintains a registry of PA subtypes.  Entries in this
      registry are added by Expert Review with Specification Required,
      following the guidelines in section 6.1.  No PA subtypes are
Top   ToC   RFC5793 - Page 23
      defined in this specification.  Definitions of IETF Standard PA
      Subtypes are contained in the PA-TNC specification [10] and other
      specifications.  IETF Standard PA Subtypes are always used with a
      PA Message Vendor ID of zero (0).

      New vendor-specific PA subtypes (those used with a non-zero PA
      Message Vendor ID) may be defined and employed by vendors without
      IETF or IANA involvement.  However, Posture Broker Clients and
      Posture Broker Servers MUST NOT require support for particular
      vendor-specific PA subtypes and MUST interoperate with other
      parties despite any differences in the set of vendor-specific PA
      subtypes supported (although they MAY permit administrators to
      configure them to require support for specific PA subtypes).

      Note that the PB-TNC Message Type field is completely separate
      from the PA Subtype field.  The same value (e.g., 0) may have
      different meanings as a PB-TNC message type and as a PA subtype.

   Posture Collector Identifier (16 bits)

      The Posture Collector Identifier field contains the identifier of
      the Posture Collector associated with this PA message.

      The Posture Broker Client is responsible for assigning one or more
      Posture Collector Identifier values (but not 0xffff) to each
      Posture Collector involved in a message exchange.  Multiple
      Posture Collector identifiers are required for appropriate
      correlation in cases where there are multiple components of the
      same type handled by a single Posture Collector, e.g., an endpoint
      with two VPN client implementations handled by a single VPN
      Posture Collector.  Please refer to section 3.3 of the PA-TNC
      specification for an example that illustrates the use of multiple
      Posture Collector Identifiers.  The Posture Collector Identifier
      value(s) assigned to a Posture Collector by a Posture Broker
      Client MUST NOT change during the course of a PT session.  This
      identifier is used to identify a unique Posture Collector
      communicating with the Posture Broker Client on the endpoint
      during a NEA exchange, and is used by the Posture Validator to
      send response attributes to a specific Posture Collector component
      if required.

      When a Posture Broker Server sets the EXCL flag for a PA message,
      the Posture Broker Server MUST set the Posture Collector
      Identifier field to the identifier of the Posture Collector that
      should receive the PA message.  If the EXCL flag is not set, a
      Posture Broker Server MAY still set the Posture Collector
      Identifier value for PA messages that it sends to indicate that
      the PA message is intended as a response to a message sent by the
Top   ToC   RFC5793 - Page 24
      Posture Collector associated with the specified Posture Collector
      Identifier.  If the Posture Broker Server does not wish to
      indicate any Posture Collector in this manner, it SHOULD set this
      field to the reserved value 0xffff.

   Posture Validator Identifier (16 bits)

      The Posture Validator Identifier field contains the identifier of
      the Posture Validator associated with this PA message.

      The Posture Broker Server MUST assign a unique Posture Validator
      Identifier value (but not 0xffff) to each Posture Validator
      involved in a message exchange and include this Posture Validator
      identifier in this field for any PA messages sent by that Posture
      Validator.  The Posture Validator Identifier value assigned to a
      Posture Validator by a Posture Broker Server MUST NOT change
      during the course of a PT session.  This identifier is used to
      identify a unique Posture Validator communicating with the Posture
      Broker Server endpoint during a NEA exchange, and is used by the
      Posture Collector to send attributes to a specific Posture
      Validator if required.

      When a Posture Broker Client sets the EXCL flag for a PA message,
      the Posture Broker Client MUST set the Posture Validator
      Identifier field to the identifier of the Posture Validator that
      should receive the PA message.  If the EXCL flag is not set, a
      Posture Broker Client MAY still set the Posture Validator
      Identifier value for PA messages that it sends to indicate that
      the PA message is intended as a response to a message sent by the
      Posture Validator associated with the specified Posture Validator
      Identifier.  If the Posture Broker Client does not wish to
      indicate any Posture Validator in this manner, it SHOULD set this
      field to the reserved value 0xffff.

   PA Message Body (variable length)

      The PA Message Body field contains the body of the PA message that
      is being carried in this PB-TNC message.  The length of this field
      can be determined by subtracting the length of the fixed-length
      fields at the start of the PB-TNC message (the fields Flags, PB-
      TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and
      the fixed-length fields at the start of the PB-PA message (Flags,
      PA Message Vendor ID, PA Subtype, Posture Collector Identifier,
      and Posture Validator Identifier) from the message length
      contained in the PB-TNC Message Length field.  The length of these
      fixed-length fields is 24 octets.  Therefore, any Posture Broker
      Client or Posture Broker Server that receives a PB-PA message with
Top   ToC   RFC5793 - Page 25
      a PB-TNC Message Length field whose value is less than 24 MUST
      respond with a fatal Invalid Parameter error code in a CLOSE
      batch.

4.6. PB-Assessment-Result

The PB-TNC message type named PB-Assessment-Result (value 2) is used by the Posture Broker Server to provide the assessment result after the Posture Broker Server has completed the assessment of the endpoint. The Posture Broker Server will typically compute the assessment result as a cumulative of the individual assessment results received from the various Posture Validators; the algorithm for computation of assessment result at the Posture Broker layer is implementation specific and can also change based on policies in a specific deployment. The Posture Broker Server MUST include one message of this type in any batch of type RESULT and MUST NOT include a message of this type in any other type of batch. The Posture Broker Client MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client MUST implement and process this message and MUST ignore any message with this message type that is not part of a batch of type RESULT. The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 2. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 2 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with the Assessment Result field described below. Any Posture Broker Client or Posture Broker Server that receives a PB-Assessment-Result message with a PB- TNC Message Length field that does not have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. The following diagram illustrates the format and contents of the PB- TNC Message Value field for this message 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5793 - Page 26
   Assessment Result

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

      Value   Description
      -----   -----------
      0       Posture Broker Server assessed the endpoint to be
              compliant with policy.

      1       Posture Broker Server assessed the endpoint to be non-
              compliant with policy but the difference from compliance
              was minor.

      2       Posture Broker Server assessed the endpoint to be non-
              compliant with policy and the assessed difference from
              compliance was very significant.

      3       Posture Broker Server was unable to determine policy
              compliance due to an error.

      4       Posture Broker Server was unable to determine whether the
              assessed endpoint is compliant with policy based on the
              attributes provided by endpoint.

      If a Posture Broker Client receives an Assessment Result value
      other than the five values described above, it MUST respond with a
      fatal Invalid Parameter error in a CLOSE batch.  Other values may
      be defined in future versions of PB-TNC but only if the PB-TNC
      version number is changed.  Therefore, there is no need for an
      IANA registry for Assessment Result values.

4.7. PB-Access-Recommendation

The PB-TNC message type named PB-Access-Recommendation (value 3) is used by the Posture Broker Server to provide an access recommendation after the Posture Broker Server has completed some assessment of the endpoint. The PB-Assessment-Result and the PB-Access-Recommendation attribute together constitute the global assessment decision for an endpoint. The PB-Access-Recommendation is not authoritative, and the network and host-based access control systems would typically use additional information to determine the network access that is granted to the endpoint. The Posture Broker Server MAY include one message of this type in any batch of type RESULT and MUST NOT include a message of this type in any other type of batch. Posture Broker Clients MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE
Top   ToC   RFC5793 - Page 27
   batch.  The Posture Broker Client MUST implement and process this
   message and MUST ignore any message with this message type that is
   not part of a batch of type RESULT.

   The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this
   message type.  Any Posture Broker Client or Posture Broker Server
   that receives a PB-Access-Recommendation message with the NOSKIP flag
   set MUST ignore the message and MUST respond with a fatal Invalid
   Parameter error code in a CLOSE batch.  The PB-TNC Vendor ID field
   MUST contain the value zero (0) and the PB-TNC Message Type field
   MUST contain 3.  If a non-zero value is contained in the PB-TNC
   Vendor ID field, message type 3 has a completely different meaning
   not defined in this specification.  The PB-TNC Message Length field
   MUST contain the value 16 since that is the total of the length of
   the fixed-length fields at the start of the PB-TNC message (the
   fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC
   Message Length) along with the Access Recommendation field described
   below.  Any Posture Broker Client or Posture Broker Server that
   receives a PB-Access-Recommendation message with a PB-TNC Message
   Length field that does not have a value of 16 MUST respond with a
   fatal Invalid Parameter error code in a CLOSE batch.

   The following diagram illustrates the format and contents of the PB-
   TNC Message Value field for this message type.  The text after this
   diagram describes the fields shown here.

       0                   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             |   Access Recommendation Code  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved (16 bits)

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

   Access Recommendation Code (16 bits)

      The Access Recommendation Code field identifies the Access
      Recommendation that the Posture Broker Server has made for this
      Posture Broker Client at this time.  This field MUST have one of
      these three values: 1 for Access Allowed (full access), 2 for
      Access Denied (no access), or 3 for Quarantined (partial access).
      If a Posture Broker Client receives an Access Recommendation Code
      value other than these three values, it MUST respond with a fatal
      Invalid Parameter error code in a CLOSE batch.  Other values may
Top   ToC   RFC5793 - Page 28
      be defined in future versions of PB-TNC but only if the PB-TNC
      version number is changed.  Therefore, there is no need for an
      IANA registry for Access Recommendation Codes.

4.8. PB-Remediation-Parameters

The PB-TNC message type named PB-Remediation-Parameters (value 4) is used by the Posture Broker Server to provide global (not Posture Validator-specific) remediation parameters after the Posture Broker Server has completed some assessment of the endpoint. The Posture Broker Server MAY include one or more messages of this type in any batch of any type, but this message type is most useful in batches of type RESULT. The Posture Broker Client MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client may implement and process this message but is not required to do so. It may skip this message. Even if the Posture Broker Client implements this message type, it is not obligated to act on it. The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 4. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 4 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type), and the Remediation Parameters. Since the Remediation Parameters field is variable length, the value in the PB- TNC Message Length field will vary also. However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client that receives a PB-Remediation- Parameters message with a PB-TNC Message Length field that contains an invalid value (e.g., less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. The following diagram illustrates the format and contents of the PB- TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
Top   ToC   RFC5793 - Page 29
       0                   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)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved (8 bits)

      These 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 type of
      remediation parameters contained in the Remediation Parameters
      field.  A Posture Broker Client or Posture Broker Server MUST
      support having multiple Remediation Parameters messages contained
      in a single PB-TNC batch that have the same Remediation Parameters
      Type and/or Remediation Parameters Vendor ID.

      IANA maintains a registry of PB-TNC Remediation Parameters Types.
      Entries in this registry are added by Expert Review with
      Specification Required, following the guidelines in section 6.1.
      A list of IETF Standard PB-TNC Remediation Parameters Types
      defined in this specification appears later in this section.

      New vendor-specific Remediation Parameters Types (those used with
      a non-zero Remediation Parameters vendor ID) may be defined and
      employed by vendors without IETF or IANA involvement.  However,
      Posture Broker Clients and Posture Broker Servers MUST NOT require
      support for particular vendor-specific Remediation Parameters
      Types and MUST interoperate with other parties despite any
      differences in the set of vendor-specific Remediation Parameters
Top   ToC   RFC5793 - Page 30
      Types supported (although they MAY permit administrators to
      configure them to require support for specific Remediation
      Parameters Types).

      Note that the Remediation Parameters Type is completely separate
      from the PB-TNC Message Type and the PA Subtype fields.  The same
      value (e.g., 0) may have different meanings in each of these
      fields.

   Remediation Parameters (variable length)

      The Remediation Parameters field contains the actual remediation
      parameters carried in this PB-TNC message.  The length of this
      field can be determined by subtracting the length of the fixed-
      length fields at the start of the PB-TNC message (the fields
      Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message
      Length) and the fixed-length fields at the start of the PB-
      Remediation-Parameters message (Reserved, Remediation Parameters
      Vendor ID, and Remediation Parameters Type) from the message
      length contained in the PB-TNC Message Length field.  The length
      of these fixed-length fields is 20 octets.  Therefore, any Posture
      Broker Client that receives a PB-Remediation-Parameters message
      with a PB-TNC Message Length field whose value is less than 20
      MUST consider this a malformed message.  The Posture Broker Client
      MUST respond with a fatal Invalid Parameter error code in a CLOSE
      batch.

4.8.1. IETF Standard PB-TNC Remediation Parameters Types

This subsection defines several Remediation Parameters Types that have been standardized by the IETF. Remediation-URI This Remediation Parameters Type is employed by creating a PB- Remediation-Parameters message with a Remediation Parameters Vendor ID equal to the value zero (0) and a Remediation Parameters Type of 1. The Remediation Parameters field in the PB- Remediation-Parameters message MUST contain a URI, as described in RFC 3986 [2]. This URI contains instructions and resources for remediation. The Posture Broker Client MAY load the URI and display the resulting web page to the user. The Posture Broker Client MAY also ignore the URI or take another action with it. The Posture Broker Server and any other parties involved in configuring this remediation URI should consider the likely capabilities of the Posture Broker Client when creating the URI
Top   ToC   RFC5793 - Page 31
      and the content referenced by the URI.  For example, they should
      consider the Posture Broker Client's language preferences as
      expressed in the PB-Language-Preference message.

   Remediation-String

      This Remediation Parameters Type is employed by creating a PB-
      Remediation-Parameters message with a Remediation Parameters
      Vendor ID equal to the value zero (0) and a Remediation Parameters
      Type of 2.  The Remediation Parameters field in the PB-
      Remediation-Parameters message MUST contain the structure defined
      below, which contains human-readable instructions for remediation.

      The Posture Broker Client MAY display the instructions to the
      user.  The Posture Broker Client MAY also ignore the instructions
      or take another action with them.  The Posture Broker Server and
      any other parties involved in configuring these instructions
      should consider the likely capabilities of the Posture Broker
      Client when creating the instructions.  For example, they should
      consider the Posture Broker Client's language preferences as
      expressed in the PB-Language-Preference message.

      The following diagram illustrates the format and contents of the
      Remediation Parameters field when carrying a Remediation-String
      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 String Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Remediation String (Variable Length)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Lang Code Len |  Remediation String Lang Code (Variable Len)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Remediation String Length (32 bits)

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

   Remediation String (variable length)

      The Remediation String field MUST contain a UTF-8 [6] encoded
      string.  This string contains human-readable instructions for
      remediation that MAY be displayed to the user by the Posture
      Broker Client.  NUL termination MUST NOT be included.  If a
Top   ToC   RFC5793 - Page 32
      Posture Broker Client receives a Reason String that does contain a
      NUL termination, it MUST respond with a fatal Invalid Parameter
      error in a CLOSE batch.

   Lang Code Len (8 bits)

      The Lang Code Len field contains the length of the Remediation
      String Lang Code field in octets.  This value may be set to zero
      to indicate that the language code for the Remediation String
      field is not known.

   Remediation String Lang Code (variable length)

      The Remediation String Lang Code field contains a US-ASCII string
      composed of a well-formed RFC 4646 [3] 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 field is not known.

4.9. PB-Error

The PB-TNC message type named PB-Error (value 5) is used by the Posture Broker Client or Posture Broker Server to indicate that an error has occurred. The Posture Broker Client or Posture Broker Server MAY include one or more messages of this type in any batch of any type. Other messages may also be included in the same batch. The party that receives a PB-Error message MAY log it or take other action as deemed appropriate. If the FATAL flag is set (value 1), the recipient MUST terminate the PB-TNC session after processing the batch without sending any messages in response. Every Posture Broker Client and Posture Broker Server MUST implement this message type. The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 5. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 5 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, Error Code Vendor ID, Error Code, and Reserved), and the Error Parameters. Since the Error Parameters field is variable length, the value in the PB-TNC Message Length field will vary also.
Top   ToC   RFC5793 - Page 33
   However, it MUST always be at least 20 to cover the fixed-length
   fields listed in the preceding sentences.  Any Posture Broker Client
   or Posture Broker Server that receives a PB-Error message with a PB-
   TNC Message Length field that contains an invalid value (e.g., less
   than 20) MUST respond with a fatal Invalid Parameter error code in a
   CLOSE batch.  Any PB-Error message generated while processing a PB-
   Error message MUST be a fatal error to avoid the chance of generating
   an infinite loop of errors.

   The following diagram illustrates the format and contents of the PB-
   TNC Message Value field for this message type.  The text after this
   diagram describes the fields shown here.

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

   Flags (8 bits)

      This field defines flags relating to the error.

      Bit 0 of this flags field (the most significant bit) is known as
      the FATAL flag.  If the FATAL bit is cleared (value 0), the
      Posture Broker Client or Posture Broker Server that receives this
      PB-TNC message SHOULD process this error and then continue with
      the exchange.  If the FATAL flag is set (value 1), the Posture
      Broker Client or Posture Broker Server that receives this PB-TNC
      message MUST terminate the exchange after processing the error.
      In addition, any Posture Broker Client or Posture Broker Server
      that sends a fatal error MUST NOT process the batch that caused
      the error and MUST terminate the exchange after sending the batch
      containing the error report.  A PB-Error message with the FATAL
      flag set MUST always be sent in a CLOSE batch since the sender
      will be terminating the exchange immediately after sending the
      batch.

      The FATAL bit allows a Posture Broker Client or Posture Broker
      Server to signal a fatal error (like an invalid batch type) and/or
      a non-fatal error (like an invalid language tag for a preferred
      language).
Top   ToC   RFC5793 - Page 34
      The other bits in this Flags field are reserved.  For this version
      of PB-TNC, they MUST be set to 0 on transmission and ignored on
      reception.

   Error Code Vendor ID (24 bits)

      The Error Code 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 Error Code Vendor ID qualifies the Error Code
      field so that each vendor has 2^16 separate Error Codes available
      for its use.  Error codes standardized by the IETF are always used
      with the value zero (0) in this field.  For detailed descriptions
      of those messages, see the next few subsections.

   Error Code (16 bits)

      The Error Code field identifies the type of error being signaled
      with this message.  The format of the Error Parameters field
      depends on the value of the Error Code Vendor ID and the Error
      Code.  However, any recipient that does not understand a
      particular error code can process the error fairly well by using
      the FATAL flag to determine whether the error is fatal and the PB-
      TNC Message Length to skip over the Error Parameters field (or log
      it).

      IANA maintains a registry of PB-TNC Error Codes.  Entries in this
      registry are added by Expert Review with Specification Required,
      following the guidelines in section 6.1.  A list of IETF Standard
      PB-TNC Error Codes defined in this specification appears later in
      section 4.9.1.

      New vendor-specific error codes (those used with a non-zero error
      code vendor ID) may be defined and employed by vendors without
      IETF or IANA involvement.  Posture Broker Clients and Posture
      Broker Servers that receive an unknown error code MUST process
      this error code gracefully by ignoring or logging it if it is not
      marked as fatal and terminating the exchange if it is marked as
      fatal.

   Reserved (16 bits)

      The Reserved bits MUST be set to 0 on transmission and ignored on
      reception.
Top   ToC   RFC5793 - Page 35

4.9.1. IETF Standard PB-TNC Error Codes

The following error codes are IETF Standard PB-TNC Error Codes, hence the Error Code Vendor ID MUST be the value zero (0). The following table defines the 16-bit error code. Vendor-specific error codes may be defined by setting the Error Code Vendor ID to the defining vendor's SMI PEN and setting the Error Code field to whatever error code(s) that vendor has defined. The format, length, and meaning of the Error Parameters field varies, based on the Error Code Vendor ID and Error Code. Subsequent sections of this document define the format, length, and meaning of the Error Parameters for the IETF Standard PB-TNC Error Codes defined in this section. Error Code Definition ---------- ---------- 0 Unexpected Batch Type. Error Parameters are empty. 1 Invalid Parameter. Error Parameters has offset where invalid value was found. 2 Local Error. Error Parameters are empty. 3 Unsupported Mandatory Message. Error Parameters has offset of offending PB-TNC Message 4 Version Not Supported. Error Parameters has information about which versions are supported.

4.9.2. Error Parameters Structures for IETF Standard PB-TNC Error Codes

This section defines the format, length, and meaning of the Error Parameters field for the IETF Standard PB-TNC Error Codes defined in this specification. The Error Parameters field is zero length for the IETF Standard PB- TNC Error Code 0. The FATAL flag MUST be set for this error code. The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 1. The Offset field is the offset in octets from the start of the PB-TNC batch to the invalid value. The FATAL flag may be either set or cleared for this error code. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5793 - Page 36
   The Error Parameters field is zero length for the IETF Standard PB-
   TNC Error Code 2.  The FATAL flag MUST be set for this error code.

   The Error Parameters field has the following structure for the IETF
   Standard PB-TNC Error Code 3.  The Offset field is the offset in
   octets from the start of the PB-TNC batch to the PB-TNC message whose
   message type was not recognized (and where the NOSKIP flag was set).
   The FATAL flag MUST be set for this error code.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Offset                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Error Parameters field has the following structure for the IETF
   Standard PB-TNC Error Code 4.  The FATAL flag MUST be set for this
   error code.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Bad Version  |  Max Version  |  Min Version  |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Bad Version field is the version number that was received and is
   not supported.  The Max Version and Min Version fields indicate which
   PB-TNC version numbers are supported by the sender of the error code.
   The sender MUST support all PB-TNC versions between the Min Version
   and the Max Version, inclusive (i.e., including the Min Version and
   the Max Version) but excluding the reserved versions listed in
   section 4.1.  The Reserved field MUST be set to 0 on transmission and
   ignored upon reception.  When possible, recipients of this error code
   SHOULD send future messages to the Posture Broker Server or Posture
   Broker Client that originated this error message with a PB-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 PB-TNC message in a PB-TNC CLOSE
   batch with version number 2.  All parties that send PB-TNC batches
   SHOULD be able to properly process a batch that meets this
   description, even if they cannot process any other aspect of PB-TNC
   version 2.  This ensures that a PB-TNC version exchange can proceed
   properly, no matter what versions of PB-TNC the parties implement.
Top   ToC   RFC5793 - Page 37

4.10. PB-Language-Preference

The PB-TNC message type named PB-Language-Parameters (value 6) is used by the Posture Broker Client to indicate which language or languages it would prefer for any human-readable strings that might be sent to it. This allows the Posture Broker Server and Posture Validators to adapt any messages they may send to the Posture Broker Client's preferences (probably determined by the language preferences of the endpoint's users). The Posture Broker Server may also send this message type to the Posture Broker Client to indicate the Posture Broker Server's language preferences, but this is not very useful since the Posture Broker Client rarely sends human-readable strings to the Posture Broker Server and, if it does, rarely can adapt those strings to the preferences of the Posture Broker Server. No Posture Broker Client or Posture Broker Server is required to send or implement this message type. However, a Posture Broker Server SHOULD attempt to adapt to user language preferences by implementing this message type, passing the language preference information to Posture Validators, and allowing administrators to configure human- readable languages in whatever languages are preferred by their users. A Posture Broker Client or Posture Broker Server may include a message of this type in any batch of any type. However, it is suggested that this message be included in the first batch sent by the Posture Broker Client or Posture Broker Server in a PB-TNC session so that the recipient can start adapting its human-readable messages as soon as possible. If one PB-Language-Parameters message is received and then another one is received in a later batch for the same PB-TNC session, the value included in the later message should be considered to replace the value in the earlier message. A Posture Broker Client or Posture Broker Server MUST NOT include more than one message of this type in a single batch. If a Posture Broker Client or Posture Broker Server receives more than one message of this type in a single batch, it should ignore all but the last one. The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 6. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 6 has a completely different meaning not defined in this specification.
Top   ToC   RFC5793 - Page 38
   The PB-TNC Message Length field MUST contain the length of the entire
   PB-TNC message, including the fixed-length fields at the start of the
   PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message
   Type, and PB-TNC Message Length) and the Language Preference field.
   Since the Language Preference field is variable length, the value in
   the PB-TNC Message Length field will vary also.  However, it MUST
   always be at least 12 to cover the fixed-length fields listed in the
   preceding sentences.

   The following diagram illustrates the format and contents of the PB-
   TNC Message Value field for this message type.  The text after this
   diagram describes the fields shown here.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Language Preference (Variable Length)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Language Preference (variable length)

      The Language Preference field contains an Accept-Language header,
      as described in RFC 3282 [4] (using the RFC 2234 ABNF definition
      of Accept-Language included in that RFC, US-ASCII only, no control
      characters allowed, no comments, no NUL termination).  Any Posture
      Broker Client or Posture Broker Server that sends a PB-Language-
      Preference message MUST ensure that the Language Preference field
      conforms to this format.  For example, one acceptable value would
      be "Accept-Language: fr, en" (without the quote marks).

      A zero-length Language Preference field indicates that no language
      preference information is available.  Generally, there's no need
      to send a PB-Language-Preference message with a zero-length
      Language Preference field since this is equivalent to sending no
      PB-Language-Preference message at all, but it may be useful to
      send a zero-length Language Preference field if a PB-Language-
      Preference message with a non-zero-length Language Preference
      field was sent in an earlier batch but these preferences no longer
      apply.

4.11. PB-Reason-String

The PB-TNC message type named PB-Reason-String (value 7) is used by the Posture Broker Server to provide a human-readable explanation for the global assessment decision conveyed in the PB-Assessment-Result & PB-Access-Recommendation messages. Therefore, a PB-Reason-String
Top   ToC   RFC5793 - Page 39
   message SHOULD only be included in the same batch as the PB-
   Assessment-Result and PB-Access-Recommendation message.  The Posture
   Broker Client MUST NOT ever send a PB-Reason-String message.

   The Posture Broker Client is not required to implement this message
   type and the Posture Broker Server is not required to send it.
   However, there is some benefit to doing so since users are often
   curious about why the endpoint was considered non-compliant.  The
   manner in which a Posture Broker Client uses this field is up to the
   implementer and not specified here.  The Posture Broker Client MAY
   display the message to the user, log it, ignore it, or take any other
   action that is not inconsistent with the requirements of this
   specification.  Since the strings contained in this message are
   human-readable, the Posture Broker Server SHOULD adapt them to the
   Posture Broker Client's language preferences as expressed in any PB-
   Language-Preference message sent by the Posture Broker Client in this
   PB-TNC session.

   A Posture Broker Server MAY include more than one message of this
   type in any batch of any type.  However, it is suggested that this
   message be included in the same batch as the PB-Assessment-Result and
   PB-Access-Recommendation message.  If more than one PB-Reason-String
   message is included in a single batch, the Posture Broker Client
   SHOULD consider the strings included in these messages to be
   equivalent in meaning.  This allows the Posture Broker Server to
   return multiple equivalent reason strings in different languages,
   which may help if the Posture Broker Server is not able to
   accommodate the Posture Broker Client's language preferences.

   The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this
   message type.  The PB-TNC Vendor ID field MUST contain the value zero
   (0) and the PB-TNC Message Type field MUST contain 7.  If a non-zero
   value is contained in the PB-TNC Vendor ID field, message type 7 has
   a completely different meaning not defined in this specification.

   The PB-TNC Message Length field MUST contain the length of the entire
   PB-TNC message, including the fixed-length fields at the start of the
   PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message
   Type, and PB-TNC Message Length), the fixed-length fields listed
   below (Reason String Length and Lang Code Len), and the Reason String
   and Reason String Language Code fields.  Since the Reason String and
   Reason String Language Code fields are variable length, the value in
   the PB-TNC Message Length field will vary also.  However, it MUST
   always be at least 17 to cover the fixed-length fields listed in the
   preceding sentences.  In fact, the PB-TNC Message Length field MUST
   be exactly the sum of 17 (for the fixed-length fields) and the values
Top   ToC   RFC5793 - Page 40
   of the Reason String Length and Lang Code Len fields.  If this is not
   the case, the recipient MUST respond with a fatal Invalid Parameter
   error code in a CLOSE batch.

   The following diagram illustrates the format and contents of the PB-
   TNC Message Value field for this message type.  The text after this
   diagram describes the fields shown here.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Reason String Length                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Reason String (Variable Length)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Lang Code Len | Reason String Language Code (Variable Length) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reason String Length (32 bits)

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

   Reason String (variable length)

      The Reason String field contains a UTF-8 encoded string that
      provides a human-readable reason for the Posture Broker Server's
      assessment decision.  NUL termination MUST NOT be included.  If a
      Posture Broker Client receives a Reason String that does contain a
      NUL termination, it MUST respond with a fatal Invalid Parameter
      error code in a CLOSE batch.  A zero-length string MUST NOT be
      sent since this is the same as sending no reason string at all,
      leaving the reason unspecified.

   Lang Code Len (8 bits)

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

   Reason String Language Code (variable length)

      The Reason String Language Code field contains a US-ASCII string
      containing a well-formed RFC 4646 [3] language tag that indicates
      the language(s) used in the Reason String in this message.  NUL
      termination MUST NOT be included in this field.  A zero-length
      string MAY be sent for this field (essentially omitting this
      field) to indicate that the language code for the reason string is
      not known.


(next page on part 3)

Next Section