Network Working Group R. Sahita Internet Draft Intel Intended status: Proposed Standard S. Hanna Expires: September 2009 Juniper R. Hurst Microsoft K. Narayan Cisco Systems March 6, 2009 PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC draft-ietf-nea-pb-tnc-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 August 6, 2009. Sahita et al. Expires September 6, 2009 [Page 1] Internet-Draft PB-TNC March 2009 Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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. Table of Contents 1. Introduction......................................... 4 1.1. Relationship to Trusted Network Connect.............. 5 1.2. Prerequisites.................................... 5 1.3. Message Diagram Conventions........................ 5 1.4. Terminology..................................... 6 1.5. Conventions used in this document................... 6 2. PB-TNC Design Considerations ........................... 6 2.1. Message Addressing................................ 6 2.1.1. Message Types................................ 6 2.1.2. Dynamic Identifiers........................... 7 2.2. Vendor IDs...................................... 8 2.3. Efficiency...................................... 8 3. PB-TNC Protocol Description............................ 8 3.1. Protocol Overview ................................ 8 3.2. PB-TNC State Machine............................. 10 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.................................. 16 4.3. IETF Standard PB-TNC Message Types ................. 19 4.4. PB-Experimental................................. 19 4.5. PB-PA......................................... 20 4.6. PB-Assessment-Result............................. 24 4.7. PB-Access-Recommendation.......................... 26 4.8. PB-Remediation-Parameters......................... 27 4.8.1. IETF Standard PB-TNC Remediation Parameters Types. 30 Sahita et al. Expires September 6, 2009 [Page 2] Internet-Draft PB-TNC March 2009 4.9. PB-Error....................................... 31 4.9.1. IETF Standard PB-TNC Error Codes............... 33 4.9.2. Error Parameters Structures for IETF Standard PB-TNC Error Codes...................................... 34 4.10. PB-Language-Preference .......................... 34 4.11. PB-Reason-String ............................... 36 5. Security Considerations............................... 39 5.1. Threat Model ................................... 39 5.2. Countermeasures................................. 40 6. IANA Considerations.................................. 41 6.1. Designated Expert Guidelines ...................... 42 6.2. Registry for PB-TNC Message Types.................. 43 6.3. Registry for PA Subtypes.......................... 43 6.4. Registry for PB-TNC Remediation Parameters Types...... 44 6.5. Registry for PB-TNC Error Codes.................... 44 7. Acknowledgments..................................... 45 8. References......................................... 46 8.1. Normative References............................. 46 8.2. Informative References........................... 46 Appendix A: Use Cases................................... 47 A.1. Initial Client triggered assessment................. 47 A.1.1. Message Contents............................ 48 A.1.1.1. N/W Join............................... 49 A.1.1.2. Request Posture (Req Post.)............... 49 A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture). 49 A.1.1.4. OS Posture............................. 49 A.1.1.5. Posture Report.......................... 49 A.1.1.6. Verify Posture.......................... 50 A.1.1.7. OS Posture Result (OS Reslt).............. 51 A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result) ............................................. 51 A.1.1.9. Assessment Result (Assess Result).......... 51 A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)53 A.2. Server initiated Assessment with Remediation......... 53 A.2.1. Message Contents............................ 55 A.2.1.1. N/W Join............................... 55 A.2.1.2. Create Posture Request (Create Posture Req.). 56 A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV Post. Req).................................... 56 A.2.1.4. Vendor Y Anti-Virus Posture Request ........ 56 A.2.1.5. Posture Request......................... 56 A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr Y AV Posture Req)............................... 57 A.2.1.7. Vendor Y Anti-Virus Posture (Vndr Y AV Posture)58 A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture)58 A.2.1.9. Posture Response........................ 58 A.2.1.10. Verify Posture......................... 59 Sahita et al. Expires September 6, 2009 [Page 3] Internet-Draft PB-TNC March 2009 A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post Result)....................................... 60 A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post Result)....................................... 60 A.2.1.13. Assessment Result (Assess Result)......... 60 A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post Reslt) ................................... 62 A.3. Client triggered re-assessment..................... 63 A.3.1. Message Contents............................ 65 A.3.1.1. Enable VPN Client (Enble)................. 65 A.3.1.2. Notify Status Change (VPN Status Change).... 65 A.3.1.3. Notify Posture Change (Posture Change)...... 65 A.3.1.4. Request Posture (Req. Post)............... 65 A.3.1.5. Inspect/Request Information (Ins/Rq Info) ... 65 A.3.1.6. Vendor X VPN Posture (VPNX Post.).......... 66 A.3.1.7. Vendor Y VPN Posture (VPNY Post.).......... 66 A.3.1.8. Posture Report (Post. Rpt.)............... 66 A.3.1.9. Verify Posture (Vrfy Post.)............... 68 A.3.1.10. VPN Posture Result (VPN PRslt)............ 68 A.3.1.11. Assessment Result (Assess Result)......... 68 A.3.1.12. Posture Result (VPN PRslt)............... 69 APPENDIX B: Evaluation Against NEA Requirements............. 70 B.1. Evaluation Against Requirement C-1 ................. 70 B.2. Evaluation Against Requirement C-2 ................. 70 B.3. Evaluation Against Requirement C-3 ................. 70 B.4. Evaluation Against Requirement C-4 ................. 71 B.5. Evaluation Against Requirement C-5 ................. 71 B.6. Evaluation Against Requirement C-6 ................. 71 B.7. Evaluation Against Requirement C-7 ................. 72 B.8. Evaluation Against Requirement C-8 ................. 72 B.9. Evaluation Against Requirement C-9 ................. 72 B.10. Evaluation Against Requirement C-10................ 73 B.11. Evaluation Against Requirement C-11................ 73 B.12. Evaluation Against Requirement PB-1................ 74 B.13. Evaluation Against Requirement PB-2................ 74 B.14. Evaluation Against Requirement PB-3................ 74 B.15. Evaluation Against Requirement PB-4................ 75 B.16. Evaluation Against Requirement PB-5................ 75 B.17. Evaluation Against Requirement PB-6................ 75 Authors' Addresses..................................... 76 Intellectual Property Statement .......................... 76 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]. Sahita et al. Expires September 6, 2009 [Page 4] Internet-Draft PB-TNC March 2009 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 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. Sahita et al. Expires September 6, 2009 [Page 5] Internet-Draft PB-TNC March 2009 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]. 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 Sahita et al. Expires September 6, 2009 [Page 6] Internet-Draft PB-TNC March 2009 Vendor ID field and a PA Subtype value assigned by that vendor in the PA Subtype field. This allows each vendor to define its own set of PA Subtype values without worrying about collisions with other vendors or with standard values. The PA message type is somewhat analogous to a MIME type in that it indicates the type of the PA message. Posture Collectors and Posture Validators can use local APIs to indicate to the Posture Broker Client and Posture Broker Server which PA message types they are interested in receiving. For instance, a Posture Validator that evaluates anti-virus posture might indicate that it would like to receive PA messages with a PA Message Vendor ID of 0 and a PA Subtype that matches the IETF Standard PA Subtype for Anti-Virus. It might also indicate interest in some vendor-specific PA message types to get additional vendor-specific information on anti-virus posture. This type-based subscription model allows great flexibility in design and implementation. One Posture Validator may be responsible for evaluating several functions: anti-virus and host-based firewall, for instance. Posture Collectors do not need to know which Posture Validators are installed on the Posture Broker Server or what they 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. Sahita et al. Expires September 6, 2009 [Page 7] Internet-Draft PB-TNC March 2009 When a Posture Broker Server loads a Posture Validator, it assigns it a Posture Validator ID. Any PA messages sent by a Posture Validator include that Posture Validator's Posture Validator ID in the Posture Validator ID field of the PB-PA message. A Posture Collector that receives such a message can send a message in response and request exclusive delivery to the Posture Validator identified by that Posture Validator ID. Dynamic identifiers avoid problems caused by the multicast nature of message types. Multiple Posture Collectors or Posture Validators may be registered for the same message type and this can cause confusion if they all respond and the software designer did not consider that possibility. The dynamic identifier system allows more directed responses but it does not work until at least one message has been received (so that the dynamic identifiers can be received). Static identifiers were considered as another alternative but rejected because they result in a brittle system that only works with a particular set of Posture Collectors and Posture Validators and causes problems if two Posture Collectors or Posture Validators with the same static identifier are installed. 2.2. Vendor IDs In several places, PB-TNC needs to define a set of standard values but also allow vendor-specific extensions. In each of these places (PB-TNC Message Types, PA Subtypes, Remediation Parameters Types and Error Codes), the solution chosen was to preface the values with a vendor ID. If a vendor ID is 0, the values in the next field are registered in an IANA registry and their meanings defined in an RFC. If a vendor ID is non-zero, the values in the next field are vendor- specific and defined by the vendor whose SMI Private Enterprise Number matches the vendor ID. Vendor-specific messages that are not understood by the recipient are ignored and skipped unless they have the NOSKIP flag set, in which case an error code is returned. 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 Sahita et al. Expires September 6, 2009 [Page 8] Internet-Draft PB-TNC March 2009 messages and manages the NEA session. It runs over a PT transport protocol. In order to work well over half-duplex PT protocols (such as those based on EAP [8]), PB-TNC supports half-duplex protocol operation. In this mode, the Posture Broker Client and Posture Broker Server take turns sending batches of messages to each other. While the half-duplex nature of PB-TNC could slow exchanges that require many round trips or bidirectional multimedia exchanges, this is not a problem in practice because endpoint assessments do not typically involve multimedia or a large number of round trips. The benefit of working over half-duplex transports outweighs any limitations imposed. PB-TNC also supports full-duplex protocol operation so that PB-TNC exchanges can be re-initialized immediately when needed (e.g. if the Posture Broker Server policy changes or if the Posture Broker Client detects a suspicious event). Each PB-TNC batch consists of a header followed by a sequence of PB- TNC messages. Each PB-TNC message has a Type-Length-Value (TLV) format with a few flags. The TLV format allows a recipient to skip messages that it does not understand. The TLV format also provides a standard way to mark messages as mandatory to ensure interoperability between a Posture Broker Client and a Posture Broker Server. This specification defines certain standard PB-TNC message types. It also permits vendors to define their own vendor-specific message types. One of the most important standard PB-TNC message types is PB-PA. A message with this type contains a PA message and various message routing information. A Posture Broker Client or Posture Broker Server that receives such a message does not interpret the PA message within. Instead, it delivers the PA message to the appropriate set of Posture Collectors or Posture Validators, as determined using the message routing information contained in the PB- PA message. A Posture Broker Server will often need to communicate with several Posture Broker Clients at once. The reverse may also be true, as when an endpoint has multiple network interfaces connected to different networks. Each connection between a Posture Broker Server and a Posture Broker Client is instantiated as a separate PB-TNC session. There may be several simultaneous sessions between a single Posture Broker Server and Posture Broker Client but this is unusual. Sahita et al. Expires September 6, 2009 [Page 9] Internet-Draft PB-TNC March 2009 3.2. PB-TNC State Machine Figure 1 illustrates the PB-TNC state machine, showing the set of states that a PB-TNC session can have and the possible transitions among these states. The following paragraphs describe this state machine in more detail. Receive CRETRY SRETRY or SRETRY +----------------+ +--+ | | v | v | +---------+ CRETRY +---------+ CDATA | Server |<---------| Decided | CLOSE +----------->| Working |--------->| |-------+ | +---------+ RESULT +---------+ | | ^ | | v | | | +---------------------->======= ======== | | CLOSE " End " " Init " CDATA| |SDATA ======= ======== | | ^ ^ | | | v | | | | SDATA +---------+ CLOSE | | | +-------->| Client |----------------------+ | | | Working | | | +---------+ | | | ^ | | +--+ | | Receive CRETRY | | CLOSE | +--------------------------------------------------+ Figure 1 PB-TNC State Machine In this diagram, states are indicated by rectangular boxes. The initial and terminal states have double outlines (with = and "). State transitions are indicated by unidirectional arrows marked with the cause of the transition. Many transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) are triggered by the transmission or reception of a PB-TNC batch of a particular type. The type of a PB-TNC batch is indicated by the contents of the Batch Type field in the PB-TNC Header for that batch. For brevity, this document says "a FOO batch" instead of "a PB-TNC batch whose Batch Type field contains FOO". Other transitions are triggered by closing the underlying PT connection (CLOSE) or by receiving a PB-TNC batch of a particular type (e.g. Receive CRETRY). Sahita et al. Expires September 6, 2009 [Page 10] Internet-Draft PB-TNC March 2009 A PB-TNC session starts in the Init state when the underlying transport protocol (PT) establishes a connection between a Posture Broker Client and a Posture Broker Server. If the Posture Broker Client initiated the underlying transport session, it starts by sending a CDATA batch to the Posture Broker Server, thus causing a transition to the Server Working state. If the Posture Broker Server initiated the transport session, it starts by sending a PB-TNC batch of type SDATA to the Posture Broker Client, thus causing a transition to the Client Working state. The Posture Broker Client and Posture Broker Server may now alternate sending CDATA and SDATA batches to each other. Only the Posture Broker Client can send a data batch when the session is in the Client Working state and only the Posture Broker Server can send a data batch when the session is in the Server Working state. The most common way to end an exchange is for the Posture Broker Server to send a RESULT batch. This causes a transition into the Decided state. This is not a terminal state. The PT session can remain open and another exchange can be initiated by having the Posture Broker Client send a CRETRY batch. This can be useful when the Posture Broker Client (or more likely a Posture Collector) discovers a suspicious condition on the endpoint, for example. If the underlying transport protocol (PT) supports full-duplex operation, the Posture Broker Server can also initiate another exchange from this state by sending a SRETRY batch. This can be useful when the policy changes on the server, for example. Whether an SRETRY or CRETRY message is sent or both, the next state is the Server Working State. From this state, the Posture Broker Server sends an SDATA batch and the new exchange begins. The state transitions marked Receive CRETRY and Receive CRETRY or SRETRY indicate that it is permissible to receive such messages in the indicated states, generally when the Posture Broker Client sent a CRETRY message at roughly the same time as the Posture Broker Server decided to send an SRETRY. In that case, a CRETRY or SRETRY message may be received while in the Server Working or Client Working state. These messages are redundant and therefore ignored, as indicated by the relevant transitions, which don't cause a state change. The only terminal state is the End state. This state is reached if the underlying PT connection closes. This can be caused by an action of the Posture Broker Client or Posture Broker Server or it can be caused by some external factor, such as pulling the network plug. 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 Sahita et al. Expires September 6, 2009 [Page 11] Internet-Draft PB-TNC March 2009 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. If a half-duplex transport is used, note that the Posture Broker Server cannot send a SRETRY batch when the session is in the Decided state because the Posture Broker Server sent the most recent batch (the RESULT batch) and this would violate the half-duplex nature of the transport protocol. Instead, a server that wishes to initiate a new exchange in the Decided state when a half-duplex transport is in use should close the PT connection and start a new PB-TNC session. This limitation does not exist when a full-duplex transport is used. The Posture Broker Server and Posture Broker Client MUST follow the state machine described in this section. 3.3. Layering on PT PB-TNC batches are carried over protocol bindings of the PT protocol, which provides the interaction between a Posture Transport Client and a Posture Transport Server. PB-TNC counts on PT to provide a secure transport. In particular, PT MUST support mutual authentication of the Posture Transport Client and the Posture Transport Server, confidentiality and integrity protection for PB-TNC batches, and protection against replay attacks. PB-TNC is unaware of the underlying transport protocols being used. PB-TNC operates directly on PT; no further layer of PB-TNC is expected. 3.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. Sahita et al. Expires September 6, 2009 [Page 12] Internet-Draft PB-TNC March 2009 Within the PT protocol, the PB-TNC header is packaged next, followed by two PB-PA messages that contain PA messages meant for the Posture Collectors and Posture Validators on the platform. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PT Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PB-TNC Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PB-PA Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PB-PA Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Example of PB-TNC message encapsulation This figure is conceptual, of course, and not an exact byte-for-byte replica. 4. PB-TNC Protocol Specification 4.1. PB-TNC Header Every PB-TNC batch MUST start with the following header. A PB-TNC batch MUST contain only one instance of this header followed by one or more PB-TNC messages. The PB-TNC messages are defined in subsequent sections of this specification. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|D|R| Reserved | B-Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Batch Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (4 bits) This field MUST be set to 2 when the batch conforms to this specification. Later versions of PB-TNC may define other values for this field. If a Posture Broker Client or Posture Broker Server receives a Version value that it does not support, it SHOULD respond with an Invalid Parameter error code. Directionality (D) (1 bit) When a Posture Broker Client is sending this message, the Directionality bit MUST be set to 0. When a Posture Broker Server Sahita et al. Expires September 6, 2009 [Page 13] Internet-Draft PB-TNC March 2009 is sending this message, the Directionality bit MUST be set to 1. This helps avoid any situation where two Posture Broker Clients or two Posture Broker Servers engage in a dialog. It also helps with debugging. Retry-Acknowledge (R) (1 bit) This bit MUST be set to 1 for the first message sent by a Posture Broker Client or Server after it has received and processed a SRETRY or CRETRY (see Batch Type field) message respectively. In all other cases, this bit MUST be set to 0. After a Posture Broker Client or Posture Broker Server sends a SRETRY or CRETRY message, it MUST ignore all messages received from the other party until it receives a message with the R bit set. This field helps avoid a situation in full-duplex transport mode where a Posture Broker Client or Posture Broker Server sends a retry message and then receives and processes a message that the other party had sent before receiving the retry message. Reserved (22 bits) This field is reserved. For this version of this specification, it MUST be set to 0 on transmission and ignored on reception. Future versions of this specification may allow senders to set some of these bits and recipients to interpret them. B-Type (Batch Type) (4 bits) This field is used to drive the state machine described in section 3.2. This field MUST have one of the values from the following table. If any other value is received, the recipient MUST send a Malformed Message error code in response. In addition, if the value received is not permitted for the current state, according to the state machine in section 3.2. , the recipient MUST send an Unexpected Batch Type error code in response. Number Name Definition ------ ---- ---------- 1 CDATA The Posture Broker Client may send a batch with this Batch Type to convey messages to the Posture Broker Server. A Posture Broker Server MUST NOT send this Batch Type. If a Posture Broker Client receives a batch with this Batch Type, it SHOULD ignore the batch and send a fatal Unexpected Batch Type error code in Sahita et al. Expires September 6, 2009 [Page 14] Internet-Draft PB-TNC March 2009 response. A CDATA batch may be empty (contain no messages) if the Posture Broker Client has nothing to send. 2 SDATA The Posture Broker Server may send a batch with this Batch Type to convey messages to the Posture Broker Client. A Posture Broker Client MUST NOT send this Batch Type. If a Posture Broker Server receives a batch with this Batch Type, it SHOULD ignore the batch and send a fatal Unexpected Batch Type error code in response. An SDATA batch may be empty (contain no messages) if the Posture Broker Server has nothing to send. 3 RESULT The Posture Broker Server may send a batch with this Batch Type to indicate that it has completed its evaluation. The batch SHOULD include a PB-Access-Recommendation message. 4 CRETRY The Posture Broker Client may send a batch with this Batch Type to indicate that it wishes to restart an exchange. A Posture Broker Server MUST NOT send this Batch Type. If a Posture Broker Client receives a batch with this Batch Type, it SHOULD ignore the batch and send a fatal Unexpected Batch Type error code in response. A CRETRY batch may be empty (contain no messages) if the Posture Broker Client has nothing else to send. 5 SRETRY The Posture Broker Server may send a batch with this Batch Type to indicate that it wishes to restart the exchange. A Posture Broker Client MUST NOT send this Batch Type. If a Posture Broker Server receives a batch with this Batch Type, it SHOULD ignore the batch and send a fatal Unexpected Batch Type error code in response. A SRETRY batch may be empty (contain no messages) if the Posture Broker Server has nothing else to send. Batch Length (32 bits) This length field contains the size of the full PB-TNC batch in octets. This length includes the PB-TNC header and all the PB-TNC messages in the batch. In other words, it includes the entire Sahita et al. Expires September 6, 2009 [Page 15] Internet-Draft PB-TNC March 2009 contents of the batch. This field MUST contain at least the value 8 for the fixed-length fields in this header. Any Posture Broker Client or Posture Broker Server that receives a PB-TNC message with a PB-TNC Message Length field whose value is less than 8 SHOULD send an Invalid Parameter error code in response. 4.2. PB-TNC Message All PB-TNC messages have the same overall structure, which is described in this section. Of course, the format and semantics of the PB-TNC Message Value field will vary, depending on the values of the PB-TNC Vendor ID and PB-TNC Message Type fields. 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 Sahita et al. Expires September 6, 2009 [Page 16] Internet-Draft PB-TNC March 2009 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 each vendor has 2^32-1 separate message types available for their use. Message types standardized by the IETF use zero (0) in this field. The Vendor ID 0xffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages in which the Vendor ID has this reserved value (0xffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PB-TNC Vendor ID has this reserved value (0xffffff), it SHOULD send an Invalid Parameter error code in the next batch that it sends. PB-TNC Message Type (32 bits) The PB-TNC Message Type field identifies the type of the PB-TNC message contained in the PB-TNC Message Value field. The PB-TNC message type 0xffffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages in which the PB-TNC Message Type field has this reserved value (0xffffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PB-TNC Message Type field has this reserved value (0xffffffff), it SHOULD send an Invalid Parameter error code in the next batch that it sends. Unless otherwise prohibited in the definition of a particular PB-TNC Message Type (e.g. PB-Language- Preference), a single PB-TNC batch may contain multiple messages with the same message type and/or Vendor ID. The IETF and any other organization with a PEN can define 2^32 - 1 unique PB-TNC message types, as long as the organization's PEN is placed in the PB-TNC Vendor ID field of the message. Since the PB-TNC message type is qualified by the Vendor ID, there is no risk of conflicts as long as each organization uses its own PEN for the Vendor ID and manages its own set of 2^32-1 message type values. Sahita et al. Expires September 6, 2009 [Page 17] Internet-Draft PB-TNC March 2009 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 PB-TNC message types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. 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. Sahita et al. Expires September 6, 2009 [Page 18] Internet-Draft PB-TNC March 2009 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]. Message Type Definition ------------ ---------- 0 PB-Experimental - reserved for experimental use 1 PB-PA - contains a PA message 2 PB-Assessment-Result - the overall assessment result computed by the Posture Broker Server. 3 PB-Access-Recommendation - includes Posture Broker Server access recommendation 4 PB-Remediation-Parameters - includes Posture Broker Server remediation parameters 5 PB-Error - error indicator 6 PB-Language-Preference - sender's preferred language(s) for human-readable strings 7 PB-Reason-String - string explaining reason for Posture Broker Server access recommendation 4.4. PB-Experimental The PB-Experimental PB-TNC message type is a PB-TNC message type (value 0) that has been set aside for experimental purposes. It may be used to test code or for other experimental purposes. It MUST NOT be used in a production environment or in a product. This meaning for this PB-TNC message type only applies if the PB-TNC Vendor ID field in the PB-TNC Message Header contains the value zero (0). If a different Vendor ID is contained in that field, the PB-TNC message type 0 has a completely different meaning not defined in this specification. The contents of the PB-TNC Message Length and PB-TNC Message Value fields for this PB-TNC message type are not specified. They may have almost any value, depending on what experiments are being conducted. Similarly, the Flags field for this message may have the NOSKIP bit Sahita et al. Expires September 6, 2009 [Page 19] Internet-Draft PB-TNC March 2009 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, in which case it SHOULD send an Unsupported Mandatory Message error code in the next batch that it sends. 4.5. PB-PA The PB-TNC message type named PB-PA (value 1) contains one PA message. Many batches will contain several PB-PA messages but some batches may not contain any messages of this type. All Posture Broker Client and Posture Broker Server implementations MUST implement support for this PB-TNC message type. Generally, this support will consist of forwarding the enclosed PA message to the appropriate Posture Collectors and Posture Validators. Specific requirements are contained later in the description of this message type. The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-PA message with the NOSKIP flag not set SHOULD ignore the message and send a fatal Invalid Parameter error code in response. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 1. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 1 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier), and the PA Message Body. Since the PA Message Body is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always Sahita et al. Expires September 6, 2009 [Page 20] Internet-Draft PB-TNC March 2009 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 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 Sahita et al. Expires September 6, 2009 [Page 21] Internet-Draft PB-TNC March 2009 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 PA subtypes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. No PA subtypes are defined in this specification. Definitions of IETF standard PA subtypes will be contained in the PA specification and other specifications. IETF standard PA subtypes are always used with a PA Message Vendor ID of zero (0). Sahita et al. Expires September 6, 2009 [Page 22] Internet-Draft PB-TNC March 2009 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. Posture Validator Identifier (16 bits) The Posture Validator Identifier field contains the identifier of the Posture Validator associated with this PA message. Sahita et al. Expires September 6, 2009 [Page 23] Internet-Draft PB-TNC March 2009 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. 4.6. PB-Assessment-Result The PB-TNC message type named PB-Assessment-Result (value 2) is used by the Posture Broker Server to provide the assessment result after the Posture Broker Server has completed the assessment of the endpoint. The Posture Broker Server will typically compute the assessment result as a cumulative of the individual assessment Sahita et al. Expires September 6, 2009 [Page 24] Internet-Draft PB-TNC March 2009 results received from the various Posture Validators; the algorithm for computation of assessment result at the Posture Broker layer is implementation specific and can also change based on policies in a specific deployment. The Posture Broker Server SHOULD include one message of this type in any batch of type RESULT and SHOULD NOT include a message of this type in any other type of batch. The Posture Broker Client MUST NOT send a PB-TNC message with this message type. The Posture Broker Client SHOULD implement and process this message and SHOULD ignore any message with this message type that is not part of a batch of type RESULT. The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 2. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 2 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with the Assessment Result field described below. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with a PB-TNC Message Length field that does not have a value of 16 SHOULD send an Invalid Parameter error code in response. The following diagram illustrates the format and contents of the PB- TNC Message Value field for this message type. The text after this diagram describes the fields shown here. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assessment Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Assessment Result This 32-bit field MUST contain one of the following values Value Description ----- ----------- 0 Posture Broker Server assessed the endpoint to be compliant with policy. Sahita et al. Expires September 6, 2009 [Page 25] Internet-Draft PB-TNC March 2009 1 Posture Broker Server assessed the endpoint to be non- compliant with policy but the difference from compliance was minor. 2 Posture Broker Server assessed the endpoint to be non- compliant with policy and the assessed difference from compliance was very significant. 3 Posture Broker Server was unable to determine policy compliance due to an error. 4 Posture Broker Server was unable to determine whether the assessed endpoint is compliant with policy based on the attributes provided by endpoint. 4.7. PB-Access-Recommendation The PB-TNC message type named PB-Access-Recommendation (value 3) is used by the Posture Broker Server to provide an access recommendation after the Posture Broker Server has completed some assessment of the endpoint. The PB-Assessment-Result and the PB-Access-Recommendation attribute together constitute the global assessment decision for an endpoint. The PB-Access-Recommendation is not authoritative and the network and host-based access control systems would typically use additional information to determine the network access that is granted to the endpoint. The Posture Broker Server SHOULD include one message of this type in any batch of type RESULT and SHOULD NOT include a message of this type in any other type of batch. Posture Broker Clients MUST NOT send a PB-TNC message with this message type. The Posture Broker Client MUST implement and process this message and SHOULD ignore any message with this message type that is not part of a batch of type RESULT. The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with the NOSKIP flag set SHOULD ignore the message and send a fatal Invalid Parameter error code in response. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 3. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 3 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with Sahita et al. Expires September 6, 2009 [Page 26] Internet-Draft PB-TNC March 2009 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) 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 Sahita et al. Expires September 6, 2009 [Page 27] Internet-Draft PB-TNC March 2009 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. 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 Sahita et al. Expires September 6, 2009 [Page 28] Internet-Draft PB-TNC March 2009 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 PB-TNC Remediation Parameters Types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. A list of IETF Standard PB-TNC Remediation Parameters Types defined in this specification appears later in this section. New vendor-specific Remediation Parameters Types (those used with a non-zero Remediation Parameters vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific Remediation Parameters Types and MUST interoperate with other parties despite any differences in the set of vendor-specific Remediation Parameters Types supported (although they MAY permit administrators to configure them to require support for specific Remediation Parameters Types). Note that the Remediation Parameters Type is completely separate from the PB-TNC Message Type and the PA Subtype fields. The same value (e.g. 0) may have different meanings in each of these fields. Remediation Parameters (variable length) The Remediation Parameters field contains the actual remediation parameters carried in this PB-TNC message. The length of this field can be determined by subtracting the length of the fixed- length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB- Remediation-Parameters message (Reserved, Remediation Parameters Sahita et al. Expires September 6, 2009 [Page 29] Internet-Draft PB-TNC March 2009 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 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 Sahita et al. Expires September 6, 2009 [Page 30] Internet-Draft PB-TNC March 2009 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. The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 5. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 5 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, Error Code Vendor ID, Error Code, and Reserved), and the Error Parameters. Since the Error Parameters field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client or Posture Broker Server that receives a PB-Remediation-Parameters message with a PB-TNC Message Length field that contains an invalid value (e.g. less than 20) SHOULD send an Invalid Parameter error code in response. The following diagram illustrates the format and contents of the PB- TNC Message Value field for this message type. The text after this diagram describes the fields shown here. Sahita et al. Expires September 6, 2009 [Page 31] Internet-Draft PB-TNC March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Error Code Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Parameters (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags (8 bits) This field defines flags relating to the error. Bit 0 of this flags field (the most significant bit) is known as the FATAL flag. If the FATAL bit is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD process this error and then continue with the exchange. If the FATAL flag is set (value 1), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message MUST terminate the exchange after processing the error. The FATAL bit allows a Posture Broker Client or Posture Broker Server to signal a fatal error (like an invalid batch type) and/or a non-fatal error (like an invalid language tag for a preferred language). The other bits in this Flags field are reserved. For this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception. Error Code Vendor ID (24 bits) The Error Code Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The Error Code Vendor ID qualifies the Error Code field so that each vendor has 2^16 separate Error Codes available for its use. Error codes standardized by the IETF are always used with the value zero (0) in this field. For detailed descriptions of those messages, see the next few subsections. Error Code (16 bits) The Error Code field identifies the type of error being signaled with this message. The format of the Error Parameters field depends on the value of the Error Code Vendor ID and the Error Sahita et al. Expires September 6, 2009 [Page 32] Internet-Draft PB-TNC March 2009 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 PB-TNC Error Codes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. A list of IETF Standard PB-TNC Error Codes defined in this specification appears later in section 4.9.1. New vendor-specific error codes (those used with a non-zero error code vendor ID) may be defined and employed by vendors without IETF or IANA involvement. Posture Broker Clients and Posture Broker Servers that receive an unknown error code MUST process this error code gracefully by ignoring or logging it if it is not marked as fatal and terminating the exchange if it is marked as fatal. Reserved (16 bits) The Reserved bits MUST be set to 0 on transmission and ignored on reception. 4.9.1. IETF Standard PB-TNC Error Codes The following error codes are IETF Standard PB-TNC Error Codes, hence the Error Code Vendor ID MUST be the value zero (0). The following table defines the 16 bit Error Code. Vendor-specific error codes may be defined by setting the Error Code Vendor ID to the defining vendor's SMI PEN and setting the Error Code field to whatever error code(s) that vendor has defined. The format, length, and meaning of the Error Parameters field varies, based on the Error Code Vendor ID and Error Code. Subsequent sections of this document define the format, length, and meaning of the Error Parameters for the IETF Standard PB-TNC Error Codes defined in this section. Error Code Definition ---------- ---------- 0 Unexpected Batch Type. Error Parameters are empty. 1 Invalid Parameter. Error Parameters has offset where invalid value was found. 2 Local Error. Error Parameters are empty. 3 Unsupported Mandatory Message. Error Parameters has offset of offending PB-TNC Message Sahita et al. Expires September 6, 2009 [Page 33] Internet-Draft PB-TNC March 2009 4.9.2. Error Parameters Structures for IETF Standard PB-TNC Error Codes This section defines the format, length, and meaning of the Error Parameters field for the IETF Standard PB-TNC Error Codes defined in this specification. The Error Parameters field is zero length for the IETF Standard PB- TNC Error Code 0. The FATAL flag MUST be set for this error code. The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 1. The Offset field is the offset in octets from the start of the PB-TNC batch to the invalid value. The FATAL flag may either be set or cleared for this error code. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Error Parameters field is zero length for the IETF Standard PB- TNC Error Code 2. The FATAL flag MUST be set for this error code. The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 3. The Offset field is the offset in octets from the start of the PB-TNC batch to the PB-TNC message whose message type was not recognized (and where the NOSKIP flag was set). The FATAL flag MUST be set for this error code. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.10. PB-Language-Preference The PB-TNC message type named PB-Language-Parameters (value 6) is used by the Posture Broker Client to indicate which language or languages it would prefer for any human-readable strings that might be sent to it. This allows the Posture Broker Server and Posture Validators to adapt any messages they may send to the Posture Broker Client's preferences (probably determined by the language preferences of the endpoint's users). The Posture Broker Server may also send this message type to the Posture Broker Client to indicate the Posture Broker Server's Sahita et al. Expires September 6, 2009 [Page 34] Internet-Draft PB-TNC March 2009 language preferences but this is not very useful since the Posture Broker Client rarely sends human-readable strings to the Posture Broker Server and, if it does, rarely can adapt those strings to the preferences of the Posture Broker Server. No Posture Broker Client or Posture Broker Server is required to send or implement this message type. However, a Posture Broker Server SHOULD attempt to adapt to user language preferences by implementing this message type, passing the language preference information to Posture Validators, and allowing administrators to configure human- readable languages in whatever languages are preferred by their users. A Posture Broker Client or Posture Broker Server may include a message of this type in any batch of any type. However, it is suggested that this message be included in the first batch sent by the Posture Broker Client or Posture Broker Server in a PB-TNC session so that the recipient can start adapting its human-readable messages as soon as possible. If one PB-Language-Parameters message is received and then another one is received in a later batch for the same PB-TNC session, the value included in the later message should be considered to replace the value in the earlier message. A Posture Broker Client or Posture Broker Server MUST NOT include more than one message of this type in a single batch. If a Posture Broker Client or Posture Broker Server receives more than one message of this type in a single batch, it should ignore all but the last one. The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 6. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 6 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the Language Preference field. Since the Language Preference field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 12 to cover the fixed-length fields listed in the preceding sentences. The following diagram illustrates the format and contents of the PB- TNC Message Value field for this message type. The text after this diagram describes the fields shown here. Sahita et al. Expires September 6, 2009 [Page 35] Internet-Draft PB-TNC March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Language Preference (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Language Preference (variable length) The Language Preference field contains an Accept-Language header, as described in RFC 3282 [4] (US-ASCII only, no control characters allowed, no NUL termination). Any Posture Broker Client or Posture Broker Server that sends a PB-Language-Preference message MUST ensure that the Language Preference field conforms to this format. A zero length Language Preference field indicates that no language preference information is available. Generally, there's no need to send a PB-Language-Preference message with a zero length Language Preference field since this is equivalent to sending no PB-Language-Preference message at all but it may be useful to send a zero length Language Preference field if a PB-Language- Preference message with a non-zero length Language Preference field was sent in an earlier batch but these preferences no longer apply. 4.11. PB-Reason-String The PB-TNC message type named PB-Reason-String (value 7) is used by the Posture Broker Server to provide a human-readable explanation for the global assessment decision conveyed in the PB-Assessment-Result & PB-Access-Recommendation messages. Therefore, a PB-Reason-String message SHOULD only be included in the same batch as the PB- Assessment-Result and PB-Access-Recommendation message. The Posture Broker Client MUST NOT ever send a PB-Reason-String message. The Posture Broker Client is not required to implement this message type and the Posture Broker Server is not required to send it. However, there is some benefit to doing so since users are often curious about why the endpoint was considered non-compliant. The manner in which a Posture Broker Client uses this field is up to the implementer and not specified here. The Posture Broker Client MAY display the message to the user, log it, ignore it, or take any other action that is not inconsistent with the requirements of this specification. Since the strings contained in this message are human-readable, the Posture Broker Server SHOULD adapt them to the Posture Broker Client's language preferences as expressed in any PB- Sahita et al. Expires September 6, 2009 [Page 36] Internet-Draft PB-TNC March 2009 Language-Preference message sent by the Posture Broker Client in this PB-TNC session. A Posture Broker Server MAY include more than one message of this type in any batch of any type. However, it is suggested that this message be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. If more than one PB-Reason-String message is included in a single batch, the Posture Broker Client SHOULD consider the strings included in these messages to be equivalent in meaning. This allows the Posture Broker Server to return multiple equivalent reason strings in different languages, which may help if the Posture Broker Server is not able to accommodate the Posture Broker Client's language preferences. The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 7. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 7 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reason String Length and Reason String Language Code Length), and the Reason String and Reason String Language Code fields. Since the Reason String and Reason String Language Code fields are variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. In fact, the PB-TNC Message Length field MUST be exactly the sum of 20 (for the fixed- length fields) and the values of the Reason String Length and Reason String Language Code Length fields. If this is not the case, the recipient SHOULD send an Invalid Parameter error code in response, if this is practical according to the PB-TNC state machine. In many cases, it will not be practical since the PB-Reason-String message often comes in a batch of type RESULT and according to the PB-TNC state machine, a Posture Broker Client cannot send a batch after this except a CRETRY batch, which would restart the handshake. That is generally not desirable. The following diagram illustrates the format and contents of the PB- TNC Message Value field for this message type. The text after this diagram describes the fields shown here. Sahita et al. Expires September 6, 2009 [Page 37] Internet-Draft PB-TNC March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason String Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason String (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason String Language Code Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason String Language Code (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reason String Length (32 bits) The Reason String Length field contains the length of the Reason String field in octets. Reason String (variable length) The Reason String field contains a UTF-8 encoded string that provides a human-readable reason for the Posture Broker Server's assessment decision. NUL termination MUST NOT be included. If a Posture Broker Client receives a Reason String that does contain a NUL termination, it SHOULD send an Invalid Parameter error code in the next batch that it sends. A zero length string SHOULD NOT be sent since this is the same as sending no reason string at all, leaving the reason unspecified. Reason String Language Code Length (32 bits) The Reason String Language Code Length field contains the length of the Reason String Language Code field in octets. Reason String Language Code (variable length) The Reason String Language Code field contains a US-ASCII string containing a well-formed RFC 4646 [3] language tag that indicates the language(s) used in the Reason String in this message. NUL termination MUST NOT be included in this field. A zero length string MAY be sent for this field (essentially omitting this field) to indicate that the language code for the reason string is not known. Sahita et al. Expires September 6, 2009 [Page 38] Internet-Draft PB-TNC March 2009 5. 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. 5.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 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 Sahita et al. Expires September 6, 2009 [Page 39] Internet-Draft PB-TNC March 2009 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. 5.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. 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 Sahita et al. Expires September 6, 2009 [Page 40] Internet-Draft PB-TNC March 2009 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. 6. IANA Considerations Four new IANA registries are defined by this specification: PB-TNC Message Types, PA Subtypes, PB-TNC Remediation Parameters Types, and PB-TNC Error Codes. This section explains how these registries work. All of these registries support IETF standard values and vendor- defined values. To explain this phenomenon, we will use the PB-TNC Message Type as an example but the other three registries work the same way. 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 specification 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 is defined by the vendor identified by the vendor ID (as listed in the IANA registry for SMI PENs). The identified vendor is encouraged but not required to register with IANA some or all of the PB-TNC Message Types used with their vendor ID and publish a specification for each of these values. This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require Sahita et al. Expires September 6, 2009 [Page 41] Internet-Draft PB-TNC March 2009 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. 6.1. Designated Expert Guidelines For all of the four IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [5]. This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for these registries. The registries defined in this document have plenty of values. In most cases, the IETF has approximately 2^32 values available for it to define and each vendor the same number of values for its use. The only exception is the registry for PB-TNC Error Codes where 2^16 values are available for the IETF and 2^16 values for each vendor. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values. Instead, designated experts should focus on the following requirements. All values in these IANA registries MUST be documented in a specification that is clear, permanently and publicly available, and likely to ensure interoperability. IETF standard values MUST be useful and not harmful to the Internet. Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single IETF standard value. However, it is beneficial to document existing practice. There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor MUST supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if at some point the document becomes no longer freely available to all through other channels. Sahita et al. Expires September 6, 2009 [Page 42] Internet-Draft PB-TNC March 2009 6.2. Registry for PB-TNC Message Types The name for this registry is "PB-TNC Message Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-2, and a reference to a specification where the contents of this message type are defined. This specification 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 designated Private Enterprise Number in the PB-TNC Vendor ID field. Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. 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 PB-TNC Message Types. PEN Integer Name Defining Specification --- ------- ---- ---------------------- 0 0 PB-Experimental RFC # Assigned to this I-D 0 1 PB-PA RFC # Assigned to this I-D 0 2 PB-Access-Recommendation RFC # Assigned to this I-D 0 3 PB-Remediation-Parameters RFC # Assigned to this I-D 0 4 PB-Error RFC # Assigned to this I-D 0 5 PB-Language-Preference RFC # Assigned to this I-D 0 6 PB-Reason-String RFC # Assigned to this I-D 0 7 PB-Assessment-Result RFC # Assigned to this I-D 6.3. Registry for PA Subtypes The name for this registry is "PA Subtypes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-2, and a reference to a specification where the contents of this PA subtype are defined. This specification 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 designated Private Enterprise Number in the PA Message Vendor ID field. Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. Sahita et al. Expires September 6, 2009 [Page 43] Internet-Draft PB-TNC March 2009 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. 6.4. Registry for PB-TNC Remediation Parameters Types The name for this registry is "PB-TNC Remediation Parameters Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference to a specification where the contents of this remediation parameters type are defined. This specification 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 designated Private Enterprise Number in the Remediation Parameters Vendor ID field. Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. 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 PB-TNC Remediation Parameters Types. PEN Integer Name Defining Specification --- ------- ---- ---------------------- 0 1 Remediation-URI RFC # Assigned to this I-D 0 2 Remediation-String RFC # Assigned to this I-D 6.5. Registry for PB-TNC Error Codes The name for this registry is "PB-TNC Error Codes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^16-1, and a reference to a specification where this error code is defined. This specification 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 designated Private Enterprise Number in the Error Code Vendor ID field. Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. Sahita et al. Expires September 6, 2009 [Page 44] Internet-Draft PB-TNC March 2009 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 PB-TNC Error Codes. PEN Integer Name Defining Specification --- ------- ---- ---------------------- 0 0 Unexpected Batch Type RFC # Assigned to this I-D 0 1 Invalid Parameter RFC # Assigned to this I-D 0 2 Local Error RFC # Assigned to this I-D 0 3 Unsupported Mandatory Message RFC # Assigned to this I-D 7. 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 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 September 6, 2009 [Page 45] Internet-Draft PB-TNC March 2009 8. References 8.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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. 8.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-03.txt, March 2009. Sahita et al. Expires September 6, 2009 [Page 46] Internet-Draft PB-TNC March 2009 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 September 6, 2009 [Page 47] Internet-Draft PB-TNC March 2009 | | +-------->| | | | | | | 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 September 6, 2009 [Page 48] Internet-Draft PB-TNC March 2009 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 { D bit=0 (Posture Broker Client is originator) Batch Type=CDATA Batch Length } PB Message 1 { Vendor-id=0 Sahita et al. Expires September 6, 2009 [Page 49] Internet-Draft PB-TNC March 2009 Type =2 (PB-PA) Length Value = { PA-Msg-vendor-id=0 (Standard) PA-subtype=1 (OS) OS Posture PA Message } } PB Message 2 { 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 } } } 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. Sahita et al. Expires September 6, 2009 [Page 50] Internet-Draft PB-TNC March 2009 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 { D bit=1 (Posture Broker Server is originator) Batch Type=RESULT Batch Length } PB Message 1 { Vendor-id=0, Type =3 (Access-Recommendation) Length Value = { Sahita et al. Expires September 6, 2009 [Page 51] Internet-Draft PB-TNC March 2009 System-Evaluation-Result=0 (Compliant) } } PB Message 2 { 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 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 Result PA Message } } } Sahita et al. Expires September 6, 2009 [Page 52] Internet-Draft PB-TNC March 2009 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 | | AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV | +----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+ | | | N/W Join| | | | | | ----->| | | | | | | Create | | | | | |Post. Req | | | | | |--------->| | | | | |Create Posture Req | Sahita et al. Expires September 6, 2009 [Page 53] Internet-Draft PB-TNC March 2009 | | | |----------+--------->| | | | |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 | | | | | | Posture | | | | | |---------->| Posture | | | | | |Response | | | | | |-------->| | | | | | | Verify | | | | | | Posture | | | | | |--------->| | | | | | Verify Posture | Sahita et al. Expires September 6, 2009 [Page 54] Internet-Draft PB-TNC March 2009 | | | |----------+--------->| | | | |Vndr Y Posture Result| | | | |<---------+----------| | | | |Vndr X AV | | | | | |Post Reslt| | | | | Assess |<---------| | | | | Result | | | | | Vndr X AV |<--------| | | | |Post Reslt |<--------| | | | |<----------| | | | | Vndr Y AV Post Reslt | | | | +<---------+-----------| | | | | | | | | | 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. Sahita et al. Expires September 6, 2009 [Page 55] Internet-Draft PB-TNC March 2009 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: PB Envelope { HDR { D bit=1 (Posture Broker Server is originator) Batch Type=SDATA Batch Length } PB Message 1 { Vendor-id=0 Sahita et al. Expires September 6, 2009 [Page 56] Internet-Draft PB-TNC March 2009 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 2 { 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 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 Sahita et al. Expires September 6, 2009 [Page 57] Internet-Draft PB-TNC March 2009 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. 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 { D bit=0 (Posture Broker Client is originator) Batch Type=CDATA Batch Length } PB Message 1 { Vendor-id=0 Type =2 (PB-PA) Sahita et al. Expires September 6, 2009 [Page 58] Internet-Draft PB-TNC March 2009 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 } } PB Message 2 { 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. Sahita et al. Expires September 6, 2009 [Page 59] Internet-Draft PB-TNC March 2009 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. 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 { D bit=1 (Posture Broker Server is originator) Batch Type=RESULT Batch Length } PB Message 1 { Vendor-id=0, Type=3 (Access-Recommendation) Length Value = { Sahita et al. Expires September 6, 2009 [Page 60] Internet-Draft PB-TNC March 2009 PB-Assessment-Result=1 (Non-Compliant) } } PB Message 2 { 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 3 { 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 4 { Sahita et al. Expires September 6, 2009 [Page 61] Internet-Draft PB-TNC March 2009 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 Result PA Message } } PB Message 5 { 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 Sahita et al. Expires September 6, 2009 [Page 62] Internet-Draft PB-TNC March 2009 results. Because this flow is triggered locally, NEA doesn't specify the contents of this flow. 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. This use case relies on the use of virtual Posture Collector concept described in section 3.3 of the PA-TNC specification. As illustrated in this example, the Posture Broker Client will assign two Posture Collector IDs to a single Posture Collector (Standard VPN PC) and the Posture Collector will generate two separate PA messages to report the posture for Vendor X and Vendor Y VPN Clients. The Posture Broker Client will use the assigned IDs in the PB message sent to the NEA Server. This entire behavior will be completely opaque to the NEA Server, which will handle the PB message as if there were two VPN Posture Collectors on the NEA Client. +--------+ +-------+ +---------+ +--------+ +-------+ +--------+ |Vndr X | |Vndr Y | |Standard | |Standard| |Standrd| |Standard| |VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV | +----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+ Sahita et al. Expires September 6, 2009 [Page 63] Internet-Draft PB-TNC March 2009 Enble| | | | | | ---->| | | | | | | VPN Status Change | | | | |--------------------->| Posture | | | | | | Change | | | | | |-------->| | | | | |Req. Post| | | | | |<--------| | | | |Ins/Rq Info| | | | | |<----------| | | | | Inspect/Request Info | | | | |<---------+-----------|VPNX Post| | | | | |-------->| | | | | |VPNY Post| | | | | |-------->| | | | | | | Posture | | | | | | Report | | | | | |--------->| | | | | | |Vrfy Post.| | | | | |--------->| | | | | |VPN PRslt | | | | | Assess |<---------| | | | | Result | | | | | |<---------| | Sahita et al. Expires September 6, 2009 [Page 64] Internet-Draft PB-TNC March 2009 | | |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. 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. Sahita et al. Expires September 6, 2009 [Page 65] Internet-Draft PB-TNC March 2009 A.3.1.6. Vendor X VPN Posture (VPNX Post.) This flow contains the PA message from the VPN Posture Collector for Vendor X VPN Client posture; the message content is described in the PA-TNC specification. A.3.1.7. Vendor Y VPN Posture (VPNY Post.) This flow contains the PA message from the VPN Posture Collector for Vendor Y VPN Client posture; the message content is described in the PA-TNC specification. A.3.1.8. Posture Report (Post. Rpt.) This flow contains the PB message containing the PA message from the VPN Posture Collector: PB Envelope { HDR { D bit=0 (Posture Broker Client is originator) Batch Type=CRETRY Batch Length } PB Message 1 { Vendor-id=0 Type =2 (PB-PA) Length Value = { Sahita et al. Expires September 6, 2009 [Page 66] Internet-Draft PB-TNC March 2009 PA-Msg-vendor-id=0 PA-subtype=7 (VPN) Posture-Collector-ID=1 //Virtual Posture Collector ID for Vendor X VPN Client Vendor X VPN Posture PA Message } } PB Message 2 { Vendor-id=0 Type =2 (PB-PA) Length Value = { PA-Msg-vendor-id=0 PA-subtype=7 (VPN) Posture-Collector-ID=2 //Virtual Posture Collector ID for Vendor Y VPN Client Vendor Y VPN Posture PA Message } } Sahita et al. Expires September 6, 2009 [Page 67] Internet-Draft PB-TNC March 2009 A.3.1.9. 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.10. 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.11. 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 { D bit=1 (Posture Broker Server is originator) R bit=1 (Retry acknowledge) Batch Type=RESULT Batch Length } PB Message 1 { Vendor-id=0, Type =3 (Access-Recommendation) Sahita et al. Expires September 6, 2009 [Page 68] Internet-Draft PB-TNC March 2009 Length Value = { PB-Assessment-Result=1 (Non-Compliant) } } PB Message 2 { 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.12. 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 September 6, 2009 [Page 69] Internet-Draft PB-TNC March 2009 APPENDIX B: Evaluation Against NEA Requirements This section evaluates the PB-TNC protocol against the requirements defined in the NEA Requirements document. Each subsection considers a separate requirement from the NEA Requirements document. Only common requirements (C-1 through C-11) and PB requirements (PB-1 through PB-6) are considered, since these are the only ones that apply to PB. B.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. B.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. B.3. Evaluation Against Requirement C-3 Requirement C-3 says: C-3 NEA protocols including security capabilities MUST be capable of protecting against active and passive attacks by Sahita et al. Expires September 6, 2009 [Page 70] Internet-Draft PB-TNC March 2009 intermediaries and endpoints including prevention from replay based attacks. PB-TNC does not include any security capabilities. It depends on PT to supply a secure transport. This addresses all the necessary threats without adding an extra layer of security. Since this requirement only applies to NEA protocols that include security capabilities, PB-TNC meets this requirement. B.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. B.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. B.6. Evaluation Against Requirement C-6 Requirement C-6 says: C-6 NEA protocols MUST be highly scalable; the protocols MUST support many Posture Collectors on a large number of NEA Sahita et al. Expires September 6, 2009 [Page 71] Internet-Draft PB-TNC March 2009 Clients to be assessed by numerous Posture Validators residing on multiple NEA Servers. PB-TNC meets this requirement. PB-TNC supports up to 2^16-1 Posture Collectors and an equal number of Posture Validators in a given PB- TNC session. It also supports an unlimited number of NEA Clients and NEA Servers. The scalability of PB-TNC extends into other areas as well. For example, PB-TNC supports an unlimited number of batches and each batch can contain up to 2^32-1 octets and about 2^24 PA messages. Each PA message can contain up to 2^32-1 octets. Of course, sending this much data in a NEA assessment is not generally advisable but the point is that PB-TNC is highly scalable. B.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. B.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. B.9. Evaluation Against Requirement C-9 Requirement C-9 says: Sahita et al. Expires September 6, 2009 [Page 72] Internet-Draft PB-TNC March 2009 C-9 For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences. PB-TNC meets this requirement. It defines a standard way for the NEA Client and NEA Server to send their language preferences to each other, leveraging the widely implemented Accept-Language format defined in RFC 3282. B.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. B.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 September 6, 2009 [Page 73] Internet-Draft PB-TNC March 2009 B.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. B.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. B.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 September 6, 2009 [Page 74] Internet-Draft PB-TNC March 2009 supports exclusive delivery, which allows messages to be targeted at a particular Posture Collector or Posture Validator. B.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. B.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. B.17. Evaluation Against Requirement PB-6 Requirement PB-6 says: Sahita et al. Expires September 6, 2009 [Page 75] Internet-Draft PB-TNC March 2009 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. Authors' 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 Sahita et al. Expires September 6, 2009 [Page 76]