[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-sahita-nea-pb-tnc) 00 01 02 03 04 05 06 RFC 5793

Network Working Group                                         R. Sahita
Internet Draft                                                    Intel
Intended status: Proposed Standard                             S. Hanna
Expires: January 2009                                           Juniper
                                                               R. Hurst
                                                              Microsoft
                                                             K. Narayan
                                                          Cisco Systems

                                                          July 14, 2008


        PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC
                       draft-ietf-nea-pb-tnc-01.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 January 14, 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 January 14, 2009                [Page 1]

Internet-Draft                  PB-TNC                        July 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
   2. PB-TNC Design Considerations...................................5
      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...........................................13
      4.3. IETF Standard PB-TNC Message Types.......................16
      4.4. PB-Experimental..........................................17
      4.5. PB-Batch-Type............................................18
      4.6. PB-PA....................................................20
      4.7. PB-Access-Recommendation.................................25
      4.8. PB-Remediation-Parameters................................26
         4.8.1. IETF Standard PB-TNC Remediation Parameters Types...28
      4.9. PB-Error.................................................29
         4.9.1. IETF Standard PB-TNC Error Codes....................32
         4.9.2. Error Parameters Structures for IETF Standard PB-TNC
         Error Codes................................................32
      4.10. PB-Language-Preference..................................33
      4.11. PB-Reason-String........................................35
   5. Evaluation Against NEA Requirements...........................37
      5.1. Evaluation Against Requirement C-1.......................38
      5.2. Evaluation Against Requirement C-2.......................38
      5.3. Evaluation Against Requirement C-3.......................38
      5.4. Evaluation Against Requirement C-4.......................39
      5.5. Evaluation Against Requirement C-5.......................39
      5.6. Evaluation Against Requirement C-6.......................39
      5.7. Evaluation Against Requirement C-7.......................40
      5.8. Evaluation Against Requirement C-8.......................40
      5.9. Evaluation Against Requirement C-9.......................40
      5.10. Evaluation Against Requirement C-10.....................41
      5.11. Evaluation Against Requirement C-11.....................41
      5.12. Evaluation Against Requirement PB-1.....................42


Sahita et al.          Expires January 14, 2009                [Page 2]

Internet-Draft                  PB-TNC                        July 2008


      5.13. Evaluation Against Requirement PB-2.....................42
      5.14. Evaluation Against Requirement PB-3.....................42
      5.15. Evaluation Against Requirement PB-4.....................43
      5.16. Evaluation Against Requirement PB-5.....................43
      5.17. Evaluation Against Requirement PB-6.....................43
   6. Security Considerations.......................................44
      6.1. Threat Model.............................................44
      6.2. Countermeasures..........................................45
   7. IANA Considerations...........................................46
      7.1. Registry for IETF Standard PB-TNC Message Types..........47
      7.2. Registry for IETF Standard PA Subtypes...................48
      7.3. Registry for IETF Standard PB-TNC Remediation Parameters
      Types.........................................................48
      7.4. Registry for IETF Standard PB-TNC Error Codes............49
   8. Acknowledgments...............................................49
   9. References....................................................51
      9.1. Normative References.....................................51
      9.2. Informative References...................................51
   Appendix A: Use Cases............................................52
      A.1. Initial Client triggered assessment......................52
         A.1.1. Message Contents....................................53
            A.1.1.1. N/W Join.......................................54
            A.1.1.2. Request Posture (Req Post.)....................54
            A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)...54
            A.1.1.4. OS Posture.....................................54
            A.1.1.5. Posture Report.................................54
            A.1.1.6. Verify Posture.................................56
            A.1.1.7. OS Posture Result (OS Reslt)...................56
            A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result)
            ........................................................56
            A.1.1.9. Assessment Result (Assess Result)..............56
            A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)58
      A.2. Server initiated Assessment with Remediation.............58
         A.2.1. Message Contents....................................61
            A.2.1.1. N/W Join.......................................61
            A.2.1.2. Create Posture Request (Create Posture Req.)...61
            A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV
            Post. Req)..............................................61
            A.2.1.4. Vendor Y Anti-Virus Posture Request............61
            A.2.1.5. Posture Request................................61
            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)63
            A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture)63
            A.2.1.9. Posture Response...............................64
            A.2.1.10. Verify Posture................................65



Sahita et al.          Expires January 14, 2009                [Page 3]

Internet-Draft                  PB-TNC                        July 2008


            A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post
            Result).................................................65
            A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post
            Result).................................................65
            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....................................70
            A.3.1.1. Enable VPN Client (Enble)......................70
            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. VPN Posture (VPN Post.)........................71
            A.3.1.7. Posture Report (Post. Rpt.)....................71
            A.3.1.8. Verify Posture (Vrfy Post.)....................73
            A.3.1.9. VPN Posture Result (VPN PRslt).................73
            A.3.1.10. Assessment Result (Assess Result).............73
            A.3.1.11. Posture Result (VPN PRslt)....................74
   Author's Addresses...............................................75
   Intellectual Property Statement..................................75
   Disclaimer of Validity...........................................76

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
   described in section 3.3 of IETF RFC 3978 to the IETF Trust for the


Sahita et al.          Expires January 14, 2009                [Page 4]

Internet-Draft                  PB-TNC                        July 2008


   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 January 14, 2009                [Page 5]

Internet-Draft                  PB-TNC                        July 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 its own set of PA
   Subtype values without worrying about collisions with other vendors
   or with standard values.

   The PA message type is somewhat analogous to a MIME type in that it
   indicates the type of the PA message. Posture Collectors and Posture
   Validators can use local APIs to indicate to the Posture Broker
   Client and Posture Broker Server which PA message types they are
   interested in receiving. For instance, a Posture Validator that
   evaluates anti-virus posture might indicate that it would like to
   receive PA messages with a PA Message Vendor ID of 0 and a PA Subtype
   that matches the IETF Standard PA Subtype for Anti-Virus. It might
   also indicate interest in some vendor-specific PA message types to
   get additional vendor-specific information on anti-virus posture.




Sahita et al.          Expires January 14, 2009                [Page 6]

Internet-Draft                  PB-TNC                        July 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
   hande. 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 January 14, 2009                [Page 7]

Internet-Draft                  PB-TNC                        July 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 is a half-duplex protocol.  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.

   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


Sahita et al.          Expires January 14, 2009                [Page 8]

Internet-Draft                  PB-TNC                        July 2008


   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.  Another important standard PB-TNC message type is PB-
   Batch-Type, which contains a batch type that drives state machine
   transitions.

   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 January 14, 2009                [Page 9]

Internet-Draft                  PB-TNC                        July 2008


                    +---------+  CRETRY  +---------+
          CDATA     | Server  |<---------| Decided | CLOSE
       +----------->| Working |--------->|         |-------+
       |            +---------+  RESULT  +---------+       |
       |                ^ |  |                             v
       |                | |  +---------------------->=======
     ========           | |              CLOSE       " End "
     " Init "   CDATA or| |SDATA or                  =======
     ========     CRETRY| |SRETRY                    ^    ^
       |  |             | v                          |    |
       |  | SDATA   +---------+          CLOSE       |    |
       |  +-------->| Client  |----------------------+    |
       |            | Working |                           |
       |            +---------+                           |
       |    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.

   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 a PB-TNC message of type PB-Batch-Type within that batch.
   For brevity, this document says "a FOO batch" instead of "a PB-TNC
   batch containing a PB-TNC message of type PB-Batch-Type whose Batch
   Type is 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.  Since PB-TNC is a
   half-duplex protocol, only the Posture Broker Client can send a batch
   when the session is in the Client Working state and only the Posture



Sahita et al.          Expires January 14, 2009               [Page 10]

Internet-Draft                  PB-TNC                        July 2008


   Broker Server can send a 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.

   The Posture Broker Client can also initiate a new exchange by sending
   a CRETRY batch when the session is in the Client Working state.  The
   Posture Broker Server can perform a similar operation by sending a
   SRETRY batch when the session is in the Server Working state.  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
   the other party has received its message until it receives a response
   from the other party.

   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


Sahita et al.          Expires January 14, 2009               [Page 11]

Internet-Draft                  PB-TNC                        July 2008


   the half-duplex nature of the PB-TNC 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.

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 a PB-Batch-Type message and 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-Batch-Type Message                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           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 January 14, 2009               [Page 12]

Internet-Draft                  PB-TNC                        July 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|                     Reserved                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       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.

   Reserved (28 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.

   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.

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 January 14, 2009               [Page 13]

Internet-Draft                  PB-TNC                        July 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 January 14, 2009               [Page 14]

Internet-Draft                  PB-TNC                        July 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-Batch-
      Type), 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 January 14, 2009               [Page 15]

Internet-Draft                  PB-TNC                        July 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 January 14, 2009               [Page 16]

Internet-Draft                  PB-TNC                        July 2008


   Message Type   Definition
   ------------   ----------
   0              PB-Experimental - reserved for experimental use
   1              PB-Batch-Type - indicates the type of the PB-TNC batch
                  that contains this message
   2              PB-PA - contains a PA message
   3              PB-Access-Recommendation - includes Posture Broker
                  Server access recommendation (also known as global
                  assessment decision)
   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 January 14, 2009               [Page 17]

Internet-Draft                  PB-TNC                        July 2008


   in which case it SHOULD send an Unsupported Mandatory Message error
   code in the next batch that it sends.

4.5. PB-Batch-Type

   The PB-TNC message type named PB-Batch-Type (value 1) indicates the
   type of the PB-TNC batch that contains it.  This value is used to
   drive the state machine described in section 3.2.

   Each PB-TNC batch MUST contain one and only one message with type PB-
   Batch-Type.  Any Posture Broker Client or Posture Broker Server that
   receives a PB-TNC batch that contains more than one message with type
   PB-Batch-Type or contains no such message SHOULD ignore the entire
   batch and send a fatal Invalid Parameter error code in response.  All
   Posture Broker Client and Posture Broker Server implementations MUST
   implement support for this PB-TNC message type.

   The NOSKIP flag in the PB-TNC Message Header MUST be set for this
   message type and the PB-TNC Message Type field MUST contain 1.  The
   PB-TNC Vendor ID field MUST contain zero (0).  If a different Vendor
   ID is contained in that field, the Message Type 1 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 fields
   described below.  Any Posture Broker Client or Posture Broker Server
   that receives a PB-Batch-Type 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.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |D|      Reserved               |           Batch Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   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


Sahita et al.          Expires January 14, 2009               [Page 18]

Internet-Draft                  PB-TNC                        July 2008


      is sending this message, the Directionality bit MUST be set to 1.
      This helps avoid any situation where two Posture Broker Clients or
      two Posture Broker Servers engage in a dialog.  It also helps with
      debugging.

   Reserved (15 bits)

      These Reserved bits MUST be set to 0 on transmission and ignored
      on reception.

   Batch Type (16 bits)

      The Batch Type 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 2.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.  This message may be the only message
                        in a batch, if the Posture Broker Client has
                        nothing else 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.  This message may be the only message
                        in a batch, if the Posture Broker Server has
                        nothing else 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 January 14, 2009               [Page 19]

Internet-Draft                  PB-TNC                        July 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.  This message may be the only message
                        in a batch, 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.  This message may be the only message
                        in a batch, if the Posture Broker Server has
                        nothing else to send.

4.6. PB-PA

   The PB-TNC message type named PB-PA (value 2) 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 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.



Sahita et al.          Expires January 14, 2009               [Page 20]

Internet-Draft                  PB-TNC                        July 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 (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.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags      |               PA Message Vendor ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           PA Subtype                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Posture Collector Identifier | Posture Validator Identifier  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 PA Message Body (Variable Length)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags (8 bits)

      This field contains flags relating to the PA message.

      Bit 0 of this flags field (the most significant bit) is known as
      the EXCL flag (for exclusive).  If the EXCL bit is cleared (value
      0), the Posture Broker Client or Posture Broker Server that
      receives this PB-TNC message SHOULD deliver the PA message
      contained in this PB-TNC message to all Posture Collectors or
      Posture Validators that have expressed an interest in PA messages
      with this PA Message Vendor ID and PA subtype.  If a Posture
      Broker Client receives a message with the EXCL flag set (value 1),
      the Posture Broker Client SHOULD deliver the PA message contained
      in this PB-TNC message only to the Posture Collector identified by
      the Posture Collector Identifier field.  However, if the
      identified Posture Collector has not expressed an interest in PA
      messages with this PA Message Vendor ID and PA subtype, the PA


Sahita et al.          Expires January 14, 2009               [Page 21]

Internet-Draft                  PB-TNC                        July 2008


      message should be silently discarded.  Analogous requirements
      apply to a Posture Broker Server that receives a message with the
      EXCL flag set.

      The EXCL bit allows, for example, a Posture Validator to handle
      the circumstance where there are two Posture Collectors on the
      endpoint that are interested in a particular kind of PA messages
      and the Posture Validator has remediation instructions that only
      apply to one of those Posture Collectors.

      The other bits in this Flags field are reserved.  For this version
      of PB-TNC, they MUST be set to 0 on transmission and ignored on
      reception.

   PA Message Vendor ID (24 bits)

      The PA Message Vendor ID field identifies a vendor by using the
      SMI Private Enterprise Number (PEN).  Any organization can receive
      its own unique PEN from IANA, the Internet Assigned Numbers
      Authority.  The PA Message Vendor ID qualifies the PA Subtype
      field so that each vendor has 2^32-1 separate PA subtypes
      available for its use.  PA subtypes standardized by the IETF are
      always used with a PA Message Vendor ID of the value zero (0) in
      this field.  The PA Message Vendor ID 0xffffff is reserved.  A
      Posture Broker Client or Posture Broker Server MUST NOT send
      messages in which the PA Message Vendor ID field has this reserved
      value (0xffffff).  If a Posture Broker Client or Posture Broker
      Server receives a message in which the PA Message Vendor ID has
      this reserved value (0xffffff), it 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,


Sahita et al.          Expires January 14, 2009               [Page 22]

Internet-Draft                  PB-TNC                        July 2008


      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.

   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.


Sahita et al.          Expires January 14, 2009               [Page 23]

Internet-Draft                  PB-TNC                        July 2008


   Posture Validator Identifier (16 bits)

      The Posture Validator Identifier field contains the identifier of
      the Posture Validator associated with this PA message.

      The Posture Broker Server MUST assign a unique Posture Validator
      Identifier value (but not 0xffff) to each Posture Validator
      involved in a message exchange and include this Posture Validator
      identifier in this field for any PA messages sent by that Posture
      Validator.  The Posture Validator Identifier value assigned to a
      Posture Validator by a Posture Broker Server MUST NOT change
      during the course of a PT session.  This identifier is used to
      identify a unique Posture Validator communicating with the Posture
      Broker Server endpoint during a NEA exchange, and is used by the
      Posture Collector to send attributes to a specific Posture
      Validator if required.

      When a Posture Broker Client sets the EXCL flag for a PA message,
      the Posture Broker Client MUST set the Posture Validator
      Identifier field to the identifier of the Posture Validator that
      should receive the PA message.  If the EXCL flag is not set, a
      Posture Broker Client MAY still set the Posture Validator
      Identifier value for PA messages that it sends to indicate that
      the PA message is intended as a response to a message sent by the
      Posture Validator associated with the specified Posture Validator
      Identifier.  If the Posture Broker 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.





Sahita et al.          Expires January 14, 2009               [Page 24]

Internet-Draft                  PB-TNC                        July 2008


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

   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.

    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)


Sahita et al.          Expires January 14, 2009               [Page 25]

Internet-Draft                  PB-TNC                        July 2008


      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.

   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.


Sahita et al.          Expires January 14, 2009               [Page 26]

Internet-Draft                  PB-TNC                        July 2008


   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)

      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.




Sahita et al.          Expires January 14, 2009               [Page 27]

Internet-Draft                  PB-TNC                        July 2008


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




Sahita et al.          Expires January 14, 2009               [Page 28]

Internet-Draft                  PB-TNC                        July 2008


      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.

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.



Sahita et al.          Expires January 14, 2009               [Page 29]

Internet-Draft                  PB-TNC                        July 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 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.

    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.




Sahita et al.          Expires January 14, 2009               [Page 30]

Internet-Draft                  PB-TNC                        July 2008


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



Sahita et al.          Expires January 14, 2009               [Page 31]

Internet-Draft                  PB-TNC                        July 2008


      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 has offset of
               offending PB-Batch-Type message.
   1           Invalid Parameter.  Error Parameters has offset where
               invalid value was found.
   2           Local Error.  Error Parameters are empty.
   3           Unsupported Mandatory Message.  Error Parameters has
               offset of offending PB-TNC Message

4.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 has the following structure for the IETF
   Standard PB-TNC Error Code 0.  The Offset field is the offset in
   octets from the start of the PB-TNC batch to the PB-Batch-Type
   message whose type was not recognized.  The FATAL flag MUST be set
   for this error code.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Offset                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Error Parameters field has the following structure for the IETF
   Standard PB-TNC Error Code 1.  The Offset field is the offset in



Sahita et al.          Expires January 14, 2009               [Page 32]

Internet-Draft                  PB-TNC                        July 2008


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



Sahita et al.          Expires January 14, 2009               [Page 33]

Internet-Draft                  PB-TNC                        July 2008


   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.

    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)




Sahita et al.          Expires January 14, 2009               [Page 34]

Internet-Draft                  PB-TNC                        July 2008


      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
   an access recommendation conveyed in a PB-Access-Recommendation
   message.  Therefore, a PB-Reason-String message SHOULD only be
   included in the same batch as a 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 network access was denied (if that was the access
   recommendation).  The manner in which a Posture Broker Client uses
   this field is up to the implementer and not specified here.  The
   Posture Broker Client MAY display the message to the user, log it,
   ignore it, or take any other action that is not inconsistent with the
   requirements of this specification.  Since the strings contained in
   this message are human-readable, the Posture Broker Server SHOULD
   adapt them to the Posture Broker Client's language preferences as
   expressed in any PB-Language-Preference message sent by the Posture
   Broker Client in this PB-TNC session.

   A Posture Broker Server MAY include more than one message of this
   type in any batch of any type.  However, it is suggested that this
   message be included in the same batch as a 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


Sahita et al.          Expires January 14, 2009               [Page 35]

Internet-Draft                  PB-TNC                        July 2008


   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 January 14, 2009               [Page 36]

Internet-Draft                  PB-TNC                        July 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
      access recommendation.  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.

5. Evaluation Against NEA Requirements

   This section evaluates the PB-TNC protocol against the requirements
   defined in the NEA Requirements document.  Each subsection considers


Sahita et al.          Expires January 14, 2009               [Page 37]

Internet-Draft                  PB-TNC                        July 2008


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


Sahita et al.          Expires January 14, 2009               [Page 38]

Internet-Draft                  PB-TNC                        July 2008


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


Sahita et al.          Expires January 14, 2009               [Page 39]

Internet-Draft                  PB-TNC                        July 2008


   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:

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




Sahita et al.          Expires January 14, 2009               [Page 40]

Internet-Draft                  PB-TNC                        July 2008


   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
   assessments) when faced with a very constrained network
   connection.





Sahita et al.          Expires January 14, 2009               [Page 41]

Internet-Draft                  PB-TNC                        July 2008


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
   and Posture Validators to be dynamically registered and deregistered,
   ensuring that each one receives the proper data.  PB-TNC also



Sahita et al.          Expires January 14, 2009               [Page 42]

Internet-Draft                  PB-TNC                        July 2008


   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.

5.17. Evaluation Against Requirement PB-6

   Requirement PB-6 says:



Sahita et al.          Expires January 14, 2009               [Page 43]

Internet-Draft                  PB-TNC                        July 2008


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


Sahita et al.          Expires January 14, 2009               [Page 44]

Internet-Draft                  PB-TNC                        July 2008


   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
   to compromise of a AAA server).  Communications between the trusted
   parties must also be secured.  For example, if the Posture Broker
   Server and the Posture Transport Server are separate components,
   their communications must be secured.


Sahita et al.          Expires January 14, 2009               [Page 45]

Internet-Draft                  PB-TNC                        July 2008


   Since the NEA Client may be a mobile device with little physical
   security (such as a laptop computer or even a public telephone), it
   should generally be assumed that some proportion of Access NEA
   Clients will be compromised and therefore hostile.  The NEA Server
   should be designed to be robust against hostile NEA Clients.  Once a
   compromised NEA Client is detected, it can be treated in a manner
   equivalent to an untrusted party and should pose no greater threat
   than any other untrusted party.

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

7. IANA Considerations

   Four new IANA registries are defined by this specification: IETF
   Standard PB-TNC Message Types, IETF Standard PA Subtypes, IETF
   Standard PB-TNC Remediation Parameters Types, and IETF Standard PB-
   TNC Error Codes.  This section explains how these registries work.

   First, it is important to note that in all four of these cases the
   IETF standard values listed in the IANA registry are only a small
   part of the possible values.  Whenever a PB-TNC Message Type appears
   on a network, it is always accompanied by an SMI Private Enterprise
   Number (PEN), also known as a vendor ID.  If this vendor ID is zero,
   the accompanying PB-TNC Message Type is an IETF standard value listed
   in the IANA registry for PB-TNC Message Types and its meaning is
   defined in the RFC listed for that PB-TNC Message Type in that
   registry.  If the vendor ID is not zero, the meaning of the PB-TNC
   Message Type has a vendor-specific meaning defined by the vendor
   identified by the vendor ID (as listed in the IANA registry for SMI
   PENs).


Sahita et al.          Expires January 14, 2009               [Page 46]

Internet-Draft                  PB-TNC                        July 2008


   This delegation of namespace is analogous to the technique used for
   OIDs.  It can result in interoperability problems if vendors require
   support for particular vendor-specific values.  However, such
   behavior is explicitly prohibited by this specification, which
   dictates that "Posture Broker Clients and Posture Broker Servers MUST
   NOT require support for particular vendor-specific PB-TNC message
   types and MUST interoperate with other parties despite any
   differences in the set of vendor-specific PB-TNC message types
   supported (although they MAY permit administrators to configure them
   to require support for specific PB-TNC message types)." Similar
   requirements are included for PA Subtypes, Remediation Parameters
   Types, and PB-TNC Error Codes.

   The following subsections provide guidance to the IANA in creating
   and managing the four new IANA registries defined by this
   specification.

7.1. Registry for IETF Standard PB-TNC Message Types

   The name for this registry is "IETF Standard PB-TNC Message Types".
   Each entry in this registry should include a human-readable name, a
   decimal integer value between 0 and 2^32-2, and a reference to an RFC
   where the contents of this message type are defined.  This RFC must
   define the meaning of this PB-TNC message type and the format and
   semantics of the PB-TNC Message Value field for PB-TNC messages that
   include the designated numeric value in the PB-TNC Message Type field
   and the value 0 in the PB-TNC Vendor ID field.

   Entries to this registry may only be added by IETF Consensus, as
   defined in RFC 2434 [5].  That is, they can only be added in an RFC
   approved by the IESG.

   The following entries for this registry are defined in this document.
   Once this document becomes an RFC, they should become the initial
   entries in the registry for IETF Standard PB-TNC Message Types.














Sahita et al.          Expires January 14, 2009               [Page 47]

Internet-Draft                  PB-TNC                        July 2008


   Integer Value  Name                      Defining RFC
   -------------  ----                      ------------
   0              PB-Experimental           RFC # Assigned to this I-D
   1              PB-Batch-Type             RFC # Assigned to this I-D
   2              PB-PA                     RFC # Assigned to this I-D
   3              PB-Access-Recommendation  RFC # Assigned to this I-D
   4              PB-Remediation-Parameters RFC # Assigned to this I-D
   5              PB-Error                  RFC # Assigned to this I-D
   6              PB-Language-Preference    RFC # Assigned to this I-D
   7              PB-Reason-String          RFC # Assigned to this I-D

7.2. Registry for IETF Standard PA Subtypes

   The name for this registry is "IETF Standard PA Subtypes".  Each
   entry in this registry should include a human-readable name, a
   decimal integer value between 0 and 2^32-2, and a reference to an RFC
   where the contents of this PA subtype are defined.  This RFC must
   define the meaning of this PA subtype and the format and semantics of
   the PA Message Body field for PB-TNC messages that have a PB-TNC
   Vendor ID of 0, a PB-TNC Message Type of PB-PA, the designated
   numeric value in the PA Subtype field, and the value 0 in the PA
   Message Vendor ID field.

   Entries to this registry may only be added by IETF Consensus, as
   defined in RFC 2434.  That is, they can only be added in an RFC
   approved by the IESG.

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

7.3. Registry for IETF Standard PB-TNC Remediation Parameters Types

   The name for this registry is "IETF Standard PB-TNC Remediation
   Parameters Types".  Each entry in this registry should include a
   human-readable name, a decimal integer value between 0 and 2^32-1,
   and a reference to an RFC where the contents of this remediation
   parameters type are defined.  This RFC must define the meaning of
   this remediation parameters type value and the format and semantics
   of the Remediation Parameters field for PB-TNC messages that have a
   PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Remediation-
   Parameters, the designated numeric value in the Remediation
   Parameters Type field, and the value 0 in the Remediation Parameters
   Vendor ID field.





Sahita et al.          Expires January 14, 2009               [Page 48]

Internet-Draft                  PB-TNC                        July 2008


   Entries to this registry may only be added by IETF Consensus, as
   defined in RFC 2434.  That is, they can only be added in an RFC
   approved by the IESG.

   The following entries for this registry are defined in this document.
   Once this document becomes an RFC, they should become the initial
   entries in the registry for IETF Standard PB-TNC Remediation
   Parameters Types.

   Integer Value  Name                      Defining RFC
   -------------  ----                      ------------
   1              Remediation-URI           RFC # Assigned to this I-D
   2              Remediation-String        RFC # Assigned to this I-D

7.4. Registry for IETF Standard PB-TNC Error Codes

   The name for this registry is "IETF Standard PB-TNC Error Codes".
   Each entry in this registry should include a human-readable name, a
   decimal integer value between 0 and 2^16-1, and a reference to an RFC
   where this error code is defined.  This RFC must define the meaning
   of this error code and the format and semantics of the Error
   Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of
   0, a PB-TNC Message Type of PB-Error, the designated numeric value in
   the Error Code field, and the value 0 in the Error Code Vendor ID
   field.

   Entries to this registry may only be added by IETF Consensus, as
   defined in RFC 2434.  That is, they can only be added in an RFC
   approved by the IESG.

   The following entries for this registry are defined in this document.
   Once this document becomes an RFC, they should become the initial
   entries in the registry for IETF Standard PB-TNC Error Codes.

   Integer Value  Name                      Defining RFC
   -------------  ----                      ------------
   0              Unexpected Batch Type     RFC # Assigned to this I-D
   1              Invalid Parameter         RFC # Assigned to this I-D
   2              Local Error               RFC # Assigned to this I-D
   3          Unsupported Mandatory Message RFC # Assigned to this I-D

8. Acknowledgments

   The authors of this draft would like to acknowledge the following
   people who have contributed to or provided substantial input on the
   preparation of this document or predecessors to it: Bernard Aboba,
   Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris


Sahita et al.          Expires January 14, 2009               [Page 49]

Internet-Draft                  PB-TNC                        July 2008


   Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen,
   Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles
   Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim,
   Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan
   Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin,
   Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod
   Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn,
   Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean
   Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad,
   Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali,
   Guha Prasad Venataraman, John Vollbrecht, Jun Wang, Han Yin.

   This document was prepared using 2-Word-v2.0.template.dot.




































Sahita et al.          Expires January 14, 2009               [Page 50]

Internet-Draft                  PB-TNC                        July 2008


9. References

9.1. Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", RFC 3986, January
         2005.

   [3]   Phillips, A. and M. Davis, "Tags for the Identification of
         Languages", RFC 4646, September 2006.

   [4]   Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.

   [5]   Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
         Considerations Section in RFCs", RFC 2434, October 1998.

9.2. Informative References

   [6]   Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV
         Binding", Trusted Computing Group, February 2008.

   [7]   Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
         Tardo, "Network Endpoint Assessment (NEA): Overview and
         Requirements", RFC 5209, June 2008.

   [8]   Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
         Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
         3748, June 2004.

   [9]   Sangster, P., "PA-TNC: A Posture Attribute Protocol (PA)
         Compatible with TNC", draft-ietf-nea-pa-tnc-01.txt, July 2008.















Sahita et al.          Expires January 14, 2009               [Page 51]

Internet-Draft                  PB-TNC                        July 2008


Appendix A: Use Cases



A.1. Initial Client triggered assessment

   This scenario involves the assessment of an endpoint initiated during
   network join. The assessment is triggered by the Posture Broker
   Client (PBC) and involves collection of patch information from both
   Standard Operating System (OS) Posture Collector and vendor-specific
   Patch Posture Collector (PC). The assessment by both the vendor-
   specific Patch Posture Validator (PV) and Standard OS Posture
   Validator result in a compliant assessment decision which results in
   a compliant System Assessment Decision to be returned by the Posture
   Broker Server (PBS).

   +--------+ +-------+ +---------+ +--------+ +-------++--------+

   | Vndr. X| |  Std. | |   Std.  | |  Std.  | | Std.  || Vndr. X|

   |Patch PC| | OS PC | |   PBC   | |  PBS   | | OS PV ||Patch PV|

   +----+---+ +---+---+ +-----+---+ +---+----+ +---+----++---+---+

      |         |   N/W Join|         |          |         |

      |         |     ----->|         |          |         |

      |         | Req Post. |         |          |         |

      |         +<----------+         |          |         |

      |         | Req Post. |         |          |         |

      +<--------------------|         |          |         |

      |Vndr X Patch Posture |         |          |         |

      |-------------------->|         |          |         |

      |         |OS Posture |         |          |         |

      |         |---------->|         |          |         |

      |         |           | Posture |          |         |

      |         |           | Report  |          |         |


Sahita et al.          Expires January 14, 2009               [Page 52]

Internet-Draft                  PB-TNC                        July 2008


      |         |           +-------->|          |         |

      |         |           |         |  Verify  |         |

      |         |           |         |  Posture |         |

      |         |           |         |--------->          |

      |         |           |         |          | Verify  |

      |         |           |         |          | Posture |

      |         |           |         |------------------->|

      |         |           |         | OS Reslt |         |

      |         |           |         |<---------|         |

      |         |           |         | VndrX Patch Result |

      |         |           | Assess  |<-------------------|

      |         |           | Result  |                    |



      |         |           <---------|          |         |

      |         | OS PRslt  |         |          |         |

      |         |<----------|         |          |         |

      | VndrX Patch PResult |         |          |         |

      |<--------------------|         |          |         |



A.1.1. Message Contents

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




Sahita et al.          Expires January 14, 2009               [Page 53]

Internet-Draft                  PB-TNC                        July 2008


A.1.1.1. N/W Join

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

A.1.1.2. Request Posture (Req Post.)

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

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

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

A.1.1.4. OS Posture

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

A.1.1.5. Posture Report

   This flow contains the PB message containing the PA messages from the
   Patch and OS Posture Collectors:



   PB Envelope {

    HDR {PB Length}

     PB Message 1 {

       Vendor-id=0

       Type =1 (Batch)

       Length

       Value = {

          Batch Type=CDATA



Sahita et al.          Expires January 14, 2009               [Page 54]

Internet-Draft                  PB-TNC                        July 2008


       }

     }

     PB Message 2 {

       Vendor-id=0

       Type =2 (PB-PA)

       Length

       Value = {

          PA-Msg-vendor-id=0 (Standard)

          PA-subtype=1 (OS)

          OS Posture PA Message

       }

     }

     PB Message 3 {

       Vendor-id=0

       Type =2 (PB-PA)

       Length

       Value = {

          PA-Msg-vendor-id=1 (Vendor X)

          PA-subtype=1 (Vendor X PA sub-type for patch management)

          Vendor X Patch Posture PA Message

        }

      }

   }




Sahita et al.          Expires January 14, 2009               [Page 55]

Internet-Draft                  PB-TNC                        July 2008


A.1.1.6. Verify Posture

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



A.1.1.7. OS Posture Result (OS Reslt)

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



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



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

A.1.1.9. Assessment Result (Assess Result)

   This flow contains the PB message containing the system assessment
   result computed by the Posture Broker Server and the PA messages from
   the Patch and OS Posture Validators:



   PB Envelope {

    HDR {PB Length}

     PB Message 1 {

       Vendor-id=0,

       Type =1 (Batch)

       Length

       Value = {



Sahita et al.          Expires January 14, 2009               [Page 56]

Internet-Draft                  PB-TNC                        July 2008


          Batch Type=RESULT

       }

     }

     PB Message 2 {

       Vendor-id=0,

       Type =3 (Access-Recommendation)

       Length

       Value = {

         System-Evaluation-Result=0 (Compliant)

       }

     }

     PB Message 3 {

       Vendor-id=0,

       Type=2 (PB-PA)

       Length

       Value = {

          PA-Msg-vendor-id=0

          PA-subtype=1 (OS)

          OS Posture Result PA Message

        }

      }

     PB Message 4 {

       Vendor-id=0,

       Type=2 (PB-PA)


Sahita et al.          Expires January 14, 2009               [Page 57]

Internet-Draft                  PB-TNC                        July 2008


       Length

       Value = {

          PA-Msg-vendor-id=1 (Vendor X)

          PA-subtype=1 (Vendor X PA sub-type for patch management)

          Vendor X Patch Posture Result PA Message

        }

      }

   }

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

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





      A.2. Server initiated Assessment with Remediation



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



   +--------+  +-------+ +---------+ +--------+ +-------+ +--------+

   | Vndr Y |  | Vndr X| |   Std.  | |  Std.  | | Vndr X| | Vndr Y |


Sahita et al.          Expires January 14, 2009               [Page 58]

Internet-Draft                  PB-TNC                        July 2008


   |  AV PC |  | AV PC | |   PBC   | |  PBS   | | AV PV | |  AV PV |

   +----+---+  +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+

        |          |           | N/W Join|          |          |

        |          |           |   ----->|          |          |

        |          |           |         |  Create  |          |

        |          |           |         |Post. Req |          |

        |          |           |         |--------->|          |

        |          |           |         |Create Posture Req   |

        |          |           |         |----------+--------->|

        |          |           |         |Vndr Y AV Posture Req|

        |          |           |         |<---------+----------|

        |          |           |         |Vndr X AV |          |

        |          |           |         |Post. Req |          |

        |          |           | Posture |<---------|          |

        |          |           | Request |          |          |

        |          | Vndr X AV |<--------|          |          |

        |          | Post. Req |         |          |          |

        |          |<----------|         |          |          |

        |      Vndr Y AV       |         |          |          |

        |     Posture Req      |         |          |          |

        +<---------+-----------|         |          |          |

        |  Vndr Y AV Posture   |         |          |          |

        +----------+---------->|         |          |          |

        |          | Vndr X AV |         |          |          |


Sahita et al.          Expires January 14, 2009               [Page 59]

Internet-Draft                  PB-TNC                        July 2008


        |          |  Posture  |         |          |          |

        |          |---------->| Posture |          |          |

        |          |           |Response |          |          |

        |          |           |-------->|          |          |

        |          |           |         |  Verify  |          |

        |          |           |         |  Posture |          |

        |          |           |         |--------->|          |

        |          |           |         |     Verify Posture  |

        |          |           |         |----------+--------->|

        |          |           |         |Vndr Y Posture Result|

        |          |           |         |<---------+----------|

        |          |           |         |Vndr X AV |          |

        |          |           |         |Post Reslt|          |

        |          |           |  Assess |<---------|          |

        |          |           |  Result |          |          |

        |          | Vndr X AV |<--------|          |          |

        |          |Post Reslt |<--------|          |          |

        |          |<----------|         |          |          |

        | Vndr Y AV Post Reslt |         |          |          |

        +<---------+-----------|         |          |          |

        |          |           |         |          |          |








Sahita et al.          Expires January 14, 2009               [Page 60]

Internet-Draft                  PB-TNC                        July 2008




A.2.1. Message Contents

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

A.2.1.1. N/W Join

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

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

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



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

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



A.2.1.4. Vendor Y Anti-Virus Posture Request

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



A.2.1.5. Posture Request

   This flow contains the PB message containing the PA messages from the
   Vendor X and Vendor Y Anti-Virus Posture Validators:




Sahita et al.          Expires January 14, 2009               [Page 61]

Internet-Draft                  PB-TNC                        July 2008


   PB Envelope {

    HDR {PB Length}

     PB Message 1 {

       Vendor-id=0

       Type =1 (Batch)

       Length

       Value = {

          Batch Type=SDATA

       }

     }

     PB Message 2 {

       Vendor-id=0

       Type =2 (PB-PA)

       Length

       Value = {

          PA-Msg-vendor-id=1 (Vendor X)

          PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)

          Vendor X AV Posture Request PA Message

       }

     }

     PB Message 3 {

       Vendor-id=0

       Type =2 (PB-PA)

       Length


Sahita et al.          Expires January 14, 2009               [Page 62]

Internet-Draft                  PB-TNC                        July 2008


       Value = {

          PA-Msg-vendor-id=2 (Vendor Y)

          PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)

          Vendor Y AV Posture Request PA Message

        }

      }

   }



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

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



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

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



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

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









Sahita et al.          Expires January 14, 2009               [Page 63]

Internet-Draft                  PB-TNC                        July 2008


A.2.1.9. Posture Response

   This flow contains the PB message containing the PA messages from the
   Vendor X and Vendor Y Anti-Virus Posture Collectors:



   PB Envelope {

    HDR {PB Length}

     PB Message 1 {

       Vendor-id=0

       Type =1 (Batch)

       Length

       Value = {

          Batch Type=CDATA

       }

     }

     PB Message 2 {

       Vendor-id=0

       Type =2 (PB-PA)

       Length

       Value = {

           PA-Msg-vendor-id=1 (Vendor X)

           PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)

           Vendor X AV Posture PA Message

       }

     }



Sahita et al.          Expires January 14, 2009               [Page 64]

Internet-Draft                  PB-TNC                        July 2008


     PB Message 3 {

       Vendor-id=0

       Type =2 (PB-PA)

       Length

       Value = {

           PA-Msg-vendor-id=2 (Vendor Y)

           PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)

           Vendor Y AV Posture PA Message

        }

      }

   }



A.2.1.10. Verify Posture

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



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

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



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

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



Sahita et al.          Expires January 14, 2009               [Page 65]

Internet-Draft                  PB-TNC                        July 2008






A.2.1.13. Assessment Result (Assess Result)

   This flow contains the PB message containing the system assessment
   result computed by the Posture Broker Server and the PA messages from
   the Patch and OS Posture Validators:



   PB Envelope {

    HDR {PB Length}

     PB Message 1 {

       Vendor-id=0,

       Type =1 (Batch)

       Length

       Value = {

          Batch Type=RESULT

       }

     }

     PB Message 2 {

       Vendor-id=0,

       Type=3 (Access-Recommendation)

       Length

       Value = {

         System-Evaluation-Result=1 (Non-Compliant)

       }

     }


Sahita et al.          Expires January 14, 2009               [Page 66]

Internet-Draft                  PB-TNC                        July 2008


     PB Message 3 {

       Vendor-id=0,

       Type=4 (Remediation-Parameters)

       Length

       Value = {

        Remidiation-Param-Vendor-ID=0

        Remidiation-Param-Type=1 (Remediation-URI)

        Remidiation-Param="http://xyz"

        }

      }

    PB Message 4 {

       Vendor-id=0,

       Type=4 (Remediation-Parameters)

       Length

       Value = {

        Remidiation-Param-Vendor-ID=0

        Remidiation-Param-Type=2 (Remediation-String)

        Remidiation-Param="Try Step1, Step2,..."

        }

      }

     PB Message 5 {

       Vendor-id=0,

       Type=2 (PB-PA)

       Length


Sahita et al.          Expires January 14, 2009               [Page 67]

Internet-Draft                  PB-TNC                        July 2008


       Value = {

           PA-Msg-vendor-id=1 (Vendor X)

           PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)

           Vendor X AV Posture Result PA Message

        }

      }

     PB Message 6 {

       Vendor-id=0,

       Type=2 (PB-PA)

       Length

       Value = {

           PA-Msg-vendor-id=2 (Vendor Y)

           PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)

           Vendor Y AV Posture Result PA Message

        }

      }

   }



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

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






Sahita et al.          Expires January 14, 2009               [Page 68]

Internet-Draft                  PB-TNC                        July 2008


      A.3. Client triggered re-assessment



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



   +--------+  +-------+ +---------+ +--------+ +-------+ +--------+

   |Vndr X  |  |Vndr Y | |Standard | |Standard| |Standrd| |Standard|

   |VPNClnt |  |VPNClnt| | VPN PC  | |  PBC   | |  PBS  | | VPN PV |

   +----+---+  +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+

   Enble|          |           |         |          |          |

   ---->|          |           |         |          |          |

        |  VPN Status Change   |         |          |          |

        |--------------------->| Posture |          |          |

        |          |           | Change  |          |          |

        |          |           |-------->|          |          |

        |          |           |Req. Post|          |          |

        |          |           |<--------|          |          |


Sahita et al.          Expires January 14, 2009               [Page 69]

Internet-Draft                  PB-TNC                        July 2008


        |          |Ins/Rq Info|         |          |          |

        |          |<----------|         |          |          |

        | Inspect/Request Info |         |          |          |

        |<---------+-----------|VPN Post.|          |          |

        |          |           |-------->|          |          |

        |          |           |         | Posture  |          |

        |          |           |         |  Report  |          |

        |          |           |         |--------->|          |

        |          |           |         |          |Vrfy Post.|

        |          |           |         |          |--------->|

        |          |           |         |          |VPN PRslt |

        |          |           |         |  Assess  |<---------|

        |          |           |         |  Result  |          |

        |          |           |         |<---------|          |

        |          |           |VPN PRslt|          |          |

        |          |           |<--------|          |          |



A.3.1. Message Contents

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

A.3.1.1. Enable VPN Client (Enble)

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


Sahita et al.          Expires January 14, 2009               [Page 70]

Internet-Draft                  PB-TNC                        July 2008


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

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

A.3.1.3. Notify Posture Change (Posture Change)

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

A.3.1.4. Request Posture (Req. Post)

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

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

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



A.3.1.6. VPN Posture (VPN Post.)

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



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

   This flow contains the PB message containing the PA message from the
   VPN Posture Collector:



   PB Envelope {

    HDR {PB Length}

     PB Message 1 {


Sahita et al.          Expires January 14, 2009               [Page 71]

Internet-Draft                  PB-TNC                        July 2008


       Vendor-id=0

       Type =1 (Batch)

       Length

       Value = {

          Batch Type=CRETRY

       }

     }

     PB Message 2 {

       Vendor-id=0

       Type =2 (PB-PA)

       Length

       Value = {

          PA-Msg-vendor-id=0

          PA-subtype=7 (VPN)

          VPN Posture PA Message

       }

     }
















Sahita et al.          Expires January 14, 2009               [Page 72]

Internet-Draft                  PB-TNC                        July 2008


A.3.1.8. Verify Posture (Vrfy Post.)

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



A.3.1.9. VPN Posture Result (VPN PRslt)

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



A.3.1.10. Assessment Result (Assess Result)

   This flow contains the PB message containing the system assessment
   result computed by the Posture Broker Server and the PA messages from
   the VPN Posture Validator:



   PB Envelope {

    HDR {PB Length}

     PB Message 1 {

       Vendor-id=0,

       Type =1 (Batch)

       Length

       Value = {

          Batch Type=RESULT

       }

     }

     PB Message 2 {



Sahita et al.          Expires January 14, 2009               [Page 73]

Internet-Draft                  PB-TNC                        July 2008


       Vendor-id=0,

       Type =3 (Access-Recommendation)

       Length

       Value = {

         System-Evaluation-Result=1 (Non-Compliant)

       }

     }

     PB Message 3 {

       Vendor-id=0,

       Type=2 (PB-PA)

       Length

       Value = {

          PA-Msg-vendor-id=0

          PA-subtype=7 (VPN)

          VPN Posture Result PA Message

        }

      }



  A.3.1.11. Posture Result (VPN PRslt)

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








Sahita et al.          Expires January 14, 2009               [Page 74]

Internet-Draft                  PB-TNC                        July 2008




Author's Addresses

   Ravi Sahita
   Intel Corporation
   2200 Mission College Blvd.
   Santa Clara, CA 95054 USA
   email: ravi.sahita@intel.com


   Steve Hanna
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089 USA
   email: shanna@juniper.net

   Ryan Hurst
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052 USA
   email: Ryan.Hurst@microsoft.com

   Kaushik Narayan
   Cisco Systems Inc.
   10 West Tasman Drive
   San Jose, CA 95134 USA
   email: kaushik@cisco.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.



Sahita et al.          Expires January 14, 2009               [Page 75]

Internet-Draft                  PB-TNC                        July 2008


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





















Sahita et al.          Expires January 14, 2009               [Page 76]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/