idnits 2.17.1 draft-ietf-nea-requirements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2434. 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 18 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 184: '... MUST - indicates an absolute requi...' RFC 2119 keyword, line 186: '... MUST NOT - indicates something abs...' RFC 2119 keyword, line 188: '... SHOULD - indicates a strong recomm...' RFC 2119 keyword, line 190: '... SHOULD NOT - indicates a strong re...' RFC 2119 keyword, line 192: '... MAY - indicates a willingness to a...' (30 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 18, 2008) is 5814 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Sangster 3 Internet-Draft Symantec 4 Intended status: Informational H. Khosravi 5 Expires: September 2008 Intel 6 M. Mani 7 Avaya 8 K. Narayan 9 Cisco Systems 10 J. Tardo 11 Nevis Networks 13 April 18, 2008 15 Network Endpoint Assessment (NEA): 16 Overview and Requirements 17 draft-ietf-nea-requirements-07.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that 22 any applicable patent or other IPR claims of which he or she is 23 aware have been or will be disclosed, and any of which he or she 24 becomes aware will be disclosed, in accordance with Section 6 of 25 BCP 79. 27 Internet-Drafts are working documents of the Internet 28 Engineering Task Force (IETF), its areas, and its working 29 groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as "work 36 in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2008). 48 Abstract 49 This document defines the problem statement, scope and protocol 50 requirements between the components of the NEA (Network Endpoint 51 Assessment) reference model. NEA provides owners of networks 52 (e.g. an enterprise offering remote access) a mechanism to 53 evaluate the posture of a system. This may take place during the 54 request for network access and/or subsequently at any time while 55 connected to the network. The learned posture information can 56 then be applied to a variety of compliance oriented decisions. 57 The posture information is frequently useful for detecting 58 systems that are lacking or have out of date security protective 59 mechanisms such as: anti-virus and host-based firewall software. 60 In order to provide context for the requirements, a reference 61 model and terminology are introduced. 63 Table of Contents 65 1. Introduction....................................................3 66 1.1 Requirements Language.......................................4 67 2. Terminology.....................................................5 68 3. Applicability...................................................7 69 3.1 Scope.......................................................7 70 3.2 Applicability of Environments...............................8 71 4. Problem Statement...............................................9 72 5. Reference Model................................................11 73 5.1 NEA Client and Server......................................12 74 5.1.1 NEA Client...........................................12 75 5.1.2 NEA Server...........................................15 76 5.2 Protocols..................................................18 77 5.2.1 Posture Attribute Protocol (PA)......................19 78 5.2.2 Posture Broker Protocol (PB).............................19 79 5.2.3 Posture Transport Protocol (PT)..........................19 80 5.3 Attributes....................................................20 81 5.3.1 Attributes Normally Sent by NEA Client:..................21 82 5.3.2 Attributes Normally Sent by NEA Server:..................21 83 6. Use Cases......................................................22 84 6.1 Initial Assessment.........................................23 85 6.1.1 Triggered by Network Connection or Service Request...23 86 6.1.2 Triggered by Endpoint................................25 87 6.2 Posture Reassessment.......................................27 88 6.2.1 Triggered by NEA Client..............................28 89 6.2.2 Triggered by NEA Server..............................29 90 7. Requirements...................................................32 91 7.1 Common Protocol Requirements...............................33 92 7.2 Posture Attribute (PA) Protocol Requirements...............34 93 7.3 Posture Broker (PB) Protocol Requirements..................35 94 7.4 Posture Transport (PT) Protocol Requirements...............37 95 8. Security Considerations........................................37 96 8.1 Trust......................................................38 97 8.1.1 Endpoint.............................................39 98 8.1.2 Network Communications...............................40 99 8.1.3 NEA Server...........................................41 100 8.2 Protection Mechanisms at Multiple Layers...................42 101 8.3 Relevant Classes of Attack.................................42 102 8.3.1 Man-in-the-Middle (MITM).............................43 103 8.3.2 Message Modification.................................44 104 8.3.3 Message Replay or Attribute Theft....................44 105 8.3.4 Other Types of Attack................................45 106 9. Privacy Considerations.........................................45 107 9.1 Implementer Considerations.................................47 108 9.2 Minimizing Attribute Disclosure............................48 109 10. IANA Considerations...........................................50 110 11. References....................................................50 111 11.1 Normative References......................................50 112 11.2 Informative References....................................50 113 Acknowledgments...................................................51 114 Authors' Addresses................................................51 116 1. Introduction 118 Endpoints connected to a network may be exposed to a wide 119 variety of threats. Some protection against these threats can be 120 provided by ensuring that endpoints conform to security 121 policies. Therefore the intent of NEA is to assess these 122 endpoints to determine their compliance with security policies 123 so that corrective measures can be provided before they are 124 exposed to those threats. For example, if a system is 125 determined to be out of compliance because it is lacking proper 126 defensive mechanisms such as host-based firewalls, anti-virus 127 software or the absence of critical security patches, the NEA 128 protocols provide a mechanism to detect this fact and indicate 129 appropriate remediation actions to be taken. Note that an 130 endpoint that is deemed compliant may still be vulnerable to 131 threats that may exist on the network. 133 NEA typically involves the use of special client software 134 running on the requesting endpoint that observes and reports on 135 the configuration of the system to the network infrastructure. 136 The infrastructure has corresponding validation software that is 137 capable of comparing the endpoint's configuration information 138 with network compliance policy and providing the result to 139 appropriate authorization entities that make decisions about 140 network and application access. Some endpoints may be incapable 141 of running the NEA Client software (e.g. printer) or be 142 unwilling to share information about their configuration. This 143 situation is outside the scope of NEA and is subject to local 144 policies. 146 The result of an endpoint assessment may influence an access 147 decision that is provisioned to the enforcement mechanisms on 148 the network and/or endpoint requesting access. While the NEA 149 Working Group recognizes there may be a link between an 150 assessment and the enforcement of a resulting access decision, 151 the mechanisms and protocols for enforcement are not in scope 152 for this specification. 154 Architectures, similar to NEA, have existed in the industry for 155 some time and are present in shipping products, but do not offer 156 adequate interoperability. Some examples of such architectures 157 include: Trusted Computing Group's Trusted Network Connect 158 [TNC], Microsoft's Network Access Protection [NAP], Cisco's 159 Network Admission Control [CNAC]. These technologies assess the 160 software and/or hardware configuration of endpoint devices for 161 the purposes of monitoring or enforcing compliance to an 162 organization's policy. 164 The NEA working group is developing standard protocols that can 165 be used to communicate compliance information between a NEA 166 Client and a NEA server. This document provides the context for 167 NEA including: terminology, applicability, problem statement, 168 reference model, and use cases. It then identifies requirements 169 for the protocols used to communicate between a NEA Client and 170 NEA server. Finally this document discusses some potential 171 security and privacy considerations with the use of NEA. The 172 majority of this specification provides informative text 173 describing the context of NEA. 175 1.1 Requirements Language 177 Because this specification is an informational specification 178 (not able to directly use RFC 2119), the following capitalized 179 words are used to express requirements language used in this 180 specification. Use of each capitalized word within a sentence 181 or phrase carries the following meaning during the NEA WG's 182 protocol selection process: 184 MUST - indicates an absolute requirement 186 MUST NOT - indicates something absolutely prohibited 188 SHOULD - indicates a strong recommendation of a desired result 190 SHOULD NOT - indicates a strong recommendation against a result 192 MAY - indicates a willingness to allow an optional outcome 193 Lower case use of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 194 "MAY" carry their normal meaning and are not subject to these 195 definitions. 197 2. Terminology 199 This section defines a set of terms used throughout this 200 document. In some cases these terms have been used in other 201 contexts with different meanings so this section attempts to 202 describe each term's meaning with respect to the NEA WG 203 activities. 205 Assessment - The process of collecting posture for a set of 206 capabilities on the endpoint (e.g. host-based firewall) such 207 that the appropriate validators may evaluate the posture 208 against compliance policy. 210 Assertion Attributes - Attributes that include reusable 211 information about the success of a prior assessment of the 212 endpoint. This could be used to optimize subsequent 213 assessments by avoiding a full posture reassessment. For 214 example, this classification of attribute might be issued 215 specifically to a particular endpoint, dated and signed by 216 the NEA Server allowing that endpoint to reuse it for a time 217 period to assert compliance to a set of policies. The NEA 218 Server might accept this in lieu of obtaining posture 219 information. 221 Attribute - Data element including any requisite meta-data 222 describing an observed, expected or the operational status of 223 an endpoint feature (e.g. anti-virus software is currently in 224 use). Attributes are exchanged as part of the NEA protocols 225 (see section 5.2). NEA recognizes a variety of usage 226 scenarios where the use of an attribute in a particular type 227 of message could indicate: 228 o previously assessed status (Assertion Attributes), 229 o observed configuration or property (Posture Attributes), 230 o request for configuration or property information 231 (Request Attributes), 232 o assessment decision (Result Attributes), or 233 o repair instructions (Remediation Attributes). 235 The NEA WG will standardize a subset of the attribute name 236 space known as standard attributes. Those attributes not 237 standardized are referred to in this specification as vendor- 238 specific. 240 Dialog - Sequence of request/response messages exchanged 242 Endpoint - Any computing device that can be connected to a 243 network. Such devices normally are associated with a 244 particular link layer address before joining the network and 245 potentially an IP address once on the network. This 246 includes: laptops, desktops, servers, cell phones or any 247 device that may have an IP address. 249 Message - Self contained unit of communication between the NEA 250 Client and Server. For example, a posture attribute message 251 might carry a set of attributes describing the configuration 252 of the anti-virus software on an endpoint. 254 Owner - the role of an entity who is the legal, rightful 255 possessor of an asset (e.g. endpoint). The owner is entitled 256 to maintain control over the policies enforced on the device 257 even if the asset is not within the owner's possession. The 258 owner may permit user override or augmentation of control 259 policies or may choose to not assert any policies limiting 260 use of asset. 262 Posture - Configuration and/or status of hardware or software on 263 an endpoint as it pertains to an organization's security 264 policy. 266 Posture Attributes - Attributes describing the configuration or 267 status (posture) of a feature of the endpoint. For example, 268 a Posture Attribute might describe the version of the 269 operating system installed on the system. 271 Request Attributes - Attributes sent by a NEA Server identifying 272 the posture information requested from the NEA Client. For 273 example, a Request Attribute might be an attribute included 274 in a request message from the NEA Server that is asking for 275 the version information for the operating system on the 276 endpoint. 278 Remediation Attributes - Attributes containing the remediation 279 instructions for how to bring an endpoint into compliance 280 with one or more policies. NEA WG will not define standard 281 remediation attributes but this specification does describe 282 where they are used within the reference model and protocols. 284 Result Attributes - Attributes describing whether the endpoint 285 is in compliance with NEA policy. The Result Attribute is 286 created by the NEA Server normally at the conclusion of the 287 assessment to indicate whether the endpoint was considered 288 compliant or not. Multiple of these attributes may be used 289 allowing for more granular feature level decisions to be 290 communicated in addition to an overall, global assessment 291 decision. 293 Session - Stateful connection capable of carrying multiple 294 message exchanges associated with an assessment(s) of a 295 particular endpoint. This document defines the term session 296 at a conceptual level and does not describe the properties of 297 the session or specify requirements for the NEA protocols to 298 manage these sessions. 300 User - Role of a person that is making use of the services of an 301 endpoint. The user may not own the endpoint so might need to 302 operate within the acceptable use constraints defined by the 303 endpoint's owner. For example, an enterprise employee might 304 be a user of a computer provided by the enterprise (owner) 305 for business purposes. 307 3. Applicability 309 This section discusses the scope of the technologies being 310 standardized and the network environments where it is envisioned 311 that the NEA technologies might be applicable. 313 3.1 Scope 315 The priority of the NEA working group is to develop standard 316 protocols at the higher layers in the reference model (see section 317 5): the Posture Attribute protocol (PA) and the Posture Broker 318 protocol (PB). PA and PB will be designed to be carried over a 319 variety of lower layer transport (PT) protocols. The NEA WG will 320 identify standard PT protocol(s) that are mandatory to implement. 321 PT protocols may be defined in other WGs because the requirements 322 may not be specific to NEA. When used with a standard PT protocol 323 (e.g. EAP, TLS [TLS]), the PA and PB protocols will allow 324 interoperability between a NEA Client from one vendor and a NEA 325 Server from another. This specification will not focus on the 326 other interfaces between the functional components of the NEA 327 reference model nor requirements on their internals. Any 328 discussion of these aspects is included to provide context for 329 understanding the model and resulting requirements. 331 Some tangent areas not shown in the reference model that are 332 also out of scope for the NEA working group, and thus this 333 specification, include: 335 o Standardizing the protocols and mechanisms for enforcing 336 restricted network access, 337 o Developing standard protocols for remediation of non- 338 compliant endpoints, 339 o Specifying protocols used to communicate with remote 340 portions of the NEA Client or Server (e.g. remote 341 collectors or validators of posture), 342 o Supporting a NEA Client providing posture for other 343 endpoints (e.g. a NEA Client on an IDS providing posture 344 for an endpoint without a NEA Client), 345 o Defining the set of events or situations that might trigger 346 a NEA Client or NEA Server to request an assessment, 347 o Detecting or handling lying endpoints (see section 8.1.1 348 for more information). 350 3.2 Applicability of Environments 352 Because the NEA model is based on NEA-oriented software being 353 present on the endpoint and in the network infrastructure and 354 due to the nature of the information being exposed, the use of 355 NEA technologies may not apply in a variety of situations 356 possible on the Internet. Therefore, this section discusses 357 some of the scenarios where NEA is most likely to be applicable 358 and some where it may not. Ultimately, the use of NEA within a 359 deployment is not restricted to just these scenarios. The 360 decision of whether to use NEA technologies lies in the hands of 361 the deployer (e.g. network provider) based upon the expected 362 relationship they have with the owners and users of potential 363 endpoints. 365 NEA technologies are largely focused on scenarios where the 366 owner of the endpoint is the same as the owner of the network. 367 This is a very common model for enterprises that provide 368 equipment to employees to perform their duties. These employees 369 are likely bound under an employment contract that outlines what 370 level of visibility the employer expects to have into the 371 employee's use of company assets and possibly activities during 372 work hours. This contract may establish the expectation that 373 the endpoint needs to conform to policies set forth by the 374 enterprise. 376 Some other environments may be in a similar situation and thus 377 find NEA technologies to be beneficial. For example, 378 environments where the endpoint is owned by a party (possibly 379 even the user) that has explicitly expressed a desire to conform 380 to the policies established by a network or service provider in 381 exchange for being able to access its resources. An example of 382 this might be an independent contractor with a personal laptop, 383 working for a company imposing NEA assessment policies on its 384 employees, who may wish a similar level of access and is willing 385 to conform to the company's policies. NEA technologies may be 386 applicable to this situation. 388 Conversely, some environments where NEA is not expected to be 389 applicable would be environments where the endpoint is owned by 390 a user that has not agreed to conform to a network provider's 391 policies. An example might include when the above contractor 392 visits any public area like the local coffee shop that offers 393 Internet access. This coffee shop would not be expected to be 394 able to use NEA technologies to assess the posture of the 395 contractor's laptop. Because of the potentially invasive nature 396 of NEA technology, such an assessment could amount to an 397 invasion of privacy of the contractor. 399 Other environments are more difficult to determine whether NEA 400 is applicable, so the NEA WG will consider them to be out of 401 scope for consideration and specification. In order for an 402 environment to be considered applicable for NEA, the owner or 403 user of an endpoint must have established a clear expectation 404 that it will comply with the policies of the owner and operator 405 of the network. Such an expectation likely includes a 406 willingness to disclose appropriate information necessary for 407 the network to perform compliance checks. 409 4. Problem Statement 411 NEA technology may be used for a variety of purposes. This 412 section highlights some of the major situations where NEA 413 technologies may be beneficial. 415 One use is to facilitate endpoint compliance checking against an 416 organization's security policy when an endpoint connects to the 417 network. Organizations often require endpoints to run an IT- 418 specified OS configuration and have certain security 419 applications enabled, e.g. anti-virus software, host intrusion 420 detection/prevention systems, personal firewalls, and patch 421 management software. An endpoint that is not compliant with IT 422 policy may be vulnerable to a number of known threats that might 423 exist on the network. 425 Without NEA technology, ensuring compliance of endpoints to 426 corporate policy is a time-consuming and difficult task. Not 427 all endpoints are managed by a corporation's IT organization, 428 e.g. lab assets and contractor machines. Even for assets that 429 are managed, they may not receive updates in a timely fashion 430 because they are not permanently attached to the corporate 431 network, e.g. laptops. With NEA technology, the network is able 432 to assess an endpoint as soon as it requests access to the 433 network or at any time after joining the network. This provides 434 the corporation an opportunity to check compliance of all NEA- 435 capable endpoints in a timely fashion and facilitate endpoint 436 remediation potentially while quarantined when needed. 438 NEA technology can be used to provide posture assessment for a 439 range of ways of connecting to the network including (but not 440 limited to) wired and wireless LAN access such as using 441 802.1X[802.1X], remote access via IPsec[IPSEC] or SSL VPN, or 442 gateway access. 444 Endpoints that are not NEA-capable or choose not to share 445 sufficient posture to evaluate compliance may be subject to 446 different access policies. The decision of how to handle non- 447 compliant or non-participating endpoints can be made by the 448 network administrator possibly based on information from other 449 security mechanisms on the network (e.g. authentication). For 450 example, remediation instructions or warnings may be sent to a 451 non-compliant endpoint with a properly authorized user while 452 allowing limited access to the network. Also, network access 453 technologies can use the NEA results to restrict or deny access 454 to an endpoint, while allowing vulnerabilities to be addressed 455 before an endpoint is exposed to attack. The communication and 456 representation of NEA assessment results to network access 457 technologies on the network is out of scope for this document. 459 Reassessment is a second important use of NEA technology as it 460 allows for additional assessments of previously considered 461 compliant endpoints to be performed. This might become 462 necessary because network compliance policies and/or endpoint 463 posture can change over time. A system initially assessed as 464 being compliant when it joined the network may no longer be in 465 compliance after changes occur. For example, reassessment might 466 be necessary if a user disables a security protection (e.g. 467 host-based firewall) required by policy or when the firewall 468 becomes non-compliant after a firewall patch is issued and 469 network policy is changed to require the patch. 471 A third use of NEA technology may be to verify or supplement 472 organization asset information stored in inventory databases. 474 NEA technology can also be used to check and report compliance 475 for endpoints when they try to access certain mission critical 476 applications within an enterprise, employing service 477 (application) triggered assessment. 479 5. Reference Model 481 This section describes the reference model for Network Endpoint 482 Assessment. This model is provided to establish a context for the 483 discussion of requirements and may not directly map to any 484 particular product or deployment architecture. The model 485 identifies the major functionality of the NEA Client and Server and 486 their relationships, as well as the protocols they use to 487 communicate at various levels (e.g. PA is carried by the PB 488 protocol). 490 While the diagram shows 3 layered protocols, it is envisioned that 491 PA is likely a thin message wrapper around a set of attributes that 492 is batched and encapsulated in PB. PB is primarily a lightweight 493 message batching protocol, so the protocol stack is mostly the 494 transport (PT). The vertical lines in the model represent APIs 495 and/or protocols between components within the NEA Client or 496 Server. These interfaces are out of scope for standardization in 497 the NEA WG. 499 +-------------+ +--------------+ 500 | Posture | <--------PA--------> | Posture | 501 | Collectors | | Validators | 502 | (1 .. N) | | (1 .. N) | 503 +-------------+ +--------------+ 504 | | 505 | | 506 | | 507 +-------------+ +--------------+ 508 | Posture | | Posture | 509 | Broker | <--------PB--------> | Broker | 510 | Client | | Server | 511 +-------------+ +--------------+ 512 | | 513 | | 514 +-------------+ +--------------+ 515 | Posture | | Posture | 516 | Transport | <--------PT--------> | Transport | 517 | Client | | Server | 518 | (1 .. N) | | (1 .. N) | 519 +-------------+ +--------------+ 521 NEA CLIENT NEA SERVER 523 Figure 1: NEA Reference Model 525 The NEA Reference model does not include mechanisms for discovery 526 of NEA Clients and NEA Servers. It is expected that NEA Clients 527 and NEA Servers are configured with information that allows them to 528 reach each other. The specific methods of referencing the 529 configuration and establishing the communication channel are out of 530 scope for the NEA reference model and should be covered in the 531 specifications of candidate protocols such as the Posture Transport 532 (PT) protocol. 534 5.1 NEA Client and Server 536 5.1.1 NEA Client 538 The NEA Client is resident on an endpoint device and comprised 539 of the following functionality: 541 o Posture Collector(s) 543 o Posture Broker Client 545 o Posture Transport Client(s) 547 The NEA Client is responsible for responding to requests for 548 attributes describing the configuration of the local operating 549 domain of the client and handling the assessment results 550 including potential remediation instructions for how to conform 551 to policy. A NEA Client is not responsible for reporting on 552 posture of entities that might exist on the endpoint or over the 553 network that are outside the domain of execution (e.g. in other 554 virtual machine domains) of the NEA Client. 556 For example a network address translation (NAT) device might 557 route communications for many systems behind it, but when the 558 NAT device is joining the network its NEA Client would only 559 report its own (local) posture. Similarly, endpoints with 560 virtualization capabilities might have multiple independent 561 domains of execution (e.g. OS instances). Each NEA Client is 562 only responsible for reporting posture for its domain of 563 execution but this information might be aggregated by other 564 local mechanisms to represent the posture for multiple domains 565 on the endpoint. Such posture aggregation mechanisms are 566 outside the focus on this specification. 568 Endpoints lacking NEA Client software (which is out of NEA 569 scope) or choosing not to provide the attributes required by the 570 NEA Server could be considered non-compliant. The NEA model 571 includes capabilities to enable the endpoint to update its 572 contents in order to become compliant. 574 5.1.1.1 Posture Collector 576 The Posture Collector is responsible for responding to requests 577 for posture information in Request Attributes from the NEA 578 Server. The Posture Collector is also responsible for handling 579 assessment decisions in Result Attributes and remediation 580 instructions in Remediation Attributes. A single NEA Client can 581 have several Posture Collectors capable of collecting standard 582 and/or vendor-specific Posture Attributes for particular 583 features of the endpoint. Typical examples include Posture 584 Collectors that provide information about Operating System (OS) 585 version and patch levels, anti-virus software, and security 586 mechanisms on the endpoint such as host-based Intrusion 587 Detection System (IDS) or firewall. 589 Each Posture Collector will be associated with one or more 590 identifiers that enable it to be specified as the destination in 591 a PA message. The Posture Broker Client uses these identifiers 592 to route messages to this collector. An identifier might be 593 dynamic (e.g. generated by the Posture Broker Client at run-time 594 during registration) or more static (e.g. pre-assigned to 595 Posture Collector at install-time and passed to Posture Broker 596 Client during registration) or a function of the attribute 597 messages the collector desires to receive (e.g. message type for 598 subscription). 600 The NEA model allocates the following responsibilities to the 601 Posture Collector: 603 o Consulting with local privacy and security policies that 604 may restrict what information is allowed to be disclosed to 605 a given NEA Server. 607 o Receiving Request Attributes from a Posture Validator and 608 performing the local processing required to respond 609 appropriately. This may include: 610 - Collecting associated posture information for 611 particular features of the endpoint and returning this 612 information in Posture Attributes. 613 - Caching and recognizing the applicability of recently 614 issued attributes containing reusable assertions that 615 might serve to prove compliance and returning this 616 attribute instead of posture information. 618 o Receiving attributes containing remediation instructions on 619 how to update functionality on the endpoint. This could 620 require the collector to interact with the user, owner 621 and/or a remediation server. 623 o Monitoring the posture of particular features(s) on the 624 endpoint for posture changes that require notification to 625 the Posture Broker Client. 627 o Providing cryptographic verification of the attributes 628 received from the Validator and offering cryptographic 629 protection to the attributes returned. 631 The above list describes the model's view of the possible 632 responsibilities of the Posture Collector. Note that this is not 633 a set of requirements for what each Posture Collector 634 implementation must support nor is it an exhaustive list of all 635 the things a Posture Collector may do. 637 5.1.1.2 Posture Broker Client 639 The Posture Broker Client is both a PA message multiplexer and a 640 de-multiplexer. The Posture Broker Client is responsible for de- 641 multiplexing the PB message received from the NEA Server and 642 distributing each encapsulated PA message to the corresponding 643 Posture Collector(s). The model also allows for the posture 644 information request to be pre-provisioned on the NEA Client to 645 improve performance by allowing the NEA Client to report posture 646 without receiving a request for particular attributes from the 647 NEA Server. 649 The Posture Broker Client also multiplexes the responses from 650 the Posture Collector(s) and returns them to the NEA Server. The 651 Posture Broker Client constructs one or more PB messages using 652 the PA message(s) it obtains from the Posture Collector(s) 653 involved in the assessment. The quantity and ordering of 654 Posture Collector responses (PA message(s)) multiplexed into the 655 PB response message(s) can be determined by the Posture Broker 656 Client based on many factors including policy or characteristics 657 of the underlying network transport (e.g. MTU). A particular 658 NEA Client will have one Posture Broker Client. 660 The Posture Broker Client also handles the global assessment 661 decision from the Posture Broker Server and may interact with 662 the user to communicate the global assessment decision and aid 663 in any necessary remediation steps. 665 The NEA model allocates the following responsibilities to the 666 Posture Broker Client: 668 o Maintaining a registry of known Posture Collectors and 669 allowing for Posture Collectors to dynamically register 670 and deregister. 672 o Multiplexing and de-multiplexing attribute messages 673 between the NEA Server and the relevant Posture 674 Collectors. 676 o Handling posture change notifications from Posture 677 Collectors and triggering reassessment. 679 o Providing user notification about the global assessment 680 decision and other user messages sent by the NEA Server. 682 5.1.1.3 Posture Transport Client 684 The Posture Transport Client is responsible for establishing a 685 reliable communication channel with the NEA Server for the 686 message dialog between the NEA Client and NEA Server. There 687 might be more than one Posture Transport Client on a particular 688 NEA Client supporting different transport protocols (e.g. 689 802.1X, VPN). Certain Posture Transport Clients may be 690 configured with the address of the appropriate Posture Transport 691 Server to use for a particular network. 693 The NEA model allocates the following responsibilities to the 694 Posture Transport Client: 696 o Initiating and maintaining the communication channel to the 697 NEA Server. The Posture Transport Client hides the details 698 of the underlying carrier that could be a Layer 2 or Layer 699 3 protocol. 701 o Providing cryptographic protection for the message dialog 702 between the NEA Client and NEA Server. 704 5.1.2 NEA Server 705 The NEA Server is typically comprised of the following NEA 706 functionality: 708 o Posture Validator(s) 710 o Posture Broker Server 712 o Posture Transport Server(s) 714 The Posture Validators might be located on a separate server 715 from the Posture Broker Server requiring the Posture Broker 716 Server to deal with both local and remote Posture Validators. 718 5.1.2.1 Posture Validator 720 A Posture Validator is responsible for handling Posture 721 Attributes from corresponding Posture Collector(s). A Posture 722 Validator can handle Posture Attributes from one or more Posture 723 Collector(s) and vice-versa. The Posture Validator performs the 724 posture assessment for one or more features of the endpoint 725 (e.g. anti-virus software) and creates the result and if 726 necessary the remediation instructions or may choose to request 727 additional attributes from one or more collectors. 729 Each Posture Validator will be associated with one or more 730 identifiers that enable it to be specified as the destination in 731 a PA message. The Posture Broker Server uses this identifier to 732 route messages to this Validator. This identifier might be 733 dynamic (e.g. generated by the Posture Broker Server at run-time 734 during registration) or more static (e.g. pre-assigned to a 735 Posture Validator at install-time and passed to the Posture 736 Broker Server during registration) or a function of the 737 attribute messages the validator desires to receive (e.g. 738 message type for subscription). 740 Posture Validators can be co-located on the NEA Server or can be 741 hosted on separate servers. A particular NEA Server is likely 742 to need to handle multiple Posture Validators. 744 The NEA model allocates the following responsibilities to the 745 Posture Validator: 747 o Requesting attributes from a Posture Collector. The 748 request may include: 749 - Request Attributes that indicate to the Posture 750 Collector to fetch and provide Posture Attributes for 751 particular functionality on the endpoint. 753 o Receiving attributes from the Posture Collector. The 754 response from the Posture Collector may include: 755 - Posture Attributes collected for the requested 756 functionality. 757 - Assertion Attributes that indicate the compliance 758 result from a prior assessment. 760 o Assessing the posture of endpoint features based on the 761 attributes received from the Collector. 763 o Communicating the posture assessment result to the Posture 764 Broker Server. 766 o Communicating the posture assessment results to the Posture 767 Collector; this attribute message may include: 768 - Result Attributes that communicate the posture 769 assessment result. 770 - Remediation Attributes that communicate the 771 remediation instructions to the Posture Collector. 773 o Monitoring out-of-band updates that trigger reassessment 774 and require notifications to be sent to the Posture Broker 775 Server. 777 o Providing cryptographic protection for attributes sent to 778 the Posture Collector and offering cryptographic 779 verification of the attributes received from the Posture 780 Collector. 782 The above list describes the model's view of the possible 783 responsibilities of the Posture Validator. Note that this is not 784 a set of requirements for what each Posture Validator 785 implementation must support nor is it an exhaustive list of all 786 the things a Posture Validator may do. 788 5.1.2.2 Posture Broker Server 790 The Posture Broker Server acts as a multiplexer and a de- 791 multiplexer for attribute messages. The Posture Broker Server 792 parses the PB messages received from the NEA Client and de- 793 multiplexes them into PA messages that it passes to the 794 associated Posture Validators. The Posture Broker Server 795 multiplexes the PA messages (e.g. messages containing Request 796 Attribute(s) from the relevant Posture Validator(s)) into one or 797 more PB messages and sends them to the NEA Client via the 798 Posture Transport protocol. The quantity and ordering of 799 Posture Validator responses (PA messages) and global assessment 800 decision multiplexed into the PB response message(s) can be 801 determined by the Posture Broker Server based on many factors 802 including policy or characteristics of the underlying network 803 transport (e.g. MTU). 805 The Posture Broker Server is also responsible for computing the 806 global assessment decision based on individual posture 807 assessment results from the various Posture Validators. This 808 global assessment decision is sent back to the NEA Client in 809 Result Attributes within a PB message. A particular NEA Server 810 will have one Posture Broker Server and this Posture Broker 811 Server will handle all the local and remote Posture Validators. 813 The NEA model allocates the following responsibilities to the 814 Posture Broker Server: 816 o Maintaining a registry of Posture Validators and allowing 817 for Posture Validators to register and deregister. 819 o Multiplexing and de-multiplexing posture messages from and 820 to the relevant Posture Validators. 822 o Computing the global assessment decision based on posture 823 assessment results from the various Posture Validators and 824 compliance policy. This assessment decision is sent to 825 the Posture Broker Client in a PB message. 827 5.1.2.3 Posture Transport Server 829 The Posture Transport Server is responsible for establishing a 830 reliable communication channel with the NEA Client for the 831 message dialog between the NEA Client and NEA Server. There 832 might be more than one Posture Transport Server on a particular 833 NEA Server to support different transport protocols. A 834 particular Posture Transport Server will typically handle 835 requests from several Posture Transport Clients and may require 836 local configuration describing how to reach the NEA Clients. 838 The NEA model allocates the following responsibilities to the 839 Posture Transport Server: 841 o Initiating and maintaining a communication channel with 842 potentially several NEA Clients. 844 o Providing cryptographic protection for the message dialog 845 between the NEA Client and NEA Server. 847 5.2 Protocols 848 The NEA reference model includes three layered protocols (PA, PB 849 and PT) that allow for the exchange of attributes across the 850 network. While these protocols are intended to be used together to 851 fulfill a particular role in the model, they may offer overlapping 852 functionality. For example, each protocol should be capable of 853 protecting its information from attack (see section 8.2 for more 854 information). 856 5.2.1 Posture Attribute Protocol (PA) 858 PA is a protocol that carries one or more attributes between 859 Posture Collectors and their associated Posture Validator. The 860 PA protocol is a message oriented lightweight wrapper around a 861 set of attributes being exchanged. This wrapper may indicate 862 the purpose of attributes within the message. Some of the types 863 of messages expected include: requests for posture information 864 (Request Attributes), posture information about the endpoint 865 (Posture Attributes), results of an assessment (Result 866 Attributes), reusable compliance assertions (Assertion 867 Attributes) and instructions to remediate non-compliant portions 868 of the endpoint (Remediation Attributes). The PA protocol also 869 provides the requisite encoding and cryptographic protection for 870 the Posture Attributes. 872 5.2.2 Posture Broker Protocol (PB) 874 PB is a protocol that carries aggregate attribute messages 875 between the Posture Collectors on the NEA Client and the 876 corresponding Posture Validators on the NEA Server involved in a 877 particular assessment. The PB protocol provides a session 878 allowing for message dialogs for every assessment. This PB 879 session is then used to bind multiple Posture Attribute requests 880 and responses from the different Posture Collectors and Posture 881 Validators involved in a particular assessment. The PB protocol 882 may also carry the global assessment decision in the Result 883 Attribute from the Posture Broker Server to the Posture Broker 884 Client. PB may be used to carry additional types of messages 885 for use by the Posture Broker Client and Server (e.g. 886 information about user preferred interface settings such as 887 language). 889 5.2.3 Posture Transport Protocol (PT) 891 PT is a transport protocol between the NEA Client and the NEA 892 Server responsible for carrying the messages generated by the PB 893 protocol. The PT protocol(s) transports PB messages during the 894 network connection request or after network connectivity has been 895 established. 897 In scenarios where an initial assessment needs to occur during the 898 network connection, the PT protocol (e.g. EAP within 802.1X) may 899 have constrained use of the network, so deployments may choose to 900 limit the amount and/or size of the attributes exchanged. The NEA 901 Client and NEA Server should be able to detect when a potentially 902 constrained situation exists prior to the assessment based upon 903 properties of the underlying network protocol. Using this 904 information, NEA policy could dictate what aspects of the endpoint 905 to include in the initial assessment and potentially limit the PA 906 message attributes exchanged. This could be followed up by a full 907 re-assessment after the endpoint is placed on the network. 908 Alternatively, deployments can choose not to limit their assessment 909 by configuring their network access technology to temporarily grant 910 restricted IP connectivity prior to the assessment and use an 911 unconstrained, high bandwidth IP-based transport during the 912 assessment. Some of the constraints that may exist for protocols 913 involved in the network connection phase include: 915 o Limited maximum transmission unit (MTU) size and ability to 916 negotiate larger MTUs, 917 o Inability to perform multiple roundtrips, 918 o Lack of support for piggybacking attributes for other 919 protocols, 920 o Low bandwidth or high latency limitations precluding exchanges 921 of large amounts of data, 922 o Inability of servers to initiate messages except during the 923 network connection phase 925 The PT protocol selection process needs to consider the impact 926 of selecting a particular PT and set of underlying protocols on 927 the deployment needs of PA and PB. PA and PB will be selected 928 prior to PT so the needs of PA and PB will be known. Certain 929 underlying protocol stacks may be too constrained to support 930 adequate NEA assessments during network connection. 932 The PT protocol provides reliable message delivery, mutual 933 authentication and cryptographic protection for the PB messages 934 as specified by local policy. 936 5.3 Attributes 938 The PA protocol is responsible for the exchange of attributes 939 between a Posture Collector and Posture Validator. The PB protocol 940 may also carry the global assessment decision attributes from the 941 Posture Broker Server. Attributes are effectively the reserved 942 word 'nouns' of the posture assessment. The NEA Server is only 943 able to ask for information that has a corresponding attribute, 944 thus bounding what type of posture can be obtained. The NEA WG 945 will define a common (standard) set of attributes that are expected 946 to be widely applicable to Posture Collectors and thus used for 947 maximum interoperability, but Posture Collectors may support 948 additional vendor-specific attributes when necessary. 950 Depending on the deployment scenario, the purpose of the attributes 951 exchanged may be different (e.g. posture information vs. asserted 952 compliance). This section discusses the originator and expected 953 situation resulting in the use of each classification of attributes 954 in a PA message. These classifications are not intended to dictate 955 how the NEA WG will specify the attributes when defining the 956 attribute name space or schema. 958 5.3.1 Attributes Normally Sent by NEA Client: 960 o Posture Attributes - Attributes and values sent to report 961 information about a particular aspect (based on semantic of 962 the attribute) of the system. These attributes are typically 963 sent in response to Request Attributes from the NEA Server. 964 For example a set of Posture Attributes might describe the 965 status of the host-based firewall (e.g. if running, vendor, 966 version). The NEA Server would base its decision on comparing 967 this type of attribute against policy. 969 o Assertion Attributes - Attributes stating recent prior 970 compliance to policy in hopes of avoiding the need to 971 recollect the posture and send it to the NEA Server. Examples 972 of assertions include (a) NEA Server provided attributes 973 (state) describing a prior evaluation (e.g. opaque to 974 endpoint, signed, time stamped items stating specific results) 975 or (b) NEA Client identity information used by the NEA Server 976 to locate state about prior decisions (e.g. system-bound 977 cookie). These might be returned in lieu of or addition to 978 Posture Attributes. 980 5.3.2 Attributes Normally Sent by NEA Server: 982 o Request Attributes - Attributes that define the specific 983 posture information desired by the NEA Server. These 984 attributes might effectively form a template that the Posture 985 Collector fills in (subject to local policy restrictions) with 986 the specific value corresponding to each attribute. The 987 resulting attributes are typically Posture or Assertion 988 Attributes from the NEA Client. 990 o Result Attributes - Attributes that contain the decisions of 991 the Posture Validators and/or Posture Broker Server. The 992 level of detail provided may vary from which individual 993 attributes were compliant or not through just the global 994 assessment decision. 996 o Remediation Attributes - Attributes that explain to the NEA 997 Client and its user how to update the endpoint to become 998 compliant with the NEA Server policies. These attributes are 999 sent when the global assessment decision was that the endpoint 1000 is not currently compliant. Remediation and Result Attributes 1001 may both exist within a NEA Server attribute message. 1003 o Assertion Attributes - Attributes containing NEA Server 1004 assertions of compliance to a policy for future use by the NEA 1005 Client. See section 5.3.1 for more information. 1007 6. Use Cases 1009 This section discusses several of the NEA use cases with intent 1010 to describe and collectively bound the NEA problem space under 1011 consideration. The use cases provide a context and general 1012 rationale for the defined requirements. In order to ease 1013 understanding of each use case and how it maps to the reference 1014 model, each use case will be accompanied by a simple example and 1015 a discussion of how this example relates to the NEA protocols. 1016 It should be emphasized that the provided examples are not 1017 intended to indicate the only approach to addressing the use 1018 case but rather are included to ease understanding of how the 1019 flows might occur and impact the NEA protocols. 1021 We broadly classify the use cases into two categories, each with 1022 its own set of trigger events: 1023 o Initial assessment - evaluation of the posture of an 1024 endpoint that has not recently been assessed and thus is 1025 not in possession of any valid proof that it should be 1026 considered compliant. This evaluation might be triggered 1027 by a request to join a network, request to use a service or 1028 desire to understand the posture of a system. 1030 o Reassessment - evaluation of the posture of an endpoint 1031 that has previously been assessed. This evaluation could 1032 occur for a variety of reasons including the NEA Client or 1033 Server recognizing an occurrence affecting the endpoint 1034 that might raise the endpoint's risk level. This could be 1035 as simple as it having been a long time since the 1036 endpoint's prior reassessment. 1038 6.1 Initial Assessment 1040 An initial assessment occurs when a NEA Client or Server event 1041 occurs that causes the evaluation of the posture of the endpoint 1042 for the first time. Endpoints do not qualify for this category 1043 of use case if they have been recently assessed and the NEA 1044 Client or Server has maintained state (or proof) that the 1045 endpoint is compliant and therefore does not need to have its 1046 posture evaluated again. 1048 6.1.1 Triggered by Network Connection or Service Request 1050 This use case focuses on assessments performed at the time an 1051 endpoint attempts to join a network or request use of a service 1052 that requires a posture evaluation. This use case is particularly 1053 interesting because it allows the NEA Server to evaluate the 1054 posture of an endpoint before allowing it access to the network or 1055 service. This approach could be used to help detect endpoints with 1056 known vulnerabilities and facilitate their repair before they are 1057 admitted to the network and potentially exposed to threats on the 1058 network. 1060 A variety of types of endpoint actions could result in this class 1061 of assessment. For example, an assessment could be triggered by 1062 the endpoint trying to access a highly protected network service 1063 (e.g. financial or HR application server) where heightened security 1064 checking is required. A better known example could include 1065 requesting entrance to a network that requires systems to meet 1066 compliance policy. This example is discussed in more detail in the 1067 following section. 1069 6.1.1.1 Example 1071 An IT employee returning from vacation boots his office desktop 1072 computer that generates a request to join the wired enterprise 1073 network. The network's security policy requires the system to 1074 provide posture information in order to determine whether the 1075 desktop's security features are enabled and up to date. The 1076 desktop sends its patch, firewall and anti-virus posture 1077 information. The NEA Server determines that the system is 1078 lacking a recent security patch designed to fix a serious 1079 vulnerability and the system is placed on a restricted access 1080 network. The desktop follows the provided remediation 1081 instructions to download and install the necessary patch. 1082 Later, the desktop requests again to join the network and this 1083 time is provided full access to the enterprise network after a 1084 full assessment. 1086 6.1.1.2 Possible flows and Protocol Usage 1088 The following describes typical message flows through the NEA 1089 reference model for this example use case: 1091 1. The IT employee's desktop computer connects to the network 1092 through an access gateway in the wired enterprise network. 1093 2. The Posture Broker Server on the NEA Server is instructed to 1094 assess the endpoint joining the wired network. 1095 3. Based upon compliance policy the Posture Broker Server 1096 contacts the operating system patch, host-based firewall and 1097 anti-virus Posture Validators to request the necessary 1098 posture. Each Posture Validator creates a PA message 1099 containing the desired attributes to be requested for 1100 assessment from the desktop system. 1101 4. The Posture Broker Server aggregates the PA messages from 1102 the Posture Validators into a PB message. The Posture 1103 Broker Server passes the PB message to the Posture Transport 1104 Server that uses the PT protocol to send the PB message to 1105 the NEA Client on the desktop computer. 1106 5. The Posture Transport Client receives the message from the 1107 NEA Server and passes it to the Posture Broker Client for 1108 message delivery. 1109 6. The Posture Broker Client de-multiplexes the PB message and 1110 delivers the PA messages with the requests for attributes to 1111 the firewall, operating system patch and anti-virus Posture 1112 Collectors. 1113 7. Each Posture Collector involved consults local privacy 1114 policy to determine what information is allowed to be 1115 disclosed and then returns the requested attributes that are 1116 authorized in a PA message to the Posture Broker Client. 1117 8. The Posture Broker Client aggregates these PA messages into 1118 a single PB message and sends it to the Posture Broker 1119 Server using the Posture Transport Client to Server session. 1120 9. The Posture Transport Server provides the PB message to the 1121 Posture Broker Server that de-multiplexes the message and 1122 sends the appropriate attributes to the corresponding 1123 Posture Validator. 1124 10. Each Posture Validator compares the values of the attributes 1125 it receives with the expected values defined in its policy. 1126 11. The anti-virus and firewall Posture Validators return 1127 attributes to the Posture Broker Server stating the desktop 1128 computer is compliant, but the operating system patch 1129 Posture Validator returns non-compliant. The operating 1130 system patch Posture Validator creates a PA message that 1131 contains attributes with remediation instructions in 1132 addition to the attribute indicating non-compliance result. 1134 12. The Posture Broker Server aggregates the PA messages and 1135 sends them in a PB message to the Posture Broker Client via 1136 the Posture Transport Server and Posture Transport Client. 1137 13. The Posture Broker Client delivers the PA messages with 1138 from the various Posture Validators to the 1139 Posture Collectors including the PA message 1140 containing attributes with remediation instructions to the 1141 operating system patch Posture Collector that interacts with 1142 the user to download and install the needed patches, 1143 potentially while quarantined. 1144 14. Upon completion of the remediation, the above steps 1-10 are 1145 repeated (triggered by the NEA Client repeating its request 1146 to join the network). 1147 15. This time each involved Posture Validator (including the 1148 operating system patch Posture Validator) returns a 1149 compliant status and the Posture Broker Server returns a 1150 compliant result indicating a global success. 1151 16. The Posture Broker Client receives the compliant result and 1152 the IT employee's desktop is now on the network. 1154 6.1.1.3 Impact on Requirements 1156 The following are several different aspects of the use case example 1157 that potentially need to be factored into the requirements. 1159 o Posture assessment before endpoint allowed on network 1160 o Endpoint sends attributes containing posture information 1161 o NEA Server sends remediation instructions 1162 o NEA Client causes a reassessment after remediation 1164 6.1.2 Triggered by Endpoint 1166 This use case highlights that an endpoint (possibly at the 1167 request of a user) may wish to trigger an assessment of its 1168 posture to determine whether its security protective mechanisms 1169 are running and up to date. 1171 6.1.2.1 Example 1173 A student goes to the terminal room to work on a project. The 1174 terminal room contains shared systems owned by the school that 1175 are on the network. These systems have been previously used by 1176 other students so their security posture is unknown. The 1177 student wishes to check whether a system is currently in 1178 compliance with the school's security policies prior to doing 1179 work, so requests a posture assessment. The NEA Server performs 1180 an initial assessment of the system and determines it is 1181 compliant but the anti-virus protection is not in use. The 1182 student receives an advisory response indicating the system's 1183 anti-virus software is turned off but that otherwise it complies 1184 with the school's policy. The student turns on the anti-virus 1185 software, initiates a scan and upon completion decides to trust 1186 the system with her work. 1188 6.1.2.2 Possible flows and Protocol Usage 1190 The following describes the message flows through the NEA reference 1191 model for the student using a terminal room shared system example: 1193 1. Student triggers the Posture Broker Client on the computer 1194 system in the terminal room to initiate a posture 1195 assessment. 1196 2. The Posture Broker Client establishes a session with the 1197 Posture Broker Server that causes an assessment to be 1198 triggered. 1199 3. The Posture Broker Server detects the new session and 1200 consults policy to determine that Posture Validators to 1201 involve in the assessment. The Posture Broker Server 1202 decides to employ several Posture Validators including the 1203 anti-virus Posture Validator. 1204 4. The Posture Validators involved create PA messages 1205 containing requests for particular attributes containing 1206 information about the desired terminal room computer based 1207 on the school's security policy. 1208 5. The Posture Broker Server assembles a PB message including 1209 each of the PA messages from the Posture Validators. 1210 6. The Posture Transport Server sends the PB message to the 1211 Posture Transport Client where it is passed on to the 1212 Posture Broker Client. 1213 7. The Posture Broker Client on the student's computer de- 1214 multiplexes the PA messages and delivers them to the 1215 corresponding Posture Collectors. 1216 8. The Posture Collectors consult privacy policy to decide what 1217 information to share with the Server. If allowable, the 1218 collectors each return a PA message containing the requested 1219 posture to the Posture Broker Client. 1220 9. The Posture Broker Client aggregates the returned PA 1221 messages into a PB message and hands it to the Posture 1222 Transport Client for transmission to the Posture Transport 1223 Server. 1224 10. The Posture Broker Server separates and distributes the 1225 Posture Collector PA messages to the associated Posture 1226 Validators. 1227 11. The Posture Validators determine whether the attributes 1228 containing the posture included in the PA message are 1229 compliant with their policies and returns a posture 1230 assessment decision to the Posture Broker Server. In this 1231 case, the anti-virus Posture Validator returns a PA message 1232 indicating a non-compliant result because the anti-virus 1233 software is not running and includes attributes describing 1234 how to activate the software. 1235 12. The Posture Broker Server determines the overall compliance 1236 decision based on all of the Validators' assessment results 1237 and sends a PB message containing an attribute expressing 1238 the global assessment decision and the anti-virus 1239 Validator's PA message. In this case, the global assessment 1240 decision indicates the system is compliant (despite the 1241 anti-virus Validator's result) because the Posture Broker 1242 Server policy allowed for the anti-virus to not be running 1243 as long as the system was properly patched and running a 1244 firewall (which was the case according to the other Posture 1245 Validators). 1246 13. The Posture Transport Server sends the PB message to the 1247 Posture Transport Client that provides the message to the 1248 Posture Broker Client. 1249 14. The Posture Broker Client on the terminal room computer 1250 examines the PB message's global assessment decision 1251 attribute and reports to the student that the system was 1252 deemed to be compliant, but that an advisory was included. 1253 15. The Posture Broker Client provides the PA message with the 1254 remediation attributes to the anti-virus Posture Collector 1255 that interacts with the user to explain how to turn on anti- 1256 virus to improve the local protections. 1257 16. The student turns on the anti-virus software and on 1258 completion steps 1-10 are repeated. 1259 17. This time the anti-virus Posture Validator returns a success 1260 status and the Posture Broker Server returns a successful 1261 global assessment decision in the PB message. 1262 18. The Posture Broker Client receives the successful global 1263 assessment decision in the PB message and the student now 1264 uses the computer for her assignment. 1266 6.1.2.3 Impact on Requirements 1268 The following are several different aspects of the use case example 1269 that potentially need to be factored into the requirements. 1271 o Voluntary endpoint requested initial assessment, 1272 o Successful (compliant) global assessment decision included in 1273 PB message with a PA message containing an advisory set of 1274 attributes for remediation. 1276 6.2 Posture Reassessment 1278 Reassessment(s) of endpoints can happen anytime after being 1279 admitted to the network after a successful initial NEA 1280 assessment. These reassessments may be event-based such as 1281 driven by posture changes detected by the NEA Client or changes 1282 detected by network infrastructure such as detection of 1283 suspicious behavior or network policy updates on the NEA Server. 1284 They may also be periodic (timer-driven) to reassess the health 1285 of the endpoint. 1287 6.2.1 Triggered by NEA Client 1289 This use case allows for software on the endpoint or a user to 1290 determine that a reassessment of the system is required. There are 1291 a variety of reasons why such a reassessment might be beneficial 1292 including: changes in its previously reported posture, detection of 1293 potentially suspicious behavior or even to enable the system to 1294 periodically poll the NEA Server to assess its condition relative 1295 to the latest policies. 1297 6.2.1.1 Example 1299 The desktops within a company's HR department have a history of 1300 poor security practices and eventual compromise. The HR 1301 department administrator decides to deploy software on each 1302 desktop to monitor the use of security protective mechanisms to 1303 assure their use. One day, an HR person accidentally turns off 1304 the desktop firewall. The monitoring process detects the lack 1305 of a firewall and contacts the NEA Server to request a 1306 reassessment of the firewall compliance. The NEA Server returns 1307 a decision that the firewall must be reactivated to stay on the 1308 network. The NEA Client explains the decision to the user and 1309 how to reactivate the firewall. The HR person restarts the 1310 firewall and initiates a request to rejoin the network. 1312 6.2.1.2 Possible Flows & Protocol Usage 1314 The following describes the message flows through the NEA reference 1315 model for the HR department example: 1317 1. The desktop monitoring software that typically might act as 1318 a Posture Collector triggers the Posture Broker Client to 1319 initiate a posture reassessment. The Posture Broker Client 1320 creates a PB message that contains a PA message indicating 1321 the desktop firewall has been disabled. 1322 2. The Posture Broker Client sends the PB message to the 1323 Posture Broker Server. 1324 3. The Posture Transport Client sends the PB message to the 1325 Posture Transport Server over the PT protocol. 1326 4. The Posture Broker Server receives the PB message and 1327 forwards the PA message to the firewall Posture Validator 1328 for evaluation. 1330 5. The firewall Posture Validator determines that the endpoint 1331 is no longer compliant because its firewall has been 1332 disabled. 1333 6. The Posture Validator generates a PA message that contains 1334 attributes indicating a non-compliant posture assessment 1335 result and remediation instructions for how to reactivate 1336 the firewall. 1337 7. The Posture Validator communicates the PA message with the 1338 posture assessment result to the Posture Broker Server to 1339 respond back to the NEA Client. 1340 8. The Posture Broker Server generates a PB message including a 1341 global assessment decision of non-compliant and the PA 1342 message from the firewall Posture Validator. 1343 9. The Posture Transport Server transports the PB message to 1344 the Posture Transport Client where it is passed to the 1345 Posture Broker Client. 1346 10. The Posture Broker Client processes the attribute containing the 1347 global assessment decision received from the NEA Server and 1348 displays the non-compliance messages to the user. 1349 11. The Posture Broker Client forwards the PA message to the 1350 firewall Posture Collector; the Posture Collector displays the 1351 remediation instructions for how to enable the desktop firewall. 1352 12. The user is prompted to initiate a reassessment after completing 1353 the remediation. 1354 13. Upon completion of the remediation, the NEA Client reinitiates a 1355 request for reassessment and steps 1-4 are repeated. This time 1356 the firewall Posture Validator determines the endpoint is 1357 compliant and returns a successful posture assessment decision. 1358 14. The Posture Broker Server generates a PB message with a global 1359 assessment decision of compliant and returns this to the NEA 1360 Client. 1362 6.2.1.3 Impact on Requirements 1364 The following are several different aspects of the use case example 1365 that potentially need to be factored into the requirements. 1367 o Voluntary, endpoint (software) initiated posture reassessment 1368 request 1369 o NEA Server requests specific firewall-oriented Posture 1370 Attributes 1371 o NEA Client (firewall Posture Collector) interacts with user 1372 to remediate problem 1374 6.2.2 Triggered by NEA Server 1376 In many cases, especially for reassessment, the NEA Server may 1377 initiate specific or complete reassessment of one or more endpoints 1378 triggered by: 1380 o Time (periodic) 1381 o Event occurrence 1382 o Policy updates 1384 6.2.2.1 Example 1386 An enterprise requires employees on the network to always stay 1387 up to date with security critical operating system patches. A 1388 marketing employee joins the network and performs an initial 1389 assessment. The assessment determines the employee's laptop is 1390 compliant. Several hours later, a major operating system vendor 1391 releases a set of patches preventing a serious vulnerability 1392 that is being exploited on the Internet. 1394 The enterprise administrators make available the patches and 1395 change the network policy to require them to be installed by 5 1396 PM. This policy change causes the NEA Server to request a 1397 reassessment to determine which endpoints are impacted and 1398 lacking the patches. The marketing employee's laptop is 1399 reassessed and determined to need the patches. A remediation 1400 advisory is sent and presented to the employee explaining how to 1401 obtain the patch and that it must be installed by 5 PM. The 1402 marketing employee immediately downloads and installs the patch 1403 and obtains an assertion that the patches are now installed. 1405 At 5 PM the enterprise performs another reassessment of all 1406 impacted endpoints to determine if they are now in compliance. 1407 The marketing employee's laptop is reassessed and presents the 1408 assertion that it has the patches installed and thus is 1409 determined to be compliant. 1411 6.2.2.2 Possible Flows and Protocol Usage 1413 The following describes the message flows through the NEA reference 1414 model for the above example: 1416 1. Marketing employee joins network and completes an initial 1417 assessment resulting in a compliant decision. 1418 2. The Enterprise Administrator configures an operating system 1419 patch policy indicating that recent patches are required on 1420 all endpoints by 5 PM to prevent serious vulnerabilities. 1421 3. The NEA Server's operating system patch Posture Validator 1422 becomes aware of this policy change and creates a PA message 1423 requesting attributes describing OS patches in use and 1424 triggers the Posture Broker Server to initiate a posture 1425 reassessment of all endpoints connected to the network. 1426 4. The Posture Broker creates a PB message that includes the PA 1427 message from the operating system patch Posture Validator. 1429 5. The Posture Broker Server gradually establishes a session 1430 with each available NEA Client. 1431 6. The Posture Broker Server sends the PB message to the 1432 Posture Broker Client. 1433 7. The Posture Transport Server carries the PB message to the 1434 Posture Transport Client over the PT protocol. 1435 8. The Posture Broker Client receives the PB message and 1436 forwards the PA message to the operating system patch 1437 Posture Collector. 1438 9. The operating system patch Posture Collector determines the 1439 OS patches present on the endpoint and if authorized by its 1440 disclosure policy creates a PA message containing the patch 1441 information attributes. 1442 10. The Posture Broker Client sends a PB message that includes 1443 the operating system patch PA message. 1444 11. The Posture Transport Client transports the PB message to 1445 the Posture Transport Server where it is passed to the 1446 Posture Broker Server. 1447 12. The Posture Broker Server receives the PB message and delivers 1448 the PA message to the operating system patch Posture Validator. 1449 13. The operating system patch Posture Validator extracts the 1450 attributes describing the current OS patches from the PA 1451 message and uses the values to determine whether the 1452 endpoint is compliant with the new policy. The Posture 1453 Validator determines that the endpoint is not compliant 1454 since it does not have the new OS patches installed. 1455 14. The Posture Validator generates a PA message that includes 1456 attributes stating the posture assessment decision is non- 1457 compliant and attributes containing the remediation 1458 instructions to enable the endpoint to download the required 1459 OS patches. 1460 15. The Posture Validator communicates the posture assessment 1461 result to the Posture Broker Server along with its PA 1462 message. 1463 16. The Posture Broker Server generates a global assessment 1464 decision and sends a PB message with the decision and the 1465 operating system patch Posture Validator's PA message. 1466 17. The Posture Transport Server transports the PB message to 1467 the Posture Transport Client where it is passed to the 1468 Posture Broker Client. 1469 18. The Posture Broker Client processes the Result Attribute 1470 received from the NEA Server and displays the non-compliance 1471 decision to the user. 1472 19. The Posture Broker Client forwards the PA message containing the 1473 remediation instructions to the operating system patch Posture 1474 Collector; the Posture Collector guides the user with 1475 instructions on how to become compliant that include downloading 1476 the appropriate OS patches to prevent the vulnerability. 1478 20. The marketing employee installs the required patches and now is 1479 in compliance. 1480 21. The NEA Client triggers a reassessment of the operating system 1481 patches that causes a repeat of many of the steps above. This 1482 time in step 13 the operating system patch Posture Validator 1483 determines the marketing employee's laptop is compliant. It 1484 returns a reusable (e.g. signed and dated) set of attributes 1485 that assert OS patch compliance to the latest policy. These OS 1486 patch compliance assertions can be used in a future PA message 1487 from the operating system patch Collector instead of determining 1488 and providing the specific patch set posture as before. 1489 22. This time when the operating system patch Posture Collector 1490 receives the PA message that contains reusable attributes 1491 asserting compliance, it caches those attributes for future use. 1492 23. Later at 5 PM, the NEA Server triggers a gradual reassessment to 1493 determine compliance to the patch advisory. When the operating 1494 system patch Posture Collector receives the request for posture 1495 information (like in step 9 above) it returns the cached set of 1496 assertions (instead of specific OS patch information) to 1497 indicate that the patches have been installed instead of 1498 determining all the patches that have been installed on the 1499 system. 1500 24. When the operating system patch Posture Validator receives the 1501 PA message containing the assertions, it is able to determine 1502 that they are authentic and acceptable assertions instead of 1503 specific posture. It returns a posture assessment decision of 1504 compliant thus allowing the laptop to remain on the network. 1506 6.2.2.3 Impact on Requirements 1508 The following are several different aspects of the use case example 1509 that potentially need to be factored into the requirements. 1511 o Server initiated reassessment required due to urgent patch 1512 availability 1513 o NEA Client submits reusable assertion attributes instead of 1514 posture that patch is installed 1515 o NEA Server capable of recognizing previously issued assertion 1516 attributes are sufficient instead of posture 1518 7. Requirements 1520 This section describes the requirements that will be used by the 1521 NEA WG to assess and compare candidate protocols for PA, PB and 1522 PT. These requirements frequently express features that a 1523 candidate protocol must be capable of offering so that a 1524 deployer can decide whether to make use of that feature. This 1525 section does not state requirements about what features of each 1526 protocol must be used during a deployment. 1528 For example, a requirement (MUST, SHOULD or MAY) might exist for 1529 cryptographic security protections to be available from each 1530 protocol but this does not require that a deployer make use of 1531 all or even any of them should they deem their environment to 1532 offer other protections that are sufficient. 1534 7.1 Common Protocol Requirements 1536 The following are the common requirements that apply to the PA, 1537 PB and PT protocols in the NEA reference model: 1539 C-1 NEA protocols MUST support multiple round trips between 1540 the NEA Client and NEA Server in a single assessment. 1542 C-2 NEA protocols SHOULD provide a way for both the NEA 1543 Client and the NEA Server to initiate a posture 1544 assessment or reassessment as needed. 1546 C-3 NEA protocols including security capabilities MUST be 1547 capable of protecting against active and passive attacks 1548 by intermediaries and endpoints including prevention from 1549 replay based attacks. 1551 C-4 The PA and PB protocols MUST be capable of operating over 1552 any PT protocol. For example, the PB protocol must 1553 provide a transport independent interface allowing the PA 1554 protocol to operate without change across a variety of 1555 network protocol environments (e.g. EAP/802.1X, TLS and 1556 IKEv2). 1558 C-5 The selection process for NEA protocols MUST evaluate and 1559 prefer the reuse of existing open standards that meet the 1560 requirements before defining new ones. The goal of NEA 1561 is not to create additional alternative protocols where 1562 acceptable solutions already exist. 1564 C-6 NEA protocols MUST be highly scalable; the protocols MUST 1565 support many Posture Collectors on a large number of NEA 1566 Clients to be assessed by numerous Posture Validators 1567 residing on multiple NEA Servers. 1569 C-7 The protocols MUST support efficient transport of a large 1570 number of attribute messages between the NEA Client and 1571 the NEA Server. 1573 C-8 NEA protocols MUST operate efficiently over low bandwidth 1574 or high latency links. 1576 C-9 For any strings intended for display to a user, the 1577 protocols MUST support adapting these strings to the 1578 user's language preferences. 1580 C-10 NEA protocols MUST support encoding of strings in UTF-8 1581 format[UTF8]. 1583 C-11 Due to the potentially different transport 1584 characteristics provided by the underlying candidate PT 1585 protocols, NEA Client and NEA Server MUST be capable of 1586 becoming aware of and adapting to the limitations of the 1587 available PT protocol. For example, some PT protocol 1588 characteristics that might impact the operation of PA and 1589 PB include restrictions on: which end can initiate a NEA 1590 connection, maximum data size in a message or full 1591 assessment, upper bound on number of roundtrips, and 1592 ordering (duplex) of messages exchanged. The selection 1593 process for the PT protocols MUST consider the 1594 limitations the candidate PT protocol would impose upon 1595 the PA and PB protocols. 1597 7.2 Posture Attribute (PA) Protocol Requirements 1599 The Posture Attribute (PA) protocol defines the transport and data 1600 model to carry posture and validation information between a 1601 particular Posture Collector associated with the NEA Client and a 1602 Posture Validator associated with a NEA Server. The PA protocol 1603 carries collections of standard attributes and vendor-specific 1604 attributes. The PA protocol itself is carried inside the PB 1605 protocol. 1607 The following requirements define the desired properties that form 1608 the basis for comparison and evaluation of candidate PA protocols. 1609 These requirements do not mandate the use of these properties, but 1610 merely that the candidate protocols are capable of offering the 1611 property if it should be needed. 1613 PA-1 The PA protocol MUST support communication of an extensible 1614 set of NEA standards defined attributes. These attributes 1615 will be distinguishable from non-standard attributes. 1617 PA-2 The PA protocol MUST support communication of an extensible 1618 set of vendor-specific attributes. These attributes will be 1619 segmented into uniquely identified vendor specific name 1620 spaces. 1622 PA-3 The PA protocol MUST enable a Posture Validator to make one 1623 or more requests for attributes from a Posture Collector 1624 within a single assessment. This enables the Posture 1625 Validator to reassess the posture of a particular endpoint 1626 feature or to request additional posture including from other 1627 parts of the endpoint. 1629 PA-4 The PA protocol MUST be capable of returning attributes from 1630 a Posture Validator to a Posture Collector. For example, 1631 this might enable the Posture Collector to learn the specific 1632 reason for a failed assessment and to aid in remediation and 1633 notification of the system owner. 1635 PA-5 The PA protocol SHOULD provide authentication, integrity, and 1636 confidentiality protection for attributes communicated 1637 between a Posture Collector and Posture Validator. This 1638 enables end-to-end security across a NEA deployment that 1639 might involve traversal of several systems or trust 1640 boundaries. 1642 PA-6 The PA protocol MUST be capable of carrying attributes that 1643 contain non-binary and binary data including encrypted 1644 content. 1646 7.3 Posture Broker (PB) Protocol Requirements 1648 The PB protocol supports multiplexing of Posture Attribute messages 1649 (based on PA protocol) between the Posture Collectors on the NEA 1650 Client to and from the Posture Validators on the NEA Server (in 1651 either direction). 1653 The PB protocol carries the global assessment decision made by the 1654 Posture Broker Server, taking into account the results of the 1655 Posture Validators involved in the assessment, to the Posture 1656 Broker Client. The PB protocol also aggregates and transports 1657 advisories and notifications such as remediation instructions (e.g. 1658 patch references) from one or more Posture Validators. 1660 The requirements for the PB protocol are: 1662 PB-1 The PB protocol MUST be capable of carrying attributes from 1663 the Posture Broker Server to the Posture Broker Client. This 1664 enables the Posture Broker Client to learn the posture 1665 assessment decision and if appropriate to aid in remediation 1666 and notification of the endpoint owner. 1668 PB-2 The PB protocol MUST NOT interpret the contents of PA 1669 messages being carried, i.e., the data it is carrying must be 1670 opaque to it. 1672 PB-3 The PB protocol MUST carry unique identifiers that are used 1673 by the Posture Brokers to route (deliver) PA messages between 1674 Posture Collectors and Posture Validators. Such message 1675 routing should facilitate dynamic registration or 1676 deregistration of Posture Collectors and Validators. For 1677 example, a dynamically registered anti-virus Posture 1678 Validator should be able to subscribe to receive messages 1679 from its respective anti-virus Posture Collector on NEA 1680 Clients. 1682 PB-4 The PB protocol MUST be capable of supporting a half-duplex 1683 PT protocol. However this does not preclude PB from 1684 operating full-duplex when running over a full-duplex PT. 1686 PB-5 The PB protocol MAY support authentication, integrity and 1687 confidentiality protection for the attribute messages it 1688 carries between a Posture Broker Client and Posture Broker 1689 Server. This provides security protection for a message 1690 dialog of the groupings of attribute messages exchanged 1691 between the Posture Broker Client and Posture Broker Server. 1692 Such protection is orthogonal to PA protections (which are 1693 end to end) and allows for simpler Posture Collector and 1694 Validators to be implemented, and for consolidation of 1695 cryptographic operations possibly improving scalability and 1696 manageability. 1698 PB-6 The PB protocol MUST support grouping of attribute messages 1699 to optimize transport of messages and minimize round trips. 1701 7.4 Posture Transport (PT) Protocol Requirements 1703 The Posture Transport (PT) protocol carries PB protocol messages 1704 between the Posture Transport Client and the Posture Transport 1705 Server. PT is responsible for providing a protected transport for 1706 the PB protocol. The PT protocol may itself be transported by one 1707 or more concatenated sessions using lower layer protocols, such as 1708 802.1X, RADIUS [RADIUS], TLS, or IKE. 1710 This section defines the requirements that candidate PT protocols 1711 must be capable of supporting. 1713 PT-1 The PT protocol MUST NOT interpret the contents of PB 1714 messages being transported, i.e., the data it is carrying 1715 must be opaque to it. 1717 PT-2 The PT protocol MUST be capable of supporting mutual 1718 authentication, integrity, confidentiality and replay 1719 protection of the PB messages between the Posture Transport 1720 Client and the Posture Transport Server. 1722 PT-3 The PT protocol MUST provide reliable delivery for the PB 1723 protocol. This includes the ability to perform fragmentation 1724 and reassembly, detect duplicates, and reorder to provide in- 1725 sequence delivery, as required. 1727 PT-4 The PT protocol SHOULD be able to run over existing network 1728 access protocols such as 802.1X and IKEv2. 1730 PT-5 The PT protocol SHOULD be able to run between a NEA Client 1731 and NEA Server over TCP or UDP (similar to LDAP). 1733 8. Security Considerations 1735 This document defines the functional requirements for the PA, PB 1736 and PT protocols used for Network Endpoint Assessment. As such, it 1737 does not define a specific protocol stack or set of technologies, 1738 so this section will highlight security issues that may apply to 1739 NEA in general or to particular aspects of the NEA reference model. 1741 Note that while a number of topics are outside the scope of the NEA 1742 WG and thus this specification (see section 3.1), it is important 1743 that those mechanisms are protected from attack. For example, the 1744 methods of triggering an assessment or reassessment are out of 1745 scope but should be appropriately protected from attack (e.g. an 1746 attacker hiding the event indicating a NEA Server policy change has 1747 occurred). 1749 NEA intends to facilitate detection and corrective actions for 1750 cooperating endpoints to become compliant with network compliance 1751 policies. For example, it is envisioned that these policies will 1752 allow deployers to detect out of date, inactive or absent security 1753 mechanisms on the endpoint that might leave it more vulnerable to 1754 known attacks. If an endpoint is more vulnerable to compromise, 1755 then it is more risky to have this endpoint present on the network 1756 with other valuable assets. By proactively assessing cooperating 1757 endpoints before their entrance to the network, deployers can 1758 improve their resilience to attack prior to network access. 1759 Similarly reassessments of cooperating endpoints on the network may 1760 be helpful in assuring that security mechanisms remain in use and 1761 are up to date with the latest policies. 1763 NEA fully recognizes that not all endpoints will be cooperating by 1764 providing their valid posture (or any posture at all). This might 1765 occur if malware is influencing the NEA Client or policies and thus 1766 a trustworthy assessment isn't possible. Such a situation could 1767 result in the admission of an endpoint that introduces threats to 1768 the network and other endpoints despite passing the NEA compliance 1769 assessment. 1771 8.1 Trust 1773 Network Endpoint Assessment involves assessing the posture of 1774 endpoints entering or already on the network against compliance 1775 policies to assure they are adequately protected. Therefore, there 1776 must be an implied distrusting of endpoints until there is reason 1777 to believe (based on posture information) that they are protected 1778 from threats addressed by compliance policy and can be trusted to 1779 not propagate those threats to other endpoints. On the network 1780 provider side, the NEA Client normally is expected to trust the 1781 network infrastructure systems to not misuse any disclosed posture 1782 information (see section 9) and any remediation instructions 1783 provided to the endpoint. The NEA Client normally also needs to 1784 trust that the NEA Server will only request information required to 1785 determine whether the endpoint is safe to access the network 1786 assets. 1788 Between the NEA Client and Server there exists a network that is 1789 not assumed to be trustworthy. Therefore, little about the network 1790 is implicitly trusted beyond its willingness and ability to 1791 transport the exchanged messages in a timely manner. The amount of 1792 trust given to each component of the NEA reference model is 1793 deployment specific. The NEA WG intends to provide security 1794 mechanisms to reduce the amount of trust that must be assumed by a 1795 deployer. The following sections will discuss each area in more 1796 detail. 1798 8.1.1 Endpoint 1800 For NEA to properly operate, the endpoint needs to be trusted to 1801 accurately represent the requested security posture of the endpoint 1802 to the NEA Server. By NEA WG charter, the NEA reference model does 1803 not explicitly specify how to detect or prevent lying endpoints 1804 that intentionally misrepresent their posture. Similarly, the 1805 detection of malware (e.g. root kits) that are able to trick the 1806 Posture Collectors into returning incorrect information is the 1807 subject for research and standardization outside the IETF (e.g. 1808 Trusted Computing Group [TCG]) and is not specifically addressed by 1809 the model. However, if such mechanisms are used in a deployment, 1810 the NEA reference model should be able to accommodate these 1811 technologies by allowing them to communicate over PA to Posture 1812 Validators or work orthogonally to protect the NEA Client from 1813 attack and assure the ability of Posture Collectors to view the 1814 actual posture. 1816 Besides having to trust the integrity of the NEA Client and its 1817 ability to accurately collect and report Posture Attributes about 1818 the endpoint, we try to limit other assumed trust. Most of the 1819 usage models for NEA expect the posture information to be sent to 1820 the NEA Server for evaluation and decision making. When PA and/or 1821 PT level security protections are used, the endpoint needs to trust 1822 the integrity and potentially confidentiality of the trust anchor 1823 information (e.g. public key certificates) used by the Posture 1824 Collector and/or Posture Transport Client. However, NEA 1825 implementations may choose to send or pre-provision some policies 1826 to the endpoint for evaluation that would assume more trust in the 1827 endpoint. In this case, the NEA Server must trust the endpoint's 1828 policy storage, evaluation and reporting mechanisms to not falsify 1829 the results of the posture evaluation. 1831 Generally the endpoint should not trust network communications 1832 (e.g. inbound connection requests) unless this trust has been 1833 specifically authorized by the user or owner defined policy or 1834 action. The NEA reference model assumes the entire NEA Client is 1835 local to the endpoint. Unsolicited communications originating from 1836 the network should be inspected by normal host-based security 1837 protective mechanisms (e.g. firewalls, security protocols, 1838 Intrusion Detection/Prevention System (IDS/IPS), etc). 1839 Communications associated with a NEA assessment or reassessment 1840 requires some level of trust particularly when initiated by the NEA 1841 Server (reassessment). The degree of trust can be limited by use 1842 of strong security protections on the messages as dictated by the 1843 network deployer and the endpoint user/owner policy. 1845 8.1.2 Network Communications 1847 Between the NEA Client and Server there may exist a variety of 1848 types of devices to facilitate the communication path. Some of the 1849 devices may serve as intermediaries (e.g. simple L2 switches) so 1850 may have the opportunity to observe and change the message dialogs. 1852 The intermediary devices may fall into a few major categories that 1853 impact our degree of trust in their operation. First, some 1854 intermediary devices may act as message forwarders or carriers for 1855 PT (e.g. L2 switches, L3 routers). For these devices we trust them 1856 not to drop the messages or actively attempt to disrupt (e.g. 1857 denial of service (DoS)) the NEA deployment. 1859 Second, some intermediary devices may be part of the access control 1860 layer of the network and as such we trust them to enforce policies 1861 including remediation, isolation, and access controls given to them 1862 as a result on a NEA assessment. These devices may also fill other 1863 types of roles described in this section. 1865 Third, some devices may act as a termination point or proxy for the 1866 PT carrier protocol. Frequently, it is expected that the carrier 1867 protocol for PT will terminate on the NEA Client and Server so will 1868 be co-resident with the PT endpoints. If this expectation is not 1869 present in a deployment, we must trust the termination device to 1870 accurately proxy the PT messages without alteration into the next 1871 carrier protocol (e.g. if inner EAP method messages are 1872 transitioned from an EAP [EAP] tunnel to a RADIUS session). 1874 Fourth, many networks include infrastructure such as IDS/IPS 1875 devices that monitor and take corrective action when suspicious 1876 behavior is observed on the network. These devices may have a 1877 relationship with the NEA Server that is not within scope for this 1878 specification. Devices trusted by the NEA Server to provide 1879 security information that might affect the NEA Server's decisions 1880 are trusted to operate properly and not cause the NEA Server to 1881 make incorrect decisions. 1883 Finally, other types of intermediary devices may exist on the 1884 network between the NEA Client and Server that are present to 1885 service other network functions beside NEA. These devices might be 1886 capable of passively eavesdropping on the network, archiving 1887 information for future purposes (e.g. replay or privacy invasion), 1888 or more actively attacking the NEA protocols. Because these 1889 devices do not play a role in facilitating NEA, it is essential 1890 that NEA deployers not be forced to trust them for NEA to reliably 1891 operate. Therefore, it is required that NEA protocols offer 1892 security protections to assure these devices can't steal, alter, 1893 spoof or otherwise damage the reliability of the message dialogs. 1895 8.1.3 NEA Server 1897 The NEA Server (including potentially remote systems providing 1898 posture validation services) is generally trusted to apply the 1899 specified assessment policies and must be protected from 1900 compromise. It is essential that NEA Server deployments properly 1901 safeguard these systems from a variety of attacks from the network 1902 and endpoints to assure their proper operation. 1904 While we need to trust the NEA Server operation to some degree, 1905 rigorous security architecture, analysis, monitoring and review 1906 should assure its network footprint and internal workings are 1907 protected from attack. The network footprint would include 1908 communications over the network that might be subject to attack 1909 such as policy provisioning from the policy authoring systems and 1910 general security and system management protocols. Some examples of 1911 internal workings include protections from malware attacking the 1912 intra-NEA Server communications, NEA Server internal logic or 1913 policy stores (particularly those that would change the resulting 1914 decisions or enforcements). The NEA Server needs to trust the 1915 underlying NEA and lower layer network protocols to properly behave 1916 and safeguard the exchanged messages with the endpoint. The NEA 1917 reference model does not attempt to address integrity protection of 1918 the operating system or other software supporting the NEA Server. 1920 One interesting example is where some components of the NEA Server 1921 physically reside in different systems. This might occur when a 1922 Posture Validator (or a remote backend server used by a local 1923 Posture Validator) exists on another system from the Posture Broker 1924 Server. Similarly, the Posture Broker Server might exist on a 1925 separate system from the Posture Transport Server. When there is a 1926 physical separation, the communications between the remote 1927 components of the NEA Server must ensure that the PB session and PA 1928 message dialogs are resistant to active and passive attacks, in 1929 particular, guarded against eavesdropping, forgery and replay. 1930 Similarly, the Posture Validators may also wish to minimize their 1931 trust in the Posture Broker Server beyond its ability to properly 1932 send and deliver PA messages. The Posture Validators could employ 1933 end-to-end PA security to verify the authenticity and protect the 1934 integrity and/or confidentiality of the PA messages exchanged. 1936 When PA security is used, each Posture Validator must be able to 1937 trust the integrity and potentially confidentiality of its trust 1938 anchor policies. 1940 8.2 Protection Mechanisms at Multiple Layers 1942 Inherent in the requirements is a desire for NEA candidate 1943 protocols throughout the reference model to be capable of providing 1944 strong security mechanisms as dictated by the particular 1945 deployment. In some cases, these mechanisms may appear to provide 1946 overlapping or redundant protections. These apparent overlaps may 1947 be used in combination to offer a defense in depth approach to 1948 security. However because of the layering of the protocols each 1949 set of protections offers slightly different benefits and levels of 1950 granularity. 1952 For example, a deployer may wish to encrypt traffic at the PT layer 1953 to protect against some forms of traffic analysis or interception 1954 by an eavesdropper. Additionally, the deployer may also 1955 selectively encrypt messages containing the posture of an endpoint 1956 to achieve end to end confidentiality to its corresponding Posture 1957 Validator. In particular, this might be desired when the Posture 1958 Validator is not co-located with the NEA Server so the information 1959 will traverse additional network segments after the PT protections 1960 have been enforced or so that the Posture Validator can 1961 authenticate the corresponding Posture Collector (or vice versa). 1963 Different use cases and environments for the NEA technologies will 1964 likely influence the selection of the strength and security 1965 mechanisms employed during an assessment. The goal of the NEA 1966 requirements is to encourage the selection of technologies and 1967 protocols that are capable of providing the necessary protections 1968 for a wide variety of types of assessment. 1970 8.3 Relevant Classes of Attack 1972 A variety of attacks are possible against the NEA protocols and 1973 assessment technologies. This section does not include a full 1974 security analysis, but wishes to highlight a few attacks that 1975 influenced the requirement definition and should be considered by 1976 deployers selecting use of protective mechanisms within the NEA 1977 reference model. 1979 As discussed, there are a variety of protective mechanisms included 1980 in the requirements for candidate NEA protocols. Different use 1981 cases and environments may cause deployers to decide not to use 1982 some of these mechanisms; however this should be done with an 1983 understanding that the deployment may become vulnerable to some 1984 classes of attack. As always a balance of risk vs. performance, 1985 usability, manageability and other factors should be taken into 1986 account. 1988 The following types of attacks are applicable to network protocols 1989 defined in the reference model and thus should be considered by 1990 deployers. 1992 8.3.1 Man-in-the-Middle (MITM) 1994 MITM attacks against a network protocol exist when a third party 1995 can insert itself between two communicating entities without 1996 detection and gain benefit from involvement in their message 1997 dialog. For example, a malware infested system might wish to join 1998 the network replaying posture observed from a clean endpoint 1999 entering the network. This might occur by the system inserting 2000 itself into and actively proxying an assessment message dialog. The 2001 impact of the damage caused by the MITM can be limited or prevented 2002 by selection of appropriate protocol protective mechanisms. 2004 For example, the requirement for PT to be capable of supporting 2005 mutual authentication prior to any endpoint assessment message 2006 dialogs prevents the attacker from inserting itself as an active 2007 participant (proxy) within the communications without detection 2008 (assuming attacker lacks credentials convincing either party it is 2009 legitimate). Reusable credentials should not be exposed on the 2010 network to assure the MITM doesn't have a way to impersonate either 2011 party. The PT requirement for confidentiality protected 2012 (encrypted) communications linked to the above authentication 2013 prevents a passive MITM from eavesdropping by observing the message 2014 dialog and keeping a record of the conformant posture values for 2015 future use. The PT requirement for replay prevention stops a 2016 passive MITM from later establishing a new session (or hijacking an 2017 existing session) and replaying previously observed message 2018 dialogs. 2020 If a non-compliant, active MITM is able to trick a clean endpoint 2021 to give up its posture information and the MITM has legitimate 2022 credentials, it might be able to appear to an NEA Server as having 2023 compliant posture when it does not. For example, a non-compliant 2024 MITM could connect and authenticate to an NEA Server and as the NEA 2025 Server requests posture information, the MITM could request the 2026 same posture from the clean endpoint. If the clean endpoint trusts 2027 the MITM to perform a reassessment and is willing to share the 2028 requested posture, the MITM could obtain the needed posture from 2029 the clean endpoint and send it to the NEA Server. In order to 2030 address this form of MITM attack, the NEA protocols would need to 2031 offer a strong (cryptographic) binding between the posture 2032 information and the authenticated session to the NEA Server so the 2033 NEA Server knows the posture originated from the endpoint that 2034 authenticated. Such a strong binding between the posture's origin 2035 and the authenticating endpoint may be feasible so should be 2036 preferred by the NEA WG. 2038 8.3.2 Message Modification 2040 Without message integrity protection, an attacker capable of 2041 intercepting a message might be capable of modifying its contents 2042 and causing an incorrect decision to be made. For example, the 2043 attacker might change the Posture Attributes to always reflect 2044 incorrect values and thus prevent a compliant system from joining 2045 the network. Unless the NEA Server could detect this change, the 2046 attacker could prevent admission to large numbers of clean systems. 2047 Conversely, the attacker could allow a malware infested machine to 2048 be admitted by changing the sent Posture Attributes to reflect 2049 compliant values, thus hiding the malware from the Posture 2050 Validator. The attacker could also infect compliant endpoints by 2051 sending malicious remediation instructions that when performed 2052 would introduce malware on the endpoint or deactivate security 2053 mechanisms. 2055 In order to protect against such attacks, the PT includes a 2056 requirement for strong integrity protection (e.g. including a 2057 protected hash like an HMAC [HMAC] of the message) so any change to 2058 a message would be detected. PA includes a similar requirement to 2059 enable end to end integrity protection of the attributes, extending 2060 the protection all the way to the Posture Validator even if it is 2061 located on another system behind the NEA Server. 2063 It is important that integrity protection schemes leverage fresh 2064 secret information (not known by the attacker) that is bound to the 2065 authenticated session such as an HMAC using a derived fresh secret 2066 associated with the session. Inclusion of freshness information 2067 allows the parties to protect against some forms of message replay 2068 attacks using secret information from prior sessions. 2070 8.3.3 Message Replay or Attribute Theft 2072 An attacker might listen to the network, recording message dialogs 2073 or attributes from a compliant endpoint for later reuse to the same 2074 NEA Server or just to build an inventory of software running on 2075 other systems watching for known vulnerabilities. The NEA Server 2076 needs to be capable of detecting the replay of posture and/or the 2077 model must assure that the eavesdropper can not obtain the 2078 information in the first place. For this reason, the PT protocol 2079 is required to provide confidentiality and replay prevention. 2081 The cryptographic protection from disclosure of the PT, PB or PA 2082 messages prevents the passive listener from observing the exchanged 2083 messages and thus prevents theft of the information for future use. 2084 However an active attacker might be able to replay the encrypted 2085 message if there is no strong link to the originating party or 2086 session. By linking the encrypted message dialog to the 2087 authentication event and leveraging per-transaction freshness and 2088 keying exchanges, this prevents a replay of the encrypted 2089 transaction. 2091 8.3.4 Other Types of Attack 2093 This section doesn't claim to present an exhaustive list of attacks 2094 against the NEA reference model. Several types of attack will 2095 become easier to understand and analyze once the NEA WG has created 2096 specifications describing the specific selected technologies and 2097 protocols to be used within NEA. One such area is Denial of 2098 Service (DoS). At this point in time it is not practical to try to 2099 define all of the potential exposures present within the NEA 2100 protocols, so such an analysis should be included in the Security 2101 Considerations sections of the selected NEA protocols. 2103 However, it is important that the NEA Server be resilient to DoS 2104 attacks as an outage might affect large numbers of endpoints 2105 wishing to join or remain on the network. The NEA reference model 2106 expects that the PT protocol would have some amount of DoS 2107 resilience and that the PA and PB protocols would need to build 2108 upon that base with their own protections. To help narrow the 2109 window of attack by unauthenticated parties, it is envisioned that 2110 NEA Servers would employ PT protocols that enable an early mutual 2111 authentication of the requesting endpoint as one technique for 2112 filtering out attacks. 2114 Attacks occurring after the authentication would at least come from 2115 sources possessing valid credentials and could potentially be held 2116 accountable. Similarly, NEA protocols should offer strong replay 2117 protection to prevent DoS based attacks based on replayed sessions 2118 and messages. Posture assessment should be strongly linked with 2119 the Posture Transport authentications that occurred to assure the 2120 posture came from the authenticated party. Cryptographic 2121 mechanisms and other potentially resource intensive operations 2122 should be used sparingly until the validity of the request can be 2123 established. This and other resource/protocol based attacks can be 2124 evaluated once the NEA technologies and their cryptographic use 2125 have been selected. 2127 9. Privacy Considerations 2128 While there are a number of beneficial uses of the NEA 2129 technology for organizations that own and operate networks 2130 offering services to similarly owned endpoints, these same 2131 technologies might enhance the potential for abuse and invasion 2132 of personal privacy if misused. This section will discuss a few 2133 of the potential privacy concerns raised by the deployment of 2134 this technology and offer some guidance to implementers. 2136 The NEA technology enables greater visibility into the 2137 configuration of an endpoint from the network. Such 2138 transparency enables the network to take into consideration the 2139 strength of the endpoint's security mechanisms when making 2140 access control decisions to network resources. However this 2141 transparency could also be used to enforce restrictive policies 2142 to the detriment of the user by limiting their choice of 2143 software or prying into past or present uses of the endpoint. 2145 The scope of the NEA WG was limited to specifying protocols 2146 targeting the use cases where the endpoints and network are 2147 owned by the same party or the endpoint owner has established a 2148 clear expectation of disclosure/compliance with the network 2149 owner. This is a familiar model for governments, institutions 2150 and a wide variety of enterprises that provide endpoints to 2151 their employees to perform their jobs. In many of these 2152 situations, the endpoint is purchased and owned by the 2153 enterprise and they often reserve the right to audit and 2154 possibly dictate the allowable uses of the device. The NEA 2155 technologies allow them to automate the inspection of the 2156 contents of an endpoint and this information may be linked to 2157 the access control mechanisms on the network to limit endpoint 2158 use should the endpoint not meet minimal compliance levels. 2160 In these environments, the level of personal privacy the 2161 employee enjoys may be significantly reduced subject to local 2162 laws and customs. However, in situations where the endpoint is 2163 owned by the user or where local laws protect the rights of the 2164 user even when using endpoints owned by another party, it is 2165 critical that the NEA implementation enable the user to control 2166 what endpoint information is shared with the network. Such 2167 controls imposed by the user might prevent or limit their 2168 ability to access certain networks or protected resources, but 2169 this must be a user choice. 2171 9.1 Implementer Considerations 2173 The NEA WG is not defining NEA Client policy content standards 2174 nor defining requirements on aspects of an implementation 2175 outside of the network protocols, however the following guidance 2176 is provided to encourage privacy friendly implementations for 2177 broader use than just the enterprise oriented setting described 2178 above. 2180 NEA Client implementations are encouraged to offer an opt-in 2181 policy to users prior to sharing their endpoint's posture 2182 information. The opt-in mechanism should be on a per-user, per- 2183 NEA Server basis so each user can control which networks can 2184 access any posture information on their system. For those 2185 networks that are allowed to assess the endpoint, the user 2186 should be able to specify granular restrictions on what 2187 particular types and specific attributes Posture Collectors are 2188 allowed to disclose. Posture Validator implementations are 2189 discouraged from having the default behavior of using wild 2190 carded requests for posture potentially leading to overexposure 2191 of information (see section 9.2). Instead Posture Validators by 2192 default should only request the specific attributes that are 2193 required to perform their assessment. 2195 Requests for attributes that are not explicitly allowed (or 2196 specifically disallowed) to be shared should result in a user 2197 notification and/or log record so the user can assess whether 2198 the service is doing something undesirable or whether the user 2199 is willing to share this additional information in order to gain 2200 access. Some products might consider policy-driven support for 2201 prompting the user for authorization with a specific description 2202 of the posture information being requested prior to sending it 2203 to the NEA Server. 2205 It is envisioned that the owner of the endpoint is able to 2206 specify disclosure policies that may override or influence the 2207 user's policies on the attributes visible to the network. If 2208 the owner disclosure policy allows for broader posture 2209 availability than the user policy, the implementation should 2210 provide a feedback mechanism to the user so they understand the 2211 situation and can choose whether to use the endpoint in those 2212 circumstances. 2214 In such a system, it is important that the user's policy 2215 authoring interface is easy to understand and clearly 2216 articulates the current disclosure policy of the system 2217 including any influences from the owner policy. Users should be 2218 able to understand what posture is available to the network and 2219 the general impact of this information being known. In order to 2220 minimize the list of restrictions enumerated, use of a 2221 conservative default disclosure policy such as 'that which is 2222 not explicitly authorized for disclosure is not allowed' might 2223 make sense to avoid unintentional leakage of information. 2225 NEA Server implementations should provide newly subscribing 2226 endpoints with a disclosure statement that clearly states: 2228 o What information is required 2229 o How this information will be used and protected 2230 o What local privacy policies are applicable 2232 This information will empower subscribing users to decide 2233 whether the disclosure of this information is acceptable 2234 considering local laws and customs. 2236 9.2 Minimizing Attribute Disclosure 2238 One important issue in the design of the NEA reference model and 2239 protocols is enabling endpoints to disclose minimal information 2240 required to establish compliance with network policies. There 2241 are several models that could be considered as to how the 2242 disclosed attribute set is established. Each model has privacy 2243 related benefits and issues that should be considered by product 2244 developers. This section summarizes three potential models for 2245 how attribute disclosure might be provided within NEA products 2246 and some privacy implications potentially associated with each 2247 model. 2249 The first model is easy to implement and deploy but has privacy 2250 and potentially latency and scalability implications. This 2251 approach effectively defaults the local policy to send all known 2252 NEA Posture Attributes when an assessment occurs. While this 2253 might simplify deployment, it exposes a lot of information that 2254 is potentially not relevant to the security assessment of the 2255 system and may introduce privacy issues. For example, is it 2256 really important that the enterprise know whether Firefox is 2257 being used on a system instead of other browsers during the 2258 security posture assessment? 2260 The second model involves an out-of-band provisioning of the 2261 disclosure policy to all endpoints. This model may involve the 2262 enterprise establishing policy that a particular list of 2263 attributes must be provided when a NEA exchange occurs. 2264 Endpoint privacy policy may filter this attribute list, but such 2265 changes could cause the endpoint not to be given network or 2266 resource access. This model simplifies the network exchange as 2267 the endpoint always sends the filtered list of attributes when 2268 challenged by a particular network. However this approach 2269 requires an out-of-band management protocol to establish and 2270 manage the NEA disclosure policies of all systems. 2272 The third model avoids the need for pre-provisioning of 2273 disclosure policy by allowing the NEA Server to specifically 2274 request what attributes are required. This is somewhat 2275 analogous to the policy being provisioned during the NEA 2276 exchanges so is much easier to manage. This model allows for 2277 the NEA Server to iteratively ask for attributes based on the 2278 values of prior attributes. Note, even in this model the NEA 2279 protocols are not expected to be a general purpose query 2280 language, but rather allow the NEA Server to request specific 2281 attributes as only the defined attributes are possible to 2282 request. For example, an enterprise might ask about the OS 2283 version in the initial message dialog and after learning the 2284 system is running Linux ask for a different set of attributes 2285 specific to Linux than it would if the endpoint was a Windows 2286 system. It is envisioned that this approach might minimize the 2287 set of attributes sent over the network if the assessment is of 2288 a complex system (such as trying to understand what patches are 2289 missing from an OS). 2291 In each model, the user could create a set of per-network 2292 privacy filter policies enforced by the NEA Client to prevent 2293 the disclosure of attributes felt to be personal in nature or 2294 not relevant to a particular network. Such filters would 2295 protect the privacy of the user but might result in the user not 2296 being allowed access to the desired asset (or network) or being 2297 provided limited access. 2299 10. IANA Considerations 2301 This document contains no required actions from the IANA. 2303 11. References 2305 11.1 Normative References 2307 [UTF8] F. Yergeau, "UTF-8, a transformation format of 2308 ISO 10646", RFC 3629, IETF, November 2003. 2310 11.2 Informative References 2312 [802.1X] IEEE Standards for Local and Metropolitan Area 2313 Networks: Port based Network Access Control, 2314 IEEE Std 802.1X-2001, June 2001. 2316 [CNAC] Cisco, Cisco's Network Admission Control Main 2317 Web Site, http://www.cisco.com/go/nac 2319 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson 2320 J., and H. Levkowetz, "Extensible Authentication 2321 Protocol (EAP)", RFC 3748, June 2004. 2323 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, 2324 "HMAC: Keyed-Hashing for Message 2325 Authentication", RFC 2104, February 1997. 2327 [IPSEC] Kent, S., Seo K., "Security Architecture for the 2328 Internet Protocol", RFC 4301, December 2005. 2330 [NAP] Microsoft, Network Access Protection Main Web 2331 Site, http://www.microsoft.com/nap 2333 [RADIUS] Rigney, C., Willens, S., Rubens, A., and 2334 Simpson, W., "Remote Authentication Dial In User 2335 Service (RADIUS)", RFC 2865, June 2000. 2337 [TLS] Dierks, T., Rescorla, E., "The Transport Layer 2338 Security (TLS) Protocol Version 1.1", RFC 4346, 2339 April 2006. 2341 [TCG] Trusted Computing Group, Main TCG Web Site, 2342 http://www.trustedcomputinggroup.org/ 2344 [TNC] Trusted Computing Group, Trusted Network Connect 2345 Main Web Site, 2346 https://www.trustedcomputinggroup.org/groups/net 2347 work/ 2349 Acknowledgments 2351 The authors of this draft would like to acknowledge the NEA working 2352 group members who have contributed to previous requirements and 2353 problem statement drafts that influenced the direction of this 2354 specification: Kevin Amorin, Parvez Anandam, Diana Arroyo, Uri 2355 Blumenthal, Alan DeKok, Lauren Giroux, Steve Hanna, Thomas 2356 Hardjono, Tim Polk, Ravi Sahita, Joe Salowey, Chris Salter, 2357 Mauricio Sanchez, Yaron Sheffer, Jeff Six, Susan Thompson, Gary 2358 Tomlinson, John Vollbrecht, Nancy Winget, Han Yin, Hao Zhou. 2360 Authors' Addresses 2362 Hormuzd Khosravi 2363 Intel 2364 2111 NE 25th Avenue 2365 Hillsboro, OR 97124 USA 2366 Phone: +1 503 264 0334 2367 Email: hormuzd.m.khosravi@intel.com 2369 Mahalingam Mani 2370 Avaya Inc. 2371 1033 McCarthy Blvd. 2372 Milpitas, CA 95035 USA 2373 Phone: +1 408 321-4840 2374 Email: mmani@avaya.com 2376 Kaushik Narayan 2377 Cisco Systems Inc. 2378 10 West Tasman Drive 2379 San Jose, CA 95134 2380 Phone: +1 408 526-8168 2381 Email: kaushik@cisco.com 2383 Paul Sangster 2384 Symantec Corporation 2385 6825 Citrine Dr 2386 Carlsbad, CA 92009 USA 2387 Phone: +1 760 438-5656 2388 Email: Paul_Sangster@symantec.com 2389 Joseph Tardo 2390 Nevis Networks 2391 295 N. Bernardo Ave., Suite 100 2392 Mountain View, CA 94043 USA 2393 Email: joseph.tardo@nevisnetworks.com 2395 Full Copyright Statement 2397 Copyright (C) The IETF Trust (2008). 2399 This document is subject to the rights, licenses and restrictions 2400 contained in BCP 78, and except as set forth therein, the authors 2401 retain all their rights. 2403 This document and the information contained herein are provided 2404 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2405 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2406 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2407 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2408 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2409 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2410 FITNESS FOR A PARTICULAR PURPOSE. 2412 Intellectual Property 2414 The IETF takes no position regarding the validity or scope of any 2415 Intellectual Property Rights or other rights that might be claimed 2416 to pertain to the implementation or use of the technology described 2417 in this document or the extent to which any license under such 2418 rights might or might not be available; nor does it represent that 2419 it has made any independent effort to identify any such rights. 2420 Information on the procedures with respect to rights in RFC 2421 documents can be found in BCP 78 and BCP 79. 2423 Copies of IPR disclosures made to the IETF Secretariat and any 2424 assurances of licenses to be made available, or the result of an 2425 attempt made to obtain a general license or permission for the use 2426 of such proprietary rights by implementers or users of this 2427 specification can be obtained from the IETF on-line IPR repository 2428 at http://www.ietf.org/ipr. 2430 The IETF invites any interested party to bring to its attention any 2431 copyrights, patents or patent applications, or other proprietary 2432 rights that may cover technology that may be required to implement 2433 this standard. Please address the information to the IETF at ietf- 2434 ipr@ietf.org.