GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5793

Internet Engineering Task Force (IETF) R. Sahita Request for Comments: 5793 Intel Category: Standards Track S. Hanna ISSN: 2070-1721 Juniper

                                                              R. Hurst
                                                             Microsoft
                                                            K. Narayan
                                                         Cisco Systems
                                                            March 2010
         PB-TNC: A Posture Broker (PB) Protocol Compatible
                 with Trusted Network Connect (TNC)

Abstract

 This document specifies PB-TNC, a Posture Broker protocol identical
 to the Trusted Computing Group's IF-TNCCS 2.0 protocol.  The document
 then evaluates PB-TNC against the requirements defined in the NEA
 Requirements specification.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5793.

Sahita, et al. Standards Track [Page 1] RFC 5793 PB-TNC March 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Table of Contents

 1. Introduction ....................................................4
    1.1. Prerequisites ..............................................4
    1.2. Message Diagram Conventions ................................4
    1.3. Terminology ................................................4
    1.4. Conventions Used in This Document ..........................4
 2. PB-TNC Design Considerations ....................................5
    2.1. Message Addressing .........................................5
    2.2. Vendor IDs .................................................7
    2.3. Efficiency .................................................7
 3. PB-TNC Protocol Description .....................................7
    3.1. Protocol Overview ..........................................7
    3.2. PB-TNC State Machine .......................................8
    3.3. Layering on PT ............................................11
    3.4. Example of PB-TNC Encapsulation ...........................12
 4. PB-TNC Protocol Specification ..................................13
    4.1. PB-TNC Header .............................................13
    4.2. PB-TNC Message ............................................16
    4.3. IETF Standard PB-TNC Message Types ........................19
    4.4. PB-Experimental ...........................................19

Sahita, et al. Standards Track [Page 2] RFC 5793 PB-TNC March 2010

    4.5. PB-PA .....................................................20
    4.6. PB-Assessment-Result ......................................25
    4.7. PB-Access-Recommendation ..................................26
    4.8. PB-Remediation-Parameters .................................28
    4.9. PB-Error ..................................................32
    4.10. PB-Language-Preference ...................................37
    4.11. PB-Reason-String .........................................38
 5. Security Considerations ........................................41
    5.1. Threat Model ..............................................41
    5.2. Countermeasures ...........................................42
 6. IANA Considerations ............................................43
    6.1. Designated Expert Guidelines ..............................44
    6.2. Registry for PB-TNC Message Types .........................45
    6.3. Registry for PA Subtypes ..................................45
    6.4. Registry for PB-TNC Remediation Parameters Types ..........46
    6.5. Registry for PB-TNC Error Codes ...........................46
 7. Acknowledgments ................................................47
 8. References .....................................................47
    8.1. Normative References ......................................47
    8.2. Informative References ....................................48
 Appendix A. Use Cases .............................................49
    A.1. Initial Client-Triggered Assessment .......................49
    A.2. Server-Initiated Assessment with Remediation ..............54
    A.3. Client-Triggered Reassessment .............................63
 Appendix B. Evaluation against NEA Requirements ...................70
    B.1. Evaluation against Requirement C-1 ........................70
    B.2. Evaluation against Requirement C-2 ........................70
    B.3. Evaluation against Requirement C-3 ........................70
    B.4. Evaluation against Requirement C-4 ........................71
    B.5. Evaluation against Requirement C-5 ........................71
    B.6. Evaluation against Requirement C-6 ........................71
    B.7. Evaluation against Requirement C-7 ........................72
    B.8. Evaluation against Requirement C-8 ........................72
    B.9. Evaluation against Requirement C-9 ........................72
    B.10. Evaluation against Requirement C-10 ......................73
    B.11. Evaluation against Requirement C-11 ......................73
    B.12. Evaluation against Requirement PB-1 ......................74
    B.13. Evaluation against Requirement PB-2 ......................74
    B.14. Evaluation against Requirement PB-3 ......................74
    B.15. Evaluation against Requirement PB-4 ......................75
    B.16. Evaluation against Requirement PB-5 ......................75
    B.17. Evaluation against Requirement PB-6 ......................76

Sahita, et al. Standards Track [Page 3] RFC 5793 PB-TNC March 2010

1. Introduction

 This document specifies PB-TNC, a Posture Broker (PB) protocol
 identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol [7].
 The document then evaluates PB-TNC against the requirements defined
 in the Network Endpoint Assessment (NEA) Requirements specification
 [8].

1.1. Prerequisites

 This document does not define an architecture or reference model.
 Instead, it defines a protocol that works within the reference model
 described in the NEA Requirements specification [8].  The reader is
 assumed to be thoroughly familiar with that document.  No familiarity
 with TCG specifications is assumed.

1.2. Message Diagram Conventions

 This specification defines the syntax of PB-TNC messages using
 diagrams.  Each diagram depicts the format and size of each field in
 bits.  Implementations MUST send the bits in each diagram as they are
 shown, traversing the diagram from top to bottom and then from left
 to right within each line (which represents a 32-bit quantity).
 Multi-byte fields representing numeric values must be sent in network
 (big endian) byte order.
 Descriptions of bit field (e.g., flag) values are described referring
 to the position of the bit within the field.  These bit positions are
 numbered from the most significant bit through the least significant
 bit, so a 1-octet field with only bit 0 set has the value 0x80.

1.3. Terminology

 This document reuses the terminology defined in the NEA Requirements
 document.  One new term is defined in this section.
 Batch - A group of PB-TNC messages sent over a Posture Transport (PT)
 protocol at one time.  Since the PB-TNC protocol needs to be able to
 work over a half-duplex PT protocol, PB-TNC messages are grouped into
 batches.  The Posture Broker Client sends one batch to the Posture
 Broker Server, which responds with a batch.

1.4. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [1].

Sahita, et al. Standards Track [Page 4] RFC 5793 PB-TNC March 2010

2. PB-TNC Design Considerations

 The primary purpose of the PB-TNC protocol is to carry Posture
 Attribute (PA) messages between Posture Collectors and Posture
 Validators.  Also, PB-TNC must carry messages between the Posture
 Broker Client and the Posture Broker Server (known as PB-TNC
 messages) and manage the state of the assessment.

2.1. Message Addressing

 The NEA Overview and Requirements document [8] describes in section
 5.1.1.1 several ways that messages can be addressed and delivered to
 the proper Posture Collector(s) and Posture Validator(s).  Of the
 techniques described in that section, PB-TNC supports dynamic
 identifiers and message types.

2.1.1. Message Types

 Message types are the simplest and most common way to handle message
 delivery.  Each PA message sent via PB-TNC has an associated PA
 message type, composed of a PA Message Vendor ID and a PA subtype.
 The PA-TNC specification [10] provides a list of IETF Standard PA
 Subtypes, which are used with a PA Message Vendor ID of 0.  These
 include values such as Operating System and Anti-Virus, which are
 used for messages relating to operating system and anti-virus
 posture.
 Vendor-specific PA message types may be indicated by placing the
 defining vendor's Structure of Management Information (SMI) Private
 Enterprise Number into the PA Message Vendor ID field and a PA
 Subtype value assigned by that vendor in the PA Subtype field.  This
 allows each vendor to define its own set of PA Subtype values without
 worrying about collisions with other vendors or with standard values.
 The PA message type is somewhat analogous to a MIME type in that it
 indicates the type of the PA message.  Posture Collectors and Posture
 Validators can use local APIs to indicate to the Posture Broker
 Client and Posture Broker Server which PA message types they are
 interested in receiving.  For instance, a Posture Validator that
 evaluates anti-virus posture might indicate that it would like to
 receive PA messages with a PA Message Vendor ID of 0 and a PA Subtype
 that matches the IETF Standard PA Subtype for Anti-Virus.  It might
 also indicate interest in some vendor-specific PA message types to
 get additional vendor-specific information on anti-virus posture.

Sahita, et al. Standards Track [Page 5] RFC 5793 PB-TNC March 2010

 This type-based subscription model allows great flexibility in design
 and implementation.  One Posture Validator may be responsible for
 evaluating several functions: anti-virus and host-based firewall, for
 instance.  Posture Collectors do not need to know which Posture
 Validators are installed on the Posture Broker Server or what they
 handle.  The Posture Collector simply sends PA messages with message
 types and the Posture Broker Server delivers them to the right
 Posture Validators.
 Because the Posture Broker Client and Posture Broker Server must have
 access to the PA Message Vendor ID and PA Subtype fields and because
 these are routing identifiers independent of the contents of the PA
 messages, these fields are located in PB-TNC not inside the PA
 messages themselves.
 A similar type-based system is used to tag PB-TNC messages.  In this
 case, the extensibility benefits are not as essential as with PA-TNC
 messages, but the ability to define IETF Standard PB-TNC Message
 Types and vendor-specific PB-TNC message types is still valuable.

2.1.2. Dynamic Identifiers

 The type-based message delivery model described above is not ideal
 for all circumstances.  Sometimes it is important for a Posture
 Collector to deliver a message to a particular Posture Validator.
 For example, a particular Posture Validator might send a remediation
 message and the Posture Collector might need to send a response only
 to that one Posture Validator.  To handle this circumstance, PB-TNC
 provides delivery based on dynamic identifiers.
 When a Posture Broker Server loads a Posture Validator, it assigns it
 a Posture Validator ID.  Any PA messages sent by a Posture Validator
 include that Posture Validator's Posture Validator ID in the Posture
 Validator ID field of the PB-PA message.  A Posture Collector that
 receives such a message can send a message in response and request
 exclusive delivery to the Posture Validator identified by that
 Posture Validator ID.
 Dynamic identifiers avoid problems caused by the multicast nature of
 message types.  Multiple Posture Collectors or Posture Validators may
 be registered for the same message type, and this can cause confusion
 if they all respond and the software designer did not consider that
 possibility.  The dynamic identifier system allows more directed
 responses, but it does not work until at least one message has been
 received (so that the dynamic identifiers can be received).  Static
 identifiers were considered as another alternative but rejected
 because they result in a brittle system that only works with a

Sahita, et al. Standards Track [Page 6] RFC 5793 PB-TNC March 2010

 particular set of Posture Collectors and Posture Validators and
 causes problems if two Posture Collectors or Posture Validators with
 the same static identifier are installed.

2.2. Vendor IDs

 In several places, PB-TNC needs to define a set of standard values
 but also allow vendor-specific extensions.  In each of these places
 (PB-TNC Message Types, PA Subtypes, Remediation Parameters Types, and
 Error Codes), the solution chosen was to preface the values with a
 vendor ID.  If a vendor ID is 0, the values in the next field are
 registered in an IANA registry and their meanings defined in an RFC.
 If a vendor ID is non-zero, the values in the next field are vendor
 specific and defined by the vendor whose SMI Private Enterprise
 Number matches the vendor ID.  Vendor-specific messages that are not
 understood by the recipient are ignored and skipped unless they have
 the NOSKIP flag set, in which case an error code is returned.

2.3. Efficiency

 PB-TNC needs to work with low bandwidth transports and low power
 devices.  Therefore, a simple, compact format was chosen for the PB-
 TNC protocol: binary messages with a Type-Length-Value structure.

3. PB-TNC Protocol Description

3.1. Protocol Overview

 The PB-TNC protocol carries batches of PB messages between a Posture
 Broker Client and a Posture Broker Server.  It encapsulates PA
 messages and manages the NEA session.  It runs over a PT protocol.
 In order to work well over half-duplex PT protocols (such as those
 based on EAP [9]), PB-TNC supports half-duplex protocol operation.
 In this mode, the Posture Broker Client and Posture Broker Server
 take turns sending a single batch of messages to each other.  While
 the half-duplex nature of PB-TNC could slow exchanges that require
 many round trips or bidirectional multimedia exchanges, this is not a
 problem in practice because endpoint assessments do not typically
 involve multimedia or a large number of round trips.  The benefit of
 working over half-duplex transports outweighs any limitations
 imposed.
 PB-TNC also supports full-duplex protocol operation so that PB-TNC
 exchanges can be re-initialized immediately when needed (e.g., if the
 Posture Broker Server policy changes or if the Posture Broker Client
 detects a suspicious event).

Sahita, et al. Standards Track [Page 7] RFC 5793 PB-TNC March 2010

 Each PB-TNC batch consists of a header followed by a sequence of PB-
 TNC messages.  Each PB-TNC message has a Type-Length-Value (TLV)
 format with a few flags.  The TLV format allows a recipient to skip
 messages that it does not understand.  The TLV format also provides a
 standard way to mark messages as mandatory to ensure interoperability
 between a Posture Broker Client and a Posture Broker Server.
 This specification defines certain standard PB-TNC message types.  It
 also permits vendors to define their own vendor-specific message
 types.  One of the most important standard PB-TNC message types is
 PB-PA.  A message with this type contains a PA message and various
 message routing information.  A Posture Broker Client or Posture
 Broker Server that receives such a message does not interpret the PA
 message within.  Instead, it delivers the PA message to the
 appropriate set of Posture Collectors or Posture Validators, as
 determined using the message routing information contained in the PB-
 PA message.
 A Posture Broker Server will often need to communicate with several
 Posture Broker Clients at once.  The reverse may also be true, as
 when an endpoint has multiple network interfaces connected to
 different networks.  Each connection between a Posture Broker Server
 and a Posture Broker Client is instantiated as a separate PB-TNC
 session.  There may be several simultaneous sessions between a single
 Posture Broker Server and Posture Broker Client, but this is unusual.

3.2. PB-TNC State Machine

 Figure 1 illustrates the PB-TNC state machine, showing the set of
 states that a PB-TNC session can have and the possible transitions
 among these states.  The following paragraphs describe this state
 machine in more detail.

Sahita, et al. Standards Track [Page 8] RFC 5793 PB-TNC March 2010

             Receive CRETRY        SRETRY
                  or SRETRY   +----------------+
                       +--+   |                |
                       v  |   v                |
                      +---------+  CRETRY  +---------+
            CDATA     | Server  |<---------| Decided | CLOSE
         +----------->| Working |--------->|         |-------+
         |            +---------+  RESULT  +---------+       |
         |                ^ |  |                             v
         |                | |  +---------------------->=======
       ========           | |              CLOSE       " End "
       " Init "      CDATA| |SDATA                     =======
       ========           | |                          ^    ^
         |  |             | v                          |    |
         |  | SDATA   +---------+          CLOSE       |    |
         |  +-------->| Client  |----------------------+    |
         |            | Working |                           |
         |            +---------+                           |
         |                |  ^                              |
         |                +--+                              |
         |            Receive CRETRY                        |
         |   CLOSE                                          |
         +--------------------------------------------------+
                       Figure 1: PB-TNC state machine
 In this diagram, states are indicated by rectangular boxes.  The
 initial and terminal states have double outlines (with = and ").
 State transitions are indicated by unidirectional arrows marked with
 the cause of the transition.
 Many transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) are
 triggered by the transmission or reception of a PB-TNC batch of a
 particular type.  The type of a PB-TNC batch is indicated by the
 contents of the Batch Type field in the PB-TNC header for that batch.
 For brevity, this document says "a FOO batch" instead of "a PB-TNC
 batch whose Batch Type field contains FOO".  Other transitions are
 triggered by receiving a PB-TNC batch of a particular type (e.g.,
 Receive CRETRY).  The CLOSE transition may be triggered by sending or
 receiving a CLOSE batch but may also be triggered by termination of
 the underlying PT connection.
 A PB-TNC session starts in the Init state when the underlying
 transport protocol (PT) establishes a connection between a Posture
 Broker Client and a Posture Broker Server.  If the Posture Broker
 Client initiated the underlying transport session, it starts by
 sending a CDATA batch to the Posture Broker Server, thus causing a
 transition to the Server Working state.  If the Posture Broker Server

Sahita, et al. Standards Track [Page 9] RFC 5793 PB-TNC March 2010

 initiated the transport session, it starts by sending a PB-TNC batch
 of type SDATA to the Posture Broker Client, thus causing a transition
 to the Client Working state.
 The Posture Broker Client and Posture Broker Server may now alternate
 sending CDATA and SDATA batches to each other.  Only the Posture
 Broker Client can send a data batch when the session is in the Client
 Working state, and only the Posture Broker Server can send a data
 batch when the session is in the Server Working state.
 The most common way to end an exchange is for the Posture Broker
 Server to send a RESULT batch.  This causes a transition into the
 Decided state.  This is not a terminal state.  The PT session can
 remain open and another exchange can be initiated by having the
 Posture Broker Client send a CRETRY batch.  This can be useful when
 the Posture Broker Client (or more likely a Posture Collector)
 discovers a suspicious condition on the endpoint, for example.  If
 the underlying transport protocol (PT) supports full-duplex
 operation, the Posture Broker Server can also initiate another
 exchange from this state by sending a SRETRY batch.  This can be
 useful when the policy changes on the server, for example.
 Whether an SRETRY or CRETRY message or both are sent, the next state
 is the Server Working State.  From this state, the Posture Broker
 Server sends an SDATA batch and the new exchange begins.  The state
 transitions marked Receive CRETRY and Receive CRETRY or SRETRY
 indicate that it is permissible to receive such messages in the
 indicated states, generally when the Posture Broker Client sent a
 CRETRY message at roughly the same time as the Posture Broker Server
 decided to send an SRETRY.  In that case, a CRETRY message may be
 received while in the Server Working or Client Working state.  Also,
 an SRETRY message may be received while in the Server Working state.
 These messages are redundant and therefore ignored, as indicated by
 the relevant transitions, which don't cause a state change.
 The only terminal state is the End state.  This state is reached if
 the underlying PT connection closes.  This can be caused by an action
 of the Posture Broker Client or Posture Broker Server or it can be
 caused by some external factor, such as pulling the network plug.
 When possible, a CLOSE batch SHOULD be sent before the underlying PT
 connection is terminated.  However, there may be cases where the PT
 connection is closed without notice.  For example, a plug may be
 pulled, a software program may fail, or a Posture Broker Client or
 Posture Broker Server may be unable to send a CLOSE message due to
 half-duplex limitations in the underlying PT protocol.  In these
 cases, the Posture Broker Client and Posture Broker Server will
 generally receive some form of notification from the Posture
 Transport Client and Posture Transport Server that the PT connection

Sahita, et al. Standards Track [Page 10] RFC 5793 PB-TNC March 2010

 has been closed.  This notification can trigger the CLOSE transition.
 However, the notification interaction is not standardized since the
 vertical interfaces in the NEA Reference Model are not standardized.
 In any case, the reception of the CLOSE batch or notification of
 termination of the transport causes the transition to the End state.
 Note that a Posture Broker Client and Posture Broker Server may not
 always have exactly the same state for a given PB-TNC session.  For
 example, say that a session is in the Client Working state and the
 Posture Broker Client transmits a CDATA batch.  While this batch is
 in transit (transmitted by the Posture Broker Client but not yet
 received by the Posture Broker Server), the Posture Broker Client
 will think that the session is in Server Working state but the
 Posture Broker Server will think that the session is in Client
 Working state.  However, this is a temporary condition and does not
 cause problems in practice.  The only possible issue is that a
 Posture Broker Client or Posture Broker Server does not know whether
 the other party has received its message until it receives a response
 from the other party.
 If a half-duplex transport is used, note that the Posture Broker
 Server cannot send a SRETRY batch when the session is in the Decided
 state because the Posture Broker Server sent the most recent batch
 (the RESULT batch) and this would violate the half-duplex nature of
 the transport protocol.  Instead, a server that wishes to initiate a
 new exchange in the Decided state when a half-duplex transport is in
 use should close the PT connection without sending a CLOSE batch and
 start a new PB-TNC session.  This limitation does not exist when a
 full-duplex transport is used.
 The Posture Broker Server and Posture Broker Client MUST follow the
 state machine described in this section.

3.3. Layering on PT

 PB-TNC batches are carried over protocol bindings of the PT protocol,
 which provides the interaction between a Posture Transport Client and
 a Posture Transport Server.  PB-TNC counts on PT to provide a secure
 transport.  In particular, PT MUST support mutual authentication of
 the Posture Transport Client and the Posture Transport Server,
 confidentiality and integrity protection for PB-TNC batches, and
 protection against replay attacks.  PB-TNC is unaware of the
 underlying transport protocols being used.  PB-TNC operates directly
 on PT; no further layer of PB-TNC is expected.

Sahita, et al. Standards Track [Page 11] RFC 5793 PB-TNC March 2010

3.3.1. Posture Transport (PT) Protocol Requirements Addendum

 RFC 5209 [8] describes normative requirements for the Posture
 Transport protocol.  This section specifies additional requirements
 for the Posture Transport protocol.  Candidate Posture Transport
 protocols must indicate conformance to requirements specified in this
 section as well as section 7.4 of RFC 5209.
 The additional requirements for candidate PT protocols are:
 PT-6 The PT protocol MUST be connection oriented; it MUST support
      confirmed initiation and close down.
 PT-7 The PT protocol MUST be able to carry binary data.
 PT-8 The PT protocol MUST provide mechanisms for flow control and
      congestion control.
 PT-9 PT protocol specifications MUST describe the capabilities that
      they provide for and limitations that they impose on the PB
      protocol (e.g., half/full duplex, maximum message size).

3.4. Example of PB-TNC Encapsulation

 This section shows how PA messages can be carried inside a PB-TNC
 batch that is inside a PT protocol.
 Within the PT protocol, the PB-TNC header is packaged next, followed
 by two PB-PA messages that contain PA messages meant for the Posture
 Collectors and Posture Validators on the platform.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           PT Protocol                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          PB-TNC Header                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           PB-PA Message                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           PB-PA Message                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 2: Example of PB-TNC message encapsulation
 This figure is conceptual, of course, and not an exact byte-for-byte
 replica.

Sahita, et al. Standards Track [Page 12] RFC 5793 PB-TNC March 2010

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.

Sahita, et al. Standards Track [Page 13] RFC 5793 PB-TNC March 2010

 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.

Sahita, et al. Standards Track [Page 14] RFC 5793 PB-TNC March 2010

    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.

Sahita, et al. Standards Track [Page 15] RFC 5793 PB-TNC March 2010

 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

Sahita, et al. Standards Track [Page 16] RFC 5793 PB-TNC March 2010

    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

Sahita, et al. Standards Track [Page 17] RFC 5793 PB-TNC March 2010

    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.

Sahita, et al. Standards Track [Page 18] RFC 5793 PB-TNC March 2010

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

Sahita, et al. Standards Track [Page 19] RFC 5793 PB-TNC March 2010

 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.

Sahita, et al. Standards Track [Page 20] RFC 5793 PB-TNC March 2010

 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

Sahita, et al. Standards Track [Page 21] RFC 5793 PB-TNC March 2010

    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

Sahita, et al. Standards Track [Page 22] RFC 5793 PB-TNC March 2010

    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

Sahita, et al. Standards Track [Page 23] RFC 5793 PB-TNC March 2010

    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

Sahita, et al. Standards Track [Page 24] RFC 5793 PB-TNC March 2010

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

Sahita, et al. Standards Track [Page 25] RFC 5793 PB-TNC March 2010

 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

Sahita, et al. Standards Track [Page 26] RFC 5793 PB-TNC March 2010

 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

Sahita, et al. Standards Track [Page 27] RFC 5793 PB-TNC March 2010

    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.

Sahita, et al. Standards Track [Page 28] RFC 5793 PB-TNC March 2010

     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

Sahita, et al. Standards Track [Page 29] RFC 5793 PB-TNC March 2010

    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

Sahita, et al. Standards Track [Page 30] RFC 5793 PB-TNC March 2010

    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

Sahita, et al. Standards Track [Page 31] RFC 5793 PB-TNC March 2010

    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.

Sahita, et al. Standards Track [Page 32] RFC 5793 PB-TNC March 2010

 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).

Sahita, et al. Standards Track [Page 33] RFC 5793 PB-TNC March 2010

    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.

Sahita, et al. Standards Track [Page 34] RFC 5793 PB-TNC March 2010

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

Sahita, et al. Standards Track [Page 35] RFC 5793 PB-TNC March 2010

 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.

Sahita, et al. Standards Track [Page 36] RFC 5793 PB-TNC March 2010

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.

Sahita, et al. Standards Track [Page 37] RFC 5793 PB-TNC March 2010

 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

Sahita, et al. Standards Track [Page 38] RFC 5793 PB-TNC March 2010

 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

Sahita, et al. Standards Track [Page 39] RFC 5793 PB-TNC March 2010

 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.

Sahita, et al. Standards Track [Page 40] RFC 5793 PB-TNC March 2010

5. Security Considerations

 PT is required and assumed to provide reliable and secure transport
 for the PB-TNC protocol (including authentication, confidentiality,
 integrity protection, and replay protection).  Still, it is useful to
 describe the possible threats to PB-TNC and the countermeasures that
 are or can be employed.  This section does that.

5.1. Threat Model

 There are several possible threats to the PB-TNC protocol.
 Untrusted intermediaries on the network between the NEA Client and
 the NEA Server may attempt to observe data sent between the Posture
 Broker Client and the Posture Broker Server via PB-TNC, modify this
 data in transit, reorder it, or replay it.  They may also attempt to
 mount a denial-of-service attack against either party or truncate the
 exchange prematurely.  If successful, these attacks may result in
 improper assessment decisions relating to the NEA Client, failure to
 reassess these decisions in light of changed circumstances, improper
 remediation instructions sent to the NEA Client (which could lead to
 the compromise of the NEA Client), unauthorized access to
 confidential information about the NEA Client's health and/or
 identity, improper reason strings or other messages that might be
 displayed to the user, access to reusable credentials such as posture
 assertions, denial of service on the NEA Client, and even complete
 denial of access to the network (if a denial-of-service attack
 against the NEA Server was successful and the network required
 permission from the NEA Server to grant network access).
 Trusted intermediaries between the Posture Broker Client and the
 Posture Broker Server include the Posture Transport Client and the
 Posture Transport Server.  These parties are considered trusted
 because they are responsible for properly implementing the security
 protections provided by PT.  If they fail to do so properly, these
 security protections may be diminished or eliminated altogether.  The
 possible attacks are the same as those listed in the previous
 paragraph.  To give one fairly likely example, if a Posture Transport
 Client fails to properly authenticate and authorize the Posture
 Transport Server (whether through implementation error or through
 user configuration to "trust anyone"), the improperly authorized
 Posture Transport Server may mount any of the previously described
 attacks against the NEA Client.
 Compromise of any of the trusted parties (the Posture Broker Client,
 the Posture Transport Client, the Posture Broker Server, or the
 Posture Transport Server) may result in failures that are equivalent
 to those listed in the first paragraph.  These failures may be even

Sahita, et al. Standards Track [Page 41] RFC 5793 PB-TNC March 2010

 more dangerous since they will not be detectable by observing network
 traffic or by examining and comparing audit logs.  Failure to
 properly secure communications between the Posture Broker Client and
 the Posture Transport Client or between the Posture Broker Server and
 the Posture Transport Server is usually indistinguishable from
 compromise of those parties.  Compromise of the operating system or
 other critical software, firmware, or hardware components on the NEA
 Client or NEA Server will typically result in an equivalent result.
 And an attacker's ability to gain privileged access to the NEA Client
 or NEA Server (even for a brief time, long enough to disable or
 misconfigure security settings) is generally equivalent as well.  If
 the NEA Client or NEA Server are dependent on other services for
 their proper operation (including Posture Collectors, Posture
 Validators, directories, and patch management services), compromise
 of those services may result in compromise or failure of the
 dependent parties.  Of course, compromise or failure of NEA Server
 components is most serious since this would probably affect a large
 number of NEA Clients while the effects of NEA Client compromise
 might well be limited to a single machine.

5.2. Countermeasures

 The primary countermeasure against attacks by untrusted network
 intermediaries is the security provided by the PT protocol.  Any
 candidate PT protocols should be carefully examined to ensure that
 all the threats described above are adequately addressed.
 As noted above, compromise or erroneous operation of any of the
 trusted parties is a serious matter with substantial security
 implications.  This includes the Posture Broker Client, the Posture
 Broker Server, the Posture Transport Client, and the Posture
 Transport Server.  These are all security-sensitive components so
 they should be built and managed in accordance with best practices
 for security devices.  This is especially important for the NEA
 Server and its components since a compromise of this device would
 affect the security and availability of the entire network (similar
 to compromise of a AAA server).  Communications between the trusted
 parties must also be secured.  For example, if the Posture Broker
 Server and the Posture Transport Server are separate components,
 their communications must be secured.
 Since the NEA Client may be a mobile device with little physical
 security (such as a laptop computer or even a public telephone), it
 should generally be assumed that some proportion of Access NEA
 Clients will be compromised and therefore hostile.  The NEA Server
 should be designed to be robust against hostile NEA Clients.  Once a

Sahita, et al. Standards Track [Page 42] RFC 5793 PB-TNC March 2010

 compromised NEA Client is detected, it can be treated in a manner
 equivalent to an untrusted party and should pose no greater threat
 than any other untrusted party.
 Countermeasures against a compromised NEA Server (or a component
 thereof such as a Posture Broker Server or a Posture Transport
 Server) include prevention of compromise, detection of compromise,
 and mitigation of the effects of compromise.  For prevention, the NEA
 Server and its components and dependencies should be implemented
 using secure implementation techniques (e.g., secure coding and
 minimization) and managed using secure practices (e.g., strong
 authentication and separation of duty).  For detection, the behavior
 of the NEA Server should be monitored (e.g., via logging especially
 of remediation instructions, intrusion detection systems, and probes
 that impersonate a valid NEA Client and record NEA Server behavior)
 and any anomalies analyzed.  For mitigation, NEA Clients should not
 blindly follow remediation instructions received from a trusted NEA
 Server.  At least for patches and other dangerous actions, they
 should validate these actions (e.g., via user confirmation) before
 proceeding.  It should not be possible to configure a NEA Client to
 trust all NEA Servers without proper authentication and
 authorization.

6. IANA Considerations

 Four new IANA registries are defined by this specification: PB-TNC
 Message Types, PA Subtypes, PB-TNC Remediation Parameters Types, and
 PB-TNC Error Codes.  This section explains how these registries work.
 All of these registries support IETF standard values and vendor-
 defined values.  To explain this phenomenon, we will use the PB-TNC
 Message Type as an example but the other three registries work the
 same way.  Whenever a PB-TNC Message 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
 PB-TNC Message Type is an IETF standard value listed in the IANA
 registry for PB-TNC Message Types and its meaning is defined in the
 specification listed for that PB-TNC Message Type in that registry.
 If the vendor ID is not zero, the meaning of the PB-TNC Message 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 PB-TNC
 Message 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

Sahita, et al. Standards Track [Page 43] RFC 5793 PB-TNC March 2010

 behavior is explicitly prohibited by this specification, which
 dictates that "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)." Similar
 requirements are included for PA Subtypes, Remediation Parameters
 Types, and PB-TNC Error Codes.

6.1. Designated Expert Guidelines

 For all of the four 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 [5].
 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.  The
 only exception is the registry for PB-TNC Error Codes where 2^16
 values are available for the IETF and 2^16 values for each vendor.
 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.
 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.

Sahita, et al. Standards Track [Page 44] RFC 5793 PB-TNC March 2010

6.2. Registry for PB-TNC Message Types

 The name for this registry is "PB-TNC Message 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-2, and
 a reference to a specification where the contents of this message
 type are defined.  This specification must define the meaning of this
 PB-TNC message type and the format and semantics of the PB-TNC
 Message Value field for PB-TNC messages that include the designated
 numeric value in the PB-TNC Message Type field and the designated
 Private Enterprise Number in the PB-TNC Vendor ID field.
 Entries to this registry are added by Expert Review with
 Specification Required, following the guidelines in section 6.1.
 The following entries for this registry are defined in this document.
 They are the initial entries in the registry for PB-TNC Message
 Types.
 PEN Integer Name                         Defining Specification
 --- ------- ----                         ----------------------
 0   0       PB-Experimental              RFC 5793
 0   1       PB-PA                        RFC 5793
 0   2       PB-Assessment-Result         RFC 5793
 0   3       PB-Access-Recommendation     RFC 5793
 0   4       PB-Remediation-Parameters    RFC 5793
 0   5       PB-Error                     RFC 5793
 0   6       PB-Language-Preference       RFC 5793
 0   7       PB-Reason-String             RFC 5793
 0 0xffffffff Reserved                    RFC 5793

6.3. Registry for PA Subtypes

 The name for this registry is "PA Subtypes".  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-2, and
 a reference to a specification where the contents of this PA subtype
 are defined.  This specification must define the meaning of this PA
 subtype and the format and semantics of the PA Message Body field for
 PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message
 Type of PB-PA, the designated numeric value in the PA Subtype field,
 and the designated Private Enterprise Number in the PA Message Vendor
 ID field.
 Entries to this registry are added by Expert Review with
 Specification Required, following the guidelines in section 6.1.

Sahita, et al. Standards Track [Page 45] RFC 5793 PB-TNC March 2010

 This document does not define any initial entries for this registry.
 Therefore, this registry should initially be empty.  Subsequent RFCs
 (such as PA-TNC) will define entries in this registry.

6.4. Registry for PB-TNC Remediation Parameters Types

 The name for this registry is "PB-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 0 and
 2^32-1, and a reference to a specification where the contents of this
 remediation parameters type are defined.  This specification must
 define the meaning of this remediation parameters type value and the
 format and semantics of the Remediation Parameters field for PB-TNC
 messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of
 PB-Remediation-Parameters, the designated numeric value in the
 Remediation Parameters Type field, and the designated Private
 Enterprise Number in the Remediation Parameters Vendor ID field.
 Entries to this registry are added by Expert Review with
 Specification Required, following the guidelines in section 6.1.
 The following entries for this registry are defined in this document.
 They are the initial entries in the registry for PB-TNC Remediation
 Parameters Types.
 PEN Integer Name                      Defining Specification
 --- ------- ----                      ----------------------
 0   1       Remediation-URI           RFC 5793
 0   2       Remediation-String        RFC 5793

6.5. Registry for PB-TNC Error Codes

 The name for this registry is "PB-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^16-1, and
 a reference to a 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 Parameters field for PB-TNC
 messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of
 PB-Error, the designated numeric value in the Error Code field, and
 the designated Private Enterprise Number in the Error Code Vendor ID
 field.
 Entries to this registry are added by Expert Review with
 Specification Required, following the guidelines in section 6.1.
 The following entries for this registry are defined in this document.
 They are the initial entries in the registry for PB-TNC Error Codes.

Sahita, et al. Standards Track [Page 46] RFC 5793 PB-TNC March 2010

 PEN Integer Name                          Defining Specification
 --- ------- ----                          ----------------------
 0   0       Unexpected Batch Type         RFC 5793
 0   1       Invalid Parameter             RFC 5793
 0   2       Local Error                   RFC 5793
 0   3       Unsupported Mandatory Message RFC 5793
 0   4       Version Not Supported         RFC 5793

7. Acknowledgments

 Thanks to the Trusted Computing Group for contributing the initial
 text upon which this document was based.
 The authors of this document would like to acknowledge the following
 people who have contributed to or provided substantial input on the
 preparation of this document or predecessors to it: Bernard Aboba,
 Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris
 Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen,
 Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles
 Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim,
 Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan
 Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin,
 Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod
 Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn,
 Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean
 Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad,
 Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali,
 Guha Prasad Venataraman, John Vollbrecht, Jun Wang, and Han Yin.

8. References

8.1. Normative References

 [1]    Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.
 [2]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
        January 2005.
 [3]    Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying
        Languages", BCP 47, RFC 5646, September 2009.
 [4]    Alvestrand, H., "Content Language Headers", RFC 3282, May
        2002.
 [5]    Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

Sahita, et al. Standards Track [Page 47] RFC 5793 PB-TNC March 2010

 [6]    Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        STD 63, RFC 3629, November 2003.

8.2. Informative References

 [7]    Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV
        Binding", Trusted Computing Group, February 2008.
 [8]    Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
        Tardo, "Network Endpoint Assessment (NEA): Overview and
        Requirements", RFC 5209, June 2008.
 [9]    Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
        Levkowetz, Ed., "Extensible Authentication Protocol (EAP)",
        RFC 3748, June 2004.
[10]    Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute
        (PA) Protocol Compatible with Trusted Network Connect (TNC)",
        RFC 5792, March 2010.

Sahita, et al. Standards Track [Page 48] RFC 5793 PB-TNC March 2010

Appendix A. Use Cases

A.1. Initial Client-Triggered Assessment

 This scenario involves the assessment of an endpoint initiated during
 network join.  The assessment is triggered by the Posture Broker
 Client (PBC) and involves collection of patch information from both
 Standard Operating System (OS) Posture Collector and vendor-specific
 Patch Posture Collector (PC).  The assessment by both the vendor-
 specific Patch Posture Validator (PV) and Standard OS Posture
 Validator result in a compliant assessment decision that results in a
 compliant System Assessment Decision to be returned by the Posture
 Broker Server (PBS).
 +--------+ +-------+ +---------+ +--------+ +-------++--------+
 | Vndr. X| |  Std. | |   Std.  | |  Std.  | | Std.  || Vndr. X|
 |Patch PC| | OS PC | |   PBC   | |  PBS   | | OS PV ||Patch PV|
 +----+---+ +---+---+ +-----+---+ +---+----+ +---+----++---+---+
    |         |   N/W Join|         |          |         |
    |         |     ----->|         |          |         |
    |         | Req Post. |         |          |         |
    |         +<----------+         |          |         |
    |         | Req Post. |         |          |         |
    +<--------------------|         |          |         |
    |Vndr X Patch Posture |         |          |         |
    |-------------------->|         |          |         |
    |         |OS Posture |         |          |         |
    |         |---------->|         |          |         |
    |         |           | Posture |          |         |
    |         |           | Report  |          |         |
    |         |           +-------->|          |         |

Sahita, et al. Standards Track [Page 49] RFC 5793 PB-TNC March 2010

    |         |           |         |  Verify  |         |
    |         |           |         |  Posture |         |
    |         |           |         |--------->          |
    |         |           |         |          | Verify  |
    |         |           |         |          | Posture |
    |         |           |         |------------------->|
    |         |           |         | OS Reslt |         |
    |         |           |         |<---------|         |
    |         |           |         | VndrX Patch Result |
    |         |           | Assess  |<-------------------|
    |         |           | Result  |                    |
    |         |           <---------|          |         |
    |         | OS PRslt  |         |          |         |
    |         |<----------|         |          |         |
    | VndrX Patch PResult |         |          |         |
    |<--------------------|         |          |         |

A.1.1. Message Contents

 This section shows the contents of the key fields in each of the PA
 messages exchanged in this use case.  When necessary, additional
 commentary is provided to explain why certain fields contain the
 shown values.  Note that many of the flows shown are between
 components on the same system so no message contents are shown.

A.1.1.1. N/W Join

 This flow represents the event that causes the PBC to decide to start
 an assessment of the endpoint in order to gain access to the network.
 This is merely an event and doesn't include a message being sent.

Sahita, et al. Standards Track [Page 50] RFC 5793 PB-TNC March 2010

A.1.1.2. Request Posture (Req Post.)

 This flow illustrates an invocation of the OS and Patch Posture
 Collectors requesting particular posture attributes to be sent.
 Because this use case is triggered locally, NEA doesn't specify the
 contents of this flow.

A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)

 This flow contains the PA message from the Vendor X Patch Posture
 Collector; the message content is described in the PA-TNC
 specification.

A.1.1.4. OS Posture

 This flow contains the PA message from the OS Posture Collector; the
 message content is described in the PA-TNC specification.

A.1.1.5. Posture Report

 This flow contains the PB message containing the PA messages from the
 Patch and OS Posture Collectors:
 PB Envelope {
  HDR {
   D bit=0 (Posture Broker Client is originator)
   Batch Type=CDATA
   Batch Length
   }
    PB Message 1 {
     Vendor-id=0
     Type =2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=0 (Standard)
        PA-subtype=1 (OS)

Sahita, et al. Standards Track [Page 51] RFC 5793 PB-TNC March 2010

        OS Posture PA Message
     }
   }
   PB Message 2 {
     Vendor-id=0
     Type =2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=1 (Vendor X)
        PA-subtype=1 (Vendor X PA sub-type for patch management)
        Vendor X Patch Posture PA Message
      }
    }
 }

A.1.1.6. Verify Posture

 This flow illustrates an invocation of the OS and Patch Posture
 Validators requesting verification of the posture attributes
 received.  Because this flow happens locally within the NEA server,
 NEA doesn't specify the message content.

A.1.1.7. OS Posture Result (OS Reslt)

 This flow contains the PA message (Posture Assessment Result) from
 the OS Posture Validator; the message content is described in the PA-
 TNC specification.

A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result)

 This flow contains the PA message (Posture Assessment Result) from
 the Vendor X Patch Posture Validator; the message content is
 described in the PA-TNC specification.

Sahita, et al. Standards Track [Page 52] RFC 5793 PB-TNC March 2010

A.1.1.9. Assessment Result (Assess Result)

 This flow contains the PB message containing the system assessment
 result computed by the Posture Broker Server and the PA messages from
 the Patch and OS Posture Validators:
 PB Envelope {
  HDR {
   D bit=1 (Posture Broker Server is originator)
   Batch Type=RESULT
   Batch Length
   }
    PB Message 1 {
     Vendor-id=0,
     Type =3 (Access-Recommendation)
     Length
     Value = {
       System-Evaluation-Result=0 (Compliant)
     }
   }
   PB Message 2 {
     Vendor-id=0,
     Type=2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=0
        PA-subtype=1 (OS)

Sahita, et al. Standards Track [Page 53] RFC 5793 PB-TNC March 2010

        OS Posture Result PA Message
      }
    }
   PB Message 3 {
     Vendor-id=0,
     Type=2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=1 (Vendor X)
        PA-subtype=1 (Vendor X PA sub-type for patch management)
        Vendor X Patch Posture Result PA Message
      }
    }
 }

A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)

 These flows illustrate an invocation of the OS and Vendor X Patch
 Posture Collectors to receive the posture assessment results.
 Because this flow is triggered locally, NEA doesn't specify the
 contents of this flow.

A.2. Server-Initiated Assessment with Remediation

 This scenario involves the assessment of an endpoint initiated by the
 NEA server.  The assessment is triggered by the Posture Broker Server
 and involves collection of Anti-Virus attributes for two Anti-Virus
 components running on the endpoint.  The endpoint is assessed to be
 compliant by one of the vendor (Vendor X) anti-virus posture
 validators and non-compliant by the other vendor (Vendor Y) anti-
 virus posture validator.  This results in a non-compliant System
 Assessment Decision to be returned by the Posture Broker Server.  The
 Posture Broker Server also returns remediation instructions for the
 endpoint as part of the response.

Sahita, et al. Standards Track [Page 54] RFC 5793 PB-TNC March 2010

 +--------+  +-------+ +---------+ +--------+ +-------+ +--------+
 | Vndr Y |  | Vndr X| |   Std.  | |  Std.  | | Vndr X| | Vndr Y |
 |  AV PC |  | AV PC | |   PBC   | |  PBS   | | AV PV | |  AV PV |
 +----+---+  +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
      |          |           | N/W Join|          |          |
      |          |           |   ----->|          |          |
      |          |           |         |  Create  |          |
      |          |           |         |Post. Req |          |
      |          |           |         |--------->|          |
      |          |           |         |Create Posture Req   |
      |          |           |         |----------+--------->|
      |          |           |         |Vndr Y AV Posture Req|
      |          |           |         |<---------+----------|
      |          |           |         |Vndr X AV |          |
      |          |           |         |Post. Req |          |
      |          |           | Posture |<---------|          |
      |          |           | Request |          |          |
      |          | Vndr X AV |<--------|          |          |
      |          | Post. Req |         |          |          |
      |          |<----------|         |          |          |
      |      Vndr Y AV       |         |          |          |
      |     Posture Req      |         |          |          |
      +<---------+-----------|         |          |          |
      |  Vndr Y AV Posture   |         |          |          |

Sahita, et al. Standards Track [Page 55] RFC 5793 PB-TNC March 2010

      +----------+---------->|         |          |          |
      |          | Vndr X AV |         |          |          |
      |          |  Posture  |         |          |          |
      |          |---------->| Posture |          |          |
      |          |           |Response |          |          |
      |          |           |-------->|          |          |
      |          |           |         |  Verify  |          |
      |          |           |         |  Posture |          |
      |          |           |         |--------->|          |
      |          |           |         |     Verify Posture  |
      |          |           |         |----------+--------->|
      |          |           |         |Vndr Y Posture Result|
      |          |           |         |<---------+----------|
      |          |           |         |Vndr X AV |          |
      |          |           |         |Post Reslt|          |
      |          |           |  Assess |<---------|          |
      |          |           |  Result |          |          |
      |          | Vndr X AV |<--------|          |          |
      |          |Post Reslt |<--------|          |          |
      |          |<----------|         |          |          |
      | Vndr Y AV Post Reslt |         |          |          |
      +<---------+-----------|         |          |          |
      |          |           |         |          |          |

Sahita, et al. Standards Track [Page 56] RFC 5793 PB-TNC March 2010

A.2.1. Message Contents

 This section shows the contents of the key fields in each of the PA
 messages exchanged in this use case.  When necessary, additional
 commentary is provided to explain why certain fields contain the
 shown values.  Note that many of the flows shown are between
 components on the same system so no message contents are shown.

A.2.1.1. N/W Join

 This flow represents the event that causes the PBS to decide to start
 an assessment of the endpoint in order to gain access to the network.
 This is merely an event and doesn't include a message being sent.

A.2.1.2. Create Posture Request (Create Posture Req)

 This flow illustrates an invocation of the Vendor X and Vendor Y
 Anti-Virus posture validators requesting posture requests to be
 created.  Because this use case is triggered locally, NEA doesn't
 specify the contents of this flow.

A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV Post. Req)

 This flow contains the PA message (Posture Request) from the Vendor X
 Anti-Virus Posture Validator; the message content is described in the
 PA-TNC specification.

A.2.1.4. Vendor Y Anti-Virus Posture Request

 This flow contains the PA message (Posture Request) from the Vendor Y
 Anti-Virus Posture Validator; the message content is described in the
 PA-TNC specification.

A.2.1.5. Posture Request

 This flow contains the PB message containing the PA messages from the
 Vendor X and Vendor Y Anti-Virus Posture Validators:
 PB Envelope {
  HDR {
   D bit=1 (Posture Broker Server is originator)
   Batch Type=SDATA
   Batch Length

Sahita, et al. Standards Track [Page 57] RFC 5793 PB-TNC March 2010

  }
   PB Message 1 {
     Vendor-id=0
     Type =2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=1 (Vendor X)
        PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
        Vendor X AV Posture Request PA Message
     }
   }
   PB Message 2 {
     Vendor-id=0
     Type =2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=2 (Vendor Y)
        PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
        Vendor Y AV Posture Request PA Message
      }
    }
 }

Sahita, et al. Standards Track [Page 58] RFC 5793 PB-TNC March 2010

A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr Y AV

        Posture Req)
 This flow illustrates an invocation of the Vendor X and Vendor Y
 Anti-Virus Posture Collectors to process the Posture Request and
 return particular posture attributes requested.  Because this use
 case is triggered locally, NEA doesn't specify the contents of this
 flow.

A.2.1.7. Vendor Y Anti-Virus Posture (Vndr Y AV Posture)

 This flow contains the PA message (response to the Posture Request)
 from the Vendor Y Anti-Virus Posture Collector; the message content
 is described in the PA-TNC specification.

A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture)

 This flow contains the PA message (response to the Posture Request)
 from the Vendor X Anti-Virus Posture Collector; the message content
 is described in the PA-TNC specification.

A.2.1.9. Posture Response

 This flow contains the PB message containing the PA messages from the
 Vendor X and Vendor Y Anti-Virus Posture Collectors:
 PB Envelope {
  HDR {
   D bit=0 (Posture Broker Client is originator)
   Batch Type=CDATA
   Batch Length
  }
   PB Message 1 {
     Vendor-id=0
     Type =2 (PB-PA)
     Length
     Value = {

Sahita, et al. Standards Track [Page 59] RFC 5793 PB-TNC March 2010

         PA-Msg-vendor-id=1 (Vendor X)
         PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
         Vendor X AV Posture PA Message
     }
   }
   PB Message 2 {
     Vendor-id=0
     Type =2 (PB-PA)
     Length
     Value = {
         PA-Msg-vendor-id=2 (Vendor Y)
         PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
         Vendor Y AV Posture PA Message
      }
    }
 }

A.2.1.10. Verify Posture

 This flow illustrates an invocation of the Vendor X and Vendor Y
 Anti-Virus Posture Validators requesting verification of the posture
 attributes received.  Because this flow happens locally within the
 NEA server, NEA doesn't specify the message contents.

A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post Result)

 This flow contains the PA message (Posture Assessment Result) from
 the Vendor Y Anti-Virus Posture Validator; the message content is
 described in the PA-TNC specification.

Sahita, et al. Standards Track [Page 60] RFC 5793 PB-TNC March 2010

A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post Result)

 This flow contains the PA message (Posture Assessment Result) from
 the Vendor X Anti-Virus Posture Validator; the message content is
 described in the PA-TNC specification.

A.2.1.13. Assessment Result (Assess Result)

 This flow contains the PB message containing the system assessment
 result computed by the Posture Broker Server and the PA messages from
 the Patch and OS Posture Validators:
 PB Envelope {
  HDR {
   D bit=1 (Posture Broker Server is originator)
   Batch Type=RESULT
   Batch Length
  }
   PB Message 1 {
     Vendor-id=0,
     Type=3 (Access-Recommendation)
     Length
     Value = {
       PB-Assessment-Result=1 (Non-Compliant)
     }
   }
   PB Message 2 {
     Vendor-id=0,
     Type=4 (Remediation-Parameters)
     Length

Sahita, et al. Standards Track [Page 61] RFC 5793 PB-TNC March 2010

     Value = {
      Remediation-Param-Vendor-ID=0
      Remediation-Param-Type=1 (Remediation-URI)
      Remediation-Param=''http://xyz''
      }
    }
  PB Message 3 {
     Vendor-id=0,
     Type=4 (Remediation-Parameters)
     Length
     Value = {
      Remediation-Param-Vendor-ID=0
      Remediation-Param-Type=2 (Remediation-String)
      Remediation-Param=''Try Step1, Step2,...''
      }
    }
   PB Message 4 {
     Vendor-id=0,
     Type=2 (PB-PA)
     Length
     Value = {
         PA-Msg-vendor-id=1 (Vendor X)
         PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
         Vendor X AV Posture Result PA Message

Sahita, et al. Standards Track [Page 62] RFC 5793 PB-TNC March 2010

      }
    }
   PB Message 5 {
     Vendor-id=0,
     Type=2 (PB-PA)
     Length
     Value = {
         PA-Msg-vendor-id=2 (Vendor Y)
         PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
         Vendor Y AV Posture Result PA Message
      }
    }
 }

A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post Reslt)

 These flows illustrate an invocation of the Vendor X and Vendor Y
 Anti-Virus Posture Collectors to receive the posture assessment
 results.  Because this flow is triggered locally, NEA doesn't specify
 the contents of this flow.

A.3. Client-Triggered Reassessment

 This scenario involves the reassessment of an endpoint as a result of
 enabling a software component on the endpoint.  The endpoint has two
 VPN client software components, one from vendor X for the user's home
 network and other from vendor Y for the network that the endpoint is
 currently accessing.  The assessment is triggered when the user tries
 to use the Vendor X VPN client; this is a violation of the posture
 policy.  The Posture Broker Client triggers the posture assessment
 when it receives a notification from the Standard VPN Posture
 Collector about the change to the operational state of the VPN
 component on the endpoint.  Note that the VPN Posture Collector
 supports standard attributes and some vendor-defined attributes from
 vendor X's and vendor Y's namespaces.  This use case doesn't leverage
 vendor-defined attributes.  The assessment involves verification of

Sahita, et al. Standards Track [Page 63] RFC 5793 PB-TNC March 2010

 the standard VPN posture attributes by the Standard VPN Posture
 Validator that results in a non-compliant assessment result.  This
 use case relies on the use of a virtual Posture Collector concept
 described in section 3.3 of the PA-TNC specification.  As illustrated
 in this example, the Posture Broker Client will assign two Posture
 Collector IDs to a single Posture Collector (Standard VPN PC), and
 the Posture Collector will generate two separate PA messages to
 report the posture for Vendor X and Vendor Y VPN Clients.  The
 Posture Broker Client will use the assigned IDs in the PB message
 sent to the NEA Server.  This entire behavior will be completely
 opaque to the NEA Server, which will handle the PB message as if
 there were two VPN Posture Collectors on the NEA Client.
 +--------+  +-------+ +---------+ +--------+ +--------+ +--------+
 |Vndr X  |  |Vndr Y | |Standard | |Standard| |Standard| |Standard|
 |VPNClnt |  |VPNClnt| | VPN PC  | |  PBC   | |   PBS  | | VPN PV |
 +----+---+  +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
 Enble|          |           |         |          |           |
  1. —>| | | | | |
      |  VPN Status Change   |         |          |           |
      |--------------------->| Posture |          |           |
      |          |           | Change  |          |           |
      |          |           |-------->|          |           |
      |          |           |Req. Post|          |           |
      |          |           |<--------|          |           |
      |          |Ins/Rq Info|         |          |           |
      |          |<----------|         |          |           |
      | Inspect/Request Info |         |          |           |
      |<---------+-----------|VPNX Post|          |           |
      |          |           |-------->|          |           |
      |          |           |VPNY Post|          |           |

Sahita, et al. Standards Track [Page 64] RFC 5793 PB-TNC March 2010

      |          |           |-------->|          |           |
      |          |           |         | Posture  |           |
      |          |           |         |  Report  |           |
      |          |           |         |--------->|           |
      |          |           |         |          |Vrfy Post. |
      |          |           |         |          |---------->|
      |          |           |         |          |VPN PRslt  |
      |          |           |         |  Assess  |<----------|
      |          |           |         |  Result  |           |
      |          |           |         |<---------|           |
      |          |           |VPN PRslt|          |           |
      |          |           |<--------|          |           |

A.3.1. Message Contents

 This section shows the contents of the key fields in each of the PA
 messages exchanged in this use case.  When necessary, additional
 commentary is provided to explain why certain fields contain the
 shown values.  Note that many of the flows shown are between
 components on the same system so no message contents are shown.

A.3.1.1. Enable VPN Client (Enble)

 This flow represents the end user triggered event of starting the VPN
 Client software from Vendor X.  This is merely an event and doesn't
 include a message being sent.

A.3.1.2. Notify Status Change (VPN Status Change)

 This flow represents the detection of the active state of the Vendor
 X VPN Client software by the Standard VPN Posture Collector.  This is
 merely an event and doesn't include a message being sent.

Sahita, et al. Standards Track [Page 65] RFC 5793 PB-TNC March 2010

A.3.1.3. Notify Posture Change (Posture Change)

 This flow represents the notification of the VPN Posture change sent
 from the VPN Posture Collector to the Standard Posture Broker Client.
 This is merely an event and doesn't include a message being sent.

A.3.1.4. Request Posture (Req. Post)

 This flow illustrates an invocation of the VPN Posture Collector
 requesting particular posture attributes to be sent.  Because this
 use case is triggered locally, the contents of this flow aren't
 specified by NEA.

A.3.1.5. Inspect/Request Information (Ins/Rq Info)

 This flow illustrates the acquisition of the posture attributes by
 the Standard VPN Posture Collector from the Vendor X and Vendor Y VPN
 Client components.  Because this flow is triggered locally, NEA
 doesn't specify the message contents.

A.3.1.6. Vendor X VPN Posture (VPNX Post.)

 This flow contains the PA message from the VPN Posture Collector for
 Vendor X VPN Client posture; the message content is described in the
 PA-TNC specification.

A.3.1.7. Vendor Y VPN Posture (VPNY Post.)

 This flow contains the PA message from the VPN Posture Collector for
 Vendor Y VPN Client posture; the message content is described in the
 PA-TNC specification.

A.3.1.8. Posture Report (Post. Rpt.)

 This flow contains the PB message containing the PA message from the
 VPN Posture Collector:
 PB Envelope {
  HDR {
   D bit=0 (Posture Broker Client is originator)
   Batch Type=CRETRY
   Batch Length
  }

Sahita, et al. Standards Track [Page 66] RFC 5793 PB-TNC March 2010

   PB Message 1 {
     Vendor-id=0
     Type =2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=0
        PA-subtype=7 (VPN)
        Posture-Collector-ID=1 //Virtual Posture Collector ID for
 Vendor X VPN Client
        Vendor X VPN Posture PA Message
     }
   }
   PB Message 2 {
     Vendor-id=0
     Type =2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=0
        PA-subtype=7 (VPN)
        Posture-Collector-ID=2 //Virtual Posture Collector ID for
 Vendor Y VPN Client
        Vendor Y VPN Posture PA Message
     }
   }

Sahita, et al. Standards Track [Page 67] RFC 5793 PB-TNC March 2010

A.3.1.9. Verify Posture (Vrfy Post.)

 This flow illustrates an invocation of the VPN Posture Validator
 requesting verification of the posture attributes received.  Because
 this flow happens locally within the NEA server, NEA doesn't specify
 the message contents.

A.3.1.10. VPN Posture Result (VPN PRslt)

 This flow contains the PA message (Posture Assessment Result) from
 the VPN Posture Validator; the message content is described in the
 PA-TNC specification.

A.3.1.11. Assessment Result (Assess Result)

 This flow contains the PB message containing the system assessment
 result computed by the Posture Broker Server and the PA messages from
 the VPN Posture Validator:
  PB Envelope {
    HDR {
     D bit=1 (Posture Broker Server is originator)
     Batch Type=RESULT
     Batch Length
    }
   PB Message 1 {
     Vendor-id=0,
     Type =3 (Access-Recommendation)
     Length
     Value = {
       PB-Assessment-Result=1 (Non-Compliant)
     }
   }

Sahita, et al. Standards Track [Page 68] RFC 5793 PB-TNC March 2010

   PB Message 2 {
     Vendor-id=0,
     Type=2 (PB-PA)
     Length
     Value = {
        PA-Msg-vendor-id=0
        PA-subtype=7 (VPN)
        VPN Posture Result PA Message
      }
    }

A.3.1.12. Posture Result (VPN PRslt)

 This flow illustrate an invocation of the VPN Posture Collectors to
 receive the posture assessment result.  Because this flow is
 triggered locally, NEA doesn't specify the contents of this flow.

Sahita, et al. Standards Track [Page 69] RFC 5793 PB-TNC March 2010

Appendix B. Evaluation against NEA Requirements

 This section evaluates the PB-TNC protocol against the requirements
 defined in the NEA Requirements document.  Each subsection considers
 a separate requirement from the NEA Requirements document.  Only
 common requirements (C-1 through C-11) and PB requirements (PB-1
 through PB-6) are considered, since these are the only ones that
 apply to PB.

B.1. Evaluation against Requirement C-1

 Requirement C-1 says:
 C-1   NEA protocols MUST support multiple round trips between the NEA
       Client and NEA Server in a single assessment.
 PB-TNC meets this requirement.  It allows an unlimited number of
 round trips between the NEA Client and NEA Server.

B.2. Evaluation against Requirement C-2

 Requirement C-2 says:
 C-2   NEA protocols SHOULD provide a way for both the NEA Client and
       the NEA Server to initiate a posture assessment or reassessment
       as needed.
 PB-TNC meets this requirement.  Either the NEA Client or the NEA
 Server can initiate a posture assessment or reassessment.
 There is one limitation on this support.  If a NEA Server wishes to
 initiate a reassessment after it has sent a RESULT batch, it must
 close the underlying transport session and initiate a new assessment.
 For half-duplex transports, this is unavoidable unless a constant
 exchange of messages is maintained, which would be very wasteful.
 For full-duplex transports, it would be possible to allow the Posture
 Broker Server to send an SRETRY batch even in the Decided state.  If
 the NEA working group reaches consensus that this change should be
 made, it will be.

B.3. Evaluation against Requirement C-3

 Requirement C-3 says:
 C-3   NEA protocols including security capabilities MUST be capable
       of protecting against active and passive attacks by
       intermediaries and endpoints including prevention from replay-
       based attacks.

Sahita, et al. Standards Track [Page 70] RFC 5793 PB-TNC March 2010

 PB-TNC does not include any security capabilities.  It depends on PT
 to supply a secure transport.  This addresses all the necessary
 threats without adding an extra layer of security.  Since this
 requirement only applies to NEA protocols that include security
 capabilities, PB-TNC meets this requirement.

B.4. Evaluation against Requirement C-4

 Requirement C-4 says:
 C-4   The PA and PB protocols MUST be capable of operating over any
       PT protocol.  For example, the PB protocol must provide a
       transport-independent interface allowing the PA protocol to
       operate without change across a variety of network protocol
       environments (e.g., EAP/802.1X, PANA, TLS, and IKE/IPsec).
 PB-TNC meets this requirement.  PB-TNC can operate over any PT
 protocol that meets the requirements for PT stated in the NEA
 Requirements document.  Also, PB-TNC insulates the PA protocol from
 any specifics of the PT protocol.  With PB-TNC, all PT protocols are
 equivalent from the perspective of the PA protocol.

B.5. Evaluation against Requirement C-5

 Requirement C-5 says:
 C-5   The selection process for NEA protocols MUST evaluate and
       prefer the reuse of existing open standards that meet the
       requirements before defining new ones.  The goal of NEA is not
       to create additional alternative protocols where acceptable
       solutions already exist.
 Based on this requirement, PB-TNC should receive a strong preference.
 PB-TNC is equivalent with IF-TNCCS 2.0, an open TCG specification.
 IF-TNCCS 2.0 is an extension of the existing IF-TNCCS 1.X protocols,
 which have been implemented by dozens of vendors and open source
 projects.

B.6. Evaluation against Requirement C-6

 Requirement C-6 says:
 C-6   NEA protocols MUST be highly scalable; the protocols MUST
       support many Posture Collectors on a large number of NEA
       Clients to be assessed by numerous Posture Validators residing
       on multiple NEA Servers.

Sahita, et al. Standards Track [Page 71] RFC 5793 PB-TNC March 2010

 PB-TNC meets this requirement.  PB-TNC supports up to 2^16-1 Posture
 Collectors and an equal number of Posture Validators in a given PB-
 TNC session.  It also supports an unlimited number of NEA Clients and
 NEA Servers.
 The scalability of PB-TNC extends into other areas as well.  For
 example, PB-TNC supports an unlimited number of batches and each
 batch can contain up to 2^32-1 octets and about 2^24 PA messages.
 Each PA message can contain up to 2^32-1 octets.  Of course, sending
 this much data in a NEA assessment is not generally advisable, but
 the point is that PB-TNC is highly scalable.

B.7. Evaluation against Requirement C-7

 Requirement C-7 says:
 C-7   The protocols MUST support efficient transport of a large
       number of attribute messages between the NEA Client and the NEA
       Server.
 PB-TNC meets this requirement.  Each PB-TNC batch can contain about
 2^24 PA messages.  Since PB-TNC supports an unlimited number of
 batches in a session, this number is actually unlimited (except
 perhaps by PT protocols, user patience, or other external factors).
 As for efficiency, PB-TNC adds only 24 octets of overhead per PA
 message.  PA-TNC can include many attributes in a single PA message
 so this overhead is diluted further.

B.8. Evaluation against Requirement C-8

 Requirement C-8 says:
 C-8   NEA protocols MUST operate efficiently over low bandwidth or
       high latency links.
 PB-TNC meets this requirement.  A minimal PB-TNC exchange can be as
 small as 72 octets and one round trip.  Even if privacy policies or
 other factors require multiple round trips, PB-TNC generally imposes
 an overhead of only 8 octets per batch and 24 octets per PA message.

B.9. Evaluation against Requirement C-9

 Requirement C-9 says:
 C-9   For any strings intended for display to a user, the protocols
       MUST support adapting these strings to the user's language
       preferences.

Sahita, et al. Standards Track [Page 72] RFC 5793 PB-TNC March 2010

       PB-TNC meets this requirement.  It defines a standard way for
       the NEA Client and NEA Server to send their language
       preferences to each other, leveraging the widely implemented
       Accept-Language format defined in RFC 3282.

B.10. Evaluation against Requirement C-10

 Requirement C-10 says:
 C-10  NEA protocols MUST support encoding of strings in UTF-8 format.
 PB-TNC meets this requirement.  All strings in the PB-TNC protocol
 are encoded in UTF-8 format.  This allows the protocol to support a
 wide range of languages efficiently.

B.11. Evaluation against Requirement C-11

 Requirement C-11 says:
 C-11  Due to the potentially different transport characteristics
       provided by the underlying candidate PT protocols, the NEA
       Client and NEA Server MUST be capable of becoming aware of and
       adapting to the limitations of the available PT protocol.  For
       example, some PT protocol characteristics that might impact the
       operation of PA and PB include restrictions on which end can
       initiate a NEA connection, maximum data size in a message or
       full assessment, upper bound on number of round trips, and
       ordering (duplex) of messages exchanged.  The selection process
       for the PT protocols MUST consider the limitations the
       candidate PT protocol would impose upon the PA and PB
       protocols.
 PB-TNC meets this requirement.  The PB-TNC protocol is designed to be
 flexible enough to operate with a variety of underlying PT protocols,
 including those that may have limitations on message or assessment
 size, number of round trips, and duplex.  Local APIs can allow
 Posture Collectors and Posture Validators to discover when they are
 operating in a less constrained deployment and then make use of more
 verbose attributes.  Similarly, Posture Collectors could choose not
 to send or use smaller attributes (including assertions from previous
 assessments) when faced with a very constrained network connection.

Sahita, et al. Standards Track [Page 73] RFC 5793 PB-TNC March 2010

B.12. Evaluation against Requirement PB-1

 Requirement PB-1 says:
 PB-1  The PB protocol MUST be capable of carrying attributes from the
       Posture Broker Server to the Posture Broker Client.  This
       enables the Posture Broker Client to learn the posture
       assessment decision and if appropriate to aid in remediation
       and notification of the endpoint owner.
 PB-TNC meets this requirement.  It can carry attributes from the
 Posture Broker Client to the Posture Broker Server and back in an
 unlimited number of round trips.  Furthermore, PB-TNC provides
 explicit attribute support for posture decision and remediation aid
 notification.

B.13. Evaluation against Requirement PB-2

 Requirement PB-2 says:
 PB-2  The PB protocol MUST NOT interpret the contents of PA messages
       being carried; i.e., the data it is carrying must be opaque to
       it.
 PB-TNC meets this requirement.  It does not parse or interpret PA
 messages in any way.

B.14. Evaluation against Requirement PB-3

 Requirement PB-3 says:
 PB-3  The PB protocol MUST carry unique identifiers that are used by
       the Posture Brokers to route (deliver) PA messages between
       Posture Collectors and Posture Validators.  Such message
       routing should facilitate dynamic registration or
       deregistration of Posture Collectors and Validators.  For
       example, a dynamically registered anti-virus Posture Validator
       should be able to subscribe to receive messages from its
       respective anti-virus Posture Collector on NEA Clients.
 PB-TNC meets this requirement.  PB-TNC tags each PA message with a PA
 subtype that the Posture Brokers can use to deliver the PA messages
 to the proper Posture Collectors and Posture Validators.  By tagging
 messages according to their content, PB-TNC allows Posture Collectors
 and Posture Validators to be dynamically registered and deregistered,
 ensuring that each one receives the proper data.  PB-TNC also
 supports exclusive delivery, which allows messages to be targeted at
 a particular Posture Collector or Posture Validator.

Sahita, et al. Standards Track [Page 74] RFC 5793 PB-TNC March 2010

B.15. Evaluation against Requirement PB-4

 Requirement PB-4 says:
 PB-4  The PB protocol MUST be capable of supporting a half-duplex PT
       protocol.  However, this does not preclude PB from operating
       full-duplex when running over a full-duplex PT.
 PB-TNC meets this requirement.  In order to insulate PA from any
 differences between half-duplex and full-duplex PT protocols, PB-TNC
 always operates in a half-duplex mode, regardless of the capabilities
 of the PT protocol.  While this could in theory slow assessments that
 require many round trips or bidirectional multimedia exchanges, this
 is not a problem in practice because endpoint assessments do not
 typically involve multimedia or a large number of round trips.

B.16. Evaluation against Requirement PB-5

 Requirement PB-5 says:
 PB-5  The PB protocol MAY support authentication, integrity, and
       confidentiality protection for the attribute messages it
       carries between a Posture Broker Client and Posture Broker
       Server.  This provides security protection for a message dialog
       of the groupings of attribute messages exchanged between the
       Posture Broker Client and Posture Broker Server.  Such
       protection is orthogonal to PA protections (which are end to
       end) and allows for simpler Posture Collector and Validators to
       be implemented, and for consolidation of cryptographic
       operations possibly improving scalability and manageability.
 PB-TNC does not address this optional requirement.  It leaves
 security to PT (which is required to address it) and PA (which SHOULD
 do so).  There seems to be minimal benefit in adding a third layer of
 security to the NEA protocol stack.  However, if the NEA working
 group determines that PB should include support for authentication,
 integrity protection, and confidentiality protection, then this could
 be added to PB in a similar manner to the way that the PA-TNC
 security is done.

Sahita, et al. Standards Track [Page 75] RFC 5793 PB-TNC March 2010

B.17. Evaluation against Requirement PB-6

 Requirement PB-6 says:
 PB-6  The PB protocol MUST support grouping of attribute messages to
       optimize transport of messages and minimize round trips.
 PB-TNC meets this requirement.  Multiple attribute messages can be
 conveyed in a single PA message.  In fact, that's how PA-TNC works.

Authors' Addresses

 Ravi Sahita
 Intel Corporation
 2200 Mission College Blvd.
 Santa Clara, CA 95054 USA
 EMail: Ravi.Sahita@intel.com
 Steve Hanna
 Juniper Networks, Inc.
 1194 North Mathilda Avenue
 Sunnyvale, CA 94089 USA
 EMail: shanna@juniper.net
 Ryan Hurst
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052 USA
 EMail: Ryan.Hurst@microsoft.com
 Kaushik Narayan
 Cisco Systems Inc.
 10 West Tasman Drive
 San Jose, CA 95134 USA
 EMail: kaushik@cisco.com

Sahita, et al. Standards Track [Page 76]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5793.txt · Last modified: 2010/03/09 22:25 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki