idnits 2.17.1 draft-ietf-nea-pb-tnc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2009) is 5297 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4646 (ref. '3') (Obsoleted by RFC 5646) ** Obsolete normative reference: RFC 5226 (ref. '5') (Obsoleted by RFC 8126) == Outdated reference: A later version (-06) exists of draft-ietf-nea-pa-tnc-05 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Sahita 2 Internet Draft Intel 3 Intended status: Proposed Standard S. Hanna 4 Expires: April 2010 Juniper 5 R. Hurst 6 Microsoft 7 K. Narayan 8 Cisco Systems 10 October 23, 2009 12 PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC 13 draft-ietf-nea-pb-tnc-06.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on April 23, 2010. 48 Copyright Statement 50 Copyright (c) 2009 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents in effect on the date of 55 publication of this document (http://trustee.ietf.org/license-info). 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. 59 Abstract 61 This document specifies PB-TNC, a Posture Broker Protocol identical 62 to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document 63 then evaluates PB-TNC against the requirements defined in the NEA 64 Requirements specification. 66 Table of Contents 68 1. Introduction...................................................4 69 1.1. Prerequisites.............................................5 70 1.2. Message Diagram Conventions...............................5 71 1.3. Terminology...............................................5 72 1.4. Conventions used in this document.........................5 73 2. PB-TNC Design Considerations...................................5 74 2.1. Message Addressing........................................6 75 2.1.1. Message Types........................................6 76 2.1.2. Dynamic Identifiers..................................7 77 2.2. Vendor IDs................................................7 78 2.3. Efficiency................................................8 79 3. PB-TNC Protocol Description....................................8 80 3.1. Protocol Overview.........................................8 81 3.2. PB-TNC State Machine......................................9 82 3.3. Layering on PT...........................................12 83 3.3.1. Posture Transport (PT) Protocol Requirements Addendum13 84 3.4. Example of PB-TNC Encapsulation..........................13 85 4. PB-TNC Protocol Specification.................................14 86 4.1. PB-TNC Header............................................14 87 4.2. PB-TNC Message...........................................16 88 4.3. IETF Standard PB-TNC Message Types.......................19 89 4.4. PB-Experimental..........................................20 90 4.5. PB-PA....................................................21 91 4.6. PB-Assessment-Result.....................................25 92 4.7. PB-Access-Recommendation.................................27 93 4.8. PB-Remediation-Parameters................................28 94 4.8.1. IETF Standard PB-TNC Remediation Parameters Types...31 96 4.9. PB-Error.................................................33 97 4.9.1. IETF Standard PB-TNC Error Codes....................36 98 4.9.2. Error Parameters Structures for IETF Standard PB-TNC 99 Error Codes................................................36 100 4.10. PB-Language-Preference..................................38 101 4.11. PB-Reason-String........................................39 102 5. Security Considerations.......................................42 103 5.1. Threat Model.............................................42 104 5.2. Countermeasures..........................................43 105 6. IANA Considerations...........................................44 106 6.1. Designated Expert Guidelines.............................45 107 6.2. Registry for PB-TNC Message Types........................46 108 6.3. Registry for PA Subtypes.................................46 109 6.4. Registry for PB-TNC Remediation Parameters Types.........47 110 6.5. Registry for PB-TNC Error Codes..........................47 111 7. Acknowledgments...............................................48 112 8. References....................................................49 113 8.1. Normative References.....................................49 114 8.2. Informative References...................................49 115 Appendix A: Use Cases............................................50 116 A.1. Initial Client triggered assessment......................50 117 A.1.1. Message Contents....................................51 118 A.1.1.1. N/W Join.......................................52 119 A.1.1.2. Request Posture (Req Post.)....................52 120 A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)...52 121 A.1.1.4. OS Posture.....................................52 122 A.1.1.5. Posture Report.................................52 123 A.1.1.6. Verify Posture.................................53 124 A.1.1.7. OS Posture Result (OS Reslt)...................54 125 A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result) 126 ........................................................54 127 A.1.1.9. Assessment Result (Assess Result)..............54 128 A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)56 129 A.2. Server initiated Assessment with Remediation.............56 130 A.2.1. Message Contents....................................58 131 A.2.1.1. N/W Join.......................................58 132 A.2.1.2. Create Posture Request (Create Posture Req.)...59 133 A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV 134 Post. Req)..............................................59 135 A.2.1.4. Vendor Y Anti-Virus Posture Request............59 136 A.2.1.5. Posture Request................................59 137 A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr 138 Y AV Posture Req).......................................60 139 A.2.1.7. Vendor Y Anti-Virus Posture (Vndr Y AV Posture)61 140 A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture)61 141 A.2.1.9. Posture Response...............................61 142 A.2.1.10. Verify Posture................................62 143 A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post 144 Result).................................................63 145 A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post 146 Result).................................................63 147 A.2.1.13. Assessment Result (Assess Result).............63 148 A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV 149 Post Reslt).............................................65 150 A.3. Client triggered re-assessment...........................66 151 A.3.1. Message Contents....................................68 152 A.3.1.1. Enable VPN Client (Enble)......................68 153 A.3.1.2. Notify Status Change (VPN Status Change).......68 154 A.3.1.3. Notify Posture Change (Posture Change).........68 155 A.3.1.4. Request Posture (Req. Post)....................68 156 A.3.1.5. Inspect/Request Information (Ins/Rq Info)......68 157 A.3.1.6. Vendor X VPN Posture (VPNX Post.)..............69 158 A.3.1.7. Vendor Y VPN Posture (VPNY Post.)..............69 159 A.3.1.8. Posture Report (Post. Rpt.)....................69 160 A.3.1.9. Verify Posture (Vrfy Post.)....................71 161 A.3.1.10. VPN Posture Result (VPN PRslt)................71 162 A.3.1.11. Assessment Result (Assess Result).............71 163 A.3.1.12. Posture Result (VPN PRslt)....................72 164 APPENDIX B: Evaluation Against NEA Requirements..................73 165 B.1. Evaluation Against Requirement C-1.......................73 166 B.2. Evaluation Against Requirement C-2.......................73 167 B.3. Evaluation Against Requirement C-3.......................73 168 B.4. Evaluation Against Requirement C-4.......................74 169 B.5. Evaluation Against Requirement C-5.......................74 170 B.6. Evaluation Against Requirement C-6.......................74 171 B.7. Evaluation Against Requirement C-7.......................75 172 B.8. Evaluation Against Requirement C-8.......................75 173 B.9. Evaluation Against Requirement C-9.......................75 174 B.10. Evaluation Against Requirement C-10.....................76 175 B.11. Evaluation Against Requirement C-11.....................76 176 B.12. Evaluation Against Requirement PB-1.....................77 177 B.13. Evaluation Against Requirement PB-2.....................77 178 B.14. Evaluation Against Requirement PB-3.....................77 179 B.15. Evaluation Against Requirement PB-4.....................78 180 B.16. Evaluation Against Requirement PB-5.....................78 181 B.17. Evaluation Against Requirement PB-6.....................78 182 Authors' Addresses...............................................79 184 1. Introduction 186 This document specifies PB-TNC, a Posture Broker Protocol (PB) 187 identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol [7]. 188 The document then evaluates PB-TNC against the requirements defined 189 in the NEA Requirements specification [8]. 191 1.1. Prerequisites 193 This document does not define an architecture or reference model. 194 Instead, it defines a protocol that works within the reference model 195 described in the NEA Requirements specification [8]. The reader is 196 assumed to be thoroughly familiar with that document. No familiarity 197 with TCG specifications is assumed. 199 1.2. Message Diagram Conventions 201 This specification defines the syntax of PB-TNC messages using 202 diagrams. Each diagram depicts the format and size of each field in 203 bits. Implementations MUST send the bits in each diagram as they are 204 shown, traversing the diagram from top to bottom and then from left 205 to right within each line (which represents a 32-bit quantity). 206 Multi-byte fields representing numeric values must be sent in network 207 (big endian) byte order. 209 Descriptions of bit field (e.g. flag) values are described referring 210 to the position of the bit within the field. These bit positions are 211 numbered from the most significant bit through the least significant 212 bit so a one octet field with only bit 0 set has the value 0x80. 214 1.3. Terminology 216 This document reuses the terminology defined in the NEA Requirements 217 document. One new term is defined in this section. 219 Batch - A group of PB-TNC messages sent over a PT protocol at one 220 time. Since the PB-TNC protocol needs to be able to work over a 221 half-duplex PT protocol, PB-TNC messages are grouped into batches. 222 The Posture Broker Client sends one batch to the Posture Broker 223 Server, which responds with a batch. 225 1.4. Conventions used in this document 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC 2119 [1]. 231 2. PB-TNC Design Considerations 233 The primary purpose of the PB-TNC protocol is to carry PA messages 234 between Posture Collectors and Posture Validators. Also, PB-TNC must 235 carry messages between the Posture Broker Client and the Posture 236 Broker Server (known as PB-TNC messages) and manage the state of the 237 assessment. 239 2.1. Message Addressing 241 The NEA Overview and Requirements document [8] describes in section 242 5.1.1.1 several ways that messages can be addressed and delivered to 243 the proper Posture Collector(s) and Posture Validator(s). Of the 244 techniques described in that section, PB-TNC supports dynamic 245 identifiers and message types. 247 2.1.1. Message Types 249 Message types are the simplest and most common way to handle message 250 delivery. Each PA message sent via PB-TNC has an associated PA 251 message type, composed of a PA Message Vendor ID and a PA Subtype. 253 The PA-TNC specification [10] provides a list of IETF Standard PA 254 Subtypes, which are used with a PA Message Vendor ID of 0. These 255 include values such as Operating System and Anti-Virus, which are 256 used for messages relating to operating system and anti-virus 257 posture. 259 Vendor-specific PA message types may be indicated by placing the 260 defining vendor's SMI Private Enterprise Number into the PA Message 261 Vendor ID field and a PA Subtype value assigned by that vendor in the 262 PA Subtype field. This allows each vendor to define its own set of PA 263 Subtype values without worrying about collisions with other vendors 264 or with standard values. 266 The PA message type is somewhat analogous to a MIME type in that it 267 indicates the type of the PA message. Posture Collectors and Posture 268 Validators can use local APIs to indicate to the Posture Broker 269 Client and Posture Broker Server which PA message types they are 270 interested in receiving. For instance, a Posture Validator that 271 evaluates anti-virus posture might indicate that it would like to 272 receive PA messages with a PA Message Vendor ID of 0 and a PA Subtype 273 that matches the IETF Standard PA Subtype for Anti-Virus. It might 274 also indicate interest in some vendor-specific PA message types to 275 get additional vendor-specific information on anti-virus posture. 277 This type-based subscription model allows great flexibility in design 278 and implementation. One Posture Validator may be responsible for 279 evaluating several functions: anti-virus and host-based firewall, for 280 instance. Posture Collectors do not need to know which Posture 281 Validators are installed on the Posture Broker Server or what they 282 hande. The Posture Collector simply sends PA messages with message 283 types and the Posture Broker Server delivers them to the right 284 Posture Validators. 286 Because the Posture Broker Client and Posture Broker Server must have 287 access to the PA Message Vendor ID and PA Subtype fields and because 288 these are routing identifiers independent of the contents of the PA 289 messages, these fields are located in PB-TNC not inside the PA 290 messages themselves. 292 A similar type-based system is used to tag PB-TNC messages. In this 293 case, the extensibility benefits are not as essential as with PA-TNC 294 messages but the ability to define IETF Standard PB-TNC Message Types 295 and vendor-specific PB-TNC Message Types is still valuable. 297 2.1.2. Dynamic Identifiers 299 The type-based message delivery model described above is not ideal 300 for all circumstances. Sometimes it is important for a Posture 301 Collector to deliver a message to a particular Posture Validator. For 302 example, a particular Posture Validator might send a remediation 303 message and the Posture Collector might need to send a response only 304 to that one Posture Validator. To handle this circumstance, PB-TNC 305 provides delivery based on dynamic identifiers. 307 When a Posture Broker Server loads a Posture Validator, it assigns it 308 a Posture Validator ID. Any PA messages sent by a Posture Validator 309 include that Posture Validator's Posture Validator ID in the Posture 310 Validator ID field of the PB-PA message. A Posture Collector that 311 receives such a message can send a message in response and request 312 exclusive delivery to the Posture Validator identified by that 313 Posture Validator ID. 315 Dynamic identifiers avoid problems caused by the multicast nature of 316 message types. Multiple Posture Collectors or Posture Validators may 317 be registered for the same message type and this can cause confusion 318 if they all respond and the software designer did not consider that 319 possibility. The dynamic identifier system allows more directed 320 responses but it does not work until at least one message has been 321 received (so that the dynamic identifiers can be received). Static 322 identifiers were considered as another alternative but rejected 323 because they result in a brittle system that only works with a 324 particular set of Posture Collectors and Posture Validators and 325 causes problems if two Posture Collectors or Posture Validators with 326 the same static identifier are installed. 328 2.2. Vendor IDs 330 In several places, PB-TNC needs to define a set of standard values 331 but also allow vendor-specific extensions. In each of these places 332 (PB-TNC Message Types, PA Subtypes, Remediation Parameters Types and 333 Error Codes), the solution chosen was to preface the values with a 334 vendor ID. If a vendor ID is 0, the values in the next field are 335 registered in an IANA registry and their meanings defined in an RFC. 336 If a vendor ID is non-zero, the values in the next field are vendor- 337 specific and defined by the vendor whose SMI Private Enterprise 338 Number matches the vendor ID. Vendor-specific messages that are not 339 understood by the recipient are ignored and skipped unless they have 340 the NOSKIP flag set, in which case an error code is returned. 342 2.3. Efficiency 344 PB-TNC needs to work with low bandwidth transports and low power 345 devices. Therefore, a simple, compact format was chosen for the PB- 346 TNC protocol: binary messages with a Type-Length-Value structure. 348 3. PB-TNC Protocol Description 350 3.1. Protocol Overview 352 The PB-TNC protocol carries batches of PB messages between a Posture 353 Broker Client and a Posture Broker Server. It encapsulates PA 354 messages and manages the NEA session. It runs over a PT transport 355 protocol. 357 In order to work well over half-duplex PT protocols (such as those 358 based on EAP [9]), PB-TNC supports half-duplex protocol operation. 359 In this mode, the Posture Broker Client and Posture Broker Server 360 take turns sending a single batch of messages to each other. While 361 the half-duplex nature of PB-TNC could slow exchanges that require 362 many round trips or bidirectional multimedia exchanges, this is not a 363 problem in practice because endpoint assessments do not typically 364 involve multimedia or a large number of round trips. The benefit of 365 working over half-duplex transports outweighs any limitations 366 imposed. 368 PB-TNC also supports full-duplex protocol operation so that PB-TNC 369 exchanges can be re-initialized immediately when needed (e.g. if the 370 Posture Broker Server policy changes or if the Posture Broker Client 371 detects a suspicious event). 373 Each PB-TNC batch consists of a header followed by a sequence of PB- 374 TNC messages. Each PB-TNC message has a Type-Length-Value (TLV) 375 format with a few flags. The TLV format allows a recipient to skip 376 messages that it does not understand. The TLV format also provides a 377 standard way to mark messages as mandatory to ensure interoperability 378 between a Posture Broker Client and a Posture Broker Server. 380 This specification defines certain standard PB-TNC message types. It 381 also permits vendors to define their own vendor-specific message 382 types. One of the most important standard PB-TNC message types is 383 PB-PA. A message with this type contains a PA message and various 384 message routing information. A Posture Broker Client or Posture 385 Broker Server that receives such a message does not interpret the PA 386 message within. Instead, it delivers the PA message to the 387 appropriate set of Posture Collectors or Posture Validators, as 388 determined using the message routing information contained in the PB- 389 PA message. 391 A Posture Broker Server will often need to communicate with several 392 Posture Broker Clients at once. The reverse may also be true, as 393 when an endpoint has multiple network interfaces connected to 394 different networks. Each connection between a Posture Broker Server 395 and a Posture Broker Client is instantiated as a separate PB-TNC 396 session. There may be several simultaneous sessions between a single 397 Posture Broker Server and Posture Broker Client but this is unusual. 399 3.2. PB-TNC State Machine 401 Figure 1 illustrates the PB-TNC state machine, showing the set of 402 states that a PB-TNC session can have and the possible transitions 403 among these states. The following paragraphs describe this state 404 machine in more detail. 406 Receive CRETRY SRETRY 407 or SRETRY +----------------+ 408 +--+ | | 409 v | v | 410 +---------+ CRETRY +---------+ 411 CDATA | Server |<---------| Decided | CLOSE 412 +----------->| Working |--------->| |-------+ 413 | +---------+ RESULT +---------+ | 414 | ^ | | v 415 | | | +---------------------->======= 416 ======== | | CLOSE " End " 417 " Init " CDATA| |SDATA ======= 418 ======== | | ^ ^ 419 | | | v | | 420 | | SDATA +---------+ CLOSE | | 421 | +-------->| Client |----------------------+ | 422 | | Working | | 423 | +---------+ | 424 | | ^ | 425 | +--+ | 426 | Receive CRETRY | 427 | CLOSE | 428 +--------------------------------------------------+ 430 Figure 1 PB-TNC State Machine 432 In this diagram, states are indicated by rectangular boxes. The 433 initial and terminal states have double outlines (with = and "). 434 State transitions are indicated by unidirectional arrows marked with 435 the cause of the transition. 437 Many transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) are 438 triggered by the transmission or reception of a PB-TNC batch of a 439 particular type. The type of a PB-TNC batch is indicated by the 440 contents of the Batch Type field in the PB-TNC Header for that batch. 441 For brevity, this document says "a FOO batch" instead of "a PB-TNC 442 batch whose Batch Type field contains FOO". Other transitions are 443 triggered by receiving a PB-TNC batch of a particular type (e.g. 444 Receive CRETRY). The CLOSE transition may be triggered by sending or 445 receiving a CLOSE batch but may also be triggered by termination of 446 the underlying PT connection. 448 A PB-TNC session starts in the Init state when the underlying 449 transport protocol (PT) establishes a connection between a Posture 450 Broker Client and a Posture Broker Server. If the Posture Broker 451 Client initiated the underlying transport session, it starts by 452 sending a CDATA batch to the Posture Broker Server, thus causing a 453 transition to the Server Working state. If the Posture Broker Server 454 initiated the transport session, it starts by sending a PB-TNC batch 455 of type SDATA to the Posture Broker Client, thus causing a transition 456 to the Client Working state. 458 The Posture Broker Client and Posture Broker Server may now alternate 459 sending CDATA and SDATA batches to each other. Only the Posture 460 Broker Client can send a data batch when the session is in the Client 461 Working state and only the Posture Broker Server can send a data 462 batch when the session is in the Server Working state. 464 The most common way to end an exchange is for the Posture Broker 465 Server to send a RESULT batch. This causes a transition into the 466 Decided state. This is not a terminal state. The PT session can 467 remain open and another exchange can be initiated by having the 468 Posture Broker Client send a CRETRY batch. This can be useful when 469 the Posture Broker Client (or more likely a Posture Collector) 470 discovers a suspicious condition on the endpoint, for example. If the 471 underlying transport protocol (PT) supports full-duplex operation, 472 the Posture Broker Server can also initiate another exchange from 473 this state by sending a SRETRY batch. This can be useful when the 474 policy changes on the server, for example. 476 Whether an SRETRY or CRETRY message is sent or both, the next state 477 is the Server Working State. From this state, the Posture Broker 478 Server sends an SDATA batch and the new exchange begins. The state 479 transitions marked Receive CRETRY and Receive CRETRY or SRETRY 480 indicate that it is permissible to receive such messages in the 481 indicated states, generally when the Posture Broker Client sent a 482 CRETRY message at roughly the same time as the Posture Broker Server 483 decided to send an SRETRY. In that case, a CRETRY message may be 484 received while in the Server Working or Client Working state. Also, 485 an SRETRY message may be received while in the Server Working state. 486 These messages are redundant and therefore ignored, as indicated by 487 the relevant transitions, which don't cause a state change. 489 The only terminal state is the End state. This state is reached if 490 the underlying PT connection closes. This can be caused by an action 491 of the Posture Broker Client or Posture Broker Server or it can be 492 caused by some external factor, such as pulling the network plug. 493 When possible, a CLOSE batch SHOULD be sent before the underlying PT 494 connection is terminated. However, there may be cases where the PT 495 connection is closed without notice. For example, a plug may be 496 pulled, a software program may fail, or a Posture Broker Client or 497 Posture Broker Server may be unable to send a CLOSE message due to 498 half duplex limitations in the underlying PT protocol. In these 499 cases, the Posture Broker Client and Posture Broker Server will 500 generally receive some form of notification from the Posture 501 Transport Client and Posture Transport Server that the PT connection 502 has been closed. This notification can trigger the CLOSE transition. 503 However, the notification interaction is not standardized since the 504 vertical interfaces in the NEA Reference Model are not standardized. 505 In any case, the reception of the CLOSE batch or notification of 506 termination of the transport causes the transition to the End state. 508 Note that a Posture Broker Client and Posture Broker Server may not 509 always have exactly the same state for a given PB-TNC session. For 510 example, say that a session is in the Client Working state and the 511 Posture Broker Client transmits a CDATA batch. While this batch is 512 in transit (transmitted by the Posture Broker Client but not yet 513 received by the Posture Broker Server), the Posture Broker Client 514 will think that the session is in Server Working state but the 515 Posture Broker Server will think that the session is in Client 516 Working state. However, this is a temporary condition and does not 517 cause problems in practice. The only possible issue is that a 518 Posture Broker Client or Posture Broker Server does not know whether 519 the other party has received its message until it receives a response 520 from the other party. 522 If a half-duplex transport is used, note that the Posture Broker 523 Server cannot send a SRETRY batch when the session is in the Decided 524 state because the Posture Broker Server sent the most recent batch 525 (the RESULT batch) and this would violate the half-duplex nature of 526 the transport protocol. Instead, a server that wishes to initiate a 527 new exchange in the Decided state when a half-duplex transport is in 528 use should close the PT connection without sending a CLOSE batch and 529 start a new PB-TNC session. This limitation does not exist when a 530 full-duplex transport is used. 532 The Posture Broker Server and Posture Broker Client MUST follow the 533 state machine described in this section. 535 3.3. Layering on PT 537 PB-TNC batches are carried over protocol bindings of the PT protocol, 538 which provides the interaction between a Posture Transport Client and 539 a Posture Transport Server. PB-TNC counts on PT to provide a secure 540 transport. In particular, PT MUST support mutual authentication of 541 the Posture Transport Client and the Posture Transport Server, 542 confidentiality and integrity protection for PB-TNC batches, and 543 protection against replay attacks. PB-TNC is unaware of the 544 underlying transport protocols being used. PB-TNC operates directly 545 on PT; no further layer of PB-TNC is expected. 547 3.3.1. Posture Transport (PT) Protocol Requirements Addendum 549 RFC 5209 [8] describes normative requirements for the Posture 550 Transport protocol. This section specifies additional requirements 551 for the Posture Transport protocol. Candidate Posture Transport 552 protocols must indicate conformance to requirements specified in this 553 section as well as Section 7.4 of RFC5209. 555 The additional requirements for candidate PT protocols are: 557 PT-6 The PT protocol MUST be connection oriented; it MUST support 558 confirmed initiation and close down. 560 PT-7 The PT protocol MUST be able to carry binary data. 562 PT-8 The PT protocol MUST provide mechanisms for flow control and 563 congestion control. 565 PT-9 PT protocol specifications MUST describe the capabilities 566 that they provide for and limitations that they impose on 567 the PB protocol (e.g. half/full duplex, maximum message size). 569 3.4. Example of PB-TNC Encapsulation 571 This section shows how PA messages can be carried inside a PB-TNC 572 batch which is inside a PT protocol. 574 Within the PT protocol, the PB-TNC header is packaged next, followed 575 by two PB-PA messages that contain PA messages meant for the Posture 576 Collectors and Posture Validators on the platform. 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | PT Protocol | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | PB-TNC Header | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | PB-PA Message | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | PB-PA Message | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Figure 2 Example of PB-TNC message encapsulation 589 This figure is conceptual, of course, and not an exact byte-for-byte 590 replica. 592 4. PB-TNC Protocol Specification 594 This section defines the syntax and semantics of the PB-TNC protocol 595 fields. If a Posture Broker Client or Posture Broker Server receives 596 a batch that violates the requirements of this specification, it MUST 597 respond by sending a fatal Invalid Parameter error in a CLOSE batch 598 unless this document specifies otherwise. 600 4.1. PB-TNC Header 602 Every PB-TNC batch MUST start with the following header. A PB-TNC 603 batch MUST contain only one instance of this header followed by zero 604 or more PB-TNC messages. The PB-TNC messages are defined in 605 subsequent sections of this specification. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Version |D| Reserved | B-Type| 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Batch Length | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Version (8 bits) 617 This field indicates the version of the format for the PB- 618 TNC message. This version is intended to allow for 619 evolution of the PB-TNC protocol in a manner that can easily 620 be detected by message recipients. 622 This field MUST be set to 2 when the batch conforms to this 623 specification. Later versions of PB-TNC may define other values 624 for this field. The values 0x00, 0x09, 0x0a, 0x0d, 0x20, and 0x3c 625 are reserved and cannot be used for any version of PB-TNC to 626 ensure that PB-TNC can be easily distinguished from earlier 627 posture broker protocols already in use. 629 If a Posture Broker Client or Posture Broker Server receives a 630 Version value that it does not support, it MUST respond with a PB- 631 TNC batch with batch type CLOSE that contains only a fatal Version 632 Not Supported error code and whose Version header field has the 633 value 2. Implementations responding to a PB-TNC message 634 containing a supported version MUST use the same Version number to 635 minimize the risk of version incompatibility. PB-TNC message 636 initiators that support multiple PB-TNC protocol versions SHOULD 637 be able to alter which version of PB-TNC message they send based 638 on prior message exchanges with a particular peer Posture Broker 639 Client or Posture Broker Server. 641 Directionality (D) (1 bit) 643 When a Posture Broker Client is sending this message, the 644 Directionality bit MUST be set to 0. When a Posture Broker Server 645 is sending this message, the Directionality bit MUST be set to 1. 646 This helps avoid any situation where two Posture Broker Clients or 647 two Posture Broker Servers engage in a dialog. It also helps with 648 debugging. 650 Reserved (19 bits) 652 This field is reserved. For this version of this specification, 653 it MUST be set to 0 on transmission and ignored on reception. 654 Future versions of this specification may allow senders to set 655 some of these bits and recipients to interpret them. 657 B-Type (Batch Type) (4 bits) 659 This field is used to drive the state machine described in section 660 3.2. This field MUST have one of the values from the following 661 table. If any other value is received, the recipient MUST ignore 662 the contents of the batch and send a fatal Invalid Parameter error 663 code in a CLOSE batch. If the value received is not permitted for 664 the current state, according to the state machine in section 3.2. 665 , the recipient MUST ignore the contents of the batch and send a 666 fatal Unexpected Batch Type error code in a CLOSE batch. 668 Number Name Definition 669 ------ ---- ---------- 671 1 CDATA The Posture Broker Client may send a batch with 672 this Batch Type to convey messages to the 673 Posture Broker Server. A Posture Broker Server 674 MUST NOT send this Batch Type. A CDATA batch 675 may be empty (contain no messages) if the 676 Posture Broker Client has nothing to send. 678 2 SDATA The Posture Broker Server may send a batch with 679 this Batch Type to convey messages to the 680 Posture Broker Client. A Posture Broker Client 681 MUST NOT send this Batch Type. An SDATA batch 682 may be empty (contain no messages) if the 683 Posture Broker Server has nothing to send. 685 3 RESULT The Posture Broker Server may send a batch with 686 this Batch Type to indicate that it has 687 completed its evaluation. The batch MUST 688 include a PB-Assessment-Result message and MAY 689 include a PB-Access-Recommendation message. 691 4 CRETRY The Posture Broker Client may send a batch with 692 this Batch Type to indicate that it wishes to 693 restart an exchange. A Posture Broker Server 694 MUST NOT send this Batch Type. A CRETRY batch 695 may be empty (contain no messages) if the 696 Posture Broker Client has nothing else to send. 698 5 SRETRY The Posture Broker Server may send a batch with 699 this Batch Type to indicate that it wishes to 700 restart the exchange. A Posture Broker Client 701 MUST NOT send this Batch Type. A SRETRY batch 702 may be empty (contain no messages) if the 703 Posture Broker Server has nothing else to send. 705 6 CLOSE The Posture Broker Server or Posture Broker 706 Client may send a batch with this Batch Type to 707 indicate that it is about to terminate the 708 underlying PT connection. A CLOSE batch may be 709 empty (contain no messages) if there is nothing 710 to send. However, if the termination is due to a 711 fatal error then the CLOSE batch MUST contain a 712 PB-Error message. 714 Batch Length (32 bits) 716 This length field contains the size of the full PB-TNC batch in 717 octets. This length includes the PB-TNC header and all the PB-TNC 718 messages in the batch. In other words, it includes the entire 719 contents of the batch. This field MUST contain at least the value 720 8 for the fixed-length fields in this header. Any Posture Broker 721 Client or Posture Broker Server that receives a PB-TNC message 722 with a PB-TNC Message Length field whose value is less than 8 MUST 723 respond with a fatal Invalid Parameter error code in a CLOSE 724 batch. 726 4.2. PB-TNC Message 728 All PB-TNC messages have the same overall structure, which is 729 described in this section. Of course, the format and semantics of 730 the PB-TNC Message Value field will vary, depending on the values of 731 the PB-TNC Vendor ID and PB-TNC Message Type fields. 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Flags | PB-TNC Vendor ID | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | PB-TNC Message Type | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | PB-TNC Message Length | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | PB-TNC Message Value (Variable Length) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Flags (8 bits) 747 This field defines flags impacting the processing of this message. 749 Bit 0 of this flags field (the most significant bit) is known as 750 the NOSKIP flag. If this flag is cleared (value 0), then the 751 recipient (a Posture Broker Client or Posture Broker Server) may 752 skip (ignore) this message if the message type is not understood 753 or the recipient cannot or will not process the message as 754 required in the definition of that message. If this flag is set 755 (value 1), then recipients MUST NOT skip this attribute. 757 This flag does not mean that all recipients must support this 758 message. Instead, any recipient that receives a message with this 759 flag set to 1 but cannot or will not process it as required MUST 760 NOT act on any part of the PB-TNC batch. Instead, the recipient 761 MUST respond with a fatal Unsupported Mandatory Message error code 762 in a CLOSE batch. In order to avoid taking action on some 763 messages in a batch only to later find an unsupported NOSKIP 764 flagged message, recipients of a PB-TNC batch might choose to scan 765 all of the messages in the batch prior to acting upon any of the 766 messages, checking to determine whether one of them is an 767 unsupported message with the NOSKIP flag set. 769 The other bits in this Flags field are reserved. For this version 770 of PB-TNC, they MUST be set to 0 on transmission and ignored on 771 reception. 773 PB-TNC Vendor ID (24 bits) 775 The PB-TNC Vendor ID field identifies a vendor by using the SMI 776 Private Enterprise Number (PEN). Any organization can receive its 777 own unique PEN from IANA, the Internet Assigned Numbers Authority. 778 This Vendor ID qualifies the PB-TNC Message Type field so that 779 each vendor has 2^32-1 separate message types available for their 780 use. 782 Message types standardized by the IETF use zero (0) in this field. 783 The Vendor ID 0xffffff is reserved. Posture Broker Clients and 784 Posture Broker Servers MUST NOT send messages in which the Vendor 785 ID has this reserved value (0xffffff). If a Posture Broker Client 786 or Posture Broker Server receives a message in which the PB-TNC 787 Vendor ID has this reserved value (0xffffff), it MUST respond with 788 a fatal Invalid Parameter error code in a CLOSE batch. 790 PB-TNC Message Type (32 bits) 792 The PB-TNC Message Type field identifies the type of the PB-TNC 793 message contained in the PB-TNC Message Value field. The PB-TNC 794 message type 0xffffffff is reserved. Posture Broker Clients and 795 Posture Broker Servers MUST NOT send messages in which the PB-TNC 796 Message Type field has this reserved value (0xffffffff). If a 797 Posture Broker Client or Posture Broker Server receives a message 798 in which the PB-TNC Message Type field has this reserved value 799 (0xffffffff), it MUST respond with a fatal Invalid Parameter error 800 code in a CLOSE batch. Unless otherwise prohibited in the 801 definition of a particular PB-TNC Message Type (e.g. PB-Language- 802 Preference), a single PB-TNC batch may contain multiple messages 803 with the same message type and/or Vendor ID. 805 The IETF and any other organization with a PEN can define 2^32-1 806 unique PB-TNC message types, as long as the organization's PEN is 807 placed in the PB-TNC Vendor ID field of the message. Since the 808 PB-TNC message type is qualified by the Vendor ID, there is no 809 risk of conflicts as long as each organization uses its own PEN 810 for the Vendor ID and manages its own set of 2^32-1 message type 811 values. 813 This document defines certain PB-TNC message types which, when 814 used with the IETF SMI PEN (0), have standard meanings. These are 815 known as IETF standard PB-TNC message types. Some of these PB-TNC 816 message types are mandatory and therefore MUST be implemented by 817 all Posture Broker Client and Posture Broker Server 818 implementations that claim compliance with this specification. 819 For details on which PB-TNC message types are mandatory, see the 820 description of these message types later in section 4. 822 IANA maintains a registry of PB-TNC message types. Entries in 823 this registry are added by Expert Review with Specification 824 Required, following the guidelines in section 6.1. 826 New vendor-specific PB-TNC message types (those used with a non- 827 zero PB-TNC vendor ID) may be defined and employed by vendors 828 without IETF or IANA involvement. However, Posture Broker Clients 829 and Posture Broker Servers MUST NOT require support for particular 830 vendor-specific PB-TNC message types and MUST interoperate with 831 other parties despite any differences in the set of vendor- 832 specific PB-TNC message types supported (although they MAY permit 833 administrators to configure them to require support for specific 834 PB-TNC message types). 836 Note that the PB-TNC Message Type field is completely separate 837 from the PA Subtype field. The same value (e.g. 0) may have 838 different meanings as a PB-TNC message type and as a PA subtype. 840 PB-TNC Message Length (32 bits) 842 This field specifies the length of this PB-TNC message in octets. 843 It includes this header (the fields Flags, PB-TNC Vendor ID, PB- 844 TNC Message Type, and PB-TNC Message Length). Therefore, this 845 value MUST always be at least 12. Any Posture Broker Client or 846 Posture Broker Server that receives a message with a PB-TNC 847 Message Length field whose value is less than 12 MUST respond with 848 a fatal Invalid Parameter error code in a CLOSE batch. 850 PB-TNC Message Value (variable length) 852 The syntax and semantics of this field varies, depending on the 853 values in the PB-TNC Vendor ID and PB-TNC Message Type fields. 854 The syntax and semantics of several standard messages is defined 855 in subsequent sections of this specification. 857 4.3. IETF Standard PB-TNC Message Types 859 This table provides a reference list with brief descriptions of the 860 IETF standard PB-TNC message types defined in this specification. 861 These PB-TNC message types must be used with a PB-TNC vendor ID of 862 zero (0). If these PB-TNC message type values are used with a 863 different PB-TNC vendor ID, they have a completely different meaning 864 that is not defined in this specification. 866 For more details on these message types, see the remainder of section 867 4. For IETF standard PA subtypes (which are completely different 868 from PB-TNC message types), please refer to the PA-TNC specification 869 [10]. 871 Message Type Definition 872 ------------ ---------- 873 0 PB-Experimental - reserved for experimental use 874 1 PB-PA - contains a PA message 875 2 PB-Assessment-Result - the overall assessment result 876 computed by the Posture Broker Server. 877 3 PB-Access-Recommendation - includes Posture Broker 878 Server access recommendation 879 4 PB-Remediation-Parameters - includes Posture Broker 880 Server remediation parameters 881 5 PB-Error - error indicator 882 6 PB-Language-Preference - sender's preferred 883 language(s) for human-readable strings 884 7 PB-Reason-String - string explaining reason for 885 Posture Broker Server access recommendation 887 4.4. PB-Experimental 889 The PB-Experimental PB-TNC message type is a PB-TNC message type 890 (value 0) that has been set aside for experimental purposes. It may 891 be used to test code or for other experimental purposes. It MUST NOT 892 be used in a production environment or in a product. This meaning 893 for this PB-TNC message type only applies if the PB-TNC Vendor ID 894 field in the PB-TNC Message Header contains the value zero (0). If a 895 different Vendor ID is contained in that field, the PB-TNC message 896 type 0 has a completely different meaning not defined in this 897 specification. 899 The contents of the PB-TNC Message Length and PB-TNC Message Value 900 fields for this PB-TNC message type are not specified. They may have 901 almost any value, depending on what experiments are being conducted. 902 Similarly, the Flags field for this message may have the NOSKIP bit 903 set or cleared, depending on what experiments are being conducted. 904 However, note that the PB-TNC Message Length field must have a value 905 of at least 12 since that is the total of the length of the fixed- 906 length fields at the start of the PB-TNC message (the fields Flags, 907 PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). 908 Any Posture Broker Client or Posture Broker Server that receives a 909 message with a PB-TNC Message Length field whose value is invalid 910 MUST respond with a fatal Invalid Parameter error code in a CLOSE 911 batch. 913 A Posture Broker Client or Posture Broker Server implementation 914 intended for production use MUST NOT send a message with this Message 915 Type with the value zero (0) as the Vendor ID. If it receives a 916 message with this Message Type and with the value zero (0) as the 917 Vendor ID, it MUST ignore the message unless the NOSKIP bit is set, 918 in which case it MUST respond with a fatal Unsupported Mandatory 919 Message error code in a CLOSE batch. 921 4.5. PB-PA 923 The PB-TNC message type named PB-PA (value 1) contains one PA 924 message. Many batches will contain several PB-PA messages but some 925 batches may not contain any messages of this type. 927 All Posture Broker Client and Posture Broker Server implementations 928 MUST implement support for this PB-TNC message type. Generally, this 929 support will consist of forwarding the enclosed PA message to the 930 appropriate Posture Collectors and Posture Validators. Specific 931 requirements are contained later in the description of this message 932 type. 934 The type of the PA message contained in a PB-PA message is indicated 935 by the PA Message Vendor ID and PA Subtype fields, as described later 936 in this section. The PA-TNC specification [10] describes several 937 standard PA message types that can be identified by the PA Message 938 Vendor ID and PA Subtype values listed in the PA-TNC specification. 939 Other PA message types may also be defined, as described in the 940 description of the PA Subtype field later in this section. 942 The NOSKIP flag in the PB-TNC Message Header MUST be set for this 943 message type. Any Posture Broker Client or Posture Broker Server 944 that receives a PB-PA message with the NOSKIP flag not set MUST 945 ignore the message and MUST respond with a fatal Invalid Parameter 946 error code in a CLOSE batch. 948 For the PB-PA message type, the PB-TNC Vendor ID field MUST contain 949 the value zero (0) and the PB-TNC Message Type field MUST contain 1. 950 If a non-zero value is contained in the PB-TNC Vendor ID field, 951 message type 1 has a completely different meaning not defined in this 952 specification. 954 The PB-TNC Message Length field MUST contain the length of the entire 955 PB-TNC message, including the fixed-length fields at the start of the 956 PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message 957 Type, and PB-TNC Message Length), the fixed-length fields listed 958 below (Flags, PA Message Vendor ID, PA Subtype, Posture Collector 959 Identifier, and Posture Validator Identifier), and the PA Message 960 Body. Since the PA Message Body is variable length, the value in the 961 PB-TNC Message Length field will vary also. However, it MUST always 962 be at least 24 to cover the fixed-length fields listed in the 963 preceding sentences. Any Posture Broker Client or Posture Broker 964 Server that receives a PB-PA message with a PB-TNC Message Length 965 field that has an invalid value MUST respond with a fatal Invalid 966 Parameter error code in a CLOSE batch. 968 The following diagram illustrates the format and contents of the PB- 969 TNC Message Value field for this message type. The text after this 970 diagram describes the fields shown here. 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Flags | PA Message Vendor ID | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | PA Subtype | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Posture Collector Identifier | Posture Validator Identifier | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | PA Message Body (Variable Length) | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Flags (8 bits) 986 This field contains flags relating to the PA message. 988 Bit 0 of this flags field (the most significant bit) is known as 989 the EXCL flag (for exclusive). If the EXCL bit is cleared (value 990 0), the Posture Broker Client or Posture Broker Server that 991 receives this PB-TNC message SHOULD deliver the PA message 992 contained in this PB-TNC message to all Posture Collectors or 993 Posture Validators that have expressed an interest in PA messages 994 with this PA Message Vendor ID and PA subtype. If a Posture 995 Broker Client receives a message with the EXCL flag set (value 1), 996 the Posture Broker Client SHOULD deliver the PA message contained 997 in this PB-TNC message only to the Posture Collector identified by 998 the Posture Collector Identifier field. However, if the 999 identified Posture Collector has not expressed an interest in PA 1000 messages with this PA Message Vendor ID and PA subtype, the PA 1001 message should be silently discarded. Analogous requirements 1002 apply to a Posture Broker Server that receives a message with the 1003 EXCL flag set. 1005 The EXCL bit allows, for example, a Posture Validator to handle 1006 the circumstance where there are two Posture Collectors on the 1007 endpoint that are interested in a particular kind of PA messages 1008 and the Posture Validator has remediation instructions that only 1009 apply to one of those Posture Collectors. 1011 The other bits in this Flags field are reserved. For this version 1012 of PB-TNC, they MUST be set to 0 on transmission and ignored on 1013 reception. 1015 PA Message Vendor ID (24 bits) 1017 The PA Message Vendor ID field identifies a vendor by using the 1018 SMI Private Enterprise Number (PEN). Any organization can receive 1019 its own unique PEN from IANA, the Internet Assigned Numbers 1020 Authority. The PA Message Vendor ID qualifies the PA Subtype 1021 field so that each vendor has 2^32-1 separate PA subtypes 1022 available for its use. PA subtypes standardized by the IETF are 1023 always used with a PA Message Vendor ID of the value zero (0) in 1024 this field. The PA Message Vendor ID 0xffffff is reserved. A 1025 Posture Broker Client or Posture Broker Server MUST NOT send 1026 messages in which the PA Message Vendor ID field has this reserved 1027 value (0xffffff). If a Posture Broker Client or Posture Broker 1028 Server receives a message in which the PA Message Vendor ID has 1029 this reserved value (0xffffff), it MUST respond with a fatal 1030 Invalid Parameter error code in a CLOSE batch. 1032 PA Subtype (32 bits) 1034 The PA Subtype field identifies the type of the PA message 1035 contained in the PA Message Body field. The PA subtype 0xffffffff 1036 is reserved. A Posture Broker Client or Posture Broker Server 1037 MUST NOT send messages in which the PA Subtype field has this 1038 reserved value (0xffffffff). If a Posture Broker Client or 1039 Posture Broker Server receives a message in which the PA Subtype 1040 has this reserved value (0xffffffff), it MUST respond with a fatal 1041 Invalid Parameter error code in a CLOSE batch. A Posture Broker 1042 Client or Posture Broker Server MUST support having multiple PA 1043 messages in a single PB-TNC batch that have the same PA subtype 1044 and/or PA Message Vendor ID. 1046 IANA maintains a registry of PA subtypes. Entries in this 1047 registry are added by Expert Review with Specification Required, 1048 following the guidelines in section 6.1. No PA subtypes are 1049 defined in this specification. Definitions of IETF standard PA 1050 subtypes are contained in the PA-TNC specification [10] and other 1051 specifications. IETF standard PA subtypes are always used with a 1052 PA Message Vendor ID of zero (0). 1054 New vendor-specific PA subtypes (those used with a non-zero PA 1055 Message Vendor ID) may be defined and employed by vendors without 1056 IETF or IANA involvement. However, Posture Broker Clients and 1057 Posture Broker Servers MUST NOT require support for particular 1058 vendor-specific PA subtypes and MUST interoperate with other 1059 parties despite any differences in the set of vendor-specific PA 1060 subtypes supported (although they MAY permit administrators to 1061 configure them to require support for specific PA subtypes). 1063 Note that the PB-TNC Message Type field is completely separate 1064 from the PA Subtype field. The same value (e.g. 0) may have 1065 different meanings as a PB-TNC message type and as a PA subtype. 1067 Posture Collector Identifier (16 bits) 1069 The Posture Collector Identifier field contains the identifier of 1070 the Posture Collector associated with this PA message. 1072 The Posture Broker Client is responsible for assigning one or more 1073 Posture Collector Identifier values (but not 0xffff) to each 1074 Posture Collector involved in a message exchange. Multiple Posture 1075 Collector identifiers are required for appropriate correlation in 1076 cases where there are multiple components of the same type handled 1077 by a single Posture Collector, e.g. an endpoint with two VPN 1078 client implementations handled by a single VPN Posture Collector. 1079 Please refer to Section 3.3 of the PA-TNC specification for an 1080 example that illustrates the use of multiple Posture Collector 1081 Identifiers. The Posture Collector Identifier value(s) assigned to 1082 a Posture Collector by a Posture Broker Client MUST NOT change 1083 during the course of a PT session. This identifier is used to 1084 identify a unique Posture Collector communicating with the Posture 1085 Broker Client on the endpoint during a NEA exchange, and is used 1086 by the Posture Validator to send response attributes to a specific 1087 Posture Collector component if required. 1089 When a Posture Broker Server sets the EXCL flag for a PA message, 1090 the Posture Broker Server MUST set the Posture Collector 1091 Identifier field to the identifier of the Posture Collector that 1092 should receive the PA message. If the EXCL flag is not set, a 1093 Posture Broker Server MAY still set the Posture Collector 1094 Identifier value for PA messages that it sends to indicate that 1095 the PA message is intended as a response to a message sent by the 1096 Posture Collector associated with the specified Posture Collector 1097 Identifier. If the Posture Broker Server does not wish to 1098 indicate any Posture Collector in this manner, it SHOULD set this 1099 field to the reserved value 0xffff. 1101 Posture Validator Identifier (16 bits) 1103 The Posture Validator Identifier field contains the identifier of 1104 the Posture Validator associated with this PA message. 1106 The Posture Broker Server MUST assign a unique Posture Validator 1107 Identifier value (but not 0xffff) to each Posture Validator 1108 involved in a message exchange and include this Posture Validator 1109 identifier in this field for any PA messages sent by that Posture 1110 Validator. The Posture Validator Identifier value assigned to a 1111 Posture Validator by a Posture Broker Server MUST NOT change 1112 during the course of a PT session. This identifier is used to 1113 identify a unique Posture Validator communicating with the Posture 1114 Broker Server endpoint during a NEA exchange, and is used by the 1115 Posture Collector to send attributes to a specific Posture 1116 Validator if required. 1118 When a Posture Broker Client sets the EXCL flag for a PA message, 1119 the Posture Broker Client MUST set the Posture Validator 1120 Identifier field to the identifier of the Posture Validator that 1121 should receive the PA message. If the EXCL flag is not set, a 1122 Posture Broker Client MAY still set the Posture Validator 1123 Identifier value for PA messages that it sends to indicate that 1124 the PA message is intended as a response to a message sent by the 1125 Posture Validator associated with the specified Posture Validator 1126 Identifier. If the Posture Broker Server does not wish to 1127 indicate any Posture Validator in this manner, it SHOULD set this 1128 field to the reserved value 0xffff. 1130 PA Message Body (variable length) 1132 The PA Message Body field contains the body of the PA message that 1133 is being carried in this PB-TNC message. The length of this field 1134 can be determined by subtracting the length of the fixed-length 1135 fields at the start of the PB-TNC message (the fields Flags, PB- 1136 TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and 1137 the fixed-length fields at the start of the PB-PA message (Flags, 1138 PA Message Vendor ID, PA Subtype, Posture Collector Identifier, 1139 and Posture Validator Identifier) from the message length 1140 contained in the PB-TNC Message Length field. The length of these 1141 fixed-length fields is 24 octets. Therefore, any Posture Broker 1142 Client or Posture Broker Server that receives a PB-PA message with 1143 a PB-TNC Message Length field whose value is less than 24 MUST 1144 respond with a fatal Invalid Parameter error code in a CLOSE 1145 batch. 1147 4.6. PB-Assessment-Result 1149 The PB-TNC message type named PB-Assessment-Result (value 2) is used 1150 by the Posture Broker Server to provide the assessment result after 1151 the Posture Broker Server has completed the assessment of the 1152 endpoint. The Posture Broker Server will typically compute the 1153 assessment result as a cumulative of the individual assessment 1154 results received from the various Posture Validators; the algorithm 1155 for computation of assessment result at the Posture Broker layer is 1156 implementation specific and can also change based on policies in a 1157 specific deployment. The Posture Broker Server MUST include one 1158 message of this type in any batch of type RESULT and MUST NOT include 1159 a message of this type in any other type of batch. The Posture 1160 Broker Client MUST NOT send a PB-TNC message with this message type. 1161 If a Posture Broker Server receives a PB-TNC message with this 1162 message type, it MUST respond with a fatal Invalid Parameter error in 1163 a CLOSE batch. The Posture Broker Client MUST implement and process 1164 this message and MUST ignore any message with this message type that 1165 is not part of a batch of type RESULT. 1167 The NOSKIP flag in the PB-TNC Message Header MUST be set for this 1168 message type. The PB-TNC Vendor ID field MUST contain the value zero 1169 (0) and the PB-TNC Message Type field MUST contain 2. If a non-zero 1170 value is contained in the PB-TNC Vendor ID field, message type 2 has 1171 a completely different meaning not defined in this specification. 1172 The PB-TNC Message Length field MUST contain the value 16 since that 1173 is the total of the length of the fixed-length fields at the start of 1174 the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC 1175 Message Type, and PB-TNC Message Length) along with the Assessment 1176 Result field described below. Any Posture Broker Client or Posture 1177 Broker Server that receives a PB-Assessment-Result message with a PB- 1178 TNC Message Length field that does not have a value of 16 MUST 1179 respond with a fatal Invalid Parameter error code in a CLOSE batch. 1181 The following diagram illustrates the format and contents of the PB- 1182 TNC Message Value field for this message type. The text after this 1183 diagram describes the fields shown here. 1185 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Assessment Result | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 Assessment Result 1193 This 32-bit field MUST contain one of the following values 1195 Value Description 1196 ----- ----------- 1197 0 Posture Broker Server assessed the endpoint to be compliant 1198 with policy. 1200 1 Posture Broker Server assessed the endpoint to be non- 1201 compliant with policy but the difference from compliance 1202 was minor. 1204 2 Posture Broker Server assessed the endpoint to be non- 1205 compliant with policy and the assessed difference from 1206 compliance was very significant. 1208 3 Posture Broker Server was unable to determine policy 1209 compliance due to an error. 1211 4 Posture Broker Server was unable to determine whether the 1212 assessed endpoint is compliant with policy based on the attributes 1213 provided by endpoint. 1215 If a Posture Broker Client receives an Assessment Result value 1216 other than the five values described above, it MUST respond with a 1217 fatal Invalid Parameter error in a CLOSE batch. Other values may 1218 be defined in future versions of PB-TNC but only if the PB-TNC 1219 version number is changed. Therefore, there is no need for an 1220 IANA registry for Assessment Result values. 1222 4.7. PB-Access-Recommendation 1224 The PB-TNC message type named PB-Access-Recommendation (value 3) is 1225 used by the Posture Broker Server to provide an access recommendation 1226 after the Posture Broker Server has completed some assessment of the 1227 endpoint. The PB-Assessment-Result and the PB-Access-Recommendation 1228 attribute together constitute the global assessment decision for an 1229 endpoint. The PB-Access-Recommendation is not authoritative and the 1230 network and host-based access control systems would typically use 1231 additional information to determine the network access that is 1232 granted to the endpoint. The Posture Broker Server MAY include one 1233 message of this type in any batch of type RESULT and MUST NOT include 1234 a message of this type in any other type of batch. Posture Broker 1235 Clients MUST NOT send a PB-TNC message with this message type. If a 1236 Posture Broker Server receives a PB-TNC message with this message 1237 type, it MUST respond with a fatal Invalid Parameter error in a CLOSE 1238 batch. The Posture Broker Client MUST implement and process this 1239 message and MUST ignore any message with this message type that is 1240 not part of a batch of type RESULT. 1242 The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this 1243 message type. Any Posture Broker Client or Posture Broker Server 1244 that receives a PB-Access-Recommendation message with the NOSKIP flag 1245 set MUST ignore the message and MUST respond with a fatal Invalid 1246 Parameter error code in a CLOSE batch. The PB-TNC Vendor ID field 1247 MUST contain the value zero (0) and the PB-TNC Message Type field 1248 MUST contain 3. If a non-zero value is contained in the PB-TNC 1249 Vendor ID field, message type 3 has a completely different meaning 1250 not defined in this specification. The PB-TNC Message Length field 1251 MUST contain the value 16 since that is the total of the length of 1252 the fixed-length fields at the start of the PB-TNC message (the 1253 fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC 1254 Message Length) along with the Access Recommendation field described 1255 below. Any Posture Broker Client or Posture Broker Server that 1256 receives a PB-Access-Recommendation message with a PB-TNC Message 1257 Length field that does not have a value of 16 MUST respond with a 1258 fatal Invalid Parameter error code in a CLOSE batch. 1260 The following diagram illustrates the format and contents of the PB- 1261 TNC Message Value field for this message type. The text after this 1262 diagram describes the fields shown here. 1264 0 1 2 3 1265 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 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Reserved | Access Recommendation Code | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 Reserved (16 bits) 1272 These Reserved bits MUST be set to 0 on transmission and ignored 1273 on reception. 1275 Access Recommendation Code (16 bits) 1277 The Access Recommendation Code field identifies the Access 1278 Recommendation that the Posture Broker Server has made for this 1279 Posture Broker Client at this time. This field MUST have one of 1280 these three values: 1 for Access Allowed (full access), 2 for 1281 Access Denied (no access), or 3 for Quarantined (partial access). 1282 If a Posture Broker Client receives an Access Recommendation Code 1283 value other than these three values, it MUST respond with a fatal 1284 Invalid Parameter error code in a CLOSE batch. Other values may 1285 be defined in future versions of PB-TNC but only if the PB-TNC 1286 version number is changed. Therefore, there is no need for an 1287 IANA registry for Access Recommendation Codes. 1289 4.8. PB-Remediation-Parameters 1291 The PB-TNC message type named PB-Remediation-Parameters (value 4) is 1292 used by the Posture Broker Server to provide global (not Posture 1293 Validator-specific) remediation parameters after the Posture Broker 1294 Server has completed some assessment of the endpoint. The Posture 1295 Broker Server MAY include one or more messages of this type in any 1296 batch of any type but this message type is most useful in batches of 1297 type RESULT. 1299 The Posture Broker Client MUST NOT send a PB-TNC message with this 1300 message type. If a Posture Broker Server receives a PB-TNC message 1301 with this message type, it MUST respond with a fatal Invalid 1302 Parameter error in a CLOSE batch. The Posture Broker Client may 1303 implement and process this message but is not required to do so. It 1304 may skip this message. Even if the Posture Broker Client implements 1305 this message type, it is not obligated to act on it. 1307 The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this 1308 message type. The PB-TNC Vendor ID field MUST contain the value zero 1309 (0) and the PB-TNC Message Type field MUST contain 4. If a non-zero 1310 value is contained in the PB-TNC Vendor ID field, message type 4 has 1311 a completely different meaning not defined in this specification. 1313 The PB-TNC Message Length field MUST contain the length of the entire 1314 PB-TNC message, including the fixed-length fields at the start of the 1315 PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message 1316 Type, and PB-TNC Message Length), the fixed-length fields listed 1317 below (Reserved, Remediation Parameters Vendor ID, and Remediation 1318 Parameters Type), and the Remediation Parameters. Since the 1319 Remediation Parameters field is variable length, the value in the PB- 1320 TNC Message Length field will vary also. However, it MUST always be 1321 at least 20 to cover the fixed-length fields listed in the preceding 1322 sentences. Any Posture Broker Client that receives a PB-Remediation- 1323 Parameters message with a PB-TNC Message Length field that contains 1324 an invalid value (e.g. less than 20) MUST respond with a fatal 1325 Invalid Parameter error code in a CLOSE batch. 1327 The following diagram illustrates the format and contents of the PB- 1328 TNC Message Value field for this message type. The text after this 1329 diagram describes the fields shown here. 1331 0 1 2 3 1332 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 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Reserved | Remediation Parameters Vendor ID | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Remediation Parameters Type | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Remediation Parameters (Variable Length) | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 Reserved (8 bits) 1343 These Reserved bits MUST be set to 0 on transmission and ignored 1344 on reception. 1346 Remediation Parameters Vendor ID (24 bits) 1348 The Remediation Parameters Vendor ID field identifies a vendor by 1349 using the SMI Private Enterprise Number (PEN). Any organization 1350 can receive its own unique PEN from IANA, the Internet Assigned 1351 Numbers Authority. The Remediation Parameters Vendor ID qualifies 1352 the Remediation Parameters Type field so that each vendor has 2^32 1353 separate Remediation Parameters Types available for its use. 1354 Remediation Parameters Types standardized by the IETF are always 1355 used with the value zero (0) in this field. 1357 Remediation Parameters Type (32 bits) 1359 The Remediation Parameters Type field identifies the type of 1360 remediation parameters contained in the Remediation Parameters 1361 field. A Posture Broker Client or Posture Broker Server MUST 1362 support having multiple Remediation Parameters messages contained 1363 in a single PB-TNC batch that have the same Remediation Parameters 1364 Type and/or Remediation Parameters Vendor ID. 1366 IANA maintains a registry of PB-TNC Remediation Parameters Types. 1367 Entries in this registry are added by Expert Review with 1368 Specification Required, following the guidelines in section 6.1. 1369 A list of IETF Standard PB-TNC Remediation Parameters Types 1370 defined in this specification appears later in this section. 1372 New vendor-specific Remediation Parameters Types (those used with 1373 a non-zero Remediation Parameters vendor ID) may be defined and 1374 employed by vendors without IETF or IANA involvement. However, 1375 Posture Broker Clients and Posture Broker Servers MUST NOT require 1376 support for particular vendor-specific Remediation Parameters 1377 Types and MUST interoperate with other parties despite any 1378 differences in the set of vendor-specific Remediation Parameters 1379 Types supported (although they MAY permit administrators to 1380 configure them to require support for specific Remediation 1381 Parameters Types). 1383 Note that the Remediation Parameters Type is completely separate 1384 from the PB-TNC Message Type and the PA Subtype fields. The same 1385 value (e.g. 0) may have different meanings in each of these 1386 fields. 1388 Remediation Parameters (variable length) 1390 The Remediation Parameters field contains the actual remediation 1391 parameters carried in this PB-TNC message. The length of this 1392 field can be determined by subtracting the length of the fixed- 1393 length fields at the start of the PB-TNC message (the fields 1394 Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message 1395 Length) and the fixed-length fields at the start of the PB- 1396 Remediation-Parameters message (Reserved, Remediation Parameters 1397 Vendor ID, and Remediation Parameters Type) from the message 1398 length contained in the PB-TNC Message Length field. The length 1399 of these fixed-length fields is 20 octets. Therefore, any Posture 1400 Broker Client that receives a PB-Remediation-Parameters message 1401 with a PB-TNC Message Length field whose value is less than 20 1402 MUST consider this a malformed message. The Posture Broker Client 1403 MUST respond with a fatal Invalid Parameter error code in a CLOSE 1404 batch. 1406 4.8.1. IETF Standard PB-TNC Remediation Parameters Types 1408 This subsection defines several Remediation Parameters Types that 1409 have been standardized by the IETF. 1411 Remediation-URI 1413 This Remediation Parameters Type is employed by creating a PB- 1414 Remediation-Parameters message with a Remediation Parameters 1415 Vendor ID equal to the value zero (0) and a Remediation Parameters 1416 Type of 1. The Remediation Parameters field in the PB- 1417 Remediation-Parameters message MUST contain a URI, as described in 1418 RFC 3986 [2]. This URI contains instructions and resources for 1419 remediation. The Posture Broker Client MAY load the URI and 1420 display the resulting web page to the user. The Posture Broker 1421 Client MAY also ignore the URI or take another action with it. 1422 The Posture Broker Server and any other parties involved in 1423 configuring this remediation URI should consider the likely 1424 capabilities of the Posture Broker Client when creating the URI 1425 and the content referenced by the URI. For example, they should 1426 consider the Posture Broker Client's language preferences as 1427 expressed in the PB-Language-Preference message. 1429 Remediation-String 1431 This Remediation Parameters Type is employed by creating a PB- 1432 Remediation-Parameters message with a Remediation Parameters 1433 Vendor ID equal to the value zero (0) and a Remediation Parameters 1434 Type of 2. The Remediation Parameters field in the PB- 1435 Remediation-Parameters message MUST contain the structure defined 1436 below, which contains human-readable instructions for remediation. 1438 The Posture Broker Client MAY display the instructions to the 1439 user. The Posture Broker Client MAY also ignore the instructions 1440 or take another action with them. The Posture Broker Server and 1441 any other parties involved in configuring these instructions 1442 should consider the likely capabilities of the Posture Broker 1443 Client when creating the instructions. For example, they should 1444 consider the Posture Broker Client's language preferences as 1445 expressed in the PB-Language-Preference message. 1447 The following diagram illustrates the format and contents of the 1448 Remediation Parameters field when carrying a Remediation-String 1449 parameter. The text after this diagram describes the fields shown 1450 here. 1452 1 2 3 1453 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 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Remediation String Length | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Remediation String (Variable Length) | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Lang Code Len | Remediation String Lang Code (Variable Len) | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 Remediation String Length (32 bits) 1464 The Remediation String Length contains the length of the 1465 Remediation String field in octets. 1467 Remediation String (variable length) 1469 The Remediation String field MUST contain a UTF-8 [6] encoded 1470 string. This string contains human-readable instructions for 1471 remediation that MAY be displayed to the user by the Posture 1472 Broker Client. NUL termination MUST NOT be included. If a Posture 1473 Broker Client receives a Reason String that does contain a NUL 1474 termination, it MUST respond with a fatal Invalid Parameter error 1475 in a CLOSE batch. 1477 Lang Code Len (8 bits) 1479 The Lang Code Len field contains the length of the Remediation 1480 String Lang Code field in octets. This value may be set to zero to 1481 indicate that the language code for the Remediation String field 1482 is not known. 1484 Remediation String Lang Code (variable length) 1486 The Remediation String Lang Code field contains a US-ASCII string 1487 comprised of a well-formed RFC 4646 [3] language tag that 1488 indicates the language(s) used in the Remediation String in the 1489 Remediation Parameters field. A zero length string may be sent 1490 for this field (essentially omitting this field) to indicate that 1491 the language code for the Remediation String field is not known. 1493 4.9. PB-Error 1495 The PB-TNC message type named PB-Error (value 5) is used by the 1496 Posture Broker Client or Posture Broker Server to indicate that an 1497 error has occurred. The Posture Broker Client or Posture Broker 1498 Server MAY include one or more messages of this type in any batch of 1499 any type. Other messages may also be included in the same batch. 1500 The party that receives a PB-Error message MAY log it or take other 1501 action as deemed appropriate. If the FATAL flag is set (value 1), 1502 the recipient MUST terminate the PB-TNC session after processing the 1503 batch without sending any messages in response. Every Posture Broker 1504 Client and Posture Broker Server MUST implement this message type. 1506 The NOSKIP flag in the PB-TNC Message Header MUST be set for this 1507 message type. The PB-TNC Vendor ID field MUST contain the value zero 1508 (0) and the PB-TNC Message Type field MUST contain 5. If a non-zero 1509 value is contained in the PB-TNC Vendor ID field, message type 5 has 1510 a completely different meaning not defined in this specification. 1512 The PB-TNC Message Length field MUST contain the length of the entire 1513 PB-TNC message, including the fixed-length fields at the start of the 1514 PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message 1515 Type, and PB-TNC Message Length), the fixed-length fields listed 1516 below (Flags, Error Code Vendor ID, Error Code, and Reserved), and 1517 the Error Parameters. Since the Error Parameters field is variable 1518 length, the value in the PB-TNC Message Length field will vary also. 1520 However, it MUST always be at least 20 to cover the fixed-length 1521 fields listed in the preceding sentences. Any Posture Broker Client 1522 or Posture Broker Server that receives a PB-Error message with a PB- 1523 TNC Message Length field that contains an invalid value (e.g. less 1524 than 20) MUST respond with a fatal Invalid Parameter error code in a 1525 CLOSE batch. Any PB-Error message generated while processing a PB- 1526 Error message MUST be a fatal error to avoid the chance of generating 1527 an infinite loop of errors. 1529 The following diagram illustrates the format and contents of the PB- 1530 TNC Message Value field for this message type. The text after this 1531 diagram describes the fields shown here. 1533 0 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Flags | Error Code Vendor ID | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Error Code | Reserved | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | Error Parameters (Variable Length) | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 Flags (8 bits) 1545 This field defines flags relating to the error. 1547 Bit 0 of this flags field (the most significant bit) is known as 1548 the FATAL flag. If the FATAL bit is cleared (value 0), the 1549 Posture Broker Client or Posture Broker Server that receives this 1550 PB-TNC message SHOULD process this error and then continue with 1551 the exchange. If the FATAL flag is set (value 1), the Posture 1552 Broker Client or Posture Broker Server that receives this PB-TNC 1553 message MUST terminate the exchange after processing the error. In 1554 addition, any Posture Broker Client or Posture Broker Server that 1555 sends a fatal error MUST NOT process the batch that caused the 1556 error and MUST terminate the exchange after sending the batch 1557 containing the error report. A PB-Error message with the FATAL 1558 flag set MUST always be sent in a CLOSE batch since the sender 1559 will be terminating the exchange immediately after sending the 1560 batch. 1562 The FATAL bit allows a Posture Broker Client or Posture Broker 1563 Server to signal a fatal error (like an invalid batch type) and/or 1564 a non-fatal error (like an invalid language tag for a preferred 1565 language). 1567 The other bits in this Flags field are reserved. For this version 1568 of PB-TNC, they MUST be set to 0 on transmission and ignored on 1569 reception. 1571 Error Code Vendor ID (24 bits) 1573 The Error Code Vendor ID field identifies a vendor by using the 1574 SMI Private Enterprise Number (PEN). Any organization can receive 1575 its own unique PEN from IANA, the Internet Assigned Numbers 1576 Authority. The Error Code Vendor ID qualifies the Error Code 1577 field so that each vendor has 2^16 separate Error Codes available 1578 for its use. Error codes standardized by the IETF are always used 1579 with the value zero (0) in this field. For detailed descriptions 1580 of those messages, see the next few subsections. 1582 Error Code (16 bits) 1584 The Error Code field identifies the type of error being signaled 1585 with this message. The format of the Error Parameters field 1586 depends on the value of the Error Code Vendor ID and the Error 1587 Code. However, any recipient that does not understand a 1588 particular error code can process the error fairly well by using 1589 the FATAL flag to determine whether the error is fatal and the PB- 1590 TNC Message Length to skip over the Error Parameters field (or log 1591 it). 1593 IANA maintains a registry of PB-TNC Error Codes. Entries in this 1594 registry are added by Expert Review with Specification Required, 1595 following the guidelines in section 6.1. A list of IETF Standard 1596 PB-TNC Error Codes defined in this specification appears later in 1597 section 4.9.1. 1599 New vendor-specific error codes (those used with a non-zero error 1600 code vendor ID) may be defined and employed by vendors without 1601 IETF or IANA involvement. Posture Broker Clients and Posture 1602 Broker Servers that receive an unknown error code MUST process 1603 this error code gracefully by ignoring or logging it if it is not 1604 marked as fatal and terminating the exchange if it is marked as 1605 fatal. 1607 Reserved (16 bits) 1609 The Reserved bits MUST be set to 0 on transmission and ignored on 1610 reception. 1612 4.9.1. IETF Standard PB-TNC Error Codes 1614 The following error codes are IETF Standard PB-TNC Error Codes, hence 1615 the Error Code Vendor ID MUST be the value zero (0). The following 1616 table defines the 16 bit Error Code. Vendor-specific error codes may 1617 be defined by setting the Error Code Vendor ID to the defining 1618 vendor's SMI PEN and setting the Error Code field to whatever error 1619 code(s) that vendor has defined. The format, length, and meaning of 1620 the Error Parameters field varies, based on the Error Code Vendor ID 1621 and Error Code. Subsequent sections of this document define the 1622 format, length, and meaning of the Error Parameters for the IETF 1623 Standard PB-TNC Error Codes defined in this section. 1625 Error Code Definition 1626 ---------- ---------- 1627 0 Unexpected Batch Type. Error Parameters are empty. 1628 1 Invalid Parameter. Error Parameters has offset where 1629 invalid value was found. 1630 2 Local Error. Error Parameters are empty. 1631 3 Unsupported Mandatory Message. Error Parameters has 1632 offset of offending PB-TNC Message 1633 4 Version Not Supported. Error Parameters has information 1634 about which versions are supported. 1636 4.9.2. Error Parameters Structures for IETF Standard PB-TNC Error Codes 1638 This section defines the format, length, and meaning of the Error 1639 Parameters field for the IETF Standard PB-TNC Error Codes defined in 1640 this specification. 1642 The Error Parameters field is zero length for the IETF Standard PB- 1643 TNC Error Code 0. The FATAL flag MUST be set for this error code. 1645 The Error Parameters field has the following structure for the IETF 1646 Standard PB-TNC Error Code 1. The Offset field is the offset in 1647 octets from the start of the PB-TNC batch to the invalid value. The 1648 FATAL flag may either be set or cleared for this error code. 1650 0 1 2 3 1651 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 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | Offset | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 The Error Parameters field is zero length for the IETF Standard PB- 1657 TNC Error Code 2. The FATAL flag MUST be set for this error code. 1659 The Error Parameters field has the following structure for the IETF 1660 Standard PB-TNC Error Code 3. The Offset field is the offset in 1661 octets from the start of the PB-TNC batch to the PB-TNC message whose 1662 message type was not recognized (and where the NOSKIP flag was set). 1663 The FATAL flag MUST be set for this error code. 1665 0 1 2 3 1666 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 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | Offset | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 The Error Parameters field has the following structure for the IETF 1672 Standard PB-TNC Error Code 4. The FATAL flag MUST be set for this 1673 error code. 1675 0 1 2 3 1676 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 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | Bad Version | Max Version | Min Version | Reserved | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 The Bad Version field is the version number that was received 1682 and is not supported. The Max Version and Min Version fields 1683 indicate which PB-TNC version numbers are supported by the 1684 sender of the error code. The sender MUST support all PB-TNC 1685 versions between the Min Version and the Max Version, inclusive 1686 (i.e. including the Min Version and the Max Version) but 1687 excluding the reserved versions listed in section 4.1. The 1688 Reserved field MUST be set to 0 on transmission and ignored 1689 upon reception. When possible, recipients of this error code 1690 SHOULD send future messages to the Posture Broker Server or 1691 Posture Broker Client that originated this error message with a 1692 PB-TNC version number within the stated range. 1694 Any party that is sending the Version Not Supported error code 1695 MUST include that error code as the only PB-TNC message in a 1696 PB-TNC CLOSE batch with version number 2. All parties that send 1697 PB-TNC batches SHOULD be able to properly process a batch that 1698 meets this description, even if they cannot process any other 1699 aspect of PB-TNC version 2. This ensures that a PB-TNC version 1700 exchange can proceed properly, no matter what versions of PB- 1701 TNC the parties implement. 1703 4.10. PB-Language-Preference 1705 The PB-TNC message type named PB-Language-Parameters (value 6) is 1706 used by the Posture Broker Client to indicate which language or 1707 languages it would prefer for any human-readable strings that might 1708 be sent to it. This allows the Posture Broker Server and Posture 1709 Validators to adapt any messages they may send to the Posture Broker 1710 Client's preferences (probably determined by the language preferences 1711 of the endpoint's users). 1713 The Posture Broker Server may also send this message type to the 1714 Posture Broker Client to indicate the Posture Broker Server's 1715 language preferences but this is not very useful since the Posture 1716 Broker Client rarely sends human-readable strings to the Posture 1717 Broker Server and, if it does, rarely can adapt those strings to the 1718 preferences of the Posture Broker Server. 1720 No Posture Broker Client or Posture Broker Server is required to send 1721 or implement this message type. However, a Posture Broker Server 1722 SHOULD attempt to adapt to user language preferences by implementing 1723 this message type, passing the language preference information to 1724 Posture Validators, and allowing administrators to configure human- 1725 readable languages in whatever languages are preferred by their 1726 users. 1728 A Posture Broker Client or Posture Broker Server may include a 1729 message of this type in any batch of any type. However, it is 1730 suggested that this message be included in the first batch sent by 1731 the Posture Broker Client or Posture Broker Server in a PB-TNC 1732 session so that the recipient can start adapting its human-readable 1733 messages as soon as possible. If one PB-Language-Parameters message 1734 is received and then another one is received in a later batch for the 1735 same PB-TNC session, the value included in the later message should 1736 be considered to replace the value in the earlier message. 1738 A Posture Broker Client or Posture Broker Server MUST NOT include 1739 more than one message of this type in a single batch. If a Posture 1740 Broker Client or Posture Broker Server receives more than one message 1741 of this type in a single batch, it should ignore all but the last 1742 one. 1744 The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this 1745 message type. The PB-TNC Vendor ID field MUST contain the value zero 1746 (0) and the PB-TNC Message Type field MUST contain 6. If a non-zero 1747 value is contained in the PB-TNC Vendor ID field, message type 6 has 1748 a completely different meaning not defined in this specification. 1750 The PB-TNC Message Length field MUST contain the length of the entire 1751 PB-TNC message, including the fixed-length fields at the start of the 1752 PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message 1753 Type, and PB-TNC Message Length) and the Language Preference field. 1754 Since the Language Preference field is variable length, the value in 1755 the PB-TNC Message Length field will vary also. However, it MUST 1756 always be at least 12 to cover the fixed-length fields listed in the 1757 preceding sentences. 1759 The following diagram illustrates the format and contents of the PB- 1760 TNC Message Value field for this message type. The text after this 1761 diagram describes the fields shown here. 1763 0 1 2 3 1764 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 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | Language Preference (Variable Length) | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 Language Preference (variable length) 1771 The Language Preference field contains an Accept-Language header, 1772 as described in RFC 3282 [4] (using the RFC 2234 ABNF definition 1773 of Accept-Language included in that RFC, US-ASCII only, no control 1774 characters allowed, no comments, no NUL termination). Any Posture 1775 Broker Client or Posture Broker Server that sends a PB-Language- 1776 Preference message MUST ensure that the Language Preference field 1777 conforms to this format. For example, one acceptable value would 1778 be "Accept-Language: fr, en" (without the quote marks). 1780 A zero length Language Preference field indicates that no language 1781 preference information is available. Generally, there's no need 1782 to send a PB-Language-Preference message with a zero length 1783 Language Preference field since this is equivalent to sending no 1784 PB-Language-Preference message at all but it may be useful to send 1785 a zero length Language Preference field if a PB-Language- 1786 Preference message with a non-zero length Language Preference 1787 field was sent in an earlier batch but these preferences no longer 1788 apply. 1790 4.11. PB-Reason-String 1792 The PB-TNC message type named PB-Reason-String (value 7) is used by 1793 the Posture Broker Server to provide a human-readable explanation for 1794 the global assessment decision conveyed in the PB-Assessment-Result & 1795 PB-Access-Recommendation messages. Therefore, a PB-Reason-String 1796 message SHOULD only be included in the same batch as the PB- 1797 Assessment-Result and PB-Access-Recommendation message. The Posture 1798 Broker Client MUST NOT ever send a PB-Reason-String message. 1800 The Posture Broker Client is not required to implement this message 1801 type and the Posture Broker Server is not required to send it. 1802 However, there is some benefit to doing so since users are often 1803 curious about why the endpoint was considered non-compliant. The 1804 manner in which a Posture Broker Client uses this field is up to the 1805 implementer and not specified here. The Posture Broker Client MAY 1806 display the message to the user, log it, ignore it, or take any other 1807 action that is not inconsistent with the requirements of this 1808 specification. Since the strings contained in this message are 1809 human-readable, the Posture Broker Server SHOULD adapt them to the 1810 Posture Broker Client's language preferences as expressed in any PB- 1811 Language-Preference message sent by the Posture Broker Client in this 1812 PB-TNC session. 1814 A Posture Broker Server MAY include more than one message of this 1815 type in any batch of any type. However, it is suggested that this 1816 message be included in the same batch as the PB-Assessment-Result and 1817 PB-Access-Recommendation message. If more than one PB-Reason-String 1818 message is included in a single batch, the Posture Broker Client 1819 SHOULD consider the strings included in these messages to be 1820 equivalent in meaning. This allows the Posture Broker Server to 1821 return multiple equivalent reason strings in different languages, 1822 which may help if the Posture Broker Server is not able to 1823 accommodate the Posture Broker Client's language preferences. 1825 The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this 1826 message type. The PB-TNC Vendor ID field MUST contain the value zero 1827 (0) and the PB-TNC Message Type field MUST contain 7. If a non-zero 1828 value is contained in the PB-TNC Vendor ID field, message type 7 has 1829 a completely different meaning not defined in this specification. 1831 The PB-TNC Message Length field MUST contain the length of the entire 1832 PB-TNC message, including the fixed-length fields at the start of the 1833 PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message 1834 Type, and PB-TNC Message Length), the fixed-length fields listed 1835 below (Reason String Length and Lang Code Len), and the Reason String 1836 and Reason String Language Code fields. Since the Reason String and 1837 Reason String Language Code fields are variable length, the value in 1838 the PB-TNC Message Length field will vary also. However, it MUST 1839 always be at least 17 to cover the fixed-length fields listed in the 1840 preceding sentences. In fact, the PB-TNC Message Length field MUST 1841 be exactly the sum of 17 (for the fixed-length fields) and the values 1842 of the Reason String Length and Lang Code Len fields. If this is not 1843 the case, the recipient MUST respond with a fatal Invalid Parameter 1844 error code in a CLOSE batch. 1846 The following diagram illustrates the format and contents of the PB- 1847 TNC Message Value field for this message type. The text after this 1848 diagram describes the fields shown here. 1850 0 1 2 3 1851 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 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Reason String Length | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | Reason String (Variable Length) | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Lang Code Len | Reason String Language Code (Variable Length) | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 Reason String Length (32 bits) 1862 The Reason String Length field contains the length of the Reason 1863 String field in octets. 1865 Reason String (variable length) 1867 The Reason String field contains a UTF-8 encoded string that 1868 provides a human-readable reason for the Posture Broker Server's 1869 assessment decision. NUL termination MUST NOT be included. If a 1870 Posture Broker Client receives a Reason String that does contain a 1871 NUL termination, it MUST respond with a fatal Invalid Parameter 1872 error code in a CLOSE batch. A zero length string MUST NOT be 1873 sent since this is the same as sending no reason string at all, 1874 leaving the reason unspecified. 1876 Lang Code Len (8 bits) 1878 The Lang Code Len field contains the length of the Reason String 1879 Language Code field in octets. 1881 Reason String Language Code (variable length) 1883 The Reason String Language Code field contains a US-ASCII string 1884 containing a well-formed RFC 4646 [3] language tag that indicates 1885 the language(s) used in the Reason String in this message. NUL 1886 termination MUST NOT be included in this field. A zero length 1887 string MAY be sent for this field (essentially omitting this 1888 field) to indicate that the language code for the reason string is 1889 not known. 1891 5. Security Considerations 1893 PT is required and assumed to provide reliable and secure transport 1894 for the PB-TNC protocol (including authentication, confidentiality, 1895 integrity protection, and replay protection). Still, it is useful to 1896 describe the possible threats to PB-TNC and the countermeasures that 1897 are or can be employed. This section does that. 1899 5.1. Threat Model 1901 There are several possible threats to the PB-TNC protocol. 1903 Untrusted intermediaries on the network between the NEA Client and 1904 the NEA Server may attempt to observe data sent between the Posture 1905 Broker Client and the Posture Broker Server via PB-TNC, modify this 1906 data in transit, reorder it, or replay it. They may also attempt to 1907 mount a denial of service attack against either party or truncate the 1908 exchange prematurely. If successful, these attacks may result in 1909 improper assessment decisions relating to the NEA Client, failure to 1910 reassess these decisions in light of changed circumstances, improper 1911 remediation instructions sent to the NEA Client (which could lead to 1912 the compromise of the NEA Client), unauthorized access to 1913 confidential information about the NEA Client's health and/or 1914 identity, improper reason strings or other messages that might be 1915 displayed to the user, access to reusable credentials such as posture 1916 assertions, denial of service on the NEA Client, and even complete 1917 denial of access to the network (if a denial of service attack 1918 against the NEA Server was successful and the network required 1919 permission from the NEA Server to grant network access). 1921 Trusted intermediaries between the Posture Broker Client and the 1922 Posture Broker Server include the Posture Transport Client and the 1923 Posture Transport Server. These parties are considered trusted 1924 because they are responsible for properly implementing the security 1925 protections provided by PT. If they fail to do so properly, these 1926 security protections may be diminished or eliminated altogether. The 1927 possible attacks are the same as those listed in the previous 1928 paragraph. To give one fairly likely example, if a Posture Transport 1929 Client fails to properly authenticate and authorize the Posture 1930 Transport Server (whether through implementation error or through 1931 user configuration to "trust anyone"), the improperly authorized 1932 Posture Transport Server may mount any of the previously described 1933 attacks against the NEA Client. 1935 Compromise of any of the trusted parties (the Posture Broker Client, 1936 the Posture Transport Client, the Posture Broker Server, or the 1937 Posture Transport Server) may result in failures that are equivalent 1938 to those listed in the first paragraph. These failures may be even 1939 more dangerous since they will not be detectable by observing network 1940 traffic or by examining and comparing audit logs. Failure to 1941 properly secure communications between the Posture Broker Client and 1942 the Posture Transport Client or between the Posture Broker Server and 1943 the Posture Transport Server is usually indistinguishable from 1944 compromise of those parties. Compromise of the operating system or 1945 other critical software, firmware, or hardware components on the NEA 1946 Client or NEA Server will typically result in an equivalent result. 1947 And an attacker's ability to gain privileged access to the NEA Client 1948 or NEA Server (even for a brief time, long enough to disable or 1949 misconfigure security settings) is generally equivalent as well. If 1950 the NEA Client or NEA Server are dependent on other services for 1951 their proper operation (including Posture Collectors, Posture 1952 Validators, directories, and patch management services), compromise 1953 of those services may result in compromise or failure of the 1954 dependent parties. Of course, compromise or failure of NEA Server 1955 components is most serious since this would probably affect a large 1956 number of NEA Clients while the effects of NEA Client compromise 1957 might well be limited to a single machine. 1959 5.2. Countermeasures 1961 The primary countermeasure against attacks by untrusted network 1962 intermediaries is the security provided by the PT protocol. Any 1963 candidate PT protocols should be carefully examined to ensure that 1964 all the threats described above are adequately addressed. 1966 As noted above, compromise or erroneous operation of any of the 1967 trusted parties is a serious matter with substantial security 1968 implications. This includes the Posture Broker Client, the Posture 1969 Broker Server, the Posture Transport Client, and the Posture 1970 Transport Server. These are all security-sensitive components so 1971 they should be built and managed in accordance with best practices 1972 for security devices. This is especially important for the NEA 1973 Server and its components since a compromise of this device would 1974 affect the security and availability of the entire network (similar 1975 to compromise of a AAA server). Communications between the trusted 1976 parties must also be secured. For example, if the Posture Broker 1977 Server and the Posture Transport Server are separate components, 1978 their communications must be secured. 1980 Since the NEA Client may be a mobile device with little physical 1981 security (such as a laptop computer or even a public telephone), it 1982 should generally be assumed that some proportion of Access NEA 1983 Clients will be compromised and therefore hostile. The NEA Server 1984 should be designed to be robust against hostile NEA Clients. Once a 1985 compromised NEA Client is detected, it can be treated in a manner 1986 equivalent to an untrusted party and should pose no greater threat 1987 than any other untrusted party. 1989 Countermeasures against a compromised NEA Server (or a component 1990 thereof such as a Posture Broker Server or a Posture Transport 1991 Server) include prevention of compromise, detection of compromise, 1992 and mitigation of the effects of compromise. For prevention, the NEA 1993 Server and its components and dependencies should be implemented 1994 using secure implementation techniques (e.g. secure coding and 1995 minimization) and managed using secure practices (e.g. strong 1996 authentication and separation of duty). For detection, the behavior 1997 of the NEA Server should be monitored (e.g. via logging especially of 1998 remediation instructions; intrusion detection systems; and probes 1999 that impersonate a valid NEA Client and record NEA Server behavior) 2000 and any anomalies analyzed. For mitigation, NEA Clients should not 2001 blindly follow remediation instructions received from a trusted NEA 2002 Server. At least for patches and other dangerous actions, they 2003 should validate these actions (e.g. via user confirmation) before 2004 proceeding. It should not be possible to configure a NEA Client to 2005 trust all NEA Servers without proper authentication and 2006 authorization. 2008 6. IANA Considerations 2010 Four new IANA registries are defined by this specification: PB-TNC 2011 Message Types, PA Subtypes, PB-TNC Remediation Parameters Types, and 2012 PB-TNC Error Codes. This section explains how these registries work. 2014 All of these registries support IETF standard values and vendor- 2015 defined values. To explain this phenomenon, we will use the PB-TNC 2016 Message Type as an example but the other three registries work the 2017 same way. Whenever a PB-TNC Message Type appears on a network, it is 2018 always accompanied by an SMI Private Enterprise Number (PEN), also 2019 known as a vendor ID. If this vendor ID is zero, the accompanying 2020 PB-TNC Message Type is an IETF standard value listed in the IANA 2021 registry for PB-TNC Message Types and its meaning is defined in the 2022 specification listed for that PB-TNC Message Type in that registry. 2023 If the vendor ID is not zero, the meaning of the PB-TNC Message Type 2024 is defined by the vendor identified by the vendor ID (as listed in 2025 the IANA registry for SMI PENs). The identified vendor is encouraged 2026 but not required to register with IANA some or all of the PB-TNC 2027 Message Types used with their vendor ID and publish a specification 2028 for each of these values. 2030 This delegation of namespace is analogous to the technique used for 2031 OIDs. It can result in interoperability problems if vendors require 2032 support for particular vendor-specific values. However, such 2033 behavior is explicitly prohibited by this specification, which 2034 dictates that "Posture Broker Clients and Posture Broker Servers MUST 2035 NOT require support for particular vendor-specific PB-TNC message 2036 types and MUST interoperate with other parties despite any 2037 differences in the set of vendor-specific PB-TNC message types 2038 supported (although they MAY permit administrators to configure them 2039 to require support for specific PB-TNC message types)." Similar 2040 requirements are included for PA Subtypes, Remediation Parameters 2041 Types, and PB-TNC Error Codes. 2043 6.1. Designated Expert Guidelines 2045 For all of the four IANA registries defined by this specification, 2046 new values are added to the registry by Expert Review with 2047 Specification Required, using the Designated Expert process defined 2048 in RFC 5226 [5]. 2050 This section provides guidance to designated experts so that they may 2051 make decisions using a philosophy appropriate for these registries. 2053 The registries defined in this document have plenty of values. In 2054 most cases, the IETF has approximately 2^32 values available for it 2055 to define and each vendor the same number of values for its use. The 2056 only exception is the registry for PB-TNC Error Codes where 2^16 2057 values are available for the IETF and 2^16 values for each vendor. 2058 Because there are so many values available, designated experts should 2059 not be terribly concerned about exhausting the set of values. 2061 Instead, designated experts should focus on the following 2062 requirements. All values in these IANA registries MUST be documented 2063 in a specification that is permanently and publicly available. IETF 2064 standard values MUST also be useful, not harmful to the Internet, and 2065 defined in a manner that is clear and likely to ensure 2066 interoperability. 2068 Designated experts should encourage vendors to avoid defining similar 2069 but incompatible values and instead agree on a single IETF standard 2070 value. However, it is beneficial to document existing practice. 2072 There are several ways to ensure that a specification is permanently 2073 and publicly available. It may be published as an RFC. Alternatively, 2074 it may be published in another manner that makes it freely available 2075 to anyone. However, in this latter case, the vendor MUST supply a 2076 copy to the IANA and authorize the IANA to archive this copy and make 2077 it freely available to all if at some point the document becomes no 2078 longer freely available to all through other channels. 2080 6.2. Registry for PB-TNC Message Types 2082 The name for this registry is "PB-TNC Message Types". Each entry in 2083 this registry should include a human-readable name, an SMI Private 2084 Enterprise Number, a decimal integer value between 0 and 2^32-2, and 2085 a reference to a specification where the contents of this message 2086 type are defined. This specification must define the meaning of this 2087 PB-TNC message type and the format and semantics of the PB-TNC 2088 Message Value field for PB-TNC messages that include the designated 2089 numeric value in the PB-TNC Message Type field and the designated 2090 Private Enterprise Number in the PB-TNC Vendor ID field. 2092 Entries to this registry are added by Expert Review with 2093 Specification Required, following the guidelines in section 6.1. 2095 The following entries for this registry are defined in this document. 2096 Once this document becomes an RFC, they should become the initial 2097 entries in the registry for PB-TNC Message Types. 2099 PEN Integer Name Defining Specification 2100 --- ------- ---- ---------------------- 2101 0 0 PB-Experimental RFC # Assigned to this I-D 2102 0 1 PB-PA RFC # Assigned to this I-D 2103 0 2 PB-Assessment-Result RFC # Assigned to this I-D 2104 0 3 PB-Access-Recommendation RFC # Assigned to this I-D 2105 0 4 PB-Remediation-Parameters RFC # Assigned to this I-D 2106 0 5 PB-Error RFC # Assigned to this I-D 2107 0 6 PB-Language-Preference RFC # Assigned to this I-D 2108 0 7 PB-Reason-String RFC # Assigned to this I-D 2109 0 0xffffffff Reserved RFC # Assigned to this I-D 2111 6.3. Registry for PA Subtypes 2113 The name for this registry is "PA Subtypes". Each entry in this 2114 registry should include a human-readable name, an SMI Private 2115 Enterprise Number, a decimal integer value between 0 and 2^32-2, and 2116 a reference to a specification where the contents of this PA subtype 2117 are defined. This specification must define the meaning of this PA 2118 subtype and the format and semantics of the PA Message Body field for 2119 PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message 2120 Type of PB-PA, the designated numeric value in the PA Subtype field, 2121 and the designated Private Enterprise Number in the PA Message Vendor 2122 ID field. 2124 Entries to this registry are added by Expert Review with 2125 Specification Required, following the guidelines in section 6.1. 2127 This document does not define any initial entries for this registry. 2128 Therefore, this registry should initially be empty. Subsequent RFCs 2129 (such as PA-TNC) will define entries in this registry. 2131 6.4. Registry for PB-TNC Remediation Parameters Types 2133 The name for this registry is "PB-TNC Remediation Parameters Types". 2134 Each entry in this registry should include a human-readable name, an 2135 SMI Private Enterprise Number, a decimal integer value between 0 and 2136 2^32-1, and a reference to a specification where the contents of this 2137 remediation parameters type are defined. This specification must 2138 define the meaning of this remediation parameters type value and the 2139 format and semantics of the Remediation Parameters field for PB-TNC 2140 messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of 2141 PB-Remediation-Parameters, the designated numeric value in the 2142 Remediation Parameters Type field, and the designated Private 2143 Enterprise Number in the Remediation Parameters Vendor ID field. 2145 Entries to this registry are added by Expert Review with 2146 Specification Required, following the guidelines in section 6.1. 2148 The following entries for this registry are defined in this document. 2149 Once this document becomes an RFC, they should become the initial 2150 entries in the registry for PB-TNC Remediation Parameters Types. 2152 PEN Integer Name Defining Specification 2153 --- ------- ---- ---------------------- 2154 0 1 Remediation-URI RFC # Assigned to this I-D 2155 0 2 Remediation-String RFC # Assigned to this I-D 2157 6.5. Registry for PB-TNC Error Codes 2159 The name for this registry is "PB-TNC Error Codes". Each entry in 2160 this registry should include a human-readable name, an SMI Private 2161 Enterprise Number, a decimal integer value between 0 and 2^16-1, and 2162 a reference to a specification where this error code is defined. 2163 This specification must define the meaning of this error code and the 2164 format and semantics of the Error Parameters field for PB-TNC 2165 messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of 2166 PB-Error, the designated numeric value in the Error Code field, and 2167 the designated Private Enterprise Number in the Error Code Vendor ID 2168 field. 2170 Entries to this registry are added by Expert Review with 2171 Specification Required, following the guidelines in section 6.1. 2173 The following entries for this registry are defined in this document. 2174 Once this document becomes an RFC, they should become the initial 2175 entries in the registry for PB-TNC Error Codes. 2177 PEN Integer Name Defining Specification 2178 --- ------- ---- ---------------------- 2179 0 0 Unexpected Batch Type RFC # Assigned to this I-D 2180 0 1 Invalid Parameter RFC # Assigned to this I-D 2181 0 2 Local Error RFC # Assigned to this I-D 2182 0 3 Unsupported Mandatory Message RFC # Assigned to this I-D 2183 0 4 Version Not Supported RFC # Assigned to this I-D 2185 7. Acknowledgments 2187 Thanks to the Trusted Computing Group for contributing the initial 2188 text upon which this document was based. 2190 The authors of this draft would like to acknowledge the following 2191 people who have contributed to or provided substantial input on the 2192 preparation of this document or predecessors to it: Bernard Aboba, 2193 Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris 2194 Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen, 2195 Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles 2196 Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim, 2197 Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan 2198 Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin, 2199 Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod 2200 Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, 2201 Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean 2202 Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad, 2203 Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali, 2204 Guha Prasad Venataraman, John Vollbrecht, Jun Wang, Han Yin. 2206 This document was prepared using 2-Word-v2.0.template.dot. 2208 8. References 2210 8.1. Normative References 2212 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2213 Levels", BCP 14, RFC 2119, March 1997. 2215 [2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2216 Resource Identifier (URI): Generic Syntax", RFC 3986, January 2217 2005. 2219 [3] Phillips, A. and M. Davis, "Tags for the Identification of 2220 Languages", RFC 4646, September 2006. 2222 [4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. 2224 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2225 Considerations Section in RFCs", RFC 5226, May 2008. 2227 [6] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2228 3629, November 2003. 2230 8.2. Informative References 2232 [7] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV 2233 Binding", Trusted Computing Group, February 2008. 2235 [8] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 2236 Tardo, "Network Endpoint Assessment (NEA): Overview and 2237 Requirements", RFC 5209, June 2008. 2239 [9] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2240 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 2241 3748, June 2004. 2243 [10] Sangster, P., "PA-TNC: A Posture Attribute Protocol (PA) 2244 Compatible with TNC", draft-ietf-nea-pa-tnc-05.txt, August 2245 2009. 2247 Appendix A: Use Cases 2249 A.1. Initial Client triggered assessment 2251 This scenario involves the assessment of an endpoint initiated during 2252 network join. The assessment is triggered by the Posture Broker 2253 Client (PBC) and involves collection of patch information from both 2254 Standard Operating System (OS) Posture Collector and vendor-specific 2255 Patch Posture Collector (PC). The assessment by both the vendor- 2256 specific Patch Posture Validator (PV) and Standard OS Posture 2257 Validator result in a compliant assessment decision which results in 2258 a compliant System Assessment Decision to be returned by the Posture 2259 Broker Server (PBS). 2261 +--------+ +-------+ +---------+ +--------+ +-------++--------+ 2263 | Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X| 2265 |Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV| 2267 +----+---+ +---+---+ +-----+---+ +---+----+ +---+----++---+---+ 2269 | | N/W Join| | | | 2271 | | ----->| | | | 2273 | | Req Post. | | | | 2275 | +<----------+ | | | 2277 | | Req Post. | | | | 2279 +<--------------------| | | | 2281 |Vndr X Patch Posture | | | | 2283 |-------------------->| | | | 2285 | |OS Posture | | | | 2287 | |---------->| | | | 2289 | | | Posture | | | 2291 | | | Report | | | 2292 | | +-------->| | | 2294 | | | | Verify | | 2296 | | | | Posture | | 2298 | | | |---------> | 2300 | | | | | Verify | 2302 | | | | | Posture | 2304 | | | |------------------->| 2306 | | | | OS Reslt | | 2308 | | | |<---------| | 2310 | | | | VndrX Patch Result | 2312 | | | Assess |<-------------------| 2314 | | | Result | | 2316 | | <---------| | | 2318 | | OS PRslt | | | | 2320 | |<----------| | | | 2322 | VndrX Patch PResult | | | | 2324 |<--------------------| | | | 2326 A.1.1. Message Contents 2328 This section shows the contents of the key fields in each of the PA 2329 messages exchanged in this use case. When necessary additional 2330 commentary is provided to explain why certain fields contain the 2331 shown values. Note that many of the flows shown are between 2332 components on the same system so no message contents are shown. 2334 A.1.1.1. N/W Join 2336 This flow represents the event that causes the PBC to decide to start 2337 an assessment of the endpoint in order to gain access to the network. 2338 This is merely an event and doesn't include a message being sent. 2340 A.1.1.2. Request Posture (Req Post.) 2342 This flow illustrates an invocation of the OS and patch posture 2343 collectors requesting particular posture attributes to be sent. 2344 Because this use case is triggered locally, NEA doesn't specify the 2345 contents of this flow. 2347 A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture) 2349 This flow contains the PA message from the Vendor X Patch Posture 2350 Collector; the message content is described in the PA-TNC 2351 specification. 2353 A.1.1.4. OS Posture 2355 This flow contains the PA message from the OS Posture Collector; the 2356 message content is described in the PA-TNC specification. 2358 A.1.1.5. Posture Report 2360 This flow contains the PB message containing the PA messages from the 2361 Patch and OS Posture Collectors: 2363 PB Envelope { 2365 HDR { 2367 D bit=0 (Posture Broker Client is originator) 2369 Batch Type=CDATA 2371 Batch Length 2373 } 2375 PB Message 1 { 2377 Vendor-id=0 2378 Type =2 (PB-PA) 2380 Length 2382 Value = { 2384 PA-Msg-vendor-id=0 (Standard) 2386 PA-subtype=1 (OS) 2388 OS Posture PA Message 2390 } 2392 } 2394 PB Message 2 { 2396 Vendor-id=0 2398 Type =2 (PB-PA) 2400 Length 2402 Value = { 2404 PA-Msg-vendor-id=1 (Vendor X) 2406 PA-subtype=1 (Vendor X PA sub-type for patch management) 2408 Vendor X Patch Posture PA Message 2410 } 2412 } 2414 } 2416 A.1.1.6. Verify Posture 2418 This flow illustrates an invocation of the OS and patch posture 2419 validators requesting verification of the posture attributes 2420 received. Because this flow happens locally within the NEA server, 2421 NEA doesn't specify the message content. 2423 A.1.1.7. OS Posture Result (OS Reslt) 2425 This flow contains the PA message (Posture Assessment Result) from 2426 the OS Posture Validator; the message content is described in the PA- 2427 TNC specification. 2429 A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result) 2431 This flow contains the PA message (Posture Assessment Result) from 2432 the Vendor X Patch Posture Validator; the message content is 2433 described in the PA-TNC specification. 2435 A.1.1.9. Assessment Result (Assess Result) 2437 This flow contains the PB message containing the system assessment 2438 result computed by the Posture Broker Server and the PA messages from 2439 the Patch and OS Posture Validators: 2441 PB Envelope { 2443 HDR { 2445 D bit=1 (Posture Broker Server is originator) 2447 Batch Type=RESULT 2449 Batch Length 2451 } 2453 PB Message 1 { 2455 Vendor-id=0, 2457 Type =3 (Access-Recommendation) 2459 Length 2461 Value = { 2462 System-Evaluation-Result=0 (Compliant) 2464 } 2466 } 2468 PB Message 2 { 2470 Vendor-id=0, 2472 Type=2 (PB-PA) 2474 Length 2476 Value = { 2478 PA-Msg-vendor-id=0 2480 PA-subtype=1 (OS) 2482 OS Posture Result PA Message 2484 } 2486 } 2488 PB Message 3 { 2490 Vendor-id=0, 2492 Type=2 (PB-PA) 2494 Length 2496 Value = { 2498 PA-Msg-vendor-id=1 (Vendor X) 2500 PA-subtype=1 (Vendor X PA sub-type for patch management) 2502 Vendor X Patch Posture Result PA Message 2504 } 2506 } 2508 } 2510 A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult) 2512 These flows illustrate an invocation of the OS and Vendor X Patch 2513 Posture Collectors to receive the posture assessment results. 2514 Because this flow is triggered locally, NEA doesn't specify the 2515 contents of this flow. 2517 A.2. Server initiated Assessment with Remediation 2519 This scenario involves the assessment of an endpoint initiated by the 2520 NEA server. The assessment is triggered by the Posture Broker Server 2521 and involves collection of Anti-Virus attributes for two Anti-Virus 2522 components running on the endpoint. The endpoint is assessed to be 2523 compliant by one of the vendor (Vendor X) anti-virus posture 2524 validators and non-complaint by the other vendor (Vendor Y) anti- 2525 virus posture validator This results in a non-compliant System 2526 Assessment Decision to be returned by the Posture Broker Server. The 2527 Posture Broker Server also returns remediation instructions for the 2528 endpoint as part of the response. 2530 +--------+ +-------+ +---------+ +--------+ +-------+ +--------+ 2532 | Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y | 2534 | AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV | 2536 +----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+ 2538 | | | N/W Join| | | 2540 | | | ----->| | | 2542 | | | | Create | | 2544 | | | |Post. Req | | 2546 | | | |--------->| | 2548 | | | |Create Posture Req | 2549 | | | |----------+--------->| 2551 | | | |Vndr Y AV Posture Req| 2553 | | | |<---------+----------| 2555 | | | |Vndr X AV | | 2557 | | | |Post. Req | | 2559 | | | Posture |<---------| | 2561 | | | Request | | | 2563 | | Vndr X AV |<--------| | | 2565 | | Post. Req | | | | 2567 | |<----------| | | | 2569 | Vndr Y AV | | | | 2571 | Posture Req | | | | 2573 +<---------+-----------| | | | 2575 | Vndr Y AV Posture | | | | 2577 +----------+---------->| | | | 2579 | | Vndr X AV | | | | 2581 | | Posture | | | | 2583 | |---------->| Posture | | | 2585 | | |Response | | | 2587 | | |-------->| | | 2589 | | | | Verify | | 2591 | | | | Posture | | 2593 | | | |--------->| | 2595 | | | | Verify Posture | 2596 | | | |----------+--------->| 2598 | | | |Vndr Y Posture Result| 2600 | | | |<---------+----------| 2602 | | | |Vndr X AV | | 2604 | | | |Post Reslt| | 2606 | | | Assess |<---------| | 2608 | | | Result | | | 2610 | | Vndr X AV |<--------| | | 2612 | |Post Reslt |<--------| | | 2614 | |<----------| | | | 2616 | Vndr Y AV Post Reslt | | | | 2618 +<---------+-----------| | | | 2620 | | | | | | 2622 A.2.1. Message Contents 2624 This section shows the contents of the key fields in each of the PA 2625 messages exchanged in this use case. When necessary additional 2626 commentary is provided to explain why certain fields contain the 2627 shown values. Note that many of the flows shown are between 2628 components on the same system so no message contents are shown. 2630 A.2.1.1. N/W Join 2632 This flow represents the event that causes the PBS to decide to start 2633 an assessment of the endpoint in order to gain access to the network. 2634 This is merely an event and doesn't include a message being sent. 2636 A.2.1.2. Create Posture Request (Create Posture Req.) 2638 This flow illustrates an invocation of the Vendor X and Vendor Y 2639 Anti-Virus posture validators requesting posture requests to be 2640 created. Because this use case is triggered locally, NEA doesn't 2641 specify the contents of this flow. 2643 A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV Post. Req) 2645 This flow contains the PA message (Posture Request) from the Vendor X 2646 Anti-Virus Posture Validator; the message content is described in the 2647 PA-TNC specification. 2649 A.2.1.4. Vendor Y Anti-Virus Posture Request 2651 This flow contains the PA message (Posture Request) from the Vendor Y 2652 Anti-Virus Posture Validator; the message content is described in the 2653 PA-TNC specification. 2655 A.2.1.5. Posture Request 2657 This flow contains the PB message containing the PA messages from the 2658 Vendor X and Vendor Y Anti-Virus Posture Validators: 2660 PB Envelope { 2662 HDR { 2664 D bit=1 (Posture Broker Server is originator) 2666 Batch Type=SDATA 2668 Batch Length 2670 } 2672 PB Message 1 { 2674 Vendor-id=0 2675 Type =2 (PB-PA) 2677 Length 2679 Value = { 2681 PA-Msg-vendor-id=1 (Vendor X) 2683 PA-subtype=2 (Vendor X PA sub-type for Anti-Virus) 2685 Vendor X AV Posture Request PA Message 2687 } 2689 } 2691 PB Message 2 { 2693 Vendor-id=0 2695 Type =2 (PB-PA) 2697 Length 2699 Value = { 2701 PA-Msg-vendor-id=2 (Vendor Y) 2703 PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus) 2705 Vendor Y AV Posture Request PA Message 2707 } 2709 } 2711 } 2713 A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr Y AV 2714 Posture Req) 2716 This flow illustrates an invocation of the Vendor X and Vendor Y 2717 Anti-Virus Posture Collectors to process the Posture Request and 2718 return particular posture attributes requested. Because this use 2719 case is triggered locally, NEA doesn't specify the contents of this 2720 flow. 2722 A.2.1.7. Vendor Y Anti-Virus Posture (Vndr Y AV Posture) 2724 This flow contains the PA message (response to the Posture Request) 2725 from the Vendor Y Anti-Virus Posture Collector; the message content 2726 is described in the PA-TNC specification. 2728 A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture) 2730 This flow contains the PA message (response to the Posture Request) 2731 from the Vendor X Anti-Virus Posture Collector; the message content 2732 is described in the PA-TNC specification. 2734 A.2.1.9. Posture Response 2736 This flow contains the PB message containing the PA messages from the 2737 Vendor X and Vendor Y Anti-Virus Posture Collectors: 2739 PB Envelope { 2741 HDR { 2743 D bit=0 (Posture Broker Client is originator) 2745 Batch Type=CDATA 2747 Batch Length 2749 } 2751 PB Message 1 { 2753 Vendor-id=0 2755 Type =2 (PB-PA) 2756 Length 2758 Value = { 2760 PA-Msg-vendor-id=1 (Vendor X) 2762 PA-subtype=2 (Vendor X PA sub-type for Anti-Virus) 2764 Vendor X AV Posture PA Message 2766 } 2768 } 2770 PB Message 2 { 2772 Vendor-id=0 2774 Type =2 (PB-PA) 2776 Length 2778 Value = { 2780 PA-Msg-vendor-id=2 (Vendor Y) 2782 PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus) 2784 Vendor Y AV Posture PA Message 2786 } 2788 } 2790 } 2792 A.2.1.10. Verify Posture 2794 This flow illustrates an invocation of the Vendor X and Vendor Y 2795 Anti-Virus Posture Validators requesting verification of the posture 2796 attributes received. Because this flow happens locally within the 2797 NEA server, NEA doesn't specify the message contents. 2799 A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post Result) 2801 This flow contains the PA message (Posture Assessment Result) from 2802 the Vendor Y Anti-Virus Posture Validator; the message content is 2803 described in the PA-TNC specification. 2805 A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post Result) 2807 This flow contains the PA message (Posture Assessment Result) from 2808 the Vendor X Anti-Virus Posture Validator; the message content is 2809 described in the PA-TNC specification. 2811 A.2.1.13. Assessment Result (Assess Result) 2813 This flow contains the PB message containing the system assessment 2814 result computed by the Posture Broker Server and the PA messages from 2815 the Patch and OS Posture Validators: 2817 PB Envelope { 2819 HDR { 2821 D bit=1 (Posture Broker Server is originator) 2823 Batch Type=RESULT 2825 Batch Length 2827 } 2829 PB Message 1 { 2831 Vendor-id=0, 2833 Type=3 (Access-Recommendation) 2835 Length 2837 Value = { 2838 PB-Assessment-Result=1 (Non-Compliant) 2840 } 2842 } 2844 PB Message 2 { 2846 Vendor-id=0, 2848 Type=4 (Remediation-Parameters) 2850 Length 2852 Value = { 2854 Remidiation-Param-Vendor-ID=0 2856 Remidiation-Param-Type=1 (Remediation-URI) 2858 Remidiation-Param=''http://xyz'' 2860 } 2862 } 2864 PB Message 3 { 2866 Vendor-id=0, 2868 Type=4 (Remediation-Parameters) 2870 Length 2872 Value = { 2874 Remidiation-Param-Vendor-ID=0 2876 Remidiation-Param-Type=2 (Remediation-String) 2878 Remidiation-Param=''Try Step1, Step2,...'' 2880 } 2882 } 2884 PB Message 4 { 2885 Vendor-id=0, 2887 Type=2 (PB-PA) 2889 Length 2891 Value = { 2893 PA-Msg-vendor-id=1 (Vendor X) 2895 PA-subtype=2 (Vendor X PA sub-type for Anti-Virus) 2897 Vendor X AV Posture Result PA Message 2899 } 2901 } 2903 PB Message 5 { 2905 Vendor-id=0, 2907 Type=2 (PB-PA) 2909 Length 2911 Value = { 2913 PA-Msg-vendor-id=2 (Vendor Y) 2915 PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus) 2917 Vendor Y AV Posture Result PA Message 2919 } 2921 } 2923 } 2925 A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post 2926 Reslt) 2928 These flows illustrate an invocation of the Vendor X and Vendor Y 2929 Anti-Virus Posture Collectors to receive the posture assessment 2930 results. Because this flow is triggered locally, NEA doesn't specify 2931 the contents of this flow. 2933 A.3. Client triggered re-assessment 2935 This scenario involves the re-assessment of an endpoint as a result 2936 of enabling a software component on the endpoint. The endpoint has 2937 two VPN client software components, one from vendor X for the user's 2938 home network and other from vendor Y for the network that the 2939 endpoint is currently accessing. The assessment is triggered when the 2940 user tries to use the Vendor X VPN client; this is a violation of the 2941 posture policy. The Posture Broker Client triggers the posture 2942 assessment when it receives a notification from the Standard VPN 2943 Posture Collector about the change to the operational state of the 2944 VPN component on the endpoint. Note that the VPN Posture Collector 2945 supports standard attributes and some vendor defined attributes from 2946 vendor X and vendor Y's namespaces. This use case doesn't leverage 2947 vendor defined attributes. The assessment involves verification of 2948 the standard VPN posture attributes by the Standard VPN Posture 2949 Validator that results in a non-compliant assessment result. This use 2950 case relies on the use of virtual Posture Collector concept described 2951 in section 3.3 of the PA-TNC specification. As illustrated in this 2952 example, the Posture Broker Client will assign two Posture Collector 2953 IDs to a single Posture Collector (Standard VPN PC) and the Posture 2954 Collector will generate two separate PA messages to report the 2955 posture for Vendor X and Vendor Y VPN Clients. The Posture Broker 2956 Client will use the assigned IDs in the PB message sent to the NEA 2957 Server. This entire behavior will be completely opaque to the NEA 2958 Server, which will handle the PB message as if there were two VPN 2959 Posture Collectors on the NEA Client. 2961 +--------+ +-------+ +---------+ +--------+ +-------+ +--------+ 2963 |Vndr X | |Vndr Y | |Standard | |Standard| |Standrd| |Standard| 2965 |VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV | 2967 +----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+ 2968 Enble| | | | | | 2970 ---->| | | | | | 2972 | VPN Status Change | | | | 2974 |--------------------->| Posture | | | 2976 | | | Change | | | 2978 | | |-------->| | | 2980 | | |Req. Post| | | 2982 | | |<--------| | | 2984 | |Ins/Rq Info| | | | 2986 | |<----------| | | | 2988 | Inspect/Request Info | | | | 2990 |<---------+-----------|VPNX Post| | | 2992 | | |-------->| | | 2994 | | |VPNY Post| | | 2996 | | |-------->| | | 2998 | | | | Posture | | 3000 | | | | Report | | 3002 | | | |--------->| | 3004 | | | | |Vrfy Post.| 3006 | | | | |--------->| 3008 | | | | |VPN PRslt | 3010 | | | | Assess |<---------| 3012 | | | | Result | | 3014 | | | |<---------| | 3015 | | |VPN PRslt| | | 3017 | | |<--------| | | 3019 A.3.1. Message Contents 3021 This section shows the contents of the key fields in each of the PA 3022 messages exchanged in this use case. When necessary additional 3023 commentary is provided to explain why certain fields contain the 3024 shown values. Note that many of the flows shown are between 3025 components on the same system so no message contents are shown. 3027 A.3.1.1. Enable VPN Client (Enble) 3029 This flow represents the end user triggered event of starting the VPN 3030 Client software from Vendor X. This is merely an event and doesn't 3031 include a message being sent. 3033 A.3.1.2. Notify Status Change (VPN Status Change) 3035 This flow represents the detection of the active state of the Vendor 3036 X VPN Client software by the Standard VPN Posture Collector. This is 3037 merely an event and doesn't include a message being sent. 3039 A.3.1.3. Notify Posture Change (Posture Change) 3041 This flow represents the notification of the VPN Posture change sent 3042 from the VPN Posture Collector to the Standard Posture Broker Client. 3043 This is merely an event and doesn't include a message being sent. 3045 A.3.1.4. Request Posture (Req. Post) 3047 This flow illustrates an invocation of the VPN Posture Collector 3048 requesting particular posture attributes to be sent. Because this 3049 use case is triggered locally the contents of this flow aren't 3050 specified by NEA. 3052 A.3.1.5. Inspect/Request Information (Ins/Rq Info) 3054 This flow illustrates the acquisition of the postures attributes by 3055 the Standard VPN Posture Collector from the Vendor X and Vendor Y VPN 3056 Client components. Because this flow is triggered locally, NEA 3057 doesn't specify the message contents. 3059 A.3.1.6. Vendor X VPN Posture (VPNX Post.) 3061 This flow contains the PA message from the VPN Posture Collector for 3062 Vendor X VPN Client posture; the message content is described in the 3063 PA-TNC specification. 3065 A.3.1.7. Vendor Y VPN Posture (VPNY Post.) 3067 This flow contains the PA message from the VPN Posture Collector for 3068 Vendor Y VPN Client posture; the message content is described in the 3069 PA-TNC specification. 3071 A.3.1.8. Posture Report (Post. Rpt.) 3073 This flow contains the PB message containing the PA message from the 3074 VPN Posture Collector: 3076 PB Envelope { 3078 HDR { 3080 D bit=0 (Posture Broker Client is originator) 3082 Batch Type=CRETRY 3084 Batch Length 3086 } 3088 PB Message 1 { 3090 Vendor-id=0 3092 Type =2 (PB-PA) 3094 Length 3096 Value = { 3097 PA-Msg-vendor-id=0 3099 PA-subtype=7 (VPN) 3101 Posture-Collector-ID=1 //Virtual Posture Collector ID for 3102 Vendor X VPN Client 3104 Vendor X VPN Posture PA Message 3106 } 3108 } 3110 PB Message 2 { 3112 Vendor-id=0 3114 Type =2 (PB-PA) 3116 Length 3118 Value = { 3120 PA-Msg-vendor-id=0 3122 PA-subtype=7 (VPN) 3124 Posture-Collector-ID=2 //Virtual Posture Collector ID for 3125 Vendor Y VPN Client 3127 Vendor Y VPN Posture PA Message 3129 } 3131 } 3133 A.3.1.9. Verify Posture (Vrfy Post.) 3135 This flow illustrates an invocation of the VPN Posture Validator 3136 requesting verification of the posture attributes received. Because 3137 this flow happens locally within the NEA server, NEA doesn't specify 3138 the message contents. 3140 A.3.1.10. VPN Posture Result (VPN PRslt) 3142 This flow contains the PA message (Posture Assessment Result) from 3143 the VPN Posture Validator; the message content is described in the 3144 PA-TNC specification. 3146 A.3.1.11. Assessment Result (Assess Result) 3148 This flow contains the PB message containing the system assessment 3149 result computed by the Posture Broker Server and the PA messages from 3150 the VPN Posture Validator: 3152 PB Envelope { 3154 HDR { 3156 D bit=1 (Posture Broker Server is originator) 3158 R bit=1 (Retry acknowledge) 3160 Batch Type=RESULT 3162 Batch Length 3164 } 3166 PB Message 1 { 3168 Vendor-id=0, 3170 Type =3 (Access-Recommendation) 3171 Length 3173 Value = { 3175 PB-Assessment-Result=1 (Non-Compliant) 3177 } 3179 } 3181 PB Message 2 { 3183 Vendor-id=0, 3185 Type=2 (PB-PA) 3187 Length 3189 Value = { 3191 PA-Msg-vendor-id=0 3193 PA-subtype=7 (VPN) 3195 VPN Posture Result PA Message 3197 } 3199 } 3201 A.3.1.12. Posture Result (VPN PRslt) 3203 This flow illustrate an invocation of the VPN Posture Collectors to 3204 receive the posture assessment result. Because this flow is 3205 triggered locally, NEA doesn't specify the contents of this flow. 3207 APPENDIX B: Evaluation Against NEA Requirements 3209 This section evaluates the PB-TNC protocol against the requirements 3210 defined in the NEA Requirements document. Each subsection considers 3211 a separate requirement from the NEA Requirements document. Only 3212 common requirements (C-1 through C-11) and PB requirements (PB-1 3213 through PB-6) are considered, since these are the only ones that 3214 apply to PB. 3216 B.1. Evaluation Against Requirement C-1 3218 Requirement C-1 says: 3220 C-1 NEA protocols MUST support multiple round trips between the NEA 3221 Client and NEA Server in a single assessment. 3223 PB-TNC meets this requirement. It allows an unlimited number of 3224 round trips between the NEA Client and NEA Server. 3226 B.2. Evaluation Against Requirement C-2 3228 Requirement C-2 says: 3230 C-2 NEA protocols SHOULD provide a way for both the NEA Client and 3231 the NEA Server to initiate a posture assessment or reassessment 3232 as needed. 3234 PB-TNC meets this requirement. Either the NEA Client or the NEA 3235 Server can initiate a posture assessment or reassessment. 3237 There is one limitation on this support. If a NEA Server wishes to 3238 initiate a reassessment after it has sent a RESULT batch, it must 3239 close the underlying transport session and initiate a new assessment. 3240 For half duplex transports, this is unavoidable unless a constant 3241 exchange of messages is maintained, which would be very wasteful. 3242 For full duplex transports, it would be possible to allow the Posture 3243 Broker Server to send an SRETRY batch even in the Decided state. If 3244 the NEA working group reaches consensus that this change should be 3245 made, it will be. 3247 B.3. Evaluation Against Requirement C-3 3249 Requirement C-3 says: 3251 C-3 NEA protocols including security capabilities MUST be capable 3252 of protecting against active and passive attacks by 3253 intermediaries and endpoints including prevention from replay 3254 based attacks. 3256 PB-TNC does not include any security capabilities. It depends on PT 3257 to supply a secure transport. This addresses all the necessary 3258 threats without adding an extra layer of security. Since this 3259 requirement only applies to NEA protocols that include security 3260 capabilities, PB-TNC meets this requirement. 3262 B.4. Evaluation Against Requirement C-4 3264 Requirement C-4 says: 3266 C-4 The PA and PB protocols MUST be capable of operating over any 3267 PT protocol. For example, the PB protocol must provide a 3268 transport independent interface allowing the PA protocol to 3269 operate without change across a variety of network protocol 3270 environments (e.g. EAP/802.1X, PANA, TLS and IKE/IPsec). 3272 PB-TNC meets this requirement. PB-TNC can operate over any PT 3273 protocol that meets the requirements for PT stated in the NEA 3274 Requirements document. Also, PB-TNC insulates the PA protocol from 3275 any specifics of the PT protocol. With PB-TNC, all PT protocols are 3276 equivalent from the perspective of the PA protocol. 3278 B.5. Evaluation Against Requirement C-5 3280 Requirement C-5 says: 3282 C-5 The selection process for NEA protocols MUST evaluate and 3283 prefer the reuse of existing open standards that meet the 3284 requirements before defining new ones. The goal of NEA is not 3285 to create additional alternative protocols where acceptable 3286 solutions already exist. 3288 Based on this requirement, PB-TNC should receive a strong preference. 3289 PB-TNC is equivalent with IF-TNCCS 2.0, an open TCG specification. 3290 IF-TNCCS 2.0 is an extension of the existing IF-TNCCS 1.X protocols, 3291 which have been implemented by dozens of vendors and open source 3292 projects. 3294 B.6. Evaluation Against Requirement C-6 3296 Requirement C-6 says: 3298 C-6 NEA protocols MUST be highly scalable; the protocols MUST 3299 support many Posture Collectors on a large number of NEA 3300 Clients to be assessed by numerous Posture Validators residing 3301 on multiple NEA Servers. 3303 PB-TNC meets this requirement. PB-TNC supports up to 2^16-1 Posture 3304 Collectors and an equal number of Posture Validators in a given PB- 3305 TNC session. It also supports an unlimited number of NEA Clients and 3306 NEA Servers. 3308 The scalability of PB-TNC extends into other areas as well. For 3309 example, PB-TNC supports an unlimited number of batches and each 3310 batch can contain up to 2^32-1 octets and about 2^24 PA messages. 3311 Each PA message can contain up to 2^32-1 octets. Of course, sending 3312 this much data in a NEA assessment is not generally advisable but the 3313 point is that PB-TNC is highly scalable. 3315 B.7. Evaluation Against Requirement C-7 3317 Requirement C-7 says: 3319 C-7 The protocols MUST support efficient transport of a large 3320 number of attribute messages between the NEA Client and the NEA 3321 Server. 3323 PB-TNC meets this requirement. Each PB-TNC batch can contain about 3324 2^24 PA messages. Since PB-TNC supports an unlimited number of 3325 batches in a session, this number is actually unlimited (except 3326 perhaps by PT protocols, user patience, or other external factors). 3327 As for efficiency, PB-TNC adds only 24 octets of overhead per PA 3328 message. PA-TNC can include many attributes in a single PA message 3329 so this overhead is diluted further. 3331 B.8. Evaluation Against Requirement C-8 3333 Requirement C-8 says: 3335 C-8 NEA protocols MUST operate efficiently over low bandwidth or 3336 high latency links. 3338 PB-TNC meets this requirement. A minimal PB-TNC exchange can be as 3339 small as 72 octets and one round trip. Even if privacy policies or 3340 other factors require multiple round trips, PB-TNC generally imposes 3341 an overhead of only 8 octets per batch and 24 octets per PA message. 3343 B.9. Evaluation Against Requirement C-9 3345 Requirement C-9 says: 3347 C-9 For any strings intended for display to a user, the protocols 3348 MUST support adapting these strings to the user's language 3349 preferences. 3351 PB-TNC meets this requirement. It defines a standard way for the NEA 3352 Client and NEA Server to send their language preferences to each 3353 other, leveraging the widely implemented Accept-Language format 3354 defined in RFC 3282. 3356 B.10. Evaluation Against Requirement C-10 3358 Requirement C-10 says: 3360 C-10 NEA protocols MUST support encoding of strings in UTF-8 format. 3362 PB-TNC meets this requirement. All strings in the PB-TNC protocol 3363 are encoded in UTF-8 format. This allows the protocol to support a 3364 wide range of languages efficiently. 3366 B.11. Evaluation Against Requirement C-11 3368 Requirement C-11 says: 3370 C-11 Due to the potentially different transport characteristics 3371 provided by the underlying candidate PT protocols, the NEA Client and 3372 NEA Server MUST be capable of becoming aware of and adapting to the 3373 limitations of the available PT protocol. For example, some PT 3374 protocol characteristics that might impact the operation of PA and 3375 PB include restrictions on: which end can initiate a NEA connection, 3376 maximum data size in a message or full assessment, upper bound on 3377 number of roundtrips, and ordering (duplex) of messages exchanged. 3378 The selection process for the PT protocols MUST consider the 3379 limitations the candidate PT protocol would impose upon the PA and 3380 PB protocols. 3382 PB-TNC meets this requirement. The PB-TNC protocol is designed 3383 to be flexible enough to operate with a variety of underlying 3384 PT protocols, including those that may have limitations on 3385 message or assessment size, number of roundtrips, and duplex. 3386 Local APIs can allow Posture Collectors and Posture Validators 3387 to discover when they are operating in a less constrained 3388 deployment and then make use of more verbose attributes. 3389 Similarly, Posture Collectors could choose to not send or use 3390 smaller attributes (including assertions from previous 3391 assessments) when faced with a very constrained network 3392 connection. 3394 B.12. Evaluation Against Requirement PB-1 3396 Requirement PB-1 says: 3398 PB-1 The PB protocol MUST be capable of carrying attributes from the 3399 Posture Broker Server to the Posture Broker Client. This 3400 enables the Posture Broker Client to learn the posture 3401 assessment decision and if appropriate to aid in remediation 3402 and notification of the endpoint owner. 3404 PB-TNC meets this requirement. It can carry attributes from the 3405 Posture Broker Client to the Posture Broker Server and back in an 3406 unlimited number of round trips. Furthermore, PB-TNC provides 3407 explicit attribute support for posture decision and remediation aid 3408 notification. 3410 B.13. Evaluation Against Requirement PB-2 3412 Requirement PB-2 says: 3414 PB-2 The PB protocol MUST NOT interpret the contents of PA messages 3415 being carried, i.e., the data it is carrying must be opaque to 3416 it. 3418 PB-TNC meets this requirement. It does not parse or interpret PA 3419 messages in any way. 3421 B.14. Evaluation Against Requirement PB-3 3423 Requirement PB-3 says: 3425 PB-3 The PB protocol MUST carry unique identifiers that are used by 3426 the Posture Brokers to route (deliver) PA messages between 3427 Posture Collectors and Posture Validators. Such message 3428 routing should facilitate dynamic registration or 3429 deregistration of Posture Collectors and Validators. For 3430 example, a dynamically registered anti-virus Posture Validator 3431 should be able to subscribe to receive messages from its 3432 respective anti-virus Posture Collector on NEA Clients. 3434 PB-TNC meets this requirement. PB-TNC tags each PA message with a PA 3435 subtype that the Posture Brokers can use to deliver the PA messages 3436 to the proper Posture Collectors and Posture Validators. By tagging 3437 messages according to their content, PB-TNC allows Posture Collectors 3438 and Posture Validators to be dynamically registered and deregistered, 3439 ensuring that each one receives the proper data. PB-TNC also 3440 supports exclusive delivery, which allows messages to be targeted at 3441 a particular Posture Collector or Posture Validator. 3443 B.15. Evaluation Against Requirement PB-4 3445 Requirement PB-4 says: 3447 PB-4 The PB protocol MUST be capable of supporting a half-duplex PT 3448 protocol. However this does not preclude PB from operating 3449 full-duplex when running over a full-duplex PT. 3451 PB-TNC meets this requirement. In order to insulate PA from any 3452 differences between half-duplex and full-duplex PT protocols, PB-TNC 3453 always operates in a half-duplex mode, regardless of the capabilities 3454 of the PT protocol. While this could in theory slow assessments that 3455 require many round trips or bidirectional multimedia exchanges, this 3456 is not a problem in practice because endpoint assessments do not 3457 typically involve multimedia or a large number of round trips. 3459 B.16. Evaluation Against Requirement PB-5 3461 Requirement PB-5 says: 3463 PB-5 The PB protocol MAY support authentication, integrity and 3464 confidentiality protection for the attribute messages it 3465 carries between a Posture Broker Client and Posture Broker 3466 Server. This provides security protection for a message dialog 3467 of the groupings of attribute messages exchanged between the 3468 Posture Broker Client and Posture Broker Server. Such 3469 protection is orthogonal to PA protections (which are end to 3470 end) and allows for simpler Posture Collector and Validators to 3471 be implemented, and for consolidation of cryptographic 3472 operations possibly improving scalability and manageability. 3474 PB-TNC does not address this optional requirement. It leaves 3475 security to PT (which is required to address it) and PA (which SHOULD 3476 do so). There seems to be minimal benefit in adding a third layer of 3477 security to the NEA protocol stack. However, if the NEA working 3478 group determines that PB should include support for authentication, 3479 integrity protection, and confidentiality protection, then this could 3480 be added to PB in a similar manner to the way that the PA-TNC 3481 security is done. 3483 B.17. Evaluation Against Requirement PB-6 3485 Requirement PB-6 says: 3487 PB-6 The PB protocol MUST support grouping of attribute messages to 3488 optimize transport of messages and minimize round trips. 3490 PB-TNC meets this requirement. Multiple attribute messages can be 3491 conveyed in a single PA message. In fact, that's how PA-TNC works. 3493 Authors' Addresses 3495 Ravi Sahita 3496 Intel Corporation 3497 2200 Mission College Blvd. 3498 Santa Clara, CA 95054 USA 3499 Email: Ravi.Sahita@intel.com 3501 Steve Hanna 3502 Juniper Networks, Inc. 3503 1194 North Mathilda Avenue 3504 Sunnyvale, CA 94089 USA 3505 Email: shanna@juniper.net 3507 Ryan Hurst 3508 Microsoft Corporation 3509 One Microsoft Way 3510 Redmond, WA 98052 USA 3511 Email: Ryan.Hurst@microsoft.com 3513 Kaushik Narayan 3514 Cisco Systems Inc. 3515 10 West Tasman Drive 3516 San Jose, CA 95134 USA 3517 Email: kaushik@cisco.com