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
Table of Contents
1. Introduction ....................................................41.1. Prerequisites ..............................................41.2. Message Diagram Conventions ................................41.3. Terminology ................................................41.4. Conventions Used in This Document ..........................42. PB-TNC Design Considerations ....................................52.1. Message Addressing .........................................52.2. Vendor IDs .................................................72.3. Efficiency .................................................73. PB-TNC Protocol Description .....................................73.1. Protocol Overview ..........................................73.2. PB-TNC State Machine .......................................83.3. Layering on PT ............................................113.4. Example of PB-TNC Encapsulation ...........................124. PB-TNC Protocol Specification ..................................134.1. PB-TNC Header .............................................134.2. PB-TNC Message ............................................164.3. IETF Standard PB-TNC Message Types ........................194.4. PB-Experimental ...........................................19
This document specifies PB-TNC, a Posture Broker (PB) 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 Network Endpoint Assessment (NEA) Requirements specification
This document does not define an architecture or reference model.
Instead, it defines a protocol that works within the reference model
described in the NEA Requirements specification . The reader is
assumed to be thoroughly familiar with that document. No familiarity
with TCG specifications is assumed.
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.
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 .
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  describes in section
220.127.116.11 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  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
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.
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
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
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
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.
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 ), 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
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).
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-
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.
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
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
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.
3.3.1. Posture Transport (PT) Protocol Requirements Addendum
RFC 5209  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
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