Internet DRAFT - draft-ietf-nea-pb-tnc
draft-ietf-nea-pb-tnc
Network Working Group R. Sahita
Internet Draft Intel
Intended status: Proposed Standard S. Hanna
Expires: May 2009 Juniper
R. Hurst
Microsoft
K. Narayan
Cisco Systems
November 3, 2008
PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC
draft-ietf-nea-pb-tnc-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 3, 2009.
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.
Sahita et al. Expires May 3, 2009 [Page 1]
Internet-Draft PB-TNC November 2008
Table of Contents
1. Introduction...................................................4
1.1. Relationship to Trusted Network Connect...................4
1.2. Prerequisites.............................................5
1.3. Message Diagram Conventions...............................5
1.4. Terminology...............................................5
1.5. Conventions used in this document.........................5
2. PB-TNC Design Considerations...................................6
2.1. Message Addressing........................................6
2.1.1. Message Types........................................6
2.1.2. Dynamic Identifiers..................................7
2.2. Vendor IDs................................................8
2.3. Efficiency................................................8
3. PB-TNC Protocol Description....................................8
3.1. Protocol Overview.........................................8
3.2. PB-TNC State Machine......................................9
3.3. Layering on PT...........................................12
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...........................................15
4.3. IETF Standard PB-TNC Message Types.......................18
4.4. PB-Experimental..........................................19
4.5. PB-PA....................................................20
4.6. PB-Assessment-Result.....................................24
4.7. PB-Access-Recommendation.................................26
4.8. PB-Remediation-Parameters................................27
4.8.1. IETF Standard PB-TNC Remediation Parameters Types...30
4.9. PB-Error.................................................31
4.9.1. IETF Standard PB-TNC Error Codes....................33
4.9.2. Error Parameters Structures for IETF Standard PB-TNC
Error Codes................................................34
4.10. PB-Language-Preference..................................34
4.11. PB-Reason-String........................................36
5. Evaluation Against NEA Requirements...........................39
5.1. Evaluation Against Requirement C-1.......................39
5.2. Evaluation Against Requirement C-2.......................39
5.3. Evaluation Against Requirement C-3.......................39
5.4. Evaluation Against Requirement C-4.......................40
5.5. Evaluation Against Requirement C-5.......................40
5.6. Evaluation Against Requirement C-6.......................40
5.7. Evaluation Against Requirement C-7.......................41
5.8. Evaluation Against Requirement C-8.......................41
5.9. Evaluation Against Requirement C-9.......................41
5.10. Evaluation Against Requirement C-10.....................42
5.11. Evaluation Against Requirement C-11.....................42
Sahita et al. Expires May 3, 2009 [Page 2]
Internet-Draft PB-TNC November 2008
5.12. Evaluation Against Requirement PB-1.....................43
5.13. Evaluation Against Requirement PB-2.....................43
5.14. Evaluation Against Requirement PB-3.....................43
5.15. Evaluation Against Requirement PB-4.....................44
5.16. Evaluation Against Requirement PB-5.....................44
5.17. Evaluation Against Requirement PB-6.....................45
6. Security Considerations.......................................45
6.1. Threat Model.............................................45
6.2. Countermeasures..........................................46
7. IANA Considerations...........................................47
7.1. Registry for IETF Standard PB-TNC Message Types..........48
7.2. Registry for IETF Standard PA Subtypes...................49
7.3. Registry for IETF Standard PB-TNC Remediation Parameters
Types.........................................................49
7.4. Registry for IETF Standard PB-TNC Error Codes............50
8. Acknowledgments...............................................50
9. References....................................................52
9.1. Normative References.....................................52
9.2. Informative References...................................52
Appendix A: Use Cases............................................53
A.1. Initial Client triggered assessment......................53
A.1.1. Message Contents....................................54
A.1.1.1. N/W Join.......................................55
A.1.1.2. Request Posture (Req Post.)....................55
A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)...55
A.1.1.4. OS Posture.....................................55
A.1.1.5. Posture Report.................................55
A.1.1.6. Verify Posture.................................56
A.1.1.7. OS Posture Result (OS Reslt)...................57
A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result)
........................................................57
A.1.1.9. Assessment Result (Assess Result)..............57
A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)59
A.2. Server initiated Assessment with Remediation.............59
A.2.1. Message Contents....................................61
A.2.1.1. N/W Join.......................................61
A.2.1.2. Create Posture Request (Create Posture Req.)...62
A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV
Post. Req)..............................................62
A.2.1.4. Vendor Y Anti-Virus Posture Request............62
A.2.1.5. Posture Request................................62
A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr
Y AV Posture Req).......................................63
A.2.1.7. Vendor Y Anti-Virus Posture (Vndr Y AV Posture)64
A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture)64
A.2.1.9. Posture Response...............................64
A.2.1.10. Verify Posture................................65
Sahita et al. Expires May 3, 2009 [Page 3]
Internet-Draft PB-TNC November 2008
A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post
Result).................................................66
A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post
Result).................................................66
A.2.1.13. Assessment Result (Assess Result).............66
A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV
Post Reslt).............................................68
A.3. Client triggered re-assessment...........................69
A.3.1. Message Contents....................................71
A.3.1.1. Enable VPN Client (Enble)......................71
A.3.1.2. Notify Status Change (VPN Status Change).......71
A.3.1.3. Notify Posture Change (Posture Change).........71
A.3.1.4. Request Posture (Req. Post)....................71
A.3.1.5. Inspect/Request Information (Ins/Rq Info)......71
A.3.1.6. Vendor X VPN Posture (VPNX Post.)..............72
A.3.1.7. Vendor Y VPN Posture (VPNY Post.)..............72
A.3.1.8. Posture Report (Post. Rpt.)....................72
A.3.1.9. Verify Posture (Vrfy Post.)....................74
A.3.1.10. VPN Posture Result (VPN PRslt)................74
A.3.1.11. Assessment Result (Assess Result).............74
A.3.1.12. Posture Result (VPN PRslt)....................75
Author's Addresses...............................................76
Intellectual Property Statement..................................76
Disclaimer of Validity...........................................77
1. Introduction
This document specifies PB-TNC, a Posture Broker Protocol (PB)
identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol [6].
The document then evaluates PB-TNC against the requirements defined
in the NEA Requirements specification [7].
1.1. Relationship to Trusted Network Connect
Starting in 2004, the Trusted Computing Group (TCG) has defined and
published the Trusted Network Connect (TNC) architecture and
standards for network access control. These standards enable multi-
vendor interoperability throughout the TNC architecture and have been
widely adopted and deployed. In order to avoid the development of
multiple incompatible standards in this area, the TCG offered several
of its TNC standards to the IETF as candidates for standardization in
the IETF also. This document is one of those standards, known in the
IETF as PB-TNC and in the TCG as IF-TNCCS 2.0 [6]. PB-TNC and IF-
TNCCS 2.0 are equivalent.
Consistent with IETF's requirements for standards track documents,
the TCG (the copyright holder for this text) has granted the licenses
Sahita et al. Expires May 3, 2009 [Page 4]
Internet-Draft PB-TNC November 2008
described in section 3.3 of IETF RFC 3978 to the IETF Trust for the
text contained in this document. As with other Internet-Drafts, the
IETF may modify this document, ignore it, publish it as an RFC, or
take any other action. If the IETF decides to adopt a version of
this document as an RFC, the TCG plans to publish a specification for
an equivalent TNC protocol to ensure continued compatibility.
1.2. 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. The reader is
assumed to be thoroughly familiar with that document. No familiarity
with TCG specifications is assumed.
1.3. 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 one octet field with only bit 0 set has the value 0x80.
1.4. 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 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.5. 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. Expires May 3, 2009 [Page 5]
Internet-Draft PB-TNC November 2008
2. PB-TNC Design Considerations
The primary purpose of the PB-TNC protocol is to carry 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 [7] 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 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 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 their 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. Expires May 3, 2009 [Page 6]
Internet-Draft PB-TNC November 2008
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. Expires May 3, 2009 [Page 7]
Internet-Draft PB-TNC November 2008
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 transport
protocol.
In order to work well over half-duplex PT protocols (such as those
based on EAP [8]), PB-TNC supports half-duplex protocol operation.
In this mode, the Posture Broker Client and Posture Broker Server
take turns sending batches 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
Sahita et al. Expires May 3, 2009 [Page 8]
Internet-Draft PB-TNC November 2008
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-
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. Expires May 3, 2009 [Page 9]
Internet-Draft PB-TNC November 2008
+-----------------------------------------+
| SRETRY*/CRETRY |
|CRETRY*/SRETRY +---------+ +---------+
| +------------| Server | RESULT | Decided | CLOSE
| | +-------->| Working |--------->| |-------+
| | |CDATA +---------+ +---------+ |
| | | ^ | | v
v v | | | +---------------------->=========
========= | | CLOSE " End "
" Init " CDATA | |SDATA =========
========= | | ^ ^
| ^ | | v | |
| | | SDATA +---------+ CLOSE | |
| | +-------->| Client |----------------------+ |
| +------------| Working | |
|SRETRY*/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 indicted by unidirectional arrows marked with
the cause of the transition. The state transitions marked with "*"
are transitions that require full-duplex operation.
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".
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
Sahita et al. Expires May 3, 2009 [Page 10]
Internet-Draft PB-TNC November 2008
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.
The Posture Broker Client can also initiate a new exchange by sending
a CRETRY batch when the session is in the Client Working state (or in
the Server Working state, if a full-duplex transport is used). The
Posture Broker Server can perform a similar operation by sending a
SRETRY batch when the session is in the Server Working state (or in
the Client Working state, if a full-duplex transport is used). This
can be useful if a suspicious condition arises on the endpoint or a
policy changes on the NEA Server while an exchange is underway.
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. No
PB-TNC batch is sent to indicate that the exchange has been closed.
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
but this interaction is not standardized since the vertical
interfaces in the NEA Reference Model are not standardized. The
CLOSE notification 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
Sahita et al. Expires May 3, 2009 [Page 11]
Internet-Draft PB-TNC November 2008
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 should close the PT connection and
start a new PB-TNC session. This limitation does not exist when a
full-duplex transport is used.
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.4. Example of PB-TNC Encapsulation
This section shows how PA messages can be carried inside a PB-TNC
batch which 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. Expires May 3, 2009 [Page 12]
Internet-Draft PB-TNC November 2008
4. PB-TNC Protocol Specification
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 one
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|R| Reserved | B-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (4 bits)
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. If a Posture Broker Client or Posture Broker
Server receives a Version value that it does not support, it
SHOULD respond with an Invalid Parameter error code.
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.
Retry-Acknowledge (R) (1 bit)
This bit MUST be set to 1 for the first message sent by a Posture
Broker Client or Server after it has received and processed a
SRETRY or CRETRY (see Batch Type field) message respectively. In
all other cases, this bit MUST be set to 0. After a Posture Broker
Client or Posture Broker Server sends a SRETRY or CRETRY message,
it MUST ignore all messages received from the other party until it
receives a message with the R bit set.
This field helps avoid a situation in full-duplex transport mode
where a Posture Broker Client or Posture Broker Server sends a
Sahita et al. Expires May 3, 2009 [Page 13]
Internet-Draft PB-TNC November 2008
retry message and then receives and processes a message that the
other party had sent before receiving the retry message.
Reserved (22 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 send a
Malformed Message error code in response. In addition, if the
value received is not permitted for the current state, according
to the state machine in section 3.2. , the recipient MUST send an
Unexpected Batch Type error code in response.
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. If a Posture
Broker Client receives a batch with this Batch
Type, it SHOULD ignore the batch and send a
fatal Unexpected Batch Type error code in
response. 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. If a Posture
Broker Server receives a batch with this Batch
Type, it SHOULD ignore the batch and send a
fatal Unexpected Batch Type error code in
response. 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
Sahita et al. Expires May 3, 2009 [Page 14]
Internet-Draft PB-TNC November 2008
completed its evaluation. The batch SHOULD
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. If a Posture
Broker Client receives a batch with this Batch
Type, it SHOULD ignore the batch and send a
fatal Unexpected Batch Type error code in
response. 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. If a Posture
Broker Server receives a batch with this Batch
Type, it SHOULD ignore the batch and send a
fatal Unexpected Batch Type error code in
response. A SRETRY batch may be empty (contain
no messages) if the Posture Broker Server has
nothing else to send.
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
SHOULD send an Invalid Parameter error code in response.
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.
Sahita et al. Expires May 3, 2009 [Page 15]
Internet-Draft PB-TNC November 2008
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
SHOULD include an Unsupported Mandatory Message error code in the
next batch that it sends. 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
Sahita et al. Expires May 3, 2009 [Page 16]
Internet-Draft PB-TNC November 2008
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 SHOULD send an
Invalid Parameter error code in the next batch that it sends.
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 SHOULD send an Invalid Parameter error code in
the next batch that it sends. 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
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 which, 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 3.
IANA maintains a registry of IETF standard PB-TNC message types.
Entries may only be added to this registry by IETF Consensus.
That is, they must be defined in an RFC approved by the IESG.
Sahita et al. Expires May 3, 2009 [Page 17]
Internet-Draft PB-TNC November 2008
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 send an
Invalid Parameter error code in response.
PB-TNC Message Value (variable length)
The syntax and semantics of this field varies, depending on the
values in the PB-TNC Vendor ID and PB-TNC Message Type fields.
The syntax and semantics of several standard messages is defined
in subsequent sections of this specification.
4.3. IETF Standard PB-TNC Message Types
This 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
3. For IETF standard PA subtypes (which are completely different
from PB-TNC message types), please refer to the PA-TNC specification
[9].
Sahita et al. Expires May 3, 2009 [Page 18]
Internet-Draft PB-TNC November 2008
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
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
SHOULD send an Invalid Parameter error code in response.
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 SHOULD ignore the message unless the NOSKIP bit is set,
Sahita et al. Expires May 3, 2009 [Page 19]
Internet-Draft PB-TNC November 2008
in which case it SHOULD send an Unsupported Mandatory Message error
code in the next batch that it sends.
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 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 SHOULD
ignore the message and send a fatal Invalid Parameter error code in
response. 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.
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 SHOULD send an Invalid Parameter
error code in response.
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. Expires May 3, 2009 [Page 20]
Internet-Draft PB-TNC November 2008
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
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
Sahita et al. Expires May 3, 2009 [Page 21]
Internet-Draft PB-TNC November 2008
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 SHOULD send an Invalid
Parameter error code in the next batch that it sends.
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 SHOULD send an Invalid
Parameter error code in the next batch that it sends. 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 IETF standard PA subtypes. Entries
may only be added to this registry by IETF Consensus. That is,
they must be defined in an RFC approved by the IESG. No IETF
standard PA subtypes are defined in this specification.
Definitions of IETF standard PA subtypes will be contained in the
PA specification and other RFCs. 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.
Sahita et al. Expires May 3, 2009 [Page 22]
Internet-Draft PB-TNC November 2008
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 MUST assign a unique Posture Collector
Identifier value (but not 0xffff) to each Posture Collector
involved in a message exchange and include this Posture Collector
identifier in this field for any PA messages sent by that Posture
Collector. The Posture Collector Identifier value 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
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.
Sahita et al. Expires May 3, 2009 [Page 23]
Internet-Draft PB-TNC November 2008
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 Server 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
a PB-TNC Message Length field whose value is less than 24 SHOULD
send an Invalid Parameter error code in response.
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 SHOULD include one
message of this type in any batch of type RESULT and SHOULD 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. The Posture Broker Client SHOULD implement and process
this message and SHOULD ignore any message with this message type
that is not part of a batch of type RESULT.
Sahita et al. Expires May 3, 2009 [Page 24]
Internet-Draft PB-TNC November 2008
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-Access-Recommendation message with a
PB-TNC Message Length field that does not have a value of 16 SHOULD
send an Invalid Parameter error code in response.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Sahita et al. Expires May 3, 2009 [Page 25]
Internet-Draft PB-TNC November 2008
4 Posture Broker Server was unable to determine whether the
assessed endpoint is compliant with policy based on the attributes
provided by endpoint.
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 SHOULD include one
message of this type in any batch of type RESULT and SHOULD 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.
The Posture Broker Client MUST implement and process this message and
SHOULD 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 SHOULD ignore the message and send a fatal Invalid Parameter
error code in response. 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 SHOULD send an Invalid Parameter error code in
response.
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. Expires May 3, 2009 [Page 26]
Internet-Draft PB-TNC November 2008
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 SHOULD respond with an
Invalid Parameter error code. 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
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. 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.
Sahita et al. Expires May 3, 2009 [Page 27]
Internet-Draft PB-TNC November 2008
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 or Posture Broker Server that
receives a PB-Remediation-Parameters message with a PB-TNC Message
Length field that contains an invalid value (e.g. less than 20)
SHOULD send an Invalid Parameter error code in response.
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 | 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)
Sahita et al. Expires May 3, 2009 [Page 28]
Internet-Draft PB-TNC November 2008
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 IETF Standard PB-TNC Remediation
Parameters Types. Entries may only be added to this registry by
IETF Consensus. That is, they must be defined in an RFC approved
by the IESG. 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
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
SHOULD consider this a malformed message. The Posture Broker
Client may send an Invalid Parameter error code in response, if
this is practical according to the PB-TNC state machine. In many
Sahita et al. Expires May 3, 2009 [Page 29]
Internet-Draft PB-TNC November 2008
cases, it will not be practical since the PB-Remediation-
Parameters message often comes in a batch of type RESULT and
according to the PB-TNC state machine, a Posture Broker Client
cannot send a batch after this except a CRETRY batch, which would
restart the handshake. That is generally not desirable.
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
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 a UTF-8 encoded
string. This string should contain 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.
Sahita et al. Expires May 3, 2009 [Page 30]
Internet-Draft PB-TNC November 2008
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 close 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.
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-Remediation-Parameters
message with a PB-TNC Message Length field that contains an invalid
value (e.g. less than 20) SHOULD send an Invalid Parameter error code
in response.
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. Expires May 3, 2009 [Page 31]
Internet-Draft PB-TNC November 2008
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.
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).
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
Sahita et al. Expires May 3, 2009 [Page 32]
Internet-Draft PB-TNC November 2008
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 IETF Standard PB-TNC Error Codes.
Entries may only be added to this registry by IETF Consensus.
That is, they must be defined in an RFC approved by the IESG. 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.
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
Sahita et al. Expires May 3, 2009 [Page 33]
Internet-Draft PB-TNC November 2008
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 either be 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Sahita et al. Expires May 3, 2009 [Page 34]
Internet-Draft PB-TNC November 2008
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.
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.
Sahita et al. Expires May 3, 2009 [Page 35]
Internet-Draft PB-TNC November 2008
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] (US-ASCII only, no control characters
allowed, 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.
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
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-
Sahita et al. Expires May 3, 2009 [Page 36]
Internet-Draft PB-TNC November 2008
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 Reason String Language Code Length),
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 20 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 20 (for the fixed-
length fields) and the values of the Reason String Length and Reason
String Language Code Length fields. If this is not the case, the
recipient SHOULD send an Invalid Parameter error code in response, if
this is practical according to the PB-TNC state machine. In many
cases, it will not be practical since the PB-Reason-String message
often comes in a batch of type RESULT and according to the PB-TNC
state machine, a Posture Broker Client cannot send a batch after this
except a CRETRY batch, which would restart the handshake. That is
generally not desirable.
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. Expires May 3, 2009 [Page 37]
Internet-Draft PB-TNC November 2008
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Language Code Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 SHOULD send an Invalid Parameter error code in
the next batch that it sends. A zero length string SHOULD NOT be
sent since this is the same as sending no reason string at all,
leaving the reason unspecified.
Reason String Language Code Length (32 bits)
The Reason String Language Code Length 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. Expires May 3, 2009 [Page 38]
Internet-Draft PB-TNC November 2008
5. 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.
5.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.
5.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.
5.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
Sahita et al. Expires May 3, 2009 [Page 39]
Internet-Draft PB-TNC November 2008
intermediaries and endpoints including prevention from replay
based attacks.
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.
5.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.
5.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.
5.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
Sahita et al. Expires May 3, 2009 [Page 40]
Internet-Draft PB-TNC November 2008
Clients to be assessed by numerous Posture Validators residing
on multiple NEA Servers.
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.
5.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.
5.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.
5.9. Evaluation Against Requirement C-9
Requirement C-9 says:
Sahita et al. Expires May 3, 2009 [Page 41]
Internet-Draft PB-TNC November 2008
C-9 For any strings intended for display to a user, the protocols
MUST support adapting these strings to the user's language
preferences.
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.
5.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.
5.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 roundtrips, 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 roundtrips, 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 to not send or use
smaller attributes (including assertions from previous
Sahita et al. Expires May 3, 2009 [Page 42]
Internet-Draft PB-TNC November 2008
assessments) when faced with a very constrained network
connection.
5.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.
5.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.
5.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
Sahita et al. Expires May 3, 2009 [Page 43]
Internet-Draft PB-TNC November 2008
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.
5.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.
5.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. Expires May 3, 2009 [Page 44]
Internet-Draft PB-TNC November 2008
5.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.
6. 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.
6.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
Sahita et al. Expires May 3, 2009 [Page 45]
Internet-Draft PB-TNC November 2008
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
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.
6.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
Sahita et al. Expires May 3, 2009 [Page 46]
Internet-Draft PB-TNC November 2008
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
