tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5793

 Errata 
Proposed STD
Pages: 76
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: NEA

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

Part 1 of 3, p. 1 to 12
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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 RFC Part