Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5793

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

Pages: 76
Proposed Standard
Errata
Part 1 of 3 – Pages 1 to 12
None   None   Next

Top   ToC   RFC5793 - Page 1
Internet Engineering Task Force (IETF)                         R. Sahita
Request for Comments: 5793                                         Intel
Category: Standards Track                                       S. Hanna
ISSN: 2070-1721                                                  Juniper
                                                                R. Hurst
                                                               Microsoft
                                                              K. Narayan
                                                           Cisco Systems
                                                              March 2010


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

Abstract

This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5793.
Top   ToC   RFC5793 - Page 2
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

1. Introduction ....................................................4 1.1. Prerequisites ..............................................4 1.2. Message Diagram Conventions ................................4 1.3. Terminology ................................................4 1.4. Conventions Used in This Document ..........................4 2. PB-TNC Design Considerations ....................................5 2.1. Message Addressing .........................................5 2.2. Vendor IDs .................................................7 2.3. Efficiency .................................................7 3. PB-TNC Protocol Description .....................................7 3.1. Protocol Overview ..........................................7 3.2. PB-TNC State Machine .......................................8 3.3. Layering on PT ............................................11 3.4. Example of PB-TNC Encapsulation ...........................12 4. PB-TNC Protocol Specification ..................................13 4.1. PB-TNC Header .............................................13 4.2. PB-TNC Message ............................................16 4.3. IETF Standard PB-TNC Message Types ........................19 4.4. PB-Experimental ...........................................19
Top   ToC   RFC5793 - Page 3
      4.5. PB-PA .....................................................20
      4.6. PB-Assessment-Result ......................................25
      4.7. PB-Access-Recommendation ..................................26
      4.8. PB-Remediation-Parameters .................................28
      4.9. PB-Error ..................................................32
      4.10. PB-Language-Preference ...................................37
      4.11. PB-Reason-String .........................................38
   5. Security Considerations ........................................41
      5.1. Threat Model ..............................................41
      5.2. Countermeasures ...........................................42
   6. IANA Considerations ............................................43
      6.1. Designated Expert Guidelines ..............................44
      6.2. Registry for PB-TNC Message Types .........................45
      6.3. Registry for PA Subtypes ..................................45
      6.4. Registry for PB-TNC Remediation Parameters Types ..........46
      6.5. Registry for PB-TNC Error Codes ...........................46
   7. Acknowledgments ................................................47
   8. References .....................................................47
      8.1. Normative References ......................................47
      8.2. Informative References ....................................48
   Appendix A. Use Cases .............................................49
      A.1. Initial Client-Triggered Assessment .......................49
      A.2. Server-Initiated Assessment with Remediation ..............54
      A.3. Client-Triggered Reassessment .............................63
   Appendix B. Evaluation against NEA Requirements ...................70
      B.1. Evaluation against Requirement C-1 ........................70
      B.2. Evaluation against Requirement C-2 ........................70
      B.3. Evaluation against Requirement C-3 ........................70
      B.4. Evaluation against Requirement C-4 ........................71
      B.5. Evaluation against Requirement C-5 ........................71
      B.6. Evaluation against Requirement C-6 ........................71
      B.7. Evaluation against Requirement C-7 ........................72
      B.8. Evaluation against Requirement C-8 ........................72
      B.9. Evaluation against Requirement C-9 ........................72
      B.10. Evaluation against Requirement C-10 ......................73
      B.11. Evaluation against Requirement C-11 ......................73
      B.12. Evaluation against Requirement PB-1 ......................74
      B.13. Evaluation against Requirement PB-2 ......................74
      B.14. Evaluation against Requirement PB-3 ......................74
      B.15. Evaluation against Requirement PB-4 ......................75
      B.16. Evaluation against Requirement PB-5 ......................75
      B.17. Evaluation against Requirement PB-6 ......................76
Top   ToC   RFC5793 - Page 4

1. Introduction

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

1.1. Prerequisites

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

1.2. Message Diagram Conventions

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

1.3. Terminology

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

1.4. Conventions Used in This Document

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

2. PB-TNC Design Considerations

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

2.1. Message Addressing

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

2.1.1. Message Types

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

2.2. Vendor IDs

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

2.3. Efficiency

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

3. PB-TNC Protocol Description

3.1. Protocol Overview

The PB-TNC protocol carries batches of PB messages between a Posture Broker Client and a Posture Broker Server. It encapsulates PA messages and manages the NEA session. It runs over a PT protocol. In order to work well over half-duplex PT protocols (such as those based on EAP [9]), PB-TNC supports half-duplex protocol operation. In this mode, the Posture Broker Client and Posture Broker Server take turns sending a single batch of messages to each other. While the half-duplex nature of PB-TNC could slow exchanges that require many round trips or bidirectional multimedia exchanges, this is not a problem in practice because endpoint assessments do not typically involve multimedia or a large number of round trips. The benefit of working over half-duplex transports outweighs any limitations imposed. PB-TNC also supports full-duplex protocol operation so that PB-TNC exchanges can be re-initialized immediately when needed (e.g., if the Posture Broker Server policy changes or if the Posture Broker Client detects a suspicious event).
Top   ToC   RFC5793 - Page 8
   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.
Top   ToC   RFC5793 - Page 9
               Receive CRETRY        SRETRY
                    or SRETRY   +----------------+
                         +--+   |                |
                         v  |   v                |
                        +---------+  CRETRY  +---------+
              CDATA     | Server  |<---------| Decided | CLOSE
           +----------->| Working |--------->|         |-------+
           |            +---------+  RESULT  +---------+       |
           |                ^ |  |                             v
           |                | |  +---------------------->=======
         ========           | |              CLOSE       " End "
         " Init "      CDATA| |SDATA                     =======
         ========           | |                          ^    ^
           |  |             | v                          |    |
           |  | SDATA   +---------+          CLOSE       |    |
           |  +-------->| Client  |----------------------+    |
           |            | Working |                           |
           |            +---------+                           |
           |                |  ^                              |
           |                +--+                              |
           |            Receive CRETRY                        |
           |   CLOSE                                          |
           +--------------------------------------------------+

                         Figure 1: PB-TNC state machine

   In this diagram, states are indicated by rectangular boxes.  The
   initial and terminal states have double outlines (with = and ").
   State transitions are indicated by unidirectional arrows marked with
   the cause of the transition.

   Many transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) are
   triggered by the transmission or reception of a PB-TNC batch of a
   particular type.  The type of a PB-TNC batch is indicated by the
   contents of the Batch Type field in the PB-TNC header for that batch.
   For brevity, this document says "a FOO batch" instead of "a PB-TNC
   batch whose Batch Type field contains FOO".  Other transitions are
   triggered by receiving a PB-TNC batch of a particular type (e.g.,
   Receive CRETRY).  The CLOSE transition may be triggered by sending or
   receiving a CLOSE batch but may also be triggered by termination of
   the underlying PT connection.

   A PB-TNC session starts in the Init state when the underlying
   transport protocol (PT) establishes a connection between a Posture
   Broker Client and a Posture Broker Server.  If the Posture Broker
   Client initiated the underlying transport session, it starts by
   sending a CDATA batch to the Posture Broker Server, thus causing a
   transition to the Server Working state.  If the Posture Broker Server
Top   ToC   RFC5793 - Page 10
   initiated the transport session, it starts by sending a PB-TNC batch
   of type SDATA to the Posture Broker Client, thus causing a transition
   to the Client Working state.

   The Posture Broker Client and Posture Broker Server may now alternate
   sending CDATA and SDATA batches to each other.  Only the Posture
   Broker Client can send a data batch when the session is in the Client
   Working state, and only the Posture Broker Server can send a data
   batch when the session is in the Server Working state.

   The most common way to end an exchange is for the Posture Broker
   Server to send a RESULT batch.  This causes a transition into the
   Decided state.  This is not a terminal state.  The PT session can
   remain open and another exchange can be initiated by having the
   Posture Broker Client send a CRETRY batch.  This can be useful when
   the Posture Broker Client (or more likely a Posture Collector)
   discovers a suspicious condition on the endpoint, for example.  If
   the underlying transport protocol (PT) supports full-duplex
   operation, the Posture Broker Server can also initiate another
   exchange from this state by sending a SRETRY batch.  This can be
   useful when the policy changes on the server, for example.

   Whether an SRETRY or CRETRY message or both are sent, the next state
   is the Server Working State.  From this state, the Posture Broker
   Server sends an SDATA batch and the new exchange begins.  The state
   transitions marked Receive CRETRY and Receive CRETRY or SRETRY
   indicate that it is permissible to receive such messages in the
   indicated states, generally when the Posture Broker Client sent a
   CRETRY message at roughly the same time as the Posture Broker Server
   decided to send an SRETRY.  In that case, a CRETRY message may be
   received while in the Server Working or Client Working state.  Also,
   an SRETRY message may be received while in the Server Working state.
   These messages are redundant and therefore ignored, as indicated by
   the relevant transitions, which don't cause a state change.

   The only terminal state is the End state.  This state is reached if
   the underlying PT connection closes.  This can be caused by an action
   of the Posture Broker Client or Posture Broker Server or it can be
   caused by some external factor, such as pulling the network plug.
   When possible, a CLOSE batch SHOULD be sent before the underlying PT
   connection is terminated.  However, there may be cases where the PT
   connection is closed without notice.  For example, a plug may be
   pulled, a software program may fail, or a Posture Broker Client or
   Posture Broker Server may be unable to send a CLOSE message due to
   half-duplex limitations in the underlying PT protocol.  In these
   cases, the Posture Broker Client and Posture Broker Server will
   generally receive some form of notification from the Posture
   Transport Client and Posture Transport Server that the PT connection
Top   ToC   RFC5793 - Page 11
   has been closed.  This notification can trigger the CLOSE transition.
   However, the notification interaction is not standardized since the
   vertical interfaces in the NEA Reference Model are not standardized.
   In any case, the reception of the CLOSE batch or notification of
   termination of the transport causes the transition to the End state.

   Note that a Posture Broker Client and Posture Broker Server may not
   always have exactly the same state for a given PB-TNC session.  For
   example, say that a session is in the Client Working state and the
   Posture Broker Client transmits a CDATA batch.  While this batch is
   in transit (transmitted by the Posture Broker Client but not yet
   received by the Posture Broker Server), the Posture Broker Client
   will think that the session is in Server Working state but the
   Posture Broker Server will think that the session is in Client
   Working state.  However, this is a temporary condition and does not
   cause problems in practice.  The only possible issue is that a
   Posture Broker Client or Posture Broker Server does not know whether
   the other party has received its message until it receives a response
   from the other party.

   If a half-duplex transport is used, note that the Posture Broker
   Server cannot send a SRETRY batch when the session is in the Decided
   state because the Posture Broker Server sent the most recent batch
   (the RESULT batch) and this would violate the half-duplex nature of
   the transport protocol.  Instead, a server that wishes to initiate a
   new exchange in the Decided state when a half-duplex transport is in
   use should close the PT connection without sending a CLOSE batch and
   start a new PB-TNC session.  This limitation does not exist when a
   full-duplex transport is used.

   The Posture Broker Server and Posture Broker Client MUST follow the
   state machine described in this section.

3.3. Layering on PT

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

3.3.1. Posture Transport (PT) Protocol Requirements Addendum

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

3.4. Example of PB-TNC Encapsulation

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


(next page on part 2)

Next Section