idnits 2.17.1 draft-khosravi-nea-requirements-01.txt: -(202): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(423): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(790): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 914. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 16 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 108 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([8], [9], [10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 384 has weird spacing: '...uctions from ...' -- 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 (July 2006) is 6495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC-2119' on line 42 looks like a reference -- Missing reference section? '9' on line 60 looks like a reference -- Missing reference section? '10' on line 60 looks like a reference -- Missing reference section? '8' on line 60 looks like a reference -- Missing reference section? '3' on line 213 looks like a reference -- Missing reference section? 'REF' on line 742 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Hormuzd Khosravi, Intel 2 Expires: January 2007 Paul Sangster, Symantec 4 Working Group: NEA July 2006 6 Requirements for Network Endpoint Assessment (NEA) 7 draft-khosravi-nea-requirements-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as ``work in 25 progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 41 this document are to be interpreted as described in [RFC-2119]. 43 Abstract 45 This document defines the interface (protocol) requirements between 46 the components of the NEA (Network Endpoint Assessment) conceptual 47 architecture. NEA provides owners of networks (e.g. an enterprise 48 offering remote access) a mechanism to learn the operational state 49 or posture of a system requesting network access and then apply this 50 knowledge to the network admission decision. In this case, 51 operational posture refers to information about the configuration 52 and use of hardware and software capabilities available or running 53 on the system. This information is frequently useful for detecting 54 systems that are lacking (or have out of date) security protective 55 mechanisms (e.g. anti-virus, firewall.) 57 In order to provide context for the requirements, a conceptual 58 architecture and terminology is introduced. This architecture is 59 provided for informational purposes but is based on the models used 60 by NAC[9], NAP[10] and TNC[8]. 62 Authors 64 The participants in the NEA Requirements Team who were instrumental 65 in the creation of this requirements draft are: 67 Kevin_Amorin, Diana Arroyo, Uri Blumenthal, Steve Hanna, Thomas 68 Hardjono, Hormuzd Khosravi, Ravi Sahita, Mauricio Sanchez, Paul 69 Sangster, Jeff Six, Joseph Tardo, Susan Thompson, John Vollbrecht, 70 Hao Zhou 72 1. Introduction....................................................2 73 2. Definitions.....................................................3 74 3. Architecture and Components.....................................4 75 4. Common Requirements Across Architecture.........................5 76 5. Protocol Requirements...........................................6 77 5.1 78 . 79 Pos 80 ture 81 At 82 t 83 r 84 ibute 85 (PA) 86 Protocol 87 Requirements.....................6 88 5.2 89 . 90 Pos 91 ture 92 Broker 93 (PB) 94 Protocol Requirements........................7 95 5.3 96 .Posture 97 Transpor 98 t 99 (PT) 100 Protocol 101 Requirements.....................8 102 5.3 103 .1 104 . 105 EAP Usage Within 106 PT............................................9 107 6. Security Analysis/Requirements.................................10 108 7. Operational Considerations.....................................12 109 8. Security Considerations........................................13 110 8.1 111 . 112 Scope 113 and Over 114 lap...............................................13 115 8.2.Relevant 116 Classes 117 of 118 At 119 tack......................................14 120 8.2 121 .1 122 . 123 Man- 124 in-the-Middle 125 (MITM).....................................14 126 8.2 127 .2 128 . 129 Message Modification.........................................14 130 8.2.3 131 .Message Replay or 132 Theft......................................15 133 9. References.....................................................15 134 9.1 135 . Normat 136 ive 137 References...........................................15 138 9.2. Informat 139 ive 140 References.........................................16 141 Authors' Addresses & Acknowledgments..............................16 143 1. 144 Introduction 146 Today, most network providers can leverage existing standards-based 147 technologies to restrict access to the network based upon the 148 requesting system's user or host-based identity, source IP address 149 or physical access point. However these approaches still leave the 150 network prone to malware-based attack, when an authorized but 151 infected system is admitted and the malware is able to spread 152 throughout the internal network. 154 As a result, network operators need the ability to preemptively 155 detect systems that are prone or already contain malware potentially 156 dangerous to the network. If a system is determined to be prone to 157 attack by lacking proper defensive mechanisms such as the absence of 158 up to date firewall and anti-virus software, there should be a way 159 to safely repair (remediate) the system so that it can be 160 subsequently trusted to join and operate on the network. 162 The Network Endpoint Assessment (NEA) system is a complementary 163 technology to existing authentication and authorization approaches 164 allowing the network to have visibility into the contents of the 165 system (security posture) requesting access so that its risk profile 166 can be factored into the admission decision. NEA typically involves 167 the use of trusted agents running on the requesting machine which 168 observe and report on the posture of the system to network 169 infrastructure. The infrastructure has equivalent components which 170 are capable of evaluating the posture information and feeding the 171 result to an appropriate network admission decision maker. Finally 172 the admission decision is provisioned to the enforcement mechanisms 173 on the network and/or system requesting access. The decision might 174 allow for no access, limited access (possibly to allow for 175 remediation), or full access to the network. 177 Architectures, similar to NEA, have been defined in the industry 178 (e.g. TNC, NAP, NAC) to assess the software or hardware 179 configuration of endpoint devices for the purposes of monitoring or 180 enforcing compliance of endpoints to an organization's policy on 181 access to the network. These architectures are not interoperable 182 since most of the technologies used to implement the architecture 183 are not standards. 185 The NEA working group is working on defining standard protocols so 186 as to enable interoperability between devices from different vendors 187 allowing network owners to deploy truly heterogeneous solutions. 188 This document describes the requirements for NEA candidate 189 technologies and protocols. 191 2. 192 Definitions 194 Component � Software, hardware or firmware entity performing a 195 particular logical function within the NEA conceptual architecture. 197 For the purposes of assessment, a component may be a particular 198 vendor product (e.g. Symantec Anti-Virus), class of application 199 (e.g. Firewall), or be more general to represent groupings of 200 software services (e.g. Operating System kernel.) 202 Dialog � Sequence of request/response messages exchanged over one or 203 more sessions. 205 Message � Self contained unit of communication between components. 206 For example, a PA message might carry a set of attributes from a 207 Posture Collector to a Validator. 209 Session � Common PB transport connection capable of carrying one or 210 more messages from multiple subscribed Posture Collectors and 211 Validators. 213 Please refer to [3] for the NEA terminology. 215 3. 216 Architecture and Components 218 The major components of NEA architecture are shown in Figure 1. The 219 PV and NAE protocols are identified for completeness but are not the 220 focus of the initial phase of NEA work items. 222 |-------------| |----------------| 223 | Posture | <--------PA---------> | Posture | 224 | Collectors | | Validators | 225 | (1 ...N) | | (1 ...N) | 226 |-------------| |----------------| 227 | | 228 | PV 229 | | 230 |-------------| |----------------| 231 | Client | <--------PB---------> | Server | 232 | Broker | | Broker | 233 |--------- ---| |----------------| 234 | | 235 | | 236 |-------------| <--------PT---------> |----------------| 237 | | | | 238 | Network | |--------| | Network | 239 | Access |----|Network |------------| Access | 240 | Requestor | |Enforcer| <---NAE--> | Authority | 241 |-------------| |--------| |----------------| 243 NEA CLIENT NEA SERVER 245 Figure 1: NEA Components and Protocols 247 4. 248 Common Requirements Across Architecture 250 The following are the common requirements that apply to the PA, PB 251 and PT protocols in NEA conceptual architecture: 253 1. NEA protocols MUST be capable of performing a multiple message 254 dialog between the client (agent) and server. This enables the 255 server to request additional information or updates to the posture 256 data already reported. The updates allow for detection of recent 257 changes in the client state (e.g. possibly due to a remediation.) 259 2. NEA protocols MUST allow the NEA server to initiate requests for 260 posture information prior to network access and at any time after 261 the client has established an identity on the network (e.g. IP 262 address.) This enables the NEA server to evaluate posture prior to 263 allowing access and to periodically re-validate systems already 264 admitted to the network to assure they are still in compliance with 265 the current policies. 267 3. NEA protocols MUST provide a way for the NEA client to initiate a 268 posture re-evaluation request as needed. This allows the client to 269 proactively request a posture re-evaluation by the NEA Server after 270 detection of a potentially suspicious event. 272 4. NEA protocols MUST provide protection against active and passive 273 attacks by intermediaries (e.g. man-in-the-middle.) Such protection 274 might come from a strong (e.g. cryptographic) binding between the 275 authenticated identity of the requesting system and the reported 276 posture information. This protection MUST prevent replay based 277 attacks (preventing a malicious machine from later replaying a 278 healthy posture report.) 280 5. The PA and PB protocols defined by NEA MUST be agnostic of the 281 transport i.e. PT protocol. For example, the PB protocol must 282 provide a transport independent interface allowing the PA protocol 283 to operate without change across a variety of network protocol 284 environments (e.g. EAP/802.1X, PANA, and IKE/IPsec.) 286 6. The selection process for NEA protocols MUST evaluate and prefer 287 the reuse of existing open standards that meet the requirements 288 before defining new ones. The goal of NEA is not to create 289 additional alternative protocols where acceptable solutions already 290 exist. 292 7. NEA protocols MUST be highly scalable allowing for many Posture 293 Collectors on large deployments of NEA Clients to be assessed by 294 numerous Posture Validators residing on multiple NEA Servers. For 295 example, the protocols need to be capable of naming large numbers of 296 types of collectors, validators, and components. 298 5. 299 Protocol Requirements 301 5.1.Posture Attribute (PA) Protocol Requirements 303 The PA protocol defines the transport and data model to carry 304 posture and validation information between a particular Posture 305 Collector associated with a NEA client and a Posture Validator 306 associated with a NEA Server. The Posture Attribute protocol carries 307 collections of core attributes and vendor defined attributes. The PA 308 protocol will be carried inside the Posture Broker (PB) protocol. 309 The following requirements define the desired properties that form 310 the basis for the working group�s comparison and evaluation of 311 candidate PA protocols. The requirements do not require that 312 deployers use these properties merely that the candidate protocol be 313 capable of offering the property should it be needed. 315 1. The PA protocol MUST support transport of the required (core) 316 attributes defined in the data model to report information 317 determined by a Posture Collector. Examples of core attributes 318 include Vendor id, Application version, and Operational status. 320 2. The PA protocol MUST support the transport of vendor defined 321 attributes enabling communication of a richer, potentially vendor 322 specific set of attributes describing the requested component. 324 3. The PA protocol MUST enable the Posture Validator to request 325 posture information about particular components on the NEA Client 326 system. The posture information may be represented as one or more 327 attributes (core and/or vendor specific) that describe the 328 operational properties of the component. 330 4. The PA protocol MUST allow for the Posture Validator to request 331 posture information on more then one occasion using an existing or 332 if unavailable on a new session. This enables the Posture Validator 333 to re-assess the posture of a particular component (in case it has 334 changed) or to request information about additional components 335 (possibly due to something learned from an earlier request.) 337 5. The PA protocol MUST be capable of returning the Posture 338 Validator�s results and any necessary remediation instructions. 339 This allows the Posture Collector to learn the specific reason for a 340 failed assessment to aid in remediation and notification of the 341 system owner. 343 6. The selection process for the PA protocol MUST evaluate and 344 prefer the reuse of existing open standards that are applicable to 345 the transport and representation of an extensible set of attributes. 347 In particular, extensible structured data formats such as XML should 348 be considered. 350 7. The PA protocol SHOULD support expression of core attributes to 351 describe remediation state of components for example, last update 352 time, remediation server used. These attributes are used after 353 remediation so that a Posture Validator can synchronize with a 354 Posture Collector and continue remediation. 356 8. The PA protocol MUST support authentication, integrity and 357 confidentiality of attributes, results and remediation instructions 358 sent between a Posture Collector and Validator. This enables end to 359 end security across an NEA deployment that might involve the 360 traversal of several systems. Deployers of Posture Collectors and 361 Posture Validators should use at least authentication and integrity 362 protection for their messages, and may also employ confidentiality 363 protection if necessary for their environment. 365 9. The PA protocol SHOULD optimize transport of messages and 366 minimize Posture Broker protocol round trips. To achieve this, the 367 PA protocol should support configuration/negotiation of the maximum 368 size and timeout period for interaction of a Posture Collector with 369 a Posture Validator. 371 5.2.Posture Broker (PB) Protocol Requirements 373 The PB protocol supports multiplexing of Posture Attribute messages 374 (based on PA protocol) from multiple Posture Collectors associated 375 with a NEA Client and de-multiplexing these messages to multiple 376 Posture Validators associated with a NEA Server. The PB protocol 377 transports the global decision made by the Server Broker, taking 378 into account the results of the Posture Validators involved in the 379 assessment, to the Client Broker. 380 The PB protocol also transports the aggregated remediation 381 instructions from one or more Posture Validators. 383 1. The PB protocol MUST be capable of carrying the global decision 384 and, if appropriate, the global remediation instructions from the 385 Server Broker to the Client Broker. 387 2. The PB protocol MUST contain information used by the Brokers to 388 route (deliver) messages between particular types of Posture 389 Collectors and Posture Validators. Such message routing information 390 should enable dynamically (de)registered Posture Collectors and 391 Validators to receive appropriate messages. For example, a 392 dynamically registered Anti-Virus Posture Validator should be able 393 to subscribe to receive messages from its respective Anti-Virus 394 Posture Collector on NEA Clients. 396 3. The PB protocol MUST support a message dialog to occur between 397 one or more Posture Collectors and Posture Validators. This allows 398 each party to send multiple messages before the dialog is complete. 400 4. The PB protocol MUST support authentication, integrity and 401 confidentiality of the PA messages, broker global decision and 402 remediation instructions sent between an NEA Client and Server. 403 This provides security protection for the aggregated set of PA 404 messages exchanged and the result between the NEA Client and Server. 405 Such protection is orthogonal to PA protections (which are end to 406 end) and allow for simpler Posture Collector and Validators to be 407 implemented and consolidation of cryptographic operations possibly 408 improving scalability and manageability. 410 5. The PB protocol SHOULD support grouping of attributes to optimize 411 transport of messages and minimize round trips. 413 5.3.Posture Transport (PT) Protocol Requirements 415 The PT is the transport protocol between the Network Access 416 Requestor (NAR) in the NEA Client and the Network Access Authority 417 (NAA) within the NEA Server present on the network owner�s 418 infrastructure. PT is responsible for providing a protected 419 transport (frequently using a tunnel) for the PB protocol. The PT 420 protocol may in turn be transported by a lower layer protocol such 421 as: 802.1x, RADIUS, TLS, IKE/IPsec or TCP,UDP/IP. This section 422 defines the requirements which candidate PT protocols must be 423 capable of supporting. The deployer�s policy will dictate how these 424 apply to a particular environment. 426 1. The PT protocol SHOULD incur low overhead to accommodate for use 427 on low bandwidth links. 429 2. The PT protocol SHOULD be capable of supporting a half duplex 430 communication environment. 432 3. The PT protocol MUST NOT attempt to interpret the contents of the 433 PB messages being transported, i.e. the data it is carrying must be 434 opaque to it. 436 4. The PT protocol MUST be capable of protecting the integrity and 437 confidentiality of the PB messages being transported between the NAR 438 and NAA. 440 5. The PT protocol MUST provide reliable delivery of PB messages. 441 This includes the ability to perform fragmentation, detect 442 duplicates, and reorder data, if necessary. 444 6. The PT protocol MUST be capable of supporting mutual 445 authentication of the communicating parties. This MAY occur by 446 initially authenticating the NEA Server and leveraging byproducts 447 (e.g. keys) associated with this authentication to construct a 448 confidential channel where the NEA Client can authenticate. 450 7. The PT protocol MUST be able to establish a restricted session 451 between the NAR and the NAA prior to the NAR granting general 452 network access. 454 8. The PT protocol MUST allow the NAR or NAA to initiate the 455 establishment of a restricted session for use by NEA when both 456 parties have necessary network addresses established. 458 5.3.1. EAP Usage Within PT 460 When EAP is being used within PT, the PT protocol can be split into 461 two groups: Posture Transport Tunnel (PTT) and Posture Transport 462 Carrier (PTC). PTT is the EAP method used between the NAR and NAA 463 (e.g. EAP-FAST, PEAP, EAP-TTLS), and PTC is the transport protocol 464 carrying EAP. When Network Enforcer (NE) is a separate entity from 465 Network Access Authority, PTC is further broken into two protocols, 466 one between NAR and NE (named NRE) and one between NE and NAA (named 467 NAE). Examples of NRE are EAPOL, PPP, IPSec etc. Examples of NAE are 468 RADIUS, Diameter, etc. This section defines the requirements which 469 candidate PTT and PTC protocols must be capable of supporting, in 470 addition to those outlined in Section 4 Common Requirements Across 471 Architecture. The deployer's policy will dictate how these apply to 472 a particular environment. 474 PTT EAP Method Requirements: 476 1. The PTT EAP Method SHOULD be standardized from one or more 477 existing methods if possible or modifying existing methods if where 478 necessary to make them appropriate to be standardized. The use of 479 existing standard EAP method for PTT SHOULD be giving preference 480 over creating a new EAP method. 482 2. The PTT EAP Method MUST NOT attempt to interpret the contents of 483 the PB messages being transported, i.e. the data it is carrying must 484 be opaque to it. This is mapped to PT Requirement 3. 486 3. The PTT EAP Method MUST support integrity and confidentiality to 487 protect key material and data. This is mapped to PT Requirement 4. 489 4. The PTT EAP Method MUST support fragmentation of payloads larger 490 then the minimum EAP MTU, and reassembly. This is mapped to PT 491 Requirement 5. 493 5. The PTT EAP Method MUST have support for mutual authentication. 494 This is mapped to PT Requirement 6. 496 6. The PTT EAP Method MUST have support and have protection for PB 497 protocol in the form of "inner EAP methods" or TLV/AVP. It SHOULD 498 support transporting of arbitrarily large posture data or 499 fragmentation of the data. 501 7. The PTT EAP Method MUST be lower layer agnostic and have support 502 for multiple carrier protocols (RADIUS, Diameter, EAPOL, etc.). 504 8. The PTT EAP Method MUST be able to dynamically generate key 505 material. 507 9. The PTT EAP Method MUST support transport PB with or without 508 identity authentication, before or after identity authentication. 510 10. The PTT EAP Method MUST support multiple message dialogs of PB 511 protocol. 513 11. The PTT EAP Method SHOULD use open (publicly available and 514 proven) algorithms in its encryption and key creation. 516 12. The PTT EAP Method SHOULD be able to perform key negotiation, 517 and cipher suite negotiation. 519 PTC Requirements 521 PTC MUST meet the following requirements, in addition to the 522 requirements described in RFC 3748 Section 3 Lower Layer Behavior. 524 1. The PTC protocol MUST be able to establish an assessment session 525 between the NAR and the NAA prior to the NAR being granted general 526 network access. This is mapped to PT Requirement 7. 528 2. The PTC protocol MUST allow the NAR or NAA to trigger 529 reassessment when there are changes in client posture and/or server 530 policy after network access is granted. This is mapped to PT 531 Requirement 8. 533 6. 534 Security Analysis/Requirements 536 There are several entities that comprise the described NEA 537 conceptual architecture. From security viewpoint, their relations 538 and communications should adhere to the following requirements. 540 End-points must be able to authenticate their peers (i.e. Posture 541 Collector and Posture Validator), for without that no meaningful 542 posture information exchange is possible. 544 1. PA Protocol 545 - Posture Validator MUST be able to ascertain that the traffic 546 (posture) it received is "fresh". This freshness prevents a third 547 party from replaying the posture information produced by an earlier 548 Posture Collector use without detection. 549 - It may be necessary (especially in case of multiple exchanges 550 between Posture Collector and Posture Validator) that Posture 551 Collector "recognizes" and trusts the given Posture Validator. This 552 ensures that Posture Collector is doing work on behalf of authentic 553 Posture Validator. 555 2. PB Protocol 556 - Communications between Client Broker and Server Broker MAY 557 need to be protected at least from active attacker (integrity, 558 confidentiality, timeliness). Integrity and timeliness are of the 559 utmost importance, to prevent third parties (any parties - including 560 Network Enforcer) from interfering with posture validation and 561 affecting PDP decisions. Confidentiality may be useful here, for 562 example to prevent attackers from determining which host would be 563 the most vulnerable target based on its posture information. 564 However there is privacy concern that the host should be able to 565 "see" what potentially privacy sensitive information about it is 566 being sent out. This concern may prevent encryption from being used 567 or force a pre-screening of the posture information against a 568 privacy policy before allowing it to be sent over the network. 570 3. PT Protocol 571 - This communication channel MUST be protected: endpoint mutual 572 authentication with subsequent secure pipe establishment. Otherwise 573 third parties could launch a variety of attacks. 575 4. Communications between Posture Collector(s) and Client Broker MAY 576 need protection, especially if those are different software 577 entities. It is important that a Client Broker be allowed to 578 communicate with only the authorized Posture Collectors because of 579 the trust issue. Denial of Service is the most obvious threat here. 580 Forging a posture should not be feasible because of PA protocol. 582 5. Communication between Client Broker and Network Access Requestor 583 MAY need protection. 585 6. Communication between Server Broker and Network Access Authority 586 MAY be protected. 588 7. 589 Operational Considerations 591 The NEA technology intends to address a major issue for owners of 592 networks by extending their existing ability to limit admission to 593 the network by inspection of the security posture of the system. In 594 order to offer a solution to this issue, NEA needs to provide a 595 scalable solution addressing a vast majority of the systems deployed 596 while remaining manageable. This introduces several issues which 597 should be considered during the definition of the protocols, 598 interfaces, architecture and their policies. 600 1. Some network devices (e.g. printers, legacy systems) will not 601 have support for NEA agents present. In this situation, the NEA 602 server must be able to detect that the system requesting access is 603 incapable of responding to NEA protocols and thus will not be able 604 to report its security posture. The NEA architecture should allow 605 for this event to be detected and reported to other components which 606 might be able to evaluate risk via other mechanisms (e.g. using 607 scanning techniques) and report back a suggested action. 609 2. Admission policy should be capable of being combined with 610 authentication policy so differentiated posture evaluation is 611 possible based on the identity and other factors about the 612 requesting system. For example, in many cases customers may wish to 613 allow certain individuals (e.g. executives) to always be allowed 614 access to the network even if NEA detects a problem. Similarly, 615 different posture checking profiles might be applied depending on 616 the requesting system or user�s identity. 618 3. Due to the potentially large number of systems offering and/or 619 evaluating posture information and the quantity of enforcement 620 devices, this presents a distributed policy issue for NEA deployers. 621 The NEA components should be manageable using data model definitions 622 associated within existing management protocol environments (e.g. 623 SNMP, CIM.) 625 4. Because the NEA infrastructure is involved in making decisions 626 about every system�s request to join and remain on the network, NEA 627 deployments should have mechanisms that protect it from direct 628 attack or operational situations where it might be unavailable. 629 Highly available, distributed deployment architectures should help 630 minimize downtown and avoid single point of failure scenarios. 631 However NEA solutions may need to offer deployers some policy-driven 632 flexibility in how the NEA components respond when faced with an 633 unavailable NEA Server component. 635 8. 636 Security Considerations 638 This document defines the requirements for the interfaces 639 (protocols) for a security mechanism assessment and enforcement 640 scheme. As such, it does not define a specific solution or set of 641 technologies, so this section will highlight security issues that 642 may apply to NEA in general or to particular aspects of the eventual 643 technical architecture. 645 8.1. Scope and Overlap 647 Inherent in the requirements is a desire for NEA candidate protocols 648 throughout the architecture to accommodate the use of strong 649 security mechanisms as dictated by the deployer. In some cases, 650 these mechanisms may appear to provide overlapping protections. The 651 overlaps may be desired by deployer to offer a defense in depth 652 approach; however because of the layering of the protocols each 653 mechanism offers slightly different protection benefits and levels 654 of granularity. 656 For example, a deployer may wish to encrypt traffic at the PT layer 657 to protect against some forms of traffic analysis or interception by 658 an eavesdropper. Additionally, the deployer may also selectively 659 encrypt a Posture Collector's set of reported attributes at the PA 660 layer to allow the peer Posture Verifier to achieve end to end 661 confidentiality. In particular, this might be desired when the NEA 662 Server side decision point spans several systems so the NAA is on a 663 different system from the Verifier. 665 In general, the NEA architecture's protocols are intending to 666 provide to the Posture Collector the ability to safely send its 667 measurement attributes across an untrustworthy network to a peer 668 Posture Validator and receive protected requests/responses. The 669 architecture is not intending to provide local integrity protection 670 for the proper operation of the Posture Collector itself. For 671 example, NEA technologies do not claim to prevent a carefully 672 crafted piece of malware (e.g. rootkit) from tricking the Posture 673 Collector into inaccurately reporting the state of the system so it 674 can remain undetected. Such integrity protection of the Collector 675 and other aspects of the system might be offered by orthogonal 676 security mechanisms leveraging security hardware and/or protected 677 trusted software. 679 Different use cases and environments for the NEA technologies will 680 likely influence the selection of the strength and security 681 mechanisms employed during an assessment. The goal of the NEA 682 requirements is to encourage the selection of technologies and 683 protocols that are capable of enforcing the necessary protections 684 for a wide variety of assessment use cases. 686 8.2. Relevant Classes of Attack 688 A variety of attacks are possible against current assessment 689 technologies. This section does not include a full threat analysis, 690 but wishes to highlight a few attacks which influenced the 691 requirement definition and should be considered by deployers 692 selecting use of protective mechanisms within the conceptual 693 architecture. 695 The following types of attacks are possible against each of the 696 network protocols defined in the conceptual architecture and thus 697 should be considered by deployers. 699 8.2.1. Man-in-the-Middle (MITM) 701 MITM attacks against a network protocol exist when a 3rd party can 702 sit between two legitimate communicating parties without detection. 703 For example, a malware infested machine might wish to join the 704 network using measurements collected by a clean system by inserting 705 itself into and proxying an assessment message exchange. The impact 706 of the damage caused by the MITM can be limited or prevented by 707 selection of appropriate protective mechanisms. 709 The requirement for PT to be capable of supporting bi-directional 710 authentication prevents the attacker from inserting themselves as an 711 active participant (proxy) within the communications without 712 detection (assuming attacker lacks credentials convincing either 713 party it is legitimate.) Re-usable credentials should not be exposed 714 on the network to assure the MITM doesn't have a way to impersonate 715 either party. 717 However the MITM might still act as a message relay between the 718 parties and change, eavesdrop, or steal and replay the 719 communications. These forms of attack require additional 720 protections discussed below. 722 8.2.2. Message Modification 724 Without message protection, an attacker capable of interception of 725 an assessment message would be capable of modifying the contents and 726 causing an incorrect action to occur. For example, the attacker 727 might change the measurement attributes to always reflect incorrect 728 values and thus prevent a system from joining the network. Unless 729 the NEA Server could detect this change, the attacker could prevent 730 network admission to large numbers of clean systems. Conversely, the 731 attacker could allow malware infested machine to be admitted by 732 changing the attributes. 734 In order to protect against such attacks, the PT includes a 735 requirement for strong integrity protection (e.g. including a 736 protected hash of the message) so this change will be detected. PA 737 includes a similar requirement to enable end to end integrity 738 protection of the message. 740 It is important that integrity protection schemes leverage secret 741 information (not known by the attacker) that are bound to the 742 transaction such as an encrypted message hash or HMAC [REF] linked 743 to the authentication. Message hash keys from prior transactions 744 possibly involving other systems must not be re-usable without 745 detection. 747 8.2.3. Message Replay or Theft 749 A passive attacker might listen to the network recording messages 750 from a healthy client for later re-use to the same NEA Server or 751 just to build an inventory of software running on other systems. 752 The NEA Server needs to be capable of detecting the replay or the 753 architecture must assure that the eavesdropper can not obtain the 754 attribute values in the first place. 756 The protection of the PT, PB or PA messages using encryption 757 prevents the passive listener from learning the exchanged attribute 758 values for theft or replay. By linking the encrypted transaction to 759 the authentication event and leveraging a per-transaction freshness 760 exchange, this prevents a replay of the encrypted transaction. 762 As discussed, there are a variety of protective mechanisms included 763 in the requirements for candidate NEA protocols. Different use cases 764 and environments may cause deployers to decide not to use some of 765 these mechanisms; however this should be done with an understanding 766 that the architecture may become vulnerable to some classes of 767 attack. As always a balance of risk vs. performance, usability, 768 manageability and other factors should be taken into account. 770 9. 771 References 772 9.1.Normative References 774 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 775 October 1996. 777 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 778 Levels", RFC2119 (BCP), IETF, March 1997. 780 3. S. Hanna, et. al., "Network Endpoint Assessment (NEA) Problem 781 Statement", draft-thomson-nea-problem-statement-01.txt, March 2006. 783 4. Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 784 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 785 June 2004. 787 5. Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 788 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 790 6. T. Dierks, E. Rescorla, �The Transport Layer Security (TLS) 791 Protocol Version 1.1�, RFC 4346, April 2006. 793 7. S. Kent, R. Atkinson, �Security Architecture for the Internet 794 Protocol�, RFC 2401, November 1998. (IPSec) 796 9.2.Informative References 798 8. �TCG Trusted Network Connect (TNC) Architecture for 799 Interoperability�, 800 https://www.trustedcomputinggroup.org/specs/TNC/TNC_Architecture_v1 801 _1_r2.pdf, May 2006. 803 9. Cisco Network Admission Control (NAC), http://www.cisco.com/go/nac 805 10. Microsoft Network Access Protection (NAP), 806 http://www.microsoft.com/technet/itsolutions/network/nap/default.ms 807 px 809 11. IEEE, "Local and Metropolitan Area Networks: Port-based Network 810 Access Control", 2004. (802.1x) 812 12. Forsberg, D., "Protocol for Carrying Authentication for Network 813 Access (PANA)", draft-ietf-pana-pana-11 (work in progress), March 814 2006. 816 Authors' Addresses & Acknowledgments 818 Hormuzd Khosravi (co-editor) 819 Intel 820 2111 NE 25th Avenue 821 Hillsboro, OR 97124 USA 822 Phone: +1 503 264 0334 823 Email: hormuzd.m.khosravi@intel.com 825 Paul Sangster (co-editor) 826 Symantec Corporation 827 6825 Citrine Dr 828 Carlsbad, CA 92009 USA 829 Email: paul_sangster@symantec.com 831 Kevin Amorin 832 Harvard University 833 79 JFK St. 834 Cambridge, MA 02138 835 Phone: +1 617-384-6699 836 Email: Kevin_Amorin@Harvard.edu 838 Diana Arroyo 839 IBM 840 11501 Burnet Road 841 Austin, Tx 78758 842 Phone: +1 512-838-0088 843 Email: darroyo@us.ibm.com 845 Uri Blumenthal 846 Intel Corporation 847 1515 Route 10, 848 Parsippany, NJ 07054 849 Phone: +1 973-967-6446 850 Email: uri.blumenthal@intel.com 852 Steve Hanna 853 Juniper Networks, Inc. 854 35 Forest Ridge Road 855 Concord, MA 01742 856 Phone: +1 978-371-3980 857 Email: shanna@juniper.net 859 Thomas Hardjono 860 SignaCert, Inc. 861 707 SW Washington St./Suite 700, 862 Portland, OR 97205 863 Phone: +1 503-227-2207 864 Email: thardjono@signacert.com 866 Ravi Sahita 867 Intel Corporation 868 2111 NE 25th Ave 869 Hillsboro OR 97124 870 Email: Ravi.sahita@intel.com 871 Mauricio Sanchez 872 Email: mauricio.sanchez@hp.com 874 Jeff Six 875 Email: jeffsix@thematrix.ncsc.mil 877 Joseph Tardo 878 Nevis Networks 879 500 N. Bernardo Ave. 880 Mountain View, CA 94043 881 Email: joseph.tardo@nevisnetworks.com 883 Susan Thomson 884 Cisco Systems 885 499 Thornall Street, 8th floor 886 Edison, NJ 08837 887 U.S.A 888 Email: sethomso@cisco.com 890 John Vollbrecht 891 9682 Alice Hill Drive 892 Dexter, Mi. 48130 893 Email: jrv@merit.edu 895 Hao Zhou 896 Cisco Systems 897 4125 Highlander Parkway 898 Richfield, OH 44286 899 U.S.A. 900 Email: hzhou@cisco.com 902 Copyright Statement 904 Copyright (C) The Internet Society (2006). This document is subject 905 to the rights, licenses and restrictions contained in BCP 78, and 906 except as set forth therein, the authors retain all their rights. 908 This document and the information contained herein are provided on 909 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 910 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 911 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 912 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 913 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 914 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.