NEA Working Group P. Sangster Internet Draft Symantec Expires: Sept 2007 H. Khosravi Intel M. Mani Avaya K. Narayan Cisco Systems J. Tardo Nevis Networks March 2007 Requirements for Network Endpoint Assessment (NEA) draft-ietf-nea-requirements-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Sangster, et. al. Expires Sept 2007 [Page 1] Internet Draft NEA Requirements Mar 2007 This document defines the problem statement, scope and interface (protocol) requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g. an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance oriented decisions. The posture information is frequently useful for detecting systems that are lacking (or have out of date) security protective mechanisms (e.g. anti-virus, firewall). In order to provide context for the requirements, a reference model and terminology are introduced. This model is provided for informational purposes but is based on the models used by NAC [CNAC], NAP[NAP] and TNC[TNC]. Table of Contents 1. Introduction....................................................3 1.1 Conventions Used in This Document............................4 2. Terminology.....................................................5 3. Applicability...................................................7 3.1 Scope........................................................7 3.2 Applicability of Environments................................8 4. Problem Statement...............................................9 5. Reference Model................................................10 5.1 Components..................................................11 5.1.1 NEA Client.............................................11 5.1.2 NEA Server.............................................14 5.2 Protocols...................................................17 5.2.1 Posture Attribute Protocol (PA)........................17 5.2.2 Posture Broker Protocol (PB)...........................18 5.2.3 Posture Transport Protocol (PT)........................18 5.3 Attributes..................................................18 5.3.1 Attributes Normally Sent by NEA Client:................19 5.3.2 Attributes Normally Sent by NEA Server:................19 6. Use Cases......................................................20 6.1 Initial Assessment..........................................21 6.1.1 Triggered by Network Connection Request................21 6.1.2 Triggered by Request for Network Service...............23 6.1.3 Triggered by Endpoint..................................26 6.2 Posture Re-Assessment.......................................28 6.2.1 Triggered by NEA Client................................29 6.2.2 Triggered by NEA Server................................31 7. Requirements...................................................34 7.1 Common Protocol Requirements................................34 7.2 Posture Attribute (PA) Protocol Requirements................35 Sangster, et. al. Expires Sept 2007 [Page 2] Internet Draft NEA Requirements Mar 2007 7.3 Posture Broker (PB) Protocol Requirements...................37 7.4 Posture Transport (PT) Protocol Requirements................38 8. Security Considerations........................................39 8.1 Trust.......................................................39 8.1.1 Endpoint Components....................................40 8.1.2 Network Communications.................................41 8.1.3 NEA Server Components..................................42 8.2 Protection Mechanisms at Multiple Layers....................42 8.3 Relevant Classes of Attack..................................43 8.3.1 Man-in-the-Middle (MITM)...............................44 8.3.2 Message Modification...................................44 8.3.3 Message Replay or Attribute Theft......................45 8.3.4 Other Types of Attack..................................45 9. Privacy Considerations.........................................46 9.1 Implementer Considerations..................................47 9.2 Minimizing Attribute Disclosure.............................48 10. References....................................................50 10.1 Normative References.......................................50 10.2 Informative References.....................................51 Acknowledgments...................................................51 Authors' Addresses................................................51 1. Introduction Today, most network providers can leverage existing standards- based technologies to restrict access to their network based upon criteria such as the requesting system's user or host-based identity, source IP address or physical access point. However these approaches still leave the network vulnerable to malware- based attack, when an authorized but infected system is admitted and the malware is able to spread throughout the internal network. As a result, network operators need a proactive mechanism to assess the state of systems joining or present on the network to determine their status relative to network compliance policies. For example, if a system is determined to be out of compliance because it is lacking proper defensive mechanisms such as firewalls, anti-virus software or the absence of critical security patches, there needs to be a way to safely repair (remediate) the system so that it can be subsequently trusted to join and operate on the network. The NEA technology strives to provide a mechanism to report the configuration of an endpoint for evaluation against network compliance policy. Such a mechanism could offer a useful tool for the network operators' arsenal but should be recognized as not being a complete Endpoint compliance solution in and of itself. Sangster, et. al. Expires Sept 2007 [Page 3] Internet Draft NEA Requirements Mar 2007 Network Endpoint Assessment (NEA) architectures have been implemented in the industry allowing the network to have visibility into the configuration of the system (e.g. security Posture). These can evaluate compliance when the system requests access to the network or at any time while the system is connected to the network, enabling that system's compliance status to be factored into various admission and access control decisions. NEA typically involves the use of special client software running on the requesting system that observes and reports on the configuration of the system to the network infrastructure. The infrastructure has corresponding validation software that is capable of comparing the system configuration information with network compliance policy and providing the result to appropriate authorization entities that make decisions about network and application access. In many cases, the admission decision is provisioned to the enforcement mechanisms on the network and/or system requesting access. The decision might allow for no access, limited access (possibly to allow for remediation), or full access to the network. While the NEA Working Group recognizes there is a link between an assessment and the enforcement of the assessment decision, the mechanisms and protocols for enforcement are not in scope for this specification. Architectures, similar to NEA, have existed in the industry for some time and are present in shipping products, but do not offer interoperability. Some examples of such architectures include: Trusted Computing Group's TNC [TNC], Microsoft's NAP [NAP], Cisco's NAC [CNAC]). These technologies assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy at the time of access to the network. These architectures are not interoperable since most of the technologies used to implement the architecture are proprietary and not standards. The NEA working group is working on defining standard protocols so as to enable interoperability between devices from different vendors allowing network owners to deploy truly heterogeneous solutions. This document describes the requirements for NEA candidate technologies and protocols. 1.1 Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. Sangster, et. al. Expires Sept 2007 [Page 4] Internet Draft NEA Requirements Mar 2007 2. Terminology This section defines a set of terms used throughout this document. In some cases these terms have been used in other contexts with different meanings so this section attempts to describe each term's meaning with respect to the NEA WG activities. Assessment - The process of collecting Posture from a set of Endpoint Components such that the appropriate validators may evaluate the Posture against compliance policy. Assertion Attributes - Class of Attribute including re-usable information about the success of a prior Assessment of the Endpoint. This could be used to optimize subsequent Assessments by avoiding a full Posture re-Assessment. For example, this type of Attribute might be issued specifically to a particular Endpoint, dated and signed by the NEA Server allowing that Endpoint to re-use it for a time period to assert compliance to a set of policies. The NEA Server might accept this in lieu of obtaining Posture information. Attribute - Data element including any requisite meta-data describing an observed, expected or status of a Component property. NEA recognizes a variety of classes of Attributes particular to their usage: Assertion Attributes, Compliance Claim Attributes, Posture Attributes, Policy Attributes, Request Attributes, Result Attributes, and Remediation Attributes. Within each class, there are two different types of Attributes: standard and vendor-specific. The standard attributes will be standardized by the NEA WG. Compliance Claim Attribute - Class of Attribute used by an NEA Client to claim that the Endpoint complies with a particular policy. For example, these Attributes are used when the NEA Client is offered Policy Attributes and wishes to claim compliance with the Policy rather then provide Posture Attributes to show compliance. Component - Software, hardware or firmware entity performing a particular logical function on the Endpoint. For example, a component may be a Posture Collector designed to ascertain the Posture of another Component such as a particular vendor product (e.g. Norton Anti-Virus) running on the Endpoint. Deployer - Role of an entity that makes available for use hardware and/or software solutions. For example, an Sangster, et. al. Expires Sept 2007 [Page 5] Internet Draft NEA Requirements Mar 2007 administrator within an enterprise IT department might release an NEA Server for use on its network. Dialog - Sequence of request/response Messages exchanged Endpoint - Any host computing device that can be connected to a network. This includes: laptops, desktops, servers, cell phone or any device with an IP address. Message - Self contained unit of communication between Components. For example, a PA Message might carry a set of Posture Attributes from a Posture Collector to a Posture Validator. Owner - the role of an entity who is the legal, rightful possessor on an asset (e.g. Endpoint). The owner is entitled to maintain control over the policies enforced on the device even if the asset is not within the Owner's possession. The Owner may permit User override or augmentation of control policies or may not assert any policies limiting use of asset. Policy Attributes - Class of Attribute sent by an NEA Server describing (or referencing) the desired policy to be met by a set of Components on the Endpoint. For example, Policy Attributes might be used to enable an NEA Client to determine whether the Endpoint is compliant without disclosing Posture information. Instead, the NEA Client makes claims of compliance to policy in Compliance Claim Attributes. Posture - Configuration and/or status of hardware or software Component(s) on an Endpoint as it pertains to an organization's security policy. Posture Attributes - Class of Attribute describing a quality or characteristic of a Component. For example, a Posture Attribute might describe the version of a Component installed on the system. Posture Attributes are normally created by a Posture Collector for inclusion in a Posture description of an Endpoint. Request Attributes - Class of Attribute containing the list of Attributes the NEA Client is requested to send to the NEA Server. Remediation Attributes - Class of Attribute including the remediation instructions for how to bring an endpoint into compliance with one or more policies. Sangster, et. al. Expires Sept 2007 [Page 6] Internet Draft NEA Requirements Mar 2007 Result Attributes - Class of Attribute describing whether the Endpoint is in compliance with NEA policy. The Result Attribute is created by the NEA Server normally at the conclusion of the Assessment to indicate whether the Endpoint was considered compliant or not. Multiple of these Attributes may be used allowing for Posture Validator level decisions to be communicated in addition to an overall, global posture decision from the Posture Broker Server. Session - Stateful connection (e.g. PB protocol described in Section 3) capable of carrying one or more Messages from multiple subscribed Posture Collectors and Validators. User - Role of an entity that is making use of the services of an Endpoint. The User may not own the Endpoint so might need to operate within the acceptable use constraints defined by the Endpoint's Owner. For example, an enterprise employee might be a User of a computer provided by the enterprise (Owner) to perform her job. 3. Applicability This section discusses the scope of technologies being standardized and the network environments where it is envisioned that the NEA technologies might be applicable. 3.1 Scope The priority of the NEA working group is to develop standard protocols at the higher layers in the Reference Model (see section 5): the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to be carried over a variety of lower layer transport (PT) protocols. When used with standard lower layer protocols, the PA and PB protocols are intended to allow interoperability between an NEA Client from one vendor and an NEA Server from another. This specification will not focus on the interfaces between NEA Reference Model Components nor requirements their internals. Any discussion of these aspects is provided to provide context for understanding the model and resulting requirements. Some tangent areas not shown in the Reference Model that are also out of scope for the NEA working group, and thus this specification, include: Sangster, et. al. Expires Sept 2007 [Page 7] Internet Draft NEA Requirements Mar 2007 o Standardizing the protocols and mechanisms for enforcing restricted network access, o Developing standard protocols for remediation of non- compliant Endpoints, o Detecting or handling lying Endpoints (see section 8.1.1 for more information). 3.2 Applicability of Environments Because the NEA model is based on special software being present on the Endpoint and in the network infrastructure and the nature of the information being exposed, the use of NEA technologies may not apply in a variety of situations possible on the Internet. Therefore, this section discusses some of the scenarios where NEA is most likely to be applicable and some where it may not. Ultimately, the use of NEA within a deployment is not restricted to just these scenarios. The decision of whether to use NEA technologies lies in the hands of the Deployer (e.g. network provider) based upon the expected relationship they have with the Owners and Users of potential Endpoints. NEA technologies are largely focused on scenarios where the Owner of the Endpoint is the same as the Owner of the Network. This is a very common model for enterprises which provide equipment to employees to perform their duties. These employees are likely bound under an employment contract which outlines what level of visibility the employer expects to have into the employee's use of company assets and possibly activities during work hours. This contract may establish the expectation that the Endpoint needs to conform to policies set forth by the enterprise. Some other environments may be in a similar situation and thus find NEA technologies to be beneficial. For example, environments where the Endpoint is owned by a party (possibly even the User) which has explicitly expressed a desire to conform to the policies established by a network or service provider in exchange for being able to access its resources. An example of this might be an independent contractor with a personal laptop, working for a company imposing NEA assessment policies on its employees, who may wish a similar level of Sangster, et. al. Expires Sept 2007 [Page 8] Internet Draft NEA Requirements Mar 2007 access and is willing to conform to its policies. NEA technologies may be applicable to this situation. Conversely, some environments where NEA is not expected to be applicable would be environments where the Endpoint is owned by a User that has not agreed to conform to a network provider's policies. An example might include when the above contractor visits any public area like the local coffee shop which offers Internet access. This coffee shop would not be expected to be able to use NEA technologies to assess the Posture of the contractor's laptop. Because of the potentially invasive nature of NEA technology, such an assessment could amount to an invasion of privacy of the contractor. Other environments are more difficult to determine whether NEA is applicable, so the NEA WG will consider them to be out of scope for consideration and specification. In order for an environment to be considered applicable for NEA, the Owner or User of an Endpoint must have established a clear expectation that it will comply with the policies of the Owner and operator of the network. Such an expectation likely includes a willingness to disclose appropriate information necessary for the network to perform compliance checks. 4. Problem Statement NEA technology may be used for several purposes. One use is to facilitate Endpoint compliance checking against an organization's security policy when an Endpoint connects to the network. Organizations often require Endpoints to run an IT- specified OS configuration and have certain security applications enabled, e.g. anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An Endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network. Without NEA technology, ensuring compliance of Endpoints to corporate policy is a time-consuming and difficult task. Not all Endpoints are managed by a corporation's IT organization, e.g. lab assets and guest machines. Even for assets that are managed, they may not receive updates in a timely fashion because they are not permanently attached to the corporate network, e.g. laptops. With NEA technology, the network is able to assess an Endpoint as soon as it requests access to the Sangster, et. al. Expires Sept 2007 [Page 9] Internet Draft NEA Requirements Mar 2007 network or at any time after joining the network. This provides the corporation an opportunity to check compliance of all NEA- capable Endpoints in a timely fashion and facilitate Endpoint remediation where needed. The decision of how to handle non-compliant Endpoints can be made by the network administrator impossibly based on information from other security mechanisms on the network (e.g. authentication). For example, remediation instructions or warnings may be sent to the endpoint. Also, network access technologies can use the NEA Assessment results to restrict or deny access to an Endpoint, while allowing vulnerabilities to be addressed before an Endpoint is exposed to attack. The communication and representation of NEA Assessment results to network access technologies on the network is out-of-scope for this document. Re-assessment is an important part of NEA technology as it allows for additional Assessments of previously considered compliant Endpoints to be performed. This might become necessary because network compliance policies and/or Endpoint Posture can change over time. A system initially assessed as being compliant when it joined the network may no longer be in compliance after changes occur. For example, re-assessment might be necessary if a User disables a security protection (e.g. host firewall) required by policy or when the firewall becomes non-compliant after a firewall patch is issued and network policy is changed to require the patch. Another use of NEA technology may be to verify or supplement organization asset information stored in inventory databases. NEA technology can be used to address the above problem covering a range of ways of connecting to the network including (but not limited to) wired and wireless LAN access, remote access via IPsec[IPSEC] or SSL[TLS] VPN, or gateway access. NEA technology can also be used to check and report compliance for Endpoints when they try to access certain mission critical applications within an enterprise by employing application triggered Assessment. 5. Reference Model This section describes the Reference Model for Network Endpoint Assessment. This model is provided to establish a context for the discussion of requirements and may not directly map to any particular product or deployment architecture. The model includes the major Components of the NEA Client and Server and their Sangster, et. al. Expires Sept 2007 [Page 10] Internet Draft NEA Requirements Mar 2007 relationships, as well as the protocols they use to communicate at various levels (e.g. PA is carried by the PB protocol). The vertical lines in the model represent APIs and/or protocols between Components within the NEA Client or Server. These interfaces are out of scope for standardization in the NEA WG. +-------------+ +--------------+ | Posture | <--------PA--------> | Posture | | Collectors | | Validators | | (1 .. N) | | (1 .. N) | +-------------+ +--------------+ | | | | | | +-------------+ +--------------+ | Posture | | Posture | | Broker | <--------PB--------> | Broker | | Client | | Server | +-------------+ +--------------+ | | | | +-------------+ +--------------+ | Posture | | Posture | | Transport | <--------PT--------> | Transport | | Client | | Server | | (1 .. N) | | (1 .. N) | +-------------+ +--------------+ NEA CLIENT NEA SERVER Figure 1: NEA Reference Model The NEA Reference model does not include any mechanisms for discovery of NEA Clients and NEA Servers. It is expected that NEA Clients and NEA Servers are configured with information that allow them to reach each other. The specific methods of referencing the configuration and establishing the communication channel are out of scope for the NEA Reference Model and should be covered part of the specifications of candidate protocols for the Posture Transport. 5.1 Components 5.1.1 NEA Client Sangster, et. al. Expires Sept 2007 [Page 11] Internet Draft NEA Requirements Mar 2007 The NEA Client is resident on an Endpoint device and comprises of the following components: o Posture Collector o Posture Broker Client o Posture Transport Client 5.1.1.1 Posture Collector The Posture Collector is the Component that is responsible for responding to requests for Posture information from the Posture Broker Client and receiving Posture Assessment requests in Request Attributes, Policy information in Policy Attributes, Assessment decisions in Result Attributes and remediation instructions (Remediation Attributes). A single NEA Client can have several Posture Collectors capable of collecting standard and/or vendor-specific Posture Attributes for particular Endpoint Components. Typical examples include Posture Collectors that provide information about Operating System (OS) patch levels, anti-virus software, and security applications on the Endpoint such as host firewall or an IDS. Posture Collectors may also be capable of evaluating rules and asserting Posture decisions. Each Posture Collector will be associated with an identifier that enables it to be the specified as the destination in a PA Message. The Posture Broker Client uses this identifier to route Messages to this collector. This identifier might be dynamic (e.g. assigned by the Posture Broker Client upon registration) or more static (e.g. provided during registration) or a function of the Attribute Messages the collector desires to receive (e.g. Message type subscription). The NEA model allocates the following responsibilities to the Posture Collector Component: o Consulting with local privacy and security policies that may restrict what information is allowed to be disclosed to a given NEA Server. o Receiving Request Attributes from a Posture Validator and performing the local processing required to respond appropriately. This may include: - Collecting associated Posture information for the Component(s) on the Endpoint and returning this information in Posture Attributes. Sangster, et. al. Expires Sept 2007 [Page 12] Internet Draft NEA Requirements Mar 2007 - Recognizing a recently issued (cached) Assertion Attribute that might serve to prove compliance and returning this attribute instead of Posture information. o Receiving Policy Attributes indicating the policies that need to be met to be considered compliant. The collector would obtain the Posture information from Component(s) on the Endpoint and compare the information with the provided (or referenced) security policy. The result would be sent back to the Validator in Compliance Claim Attributes. - If the Policy Attributes merely reference a compliance policy, the collector may need to fetch or locate this policy. o Receiving Remediation Attributes containing instruction on how to update the Component(s) on the Endpoint. This could require the collector to interact with the User, Owner and/or a remediation server. o Monitoring the Posture of Component(s) on the Endpoint for Posture changes that require notification to the Posture Broker Client. o Providing cryptographic verification of the Attributes received from the Validator and offering cryptographic protection to the Attributes returned. The above list describes the model's view of the possible responsibilities of the Posture Collector. Recall that this is not a set of requirements for what each Posture Collector implementation must support. 5.1.1.2 Posture Broker Client The Posture Broker Client is a Component that is both a PA Message multiplexer and a de-multiplexer. The Posture Broker Client is responsible for de-multiplexing the Posture information request from the NEA Server and distributing each request to the corresponding Posture Collector(s). The model also allows for the Posture information request to be pre- provisioned on the NEA Client to improve performance by allowing the NEA Client to report Posture without Request Attributes being sent by the NEA Server. The Posture Broker Client also multiplexes the responses from the Posture Collector(s) and returns them to the NEA Server. The Posture Broker Client constructs one or more PB Messages using the PA Message(s) it obtains from the Posture Collector(s) Sangster, et. al. Expires Sept 2007 [Page 13] Internet Draft NEA Requirements Mar 2007 involved in the Assessment. The quantity and ordering of Posture Collector responses (PA Message(s)) multiplexed into the PB response Message(s) can be determined by the Posture Broker Client based on many factors including policy or characteristics of the underlying network transport (e.g. MTU). A particular NEA Client will have one Posture Broker Client. The NEA model allocates the following responsibilities to the Posture Broker Client Component: o Maintaining a registry of known Posture Collectors and allowing for Posture Collectors to dynamically register/un-register. o Multiplexing and de-multiplexing Attribute Messages between the NEA Server and the relevant Posture Collectors. o Handling Posture Change Notifications from Posture Collectors and triggering re-Assessment. o Providing User notification about the global Posture decision and other User Messages sent by the NEA Server. 5.1.1.3 Posture Transport Client The Posture Transport Client is a component responsible for establishing a reliable communication channel with the NEA Server for the Message Dialog between the NEA Client and NEA Server. There might be more than one Posture Transport Client on a particular NEA Client. Certain Posture Transport Clients may be configured with the address of the appropriate Posture Transport Server to use for a particular network. The NEA model allocates the following responsibilities to the Posture Transport Client Component: o Initiating and maintaining the communication channel to the NEA Server, the Posture Transport Client hides the details of the underlying carrier which could be a Layer 2 or Layer 3 protocol. o Providing cryptographic protection for the Message Dialog between the NEA Client and NEA Server. 5.1.2 NEA Server The NEA Server will typically comprise of the following logical components: Sangster, et. al. Expires Sept 2007 [Page 14] Internet Draft NEA Requirements Mar 2007 o Posture Validator o Posture Broker Server o Posture Transport Server The Posture Validator can be located on a separate server from the Posture Broker Server requiring the Posture Broker Server to deal with both local and remote Posture Validators. 5.1.2.1 Posture Validator A Posture Validator is a Component that is responsible for assessing the Posture Attributes from the corresponding Posture Collector and determining the result of the Assessment. The Posture Validator performs the Posture Assessment for one or more Components and creates the result and if necessary the remediation instructions. The Posture Validator can request a set of primitive attributes or can pass compliance policies that might be evaluated by the Posture Collector. The response from the Posture Collector could be a set of Attributes or a set of assertions in case of NEA Client based evaluation. Each Posture Validator will be associated with an identifier that enables it to be the specified as the destination in a PA Message. The Posture Broker Server uses this identifier to route Messages to this Validator. This identifier might be dynamic (e.g. assigned by the Posture Broker Server upon registration) or more static (e.g. provided during registration) or a function of the Attribute Messages the validator desires to receive (e.g. Message type subscription). Posture Validators can be co-located on the NEA Server or can be hosted on separate servers. A particular NEA Server is required to handle several Posture Validators. The NEA model allocates the following responsibilities to the Posture Validator Component: o Requesting Attributes from a Posture Collector. The request may include: - Request Attributes that indicate to the Posture Collector to fetch and provide Posture Attributes from various Component(s) on the NEA Client. - Policy Attributes that indicate to the Posture Collector the policies that need to met by various Component(s) for them to be considered compliant. Sangster, et. al. Expires Sept 2007 [Page 15] Internet Draft NEA Requirements Mar 2007 o Receiving Attributes from the Posture Collector. The response from the Posture Collector may include: - Posture Attributes collected from various Component(s). - Assertion Attributes that indicate the compliance result from a prior Assessment. - Compliance Claim Attributes in response to Policy Attributes sent in the request. o Assessing the Posture of the Component(s) based on the various Attributes received from the Collector. o Communicating the Posture Assessment Result to the Posture Broker Server. o Communicating the Posture Assessment Results to the Posture Collector; this Attribute Message may include: - Results Attribute that communicates the Posture Assessment Result. - Remediation Attributes that communicate the Remediation Instructions to the Posture Collector. o Monitoring out-of-band updates that trigger re-assessment and require notifications to be sent to the Posture Broker Server. o Providing cryptographic protection for Attributes sent to the Collector and offering cryptographic verification of the Attributes received from the Collector. 5.1.2.2 Posture Broker Server The Posture Broker Server is a Component that acts as a multiplexer and a de-multiplexer for Attribute Messages. The Posture Broker Client multiplexes the PA Messages, e.g. Messages containing Request Attribute(s) from the relevant Posture Validator(s) in one or more PB Messages and returns them to the NEA Client. The Posture Broker Server de-multiplexes the PA Messages received from the NEA Client and passes them to the associated Posture Validators. The quantity and ordering of Posture Collector responses (PA Message(s)) multiplexed into the PB response Message(s) can be determined by the Posture Broker Client based on many factors including policy or characteristics of the underlying network transport (e.g. MTU). The Posture Broker Server is also responsible for computing the global Posture decision based on individual Posture Assessment results from the various Posture Validators, this global Posture decision is sent back to the NEA Client. A particular NEA Server Sangster, et. al. Expires Sept 2007 [Page 16] Internet Draft NEA Requirements Mar 2007 will have one Posture Broker Server and this Posture Broker Server will handle all the local and remote Posture Validators. The NEA model allocates the following responsibilities to the Posture Broker Server Component: o Maintaining a registry of Posture Validators and allowing for Posture Validators to register/un-register. o Multiplexing and de-multiplexing Posture Messages between the NEA Client and the relevant Posture Validators. o Computing the global Posture decision based on Posture Assessment results from the various Posture Validators. 5.1.2.3 Posture Transport Server The Posture Transport Server is a Component responsible for establishing a reliable communication channel with the NEA Client for the Message Dialog between the NEA Client and NEA Server. There might be more than one Posture Transport Servers on a particular NEA Server. A particular Posture Transport Server will typically handle requests from several Posture Transport Clients and may require local configuration describing how to reach the NEA Clients. The NEA model allocates the following responsibilities to the Posture Transport Server Component: o Initiating and maintaining a communication channel with potentially several NEA Clients. o Providing cryptographic protection for the Message Dialog between the NEA Client and NEA Server. 5.2 Protocols The NEA Reference Model includes three layered protocols (PA, PB and PT) that allow for the exchange of Attributes across the different sets of Components on the network. While these protocols are intended to be used together to fulfill a particular role in the model, they may offer overlapping functionality. For example, each protocol should be capable of protecting its information from attack (see section 8.2 for more information). 5.2.1 Posture Attribute Protocol (PA) Sangster, et. al. Expires Sept 2007 [Page 17] Internet Draft NEA Requirements Mar 2007 PA is a protocol that carries Attribute Messages between a Posture Collector and its associated Posture Validator. The PA protocol is required to handle several types of Attributes including Posture Attributes, Request Attributes, Result Attributes, Policy Attributes, Compliance Claim Attributes, Assertion Attributes and Remediation Attributes. The PA protocol also provides the requisite encoding and cryptographic protection for the Posture Attributes. 5.2.2 Posture Broker Protocol (PB) PB is a protocol that carries aggregate Attribute Messages between the requested Posture Collectors on the NEA Client and the corresponding Posture Validators on the NEA Server involved in a particular Assessment. The PB protocol creates and manages a Session allowing for Message Dialogs for every Assessment. This PB Session is then used to bind multiple Posture Attribute requests and responses from the different Posture Collectors and Posture Validators involved in a particular Assessment. The PB protocol may also carry the global Posture decision in the Result Attribute from the Posture Broker Server to the Posture Broker Client. 5.2.3 Posture Transport Protocol (PT) PT is a transport protocol between the NEA Client and the NEA Server responsible for carrying the Messages generated by the PB protocol. The PT protocol(s) must be capable of transporting Messages for Assessment during network connection request or after network connectivity has been established. It is conceivable that certain candidate PT protocols are capable of transporting Messages both during network connection request and after network connectivity has been established, but this isn't a mandatory requirement for all candidate PT protocols. Should the NEA WG select a PT protocol capable of operating only during one time horizon, the WG should select an additional one so that both horizons could be possible. The PT protocol provides reliable Message delivery, mutual authentication and cryptographic protection for the PB Messages. 5.3 Attributes The PA protocol is responsible for the exchange of Attributes between a Posture Collector and Posture Validator. Attributes are effectively the reserved word "nouns" of the Posture Assessment. The NEA Server is only able to ask for information that has a corresponding Attribute, thus bounding what type of Posture can be Sangster, et. al. Expires Sept 2007 [Page 18] Internet Draft NEA Requirements Mar 2007 obtained. The NEA WG will define a common (standard) set of Attributes that are expected to be supported by all Posture Collectors, but outside this set Posture Collectors may support additional vendor-specific attributes. As discussed in the Use Cases section below, depending on the deployment scenario, different types of Attributes may be used. The Attribute classes defined in this specification may be merged when the NEA WG defines the name space and schema for each Attribute class, but for now this specification recognizes their distinct roles. This section summarizes the purpose of each class of Attribute and how they are generated. 5.3.1 Attributes Normally Sent by NEA Client: o Posture Attributes - Attributes and values sent to report information about a particular aspect (based on semantic of the Attribute) of the system. These Attributes are typically sent in response to Request Attributes from the NEA Server. For example a set of Posture Attributes might describe the status of the firewall (e.g. If running, Vendor, Version). The NEA Server would base its decision on comparing this type of attribute against policy. o Assertion Attributes - Attributes claiming recent prior compliance to policy in hopes of avoiding a re-assessment. These attributes might consist of NEA Server provided attributes (state) describing a prior evaluation (e.g. opaque to Endpoint, signed, time stamped items stating specific results) or might consist of NEA Client identity information used by the NEA Server to locate state about prior decisions (e.g. system-bound cookie). These might be returned in lieu of or addition to Posture Attributes. o Compliance Claim Attributes - Attributes claiming compliance with a particular policy provided by the NEA Server (in Policy Attributes). 5.3.2 Attributes Normally Sent by NEA Server: o Request Attributes - Attributes which define the specific Posture information desired by the NEA Server. These attributes might effectively form a template that the Posture Collector fills in (subject to local policy restrictions) with the specific value corresponding to each Attribute. The resulting Attributes are typically Posture or Assertion Attributes from the NEA Client. Sangster, et. al. Expires Sept 2007 [Page 19] Internet Draft NEA Requirements Mar 2007 o Policy Attributes - Attributes including the NEA Server's network access policies that the Endpoint must meet. These Attributes are normally sent when the Endpoint is empowered to merely provide the NEA Server with a compliance claim (in Compliance Claim Attributes) without providing Posture Attributes. o Result Attributes - Attributes that contain the decisions of the Posture Validators and/or Posture Broker Server. The level of detail provided may vary from which individual Attributes were compliant or not thru just the global decision. o Remediation Attributes - Attributes that describe to the NEA Client and its User how to update the Endpoint to become compliant with the NEA Server policies. These Attributes are sent when the global decision was that the Endpoint is not currently compliant. Remediation and Result Attributes may both exist within an NEA Server Attribute Message. 6. Use Cases This section discusses use cases with intent to describe and collectively bound the NEA problem space under consideration. The use cases provide a context and general rationale for the defined requirements. In order to ease understanding of each use case and how it maps to the reference model, each use case will be accompanied by a simple example and a discussion of how this example relates to the NEA protocols. It should be emphasized that the provided examples are not intended to indicate the only approach to addressing the use case but rather are included to ease understanding of how the flows might occur and require support from the NEA protocols. We broadly classify the use cases into two categories each with their own set of trigger events: o Initial Assessment - evaluation of the Posture of an Endpoint that has not recently been assessed and thus is not in possession of any valid proof that it should be considered compliant. This might be triggered by a request to join a network, request to use a service or a desire to understand the Posture of a system. o Re-assessment - evaluation of the Posture of an endpoint that has previously been assessed. This could occur for a variety of reasons including the NEA Client or Server recognizing an occurrence affecting the endpoint which Sangster, et. al. Expires Sept 2007 [Page 20] Internet Draft NEA Requirements Mar 2007 might raise its risk level. This could be as simple as it having been a long time since its last re-assessment. 6.1 Initial Assessment An initial Assessment occurs when a NEA Client or Server event occurs that causes the evaluation of the Posture of the Endpoint for the first time. Endpoints that have been recently assessed and the NEA Client or Server has maintained state (or proof) that the Endpoint is compliant and therefore does not need to have their Posture evaluated again do not qualify for this category of use case. Posture P.Broker Transport Transport P.Broker Posture Collectors Client Client Server Server Validators | | | | | | | | client requests network access | | | |---------->| | | | | | |-------->|Posture reqs | | | | |<----------| | | | Posture Req | | | | Pos Req |<----------|<--------| | | Pos Req |<--------| | | | |<--------| | | | | |Pos Resp | | | | | |-------->|Pos Resp | | | | | |-------->| Posture Resp | | | | |---------->|-------->| Pos Resp | | | | | |---------->| | | | | | Decisions | | | | Posture Decision |<----------| | | Decision|<----------|<--------| | | Decision|<--------| | | | |<--------| | | | | | | | | | | Figure 2: Illustration of NEA Initial Assessment Use case 6.1.1 Triggered by Network Connection Request This use case focuses on Assessments performed at the time an Endpoint attempts to join a network. This use case is particularly interesting because it allows the NEA Server to evaluate the Posture of an Endpoint before allowing it access to the network. This approach could be used to help detect Endpoints with known vulnerabilities and facilitate their repair before they are admitted to the network and potentially exposed to such threats on the network. Sangster, et. al. Expires Sept 2007 [Page 21] Internet Draft NEA Requirements Mar 2007 6.1.1.1 Example An IT employee returning from vacation boots his office desktop computer which generates a request to join the wired enterprise network. The network's security policy requires the system to provide Posture information in order to determine whether the desktop's security features are enabled and up to date. The desktop sends its patch, firewall and anti-virus Posture information. The network determines that the system is lacking a recent security patch designed to fix a serious vulnerability and places the system on a restricted access network. The desktop follows the network provided remediation instructions to download and install the necessary patch. Later, the desktop requests again to join the network and this time is allowed on the enterprise network after a full Assessment. 6.1.1.2 Possible flows and Protocol Usage The following describes the Message flows through the NEA Reference Model for the described example: 1. The IT employee's desktop computer connects to the network through an access gateway in the wired enterprise network. 2. The Posture Broker Server on the NEA Server is notified of the request to join the wired network. 3. Based upon compliance policy the Posture Broker Server contacts the OS Patch, Firewall and Anti-Virus Posture Validators to request the necessary Posture. Each Posture Validator creates a PA Message containing the desired Request Attributes for the desktop system. 4. The Posture Broker Server aggregates the Request Attributes from the Posture Validators and sends them to the NEA Client on the desktop using the Posture Transport Server. 5. The Posture Transport Client receives the Message from the NEA Server and passes it to the Posture Broker Client for Message delivery. 6. The Posture Broker Client de-multiplexes the PB Message and delivers Request Attributes to the Firewall, OS Patch and Anti-Virus Posture Collectors. 7. Each Posture Collector involved consults local privacy policy to determine what information is allowed to be disclosed and then returns the requested Posture Attributes that are authorized in a PA Message to the Posture Broker Client. 8. The Posture Broker Client aggregates these into a single PB Message and sends it to the Posture Broker Server using the Posture Transport Client to Server Session. Sangster, et. al. Expires Sept 2007 [Page 22] Internet Draft NEA Requirements Mar 2007 9. The Posture Transport Server provides the PB Message to the Posture Broker Server which de-multiplexes the Message and sends the appropriate Posture Attributes to the corresponding Posture Validator. 10. Each Posture Validator compares the contents of the Posture Attribute Message it receives with the expected values defined in its policy. 11. The Anti-Virus and Firewall Posture Validators return Result Attributes stating it's compliant to the Posture Broker Server, but the OS Patch Posture Validator returns non- compliant and a PA Message with Result and Remediation Attributes. 12. The Posture Broker Server sends the Result and Remediation Attributes in a PB Message to the Posture Broker Client 13. The Posture Broker Client delivers the PA Message containing Result and Remediation Attributes to the OS Patch Posture Collector which interacts with the User to download and install the needed patches. 14. Upon completion, the above steps 1-10 are repeated (triggered by the NEA Client again requesting network access). 15. This time the OS Patch Posture Validator (step 11) returns a success status and the Posture Broker Server returns a successful Result Attribute in a PB Message indicating a global success. 16. The Posture Broker Client receives the successful Result Attribute and the IT employee's desktop is now on the network. 6.1.1.3 Impact on Requirements The following are several different aspects of the use case example that potentially need to be factored into the requirements. o Posture Assessment before Endpoint allowed on network o Endpoint sends Posture Attributes o NEA Server sends Remediation Attributes o NEA Client causes a re-assessment to join network after remediation 6.1.2 Triggered by Request for Network Service In this use-case, the Endpoint was allowed access to the network without a NEA Posture validation. Now the Endpoint is requesting use of a protected resource or service which results in the need for an Assessment. There are a variety of possible resources or network services that could be involved with this use case (e.g. critical application server seeking tighter security assurances of the accessing Endpoints). Sangster, et. al. Expires Sept 2007 [Page 23] Internet Draft NEA Requirements Mar 2007 6.1.2.1 Example The CEO of a small company working from home wishes to establish a VPN connection into the office to read e-mail. The CEO is already on the home IP-based network which did not perform an initial Assessment. When the VPN service request reaches the company's gateway, it wishes some assurance the CEO's system is virus protected before allowing access to the company network. The gateway's policies require the system be running anti-virus that has up to date signatures, but does not wish to expose details (potentially personal in nature) of what is running on the system to the network. The gateway sends its specific policy on allowable anti-virus products and versions to the CEO's system and inquires as to whether it is compliant. The CEO's system assesses the anti-virus software and determines it meets the request policy, thus it sends a Message claiming it is compliant. The gateway decides to trust the claim and allow the system on the network. 6.1.2.2 Possible flows and Protocol Usage The following describes the Message flows through the NEA Reference Model for the remote User using a VPN to access the enterprise network example: 1. CEO's computer initiates a remote access request to the VPN gateway via his home network. 2. The VPN gateway triggers an authentication exchange with the Endpoint. The protocol that carries this exchange does double duty by also carrying the Posture Transport protocol. 3. The VPN gateway notifies the Posture Transport Server that a new VPN session has been requested which triggers the Posture Broker Server to initiate an NEA assessment. 4. The Posture Broker Server policy requires that Anti-Virus be checked so it contacts the Anti-Virus Posture Validator. 5. Since in this case the Anti-Virus Posture Validator policy trusts the NEA Client to perform the assessment it creates a PA Message containing Policy Attributes including the most recent Posture values describing the required Anti-Virus policy that the CEO's computer must meet. 6. The Posture Broker Server assembles the PB protocol Message containing the Policy Attributes, and forwards them to the Posture Broker Client on the Endpoint over the PT protocol. 7. The gateway forwards the PB Message to the Posture Transport Client in the NEA Client, which passes the Message to its Posture Broker Client. Sangster, et. al. Expires Sept 2007 [Page 24] Internet Draft NEA Requirements Mar 2007 8. The Posture Broker Client extracts the PA Message from the PB Message and delivers it to the Anti-Virus Posture Collector for processing. 9. The Anti-Virus Posture Collector finds Policy Attributes (instead of the normal Request Attributes) so is empowered to make a claim of compliance with respect to the included (or referenced) policy. 10. The Anti-Virus Posture Collector obtains information about the running Anti-Virus software and compares this information with the provided Policy Attributes. 11. In this case, it determines the CEO's system is compliant with the policy and creates a PA Message containing Compliance Claim Attribute(s) describing the compliance. The PA Message is returned to the Posture Broker Client. 12. The Posture Broker Client takes the Compliance Claims Attributes from the Posture Collector, assembles a PB protocol Message, and forwards it to NEA Server, via the gateway, over the PT protocol. 13. The gateway in turn forwards the PT protocol Messages to the Posture Transport Server on the NEA Server. 14. The Posture Broker Server de-multiplexes the Compliance Claims Attributes and delivers them to the Anti-Virus Posture Validator. The Posture Validator can return Result Attributes indicating compliance status and, if required, Remediation Attributes to the Posture Broker Server. In this example, the Anti-Virus Posture Validator trusts the claims that the CEO's system is compliant so creates a PA Message containing a Result Attribute stating the system is compliant and returns a successful Posture Assessment Decision. 15. The Posture Broker Server creates a PB Message containing the PA Message and includes a successful global compliance decision, and returns it and specific Result Messages to the NEA Client via the PB protocol. 16. The gateway is informed about the compliance status using the PT protocol or other protocols, so that it can take the appropriate enforcement action if required. The VPN authentication process continues, in this case over the same physical protocol as used for PT. 17. Upon successful VPN authentication appropriate enforcement policies are applied. The gateway allows normal access to an Endpoint that is in compliance. 6.1.2.3 Impact on Requirements The following are several different aspects of the use case example that potentially need to be factored into the requirements. Sangster, et. al. Expires Sept 2007 [Page 25] Internet Draft NEA Requirements Mar 2007 o Posture Assessment after Endpoint on network, triggered by service request o NEA Server requests only anti-virus Posture o Endpoint sends Compliance Claim Attributes rather than Posture Attributes o NEA Server decision based only on Compliance Attributes (no Posture Attributes sent) 6.1.3 Triggered by Endpoint This use case highlights that an Endpoint (possibly caused by a User) may wish to trigger an Assessment of its Posture to determine whether its security protective mechanisms are running and up to date. 6.1.3.1 Example A student goes to the terminal room to work on a project. The terminal room contains shared systems owned by the school that are on the network. These systems have been previously used by other students so their security Posture is unknown. The student wishes to check whether a system is currently in compliance with the school's security policies prior to doing work, so requests a Posture Assessment. The network performs an Initial Assessment of the system and determines it's compliant but the anti-virus protection is not in use. The student receives an advisory response indicating the system's anti-virus software is turned off but that otherwise it complies with the school's policy. The student turns on the anti-virus software, initiates a scan and upon completion decides to trust the system with her work. 6.1.3.2 Possible flows and Protocol Usage The following describes the Message flows through the NEA Reference Model for the student using a terminal room shared system example: 1. Student triggers the Posture Broker Client on the computer system in the terminal room to initiate a Posture Assessment. 2. The Posture Broker Client establishes a Session with the Posture Broker Server which causes an assessment to be triggered. 3. The Posture Transport Client establishes the transport channel to the Posture Transport Server causing a new protocol context exchange to be initiated. 4. The Posture Broker Server detects the new Session and consults policy to determine which Posture Validators to involve in the assessment. The Posture Broker Server Sangster, et. al. Expires Sept 2007 [Page 26] Internet Draft NEA Requirements Mar 2007 contacts several Posture Validators including the Anti-Virus Posture Validator. 5. The Posture Validators involved create PA Messages containing Request Attributes for information desired about the terminal room computer based on the school's security policy. 6. The Posture Broker Server assembles a PB Message including each of the PA Messages from the Posture Validators. 7. The Posture Transport Server sends the PB Message to the Posture Transport Client where it is passed on to the Posture Broker Client. 8. The Posture Broker Client on the student's computer de- multiplexes the PA Message and delivers them to the corresponding Posture Collectors. 9. The Posture Collectors consult privacy policy to decide what information to share with the Server. If allowable, the collectors each return a PA Message containing Posture Attributes to the Posture Broker Client. 10. The Posture Broker Client aggregates the returned PA Messages into a PB Message and hands it to the Posture Transport Client for transmission to the Posture Transport Server. 11. The Posture Broker Server separates and distributes the Posture Collector PA Messages to the associated Posture Validators. 12. The Posture Validators determine whether the Posture Attributes included in the PA Message are compliant with their specific policies and returns a Posture Assessment Decision to the Posture Broker Server. The anti-virus Posture Validator returns a non-compliant decision because the Anti-Virus software is not running. In case the User wishes to activate the Anti-Virus software, the Validator creates Remediation Attributes. 13. The Posture Broker Server determines the global compliance decision based on each Validator's assessment decision and sends Result Attributes containing the global decision and the Anti-Virus's Remediation Attributes. In this case the Result Attribute contains a compliant decision (despite the single remediation attributes) because the Posture Broker Server policy allowed for the Anti-Virus to not be running as long as the system was properly patched and running a Firewall (which were the case according to the other Posture Validators). This information is included in a PB Message. 14. The Posture Transport Server sends the PB Message to the Posture Transport Client which provides the Message to the Posture Broker Client. 15. The Posture Broker Client on the student's computer examines the Result Attribute's global decision and reports to the Sangster, et. al. Expires Sept 2007 [Page 27] Internet Draft NEA Requirements Mar 2007 Student that the system was deemed to be compliant, but that an advisory was included. 16. The Posture Broker Client provides the Remediation Attributes to the Anti-Virus Posture Collector which interacts with the User to explain how to turn on Anti-Virus to improve the local protections. 17. The student turns on the Anti-Virus software and on completion steps 1-10 are repeated. 18. This time the Anti-Virus Posture Validator returns a success status and the Posture Broker Server returns a successful Result Attribute in a PB Message indicating a global success. 19. The Posture Broker Client receives the successful Result Attribute on the student's computer and the student now uses the computer for his/her assignment. 6.1.3.3 Impact on Requirements The following are several different aspects of the use case example that potentially need to be factored into the requirements. o Voluntary, Endpoint requested Initial Assessment o Successful (compliant) Result Attribute with an advisory Remediation Attribute. 6.2 Posture Re-Assessment Re-assessment(s) of Endpoints can happen anytime after being admitted to the network after a successful initial NEA Assessment. These may be event-based such as driven by Posture changes detected by the NEA Client or changes detected by network infrastructure such as detection of suspicious behavior or network policy updates. They may also be periodic (timer-driven) to re-assess the health of the Endpoint. Posture P.Broker Transport Transport P.Broker Posture Collectors Client Client Server Server Validators | | | | | | | | initial assessment complete | | | | |<--------->| |event triggered | | | | |Posture request | | | | |<----------| | | | Posture Req | | | | Pos Req |<----------|<--------| | | Pos Req |<--------| | | | |<--------| | | | | Sangster, et. al. Expires Sept 2007 [Page 28] Internet Draft NEA Requirements Mar 2007 |Pos Resp | | | | | |-------->|Pos Resp | | | | | |-------->| Posture Resp | | | | |---------->|-------->| Pos Resp | | | | | |---------->| | | | | | Decision | | | | Posture Decision |<----------| | | Decision|<----------|<--------| | | Decision|<--------| | | | |<--------| | | | | | | | | | | Figure 3: Illustration of NEA Posture Re-assessment Use case 6.2.1 Triggered by NEA Client This use case allows for software on the Endpoint or a User to determine that a re-assessment of the system is required. There are a variety of reasons why such a re-assessment might be beneficial including: changes in its previously reported Posture, detection of potentially suspicious behavior or even to enable the system to periodically poll the network to assess its condition relative to the latest policies. 6.2.1.1 Example The desktops within a company's HR department have a history of poor security practices and eventual compromise. The HR department administrator decides to deploy software on each desktop to monitor the use of security protective mechanisms to assure their use. One day, an HR person accidentally turns off the desktop firewall. The monitoring process detects the lack of a firewall and contacts the NEA Server to request a re- Assessment of the firewall compliance. The NEA Server returns a decision that the firewall must be re-activated to stay on the network. The NEA Client explains the decision to the User and how to re-activate the firewall. The HR person re-starts the firewall and initiates a request to re-join the network. 6.2.1.2 Possible Flows & Protocol Usage The following describes the Message flows through the NEA Reference Model for the HR department example: 1. The Desktop Monitoring Software which typically might act as a Posture Collector triggers the Posture Broker Client to initiate a Posture Re-assessment. This PB Message contains a Sangster, et. al. Expires Sept 2007 [Page 29] Internet Draft NEA Requirements Mar 2007 PA Message with the appropriate Posture Attribute indicating the disabled desktop firewall. 2. The Posture Broker Client sends the PB Message to the Posture Broker Server. The Posture Broker Client will create a new session for the assessment. 3. The Posture Transport Client sends the PB Message to the Posture Transport Server over the PT protocol. 4. The Posture Broker Server receives the PB Message and forwards the Posture Attributes Message to the Firewall Posture Validator responsible for handling Firewall related Posture Attribute(s). 5. The Firewall Posture Validator processes the new value(s) of the Posture Attribute(s) and determines that the Endpoint is no longer compliant. 6. The Posture Validator generates a PA Message that includes a Result Attribute with the Posture Assessment Decision set to non-compliant and Remediation Attributes indicating how to re-activate the firewall. 7. The Posture Validator communicates the PA Message with the Posture Assessment Result to the Posture Broker Server and instructs it to respond back to the NEA Client. 8. The Posture Broker Server generates a PB Message with the Global Posture Assessment Decision and PA Message from the Firewall Posture Validator. 9. The Posture Transport Server transports the PB Message to the Posture Transport Client where it is passed to the Posture Broker Client. 10. The Posture Broker Client processes the Result Attribute received from the NEA Server and displays non-compliance Messages to the end User. 11. The Posture Broker Client forwards the PA Message to the Firewall Posture Collector; the Posture Collector guides the end User with instructions to be compliant which includes enabling the Desktop Firewall. 12. The end User will be prompted to initiate a Re-assessment after completing the Remediation. 13. Upon completion of the remediation, the NEA Client re-initiates a request for re-assessment and steps 1-4 are repeated. This time the Firewall Posture Validator determines the Endpoint is compliant and returns a successful Posture Assessment Decision. 14. The successful Posture Broker Server generates a PB Message with a Global Posture Assessment of compliant and returns this to the NEA Client. 6.2.1.3 Impact on Requirements The following are several different aspects of the use case example that potentially need to be factored into the requirements. Sangster, et. al. Expires Sept 2007 [Page 30] Internet Draft NEA Requirements Mar 2007 o Voluntary, Endpoint (software) initiated Posture evaluation request o NEA Server requests specific firewall-oriented Posture Attributes o NEA Client (firewall Posture Collector) interact with User to fix problem 6.2.2 Triggered by NEA Server In many cases, especially for re-assessment, the NEA Server may initiate specific or complete re-assessment of one or more Endpoints triggered by: o Time (periodic) o Event occurrence 6.2.2.1 Example An enterprise requires employees on the network to always stay up to date with security critical operating system patches. A marketing employee joins the network and performs an Initial Assessment. The Assessment determines the employee's laptop is compliant. Several hours later, a major operating system vendor releases a set of patches preventing a serious vulnerability that is being exploited on the Internet. The enterprise administrators make available the patches and change the network policy to require it to be installed by 5PM. This policy change causes the NEA Server to request a re- assessment to determine what Endpoints are impacted and lacking the patches. The marketing employee's laptop is re-assessed and determined to need the patches. A remediation advisory is sent and presented to the employee how to obtain the patch and that it must be installed by 5PM. The marketing employee immediately downloads and installs the patch and obtains an assertion that the patches are now installed. At 5PM the enterprise performs another re-assessment of all impacted Endpoints to determine if they are now in compliance. The marketing employee's laptop is re-assessed and presents the assertion that it has the patches installed and thus is allowed to remain on the network. 6.2.2.2 Possible Flows and Protocol Usage The following describes the Message flows through the NEA Reference Model for the above example: Sangster, et. al. Expires Sept 2007 [Page 31] Internet Draft NEA Requirements Mar 2007 1. Marketing employee joins network and completes an initial Assessment resulting in a compliant decision. 2. The Enterprise Administrator configures an OS Patch policy for indicating that recent patches are required on all Endpoints by 5PM to prevent serious vulnerabilities. 3. The NEA Server's OS Patch Posture Validator become aware of this policy change and creates a PA Message containing a Request Attributes for information about OS patches in use and triggers the Posture Broker Server to initiate a Posture Re-Assessment of all Endpoints connected to the network. 4. The Posture Broker creates a PB Message that includes the PA Message that contains the set of Request Attribute(s) that are related to OS patch versions. 5. The Posture Broker Server establishes a session with each available NEA Client. The rest of the flow focuses on the exchanges between the NEA Server and one NEA Client; the NEA Server will engage in such a Message Dialog with each available NEA Client. 6. The Posture Broker Server sends the PB Message to the Posture Broker Client. 7. The Posture Transport Server carries the PB Message to the Posture Transport Client over the PT protocol. 8. The Posture Broker Client receives the PB Message and forwards the PA Message to the appropriate Posture Collector responsible for handling OS Patch Request Attribute(s). 9. The OS Patch Posture Collector determines the OS patches present on the Endpoint and if authorized by its disclosure policy accumulates the value(s) for each Posture Attribute requested by the Posture Validator. 10. The OS Patch Posture Collector constructs a PA Message and includes the authorized Posture Attributes accumulated about the OS patches. 11. The Posture Collector instructs the Posture Broker Client to respond back to the NEA Server with the PA Message. 12. The Posture Broker Client sends a PB Message that includes the OS Patch PA Message. 13. The Posture Transport Client transports the PB Message to the Posture Transport Server where it is passed to the Posture Broker Server. 14. The Posture Broker Server receives the PB Message and delivers the PA Message to the OS Patch Posture Validator. 15. The OS Patch Posture Validator extracts the Posture Attribute(s) from the PA Message and uses the values to determine whether the Endpoint is compliant with the new policy. The Posture Validator determines that the Endpoint is not compliant since it does not have the new OS patches installed. 16. The Posture Validator generates a PA Message that includes a Result Attribute with the Posture Assessment Decision set to Sangster, et. al. Expires Sept 2007 [Page 32] Internet Draft NEA Requirements Mar 2007 non-compliant and appropriate Remediation Attributes to enable the Endpoint to download the required OS patches. 17. The Posture Validator communicates the Posture Assessment Result to the Posture Broker Server and instructs the Posture Broker to respond back to the NEA Client with the Posture Attribute Message. 18. The Posture Broker Server generates a Global Posture Assessment Decision and sends a PB Message with the Result Attribute and Posture Attribute Message. 19. The Posture Transport Server transports the PB Message to the Posture Transport Client where it is passed to the Posture Broker Client. 20. The Posture Broker Client processes the Result Attribute received from the NEA Server and displays the non-compliance Messages to the User. 21. The Posture Broker Client forwards the PA Message to the OS Patch Posture Collector; the Posture Collector guides the User with instructions on how to become compliant that includes downloading the appropriate OS patches to prevent the vulnerability. 22. The marketing employee installs the required patches and how is in compliance. 23. The NEA Client triggers a re-assessment of the OS Patches which causes a repeat of many of the steps above. This time step 15 determines the marketing employee's laptop is compliant and returns re-usable (signed and dated) Assertion Attributes in the PA Message instead of Remediation Attributes as before. 24. This time when the OS Patch Posture Collector receives the PA Message that contains Assertion Attributes which is caches for future use. 25. Later at 5PM, the NEA Server triggers a Re-assessment to determine compliance to the patch advisory. When the OS Patch Posture Collector receives the Request Attributes (like in step 9-10 above) it will return Assertion Attributes (instead of Posture Attributes) to indicate that the patches have been installed instead of engaging in the entire assessment process. 26. When the OS Patch Posture Validator receives the PA Message containing the Assertion Attributes it is able to determine that they are authentic and returns a Posture Assessment Decision of compliant thus allowing the laptop to remain on the network. 6.2.2.3 Impact on Requirements The following are several different aspects of the use case example that potentially need to be factored into the requirements. o Server initiated re-assessment required due to urgent patch availability Sangster, et. al. Expires Sept 2007 [Page 33] Internet Draft NEA Requirements Mar 2007 o NEA Client submits Assertion Attributes instead of Posture that patch is installed o NEA Server capable of recognizing Assertion Attributes are sufficient instead of Posture Attributes 7. Requirements This section describes the requirements that will be used by the NEA WG to assess and compare candidate protocols for PA, PB and PT. These requirements frequently express features that a candidate protocol must be capable of offering so that a Deployer can decide to make use of that feature. This section does not state requirements about what features of each protocol must be used during a deployment. For example, a requirement may exist for cryptographic security protections to be available from each protocol but this does not require that a Deployer make use of all or even any of them should they deem their environment to offer other protections which are sufficient. 7.1 Common Protocol Requirements The following are the common requirements that apply to the PA, PB and PT protocols in NEA conceptual architecture: C-1 NEA protocols MUST be capable of performing a multiple Message Dialog between the NEA Client and NEA Server. This allows for Assessment models that require more than one round trip to complete the Assessment. This also allows for updates to already reported Posture information. These updates allow for detection of recent changes in the Endpoint state (e.g. possibly due to a remediation). C-2 NEA protocols MUST allow Posture Assessment to occur before or after the Endpoint has established network connectivity. The support for both time periods will facilitate multiple deployment models including those that leverage the network access technology to restrict access based on Posture. Should the WG select a protocol used only during one time period, this requirement would cause the selection of an additional protocol with coverage of the other time period. Sangster, et. al. Expires Sept 2007 [Page 34] Internet Draft NEA Requirements Mar 2007 C-3 NEA protocols MUST provide a way for both the NEA Client and the NEA Server to initiate a Posture re-assessment request as needed. C-4 NEA protocols MUST provide protection against active and passive attacks by intermediaries including protection to prevent replay based attacks. C-5 The PA and PB protocols defined by NEA MUST be agnostic of the transport i.e. PT protocol. For example, the PB protocol must provide a transport independent interface allowing the PA protocol to operate without change across a variety of network protocol environments (e.g. EAP/802.1X, PANA, and IKE/IPsec). C-6 The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones. The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist. C-7 NEA protocols MUST be highly scalable; the protocols MUST support many Posture Collectors on a large number of NEA Clients to be assessed by numerous Posture Validators residing on multiple NEA Servers. C-8 The protocols MUST support efficient transport of a large number of Attributes Messages between the NEA Client and the NEA Server. C-9 The protocols MUST support deployments that have large numbers of compliance policies. C-10 The protocols MUST allow for Assessment modes that can reduce the amount information to be exchanged between the NEA Client and Server to complete an assessment. 7.2 Posture Attribute (PA) Protocol Requirements The Posture Attribute (PA) protocol defines the transport and data model to carry Posture and validation information between a particular Posture Collector associated with the NEA Client and a Sangster, et. al. Expires Sept 2007 [Page 35] Internet Draft NEA Requirements Mar 2007 Posture Validator associated with an NEA Server. The PA protocol carries collections of standard attributes and vendor-specific attributes. The PA protocol itself is carried inside the PB protocol. The following requirements define the desired properties that form the basis for comparison and evaluation of candidate PA protocols. These requirements do not mandate the use of these properties, but merely that the candidate protocols are capable of offering the property if it should be needed. PA-1 The PA protocol MUST support transport of the required (standard) Attributes defined in the data model. PA-2 The PA protocol MUST support the transport of vendor-specific Attributes. PA-3 The PA protocol MUST enable a Posture Validator to request Posture, Compliance Claims, and Assertion Attributes about particular Components on the NEA Client system from its peer Posture Collector. PA-4 The PA protocol MUST enable a Posture Validator to request Posture, Compliance Claims, and Assertion Attributes from its peer Posture Collector on more than one occasion using an existing or new Session. This enables the Posture Validator to reassess the Posture of a particular Component or to request information about additional Component. PA-5 The PA protocol MUST be capable of returning Results and Remediation Attributes from the Posture Validator. This enables the Posture Collector to learn the specific reason for a failed Assessment and to aid in remediation and notification of the system owner. PA-6 The PA protocol SHOULD support expression of standard Attributes to describe remediation state of Components, for example, last update time or remediation server used. These Attributes are used after remediation so that a Posture Validator can synchronize with a Posture Collector and continue remediation. Sangster, et. al. Expires Sept 2007 [Page 36] Internet Draft NEA Requirements Mar 2007 PA-7 The PA protocol MUST support authentication, integrity, and confidentiality of Attributes, results, and remediation instructions sent between a Posture Collector and Posture Validator. This enables end-to-end security across an NEA deployment that might involve traversal of several systems. PA-8 The PA protocol MUST be capable of carrying attributes that contain binary data including encrypted content. PA-9 String Attributes MUST support being encoded with an encoding standard that supports internationalization. 7.3 Posture Broker (PB) Protocol Requirements The PB protocol supports multiplexing of Posture Attribute Messages (based on PA protocol) from multiple Posture Collectors associated with a NEA Client and transmitting them to an NEA Server, where they can be de-multiplexed to potentially multiple corresponding Posture Validators. The PB protocol carries the global decision made by the Posture Broker Server, taking into account the results of the Posture Validators involved in the Assessment, to the Posture Broker Client. The PB protocol also aggregates and transports advisories and notifications such as remediation instructions and patch references from one or more Posture Validators. The requirements for the PB protocol are: PB-1 The PB protocol MUST be capable of carrying the Result Attributes and, if appropriate, the Remediation Attributes from the Posture Broker Server to the Posture Broker Client. PB-2 The PB protocol MUST carry identifiers that are used by the Posture Brokers to route (deliver) Messages between peer Posture Collectors and Posture Validators. Such Message routing should facilitate dynamic (de)registration of Posture Collectors and Validators to the NEA service. For example, a dynamically registered Anti-Virus Posture Validator should be able to subscribe to receive Messages from its respective Anti-Virus Posture Collector on NEA Clients. Sangster, et. al. Expires Sept 2007 [Page 37] Internet Draft NEA Requirements Mar 2007 PB-3 The PB protocol MUST support creation and management of a Session that can carry a Message Dialog between one or more Posture Collectors and Posture Validators. This allows each party to send multiple Messages before the dialog is complete. PB-4 The PB protocol SHOULD support authentication, integrity and confidentiality protection for the Attribute Messages it carries between an NEA Client and Server. This provides security protection for a Message Dialog of the groupings of Attribute Messages exchanged between the NEA Client and Server. Such protection is orthogonal to PA protections (which are end to end) and allow for simpler Posture Collector and Validators be implemented, and for consolidation of cryptographic operations possibly improving scalability and manageability. PB-5 The PB protocol MUST support grouping of Attribute Messages to optimize transport of Messages and minimize round trips. 7.4 Posture Transport (PT) Protocol Requirements The Posture Transport (PT) protocol carries PB protocol Messages between the Posture Transport Client and the Posture Transport Server. PT is responsible for providing a protected transport for the PB protocol. The PT protocol may itself be transported by one or more concatenated sessions using lower layer protocols, such as 802.1X, RADIUS, TLS, or IKE. This section defines the requirements that candidate PT protocols must be capable of supporting. PT-1 The PT protocol SHOULD incur low overhead to accommodate us on low bandwidth links PT-2 The PT protocol SHOULD be capable of supporting a half-duplex communication environment. PT-3 The PT protocol MUST NOT attempt to interpret the contents of PB Messages being transported, i.e., the data it is carrying must be opaque to it. PT-4 The PT protocol MUST be capable of protecting the integrity and confidentiality of the PB Messages between the Posture Sangster, et. al. Expires Sept 2007 [Page 38] Internet Draft NEA Requirements Mar 2007 Transport Client and the Posture Transport Server. This includes protection against replay and reflection. PT-5 The PT protocol MUST provide reliable delivery for the PB protocol. This includes the ability to perform fragmentation, reassembly, and detect duplicates and reorder to provide in- sequence delivery, as required. PT-6 The PT protocol MUST be capable of supporting mutual authentication between the Posture Transport Client and the Posture Transport Server. This MAY occur by leveraging by- products (e.g., keys) supplied by the PB protocol authentication. PT-7 The PT protocol MUST support establishing a restricted Session between the Posture Transport client and the Posture Transport server prior to the NEA Client being granted unrestricted network access. PT-8 The PT protocol MUST allow either the Posture Transport Client or the Posture Transport Server to initiate a restricted session for use by NEA when both parties have necessary network addresses established. 8. Security Considerations This document defines the functional requirements for the PA, PB and PT protocols used for Network Endpoint Assessment. As such, it does not define a specific protocol stack or set of technologies, so this section will highlight security issues that may apply to NEA in general or to particular aspects of the reference model's components. 8.1 Trust Network Endpoint Assessment involves assessing the Posture of Endpoints entering or already on the network against compliance policies to assure they are adequately protected. Therefore, there is an implied distrusting of Endpoints until there is reason to believe (based on Posture information) that they are well protected and can be trusted to not infect/attack other Endpoints. On the network provider side, the NEA Client normally is expected to trust the network infrastructure systems not to misuse any disclosed Posture information (see section 9) and any remediation instructions necessary to join the network. The NEA Client normally needs to trust that the NEA Server will only request information required to determine whether the Endpoint is safe to access the network assets. Sangster, et. al. Expires Sept 2007 [Page 39] Internet Draft NEA Requirements Mar 2007 In between the NEA Client and Server exists a network that is not assumed to be trustworthy. Therefore, little about the network is implicitly trusted beyond its willingness and ability to transport the exchanged Messages in a timely manner. The amount of trust given to each of these parties is deployment specific. The NEA Reference Model intends to provide security mechanisms to reduce the amount of trust that must be assumed by a Deployer. The following sections will discuss each area in more detail. 8.1.1 Endpoint Components For NEA to properly operate, the Endpoint needs to be trusted to accurately represent the requested security Posture of the Endpoint to the NEA Server. By NEA WG charter, the NEA Reference Model does not explicitly specify how to detect or prevent lying endpoints that intentionally misrepresent their Posture. Similarly, the detection of malware (e.g. root kits) that are able to trick the Posture Collectors into returning incorrect information is the subject for research and standardization outside the IETF (e.g. Trusted Computing Group) and is not specifically addressed by the model. However, if such mechanisms do come into existence, the NEA Reference Model should be able to accommodate these technologies by allowing them to communicate over PA to Posture Validators or work orthogonally to protect the NEA Components from attack and assure the ability of Posture Collectors to view the actual Posture. Besides having to trust the integrity of the NEA Components and their ability to properly collect and report Posture Attributes about the Endpoint, we try to limit other assumed trust. Most of the usage models for NEA expect the Posture information to be sent to the NEA Server for evaluation and decision making. However, one approach assumes more trust in the Endpoint. This approach allows for the NEA Client to receive compliance policies in Policy Attributes and perform the comparison of the current Posture to the policies and make a claim of compliance in Compliance Claim Attributes to the NEA Server instead of providing the Posture Attributes themselves. In this case, the NEA Server must trust the Endpoint's policy storage, comparison and reporting mechanisms to not falsify the results of the Posture evaluation. Generally the Endpoint should not trust network communications (e.g. inbound connection requests) unless it has been specifically authorized by the User or Owner defined policy. The NEA Reference Model assumes all the NEA Client components are local to the Endpoint and communicate over local API or program calls. Unsolicited communications originating from the network should be inspected by normal security protective mechanisms (e.g. firewalls, security protocols, IDS/IPS, etc). Communications associated with Sangster, et. al. Expires Sept 2007 [Page 40] Internet Draft NEA Requirements Mar 2007 the NEA Assessment or re-assessment requires some level of trust particularly when initiated by the NEA Server (re-assessment). The degree of trust can be limited by use of strong security protections on the Messages as dictated by the network Deployer and the Endpoint User/Owner policy. 8.1.2 Network Communications Between the NEA Client and Server there may exist a variety of types of devices to facilitate the communication path. Some of the devices may serve as intermediaries (e.g. simple L2 switches) so may have the opportunity to observe and change the Message Dialogs. The intermediary devices may fall into a few major categories which impact our degree of trust in their operation. First, some intermediary devices may act as Message forwarders or carriers for PT (e.g. L2 switches, L3 routers, or alike). For these devices we trust them not to drop the Messages or actively DOS the NEA deployment. Second, some intermediary devices may be part of the access control layer of the network and as such we trust them to enforce policies including remediation isolation and access controls given to them by the NEA Server. These devices may also fill other types of roles described in this section. Third, some devices may act as a termination point or proxy for the PT carrier protocol. Frequently, it's expected that the carrier protocol for PT will terminate on the NEA Client and Server so will be co-resident with the PT endpoints. If this expectation is not present in a deployment, we must trust the termination device to accurately proxy the PT Messages without alteration into the next carrier protocol (e.g. if inner EAP method Messages are transitioned from an EAP [EAP] tunnel to a RADIUS [RADIUS] session). Fourth, many networks include infrastructure such as IDS/IPS devices which monitor and take corrective action when suspicious behavior is observed on the network. These devices may have a relationship with the NEA Server which is not within scope for this specification. Devices trusted by the NEA Server to provide security information that might affect the NEA Server's decisions are trusted to operate properly and not cause the NEA Server to make incorrect decisions. Finally, other types of intermediary devices may exist on the network between the NEA Client and Server which are present to service other network functions beside NEA. These devices might be capable of passively eavesdropping on the network archiving Sangster, et. al. Expires Sept 2007 [Page 41] Internet Draft NEA Requirements Mar 2007 information for future purposes (e.g. replay or privacy invasion) or more actively attacking the NEA protocols. Because these devices do not play a role in facilitating NEA, it's essential that NEA Deployers not be forced to trust them for NEA to reliably operate. Therefore, it is required that NEA protocols offer security protections to assure these devices can't steal, alter, spoof or otherwise damage the reliability of the Message Dialogs. 8.1.3 NEA Server Components The NEA Server components including systems providing (remote) Posture Validation are generally trusted to enforce the specified Assessment policies and are protected from compromise. It's essential that NEA Server deployments properly safeguard these systems from a variety of attacks from the network and Endpoints to assure their proper operation. While we need to trust the NEA Server operation to some degree, rigorous security architecture, analysis, monitoring and review should assure their network footprint and internal workings are protected from attack. The network footprint would include communications over the network which might be subject to attack such as policy provisioning from the policy authoring systems and general security and system management protocols. Some examples of internal workings include protections from malware attacking the intra-NEA Component communications, Component inner workings or policy stores particularly those that would change the resulting decisions or enforcements. The NEA Server needs to trust the underlying carrier protocols to properly behave and safeguard the exchanged Messages with the Endpoint. The NEA Reference Model does not attempt to address integrity protection of the operating system or other software supporting the NEA Server. One interesting example combines aspects of both areas, where each of the NEA Server Components physically reside in different systems. This might occur when a Posture Validator (or a remote backend server used by a local Posture Validator) exists on another system from the Posture Broker Server. Similarly, the Posture Broker Server might exist on a separate system from the Posture Transport Server. When there is a physical separation, the communications between the NEA Server components must ensure that the PB Session and PA Message Dialogs are resistant to active and passive attacks, in particular, guarded against eavesdropping, forgery and replay. 8.2 Protection Mechanisms at Multiple Layers Sangster, et. al. Expires Sept 2007 [Page 42] Internet Draft NEA Requirements Mar 2007 Inherent in the requirements is a desire for NEA candidate protocols throughout the Reference Model to be capable of providing strong security mechanisms as dictated by the particular deployment. In some cases, these mechanisms may appear to provide overlapping or redundant protections. These apparent overlaps may be used in combination to offer a defense in depth approach to security. However because of the layering of the protocols each set of protections offers slightly different benefits and levels of granularity. For example, a Deployer may wish to encrypt traffic at the PT layer to protect against some forms of traffic analysis or interception by an eavesdropper. Additionally, the Deployer may also selectively encrypt some set of Posture Attributes to achieve end to end confidentiality to its peer Posture Validator. In particular, this might be desired when the Posture Validator is not co-located with the PT Server so the information will traverse additional network segments after the PT protections have been enforced. Different use cases and environments for the NEA technologies will likely influence the selection of the strength and security mechanisms employed during an Assessment. The goal of the NEA requirements is to encourage the selection of technologies and protocols that are capable of enforcing the necessary protections for a wide variety of types of Assessment. 8.3 Relevant Classes of Attack A variety of attacks are possible against the NEA protocols and Assessment technologies. This section does not include a full security analysis, but wishes to highlight a few attacks that influenced the requirement definition and should be considered by Deployers selecting use of protective mechanisms within the NEA Reference Model. As discussed, there are a variety of protective mechanisms included in the requirements for candidate NEA protocols. Different use cases and environments may cause Deployers to decide not to use some of these mechanisms; however this should be done with an understanding that the deployment may become vulnerable to some classes of attack. As always a balance of risk vs. performance, usability, manageability and other factors should be taken into account. The following types of attacks are applicable to network protocols defined in the Reference Model and thus should be considered by Deployers. Sangster, et. al. Expires Sept 2007 [Page 43] Internet Draft NEA Requirements Mar 2007 8.3.1 Man-in-the-Middle (MITM) MITM attacks against a network protocol exist when a third party can insert itself between two communicating entities without detection and gain benefit from involvement in their Message Dialog. For example, a malware infested system might wish to join the network replaying Posture observed from a clean Endpoint entering the network. This might occur by the system inserting itself into and actively proxying an Assessment Message Dialog. The impact of the damage caused by the MITM can be limited or prevented by selection of appropriate protocol protective mechanisms. For example, the requirement for PT to be capable of supporting mutual authentication prior to any Endpoint Assessment Message Dialogs prevents the attacker from inserting themselves as an active participant (proxy) within the communications without detection (assuming attacker lacks credentials convincing either party it is legitimate). Re-usable credentials should not be exposed on the network to assure the MITM doesn't have a way to impersonate either party. The PT requirement for confidentiality protected (encrypted) communications linked to the above authentication prevent a passive MITM from eavesdropping by observing the Message Dialog and keeping a record of the conformant Posture values for future use. The PT requirement for replay prevention stops the passive MITM from later establishing a new Session (or hijacking an existing Session) and replaying previously observed Message Dialogs. 8.3.2 Message Modification Without Message integrity protection, an attacker capable of interception of a Message might be capable of modifying its contents and causing an incorrect decision to be made. For example, the attacker might change the Posture Attributes to always reflect incorrect values and thus prevent a compliant system from joining the network. Unless the NEA Server could detect this change, the attacker could prevent admission to large numbers of clean systems. Conversely, the attacker could allow malware infested machine to be admitted by changing the sent Posture Attributes to reflect compliant values, thus hiding the malware from the Posture Validator. In order to protect against such attacks, the PT includes a requirement for strong integrity protection (e.g. including a protected hash like an HMAC [HMAC] of the Message) so this change would be detected. PA includes a similar requirement to enable end to end integrity protection of the Attributes extending the protection all the way to the Posture Validator even if it existed on another system behind the NEA Server. Sangster, et. al. Expires Sept 2007 [Page 44] Internet Draft NEA Requirements Mar 2007 It is important that integrity protection schemes leverage fresh secret information (not known by the attacker) that is bound to the authenticated Session such as an HMAC using a derived fresh secret associated with the Session. Inclusion of freshness information allows the parties to protect against some forms of Message replay attacks using secret information from prior Sessions. 8.3.3 Message Replay or Attribute Theft An attacker might listen to the network recording Message Dialogs or Attributes from a compliant Endpoint for later re-use to the same NEA Server or just to build an inventory of software running on other systems watching for known vulnerabilities. The NEA Server needs to be capable of detecting the replay of Posture and/or the model must assure that the eavesdropper can not obtain the information in the first place. The cryptographic protection from disclosure of the PT, PB or PA Messages prevents the passive listener from observing the exchanged Messages and thus prevents theft of the information for future use. However an active attacker might be able to replay the encrypted Message if there is no strong link to the originating party or session. By linking the encrypted Message Dialog to the authentication event and leveraging per-transaction freshness and keying exchanges, this prevents a replay of the encrypted transaction. 8.3.4 Other Types of Attack This section doesn't claim to present an exhaustive list of attacks against the NEA Reference Model. Several types of attack will become easier to understand and analyze once the NEA WG has created specifications describing the specific selected technologies and protocols to be used within NEA. One such area is Denial of Service (DoS). At this point in time it's not practical to try to define the all of the potential exposures present within the NEA protocols, so such an analysis should be included in the Security Considerations sections of the selected NEA protocols. However, it's important that the NEA Server be resilient to DoS attacks as an outage might affect large numbers of Endpoints wishing to join or remain on the network. The NEA Reference Model expects that the underlying carrier protocols would have some amount of DoS resilience and that the NEA protocols would need to build upon that base with their own protections. To help narrow the window of attack by unauthenticated parties, it is envisioned that NEA Servers would employ carrier protocols that enable an early authentication of the requesting Endpoint as one technique Sangster, et. al. Expires Sept 2007 [Page 45] Internet Draft NEA Requirements Mar 2007 for filtering out attacks. The PT protocol also requires support of a mutual authentication that can be used in addition to (or in lieu of) the carrier authentication to limit the window of unauthenticated attack against the Posture assessment. Attacks occurring after the authentication would at least come from sources possessing valid credentials and could potentially be held accountable. Similarly, NEA protocols should offer strong replay protection to prevent DoS based attacks based on replayed Sessions and Messages. Posture assessment should be strongly linked with the carrier and/or Posture Transport authentications that occurred to assure the Posture came from the authenticated party. Cryptographic mechanisms and other potentially resource intensive operations should be used sparingly until the validity of the request can be established. This and other resource/protocol based attacks can be evaluated once the NEA technologies and their cryptographic use have been selected. 9. Privacy Considerations While there are a number of beneficial uses of the NEA technology for organizations that own and operate networks offering services to similarly owned Endpoints, these same technologies might enhance the potential for abuse and invasion of personal privacy if misused. This section will discuss a few of the potential privacy concerns raised by the deployment of this technology and offer some guidance to implementers. The NEA technology enables greater visibility into the configuration of an Endpoint from the network. Such transparency enables the network to take into consideration the strength of the Endpoint's security mechanisms when making access control decisions to network resources. However this transparency could also be used to enforce restrictive policies to the detriment of the User by limiting their choice of software or prying into past or present uses of the Endpoint. The scope of the NEA WG was limited to specify protocols targeting the use cases where the Endpoints and network are owned by the same party or a clear expectation of disclosure/compliance has been established with the network owner. This is a familiar model for governments, institutions and a wide variety of enterprises that provide Endpoints to their employees to perform their jobs. In many of these situations, the Endpoint is purchased and owned by the Sangster, et. al. Expires Sept 2007 [Page 46] Internet Draft NEA Requirements Mar 2007 enterprise and they often reserve the right to audit and possibly dictate the allowable uses of the device. The NEA technologies allow them to automate the inspection of the contents of an Endpoint and this information may be linked to the access control mechanisms on the network to limit their use should they not meet minimal compliance levels. In these environments, the level of personal privacy the employee enjoys may be significantly reduced subject to local laws and customs. However, in situations where the Endpoint is owned by the User or where local laws protect the rights of the User even when using Endpoints owned by another party, it's critical that the NEA implementation enable the User to control what Endpoint information is shared with the network. Such controls imposed by the User might prevent or limit their ability to access certain networks or protected resources, but this must be a User choice. 9.1 Implementer Considerations The NEA WG is not defining NEA Client policy content standards nor defining requirements on aspects of an implementation outside of the network protocols, however the following guidance is provided to encourage privacy friendly implementations for broader use than just the enterprise oriented setting described above. NEA Client implementations are encouraged to offer an opt-in policy to Users prior to sharing their Endpoint's Posture information. The opt-in mechanism should be on a per-User, per- NEA Server basis so each User can control which networks can access any Posture information on their system. For those networks that are allowed to assess the Endpoint, the User should be able to specify granular restrictions on what particular types and specific Attributes Posture Collectors are allowed to disclose. Requests for Attributes that are explicitly not allowed to be shared should result in a User notification and/or log record so the User can assess whether the service is doing something undesirable or whether the User is willing to share this additional information in order to gain access. Some products might consider policy-driven support for prompting the User for Sangster, et. al. Expires Sept 2007 [Page 47] Internet Draft NEA Requirements Mar 2007 authorization with a specific description of the Posture information being requested prior to sending it to the NEA Server. It's envisioned that the Owner of the Endpoint is able to specify disclosure policies that may override or influence the User's policies of the Attributes visible to the network. If the Owner disclosure policy allows for broader Posture availability than the User policy, the implementation should provide a feedback mechanism to the User so they understand the situation and can choose to whether to use the Endpoint in those circumstances. In such a system, it is important that the User's policy authoring interface be easy to understand and clearly articulates the current disclosure policy of the system including any influences from the Owner policy. Users should be able to understand what Posture is available to the network and the general impact of this information being known. In order to minimize the list of restrictions enumerated, use of a conservative default disclosure policy such as "that which is not explicitly authorized for disclosure is not allowed" might make sense to avoid unintentional leakage of information. NEA Server implementations should provide newly subscribing Endpoints with a disclosure statement that clearly states: o What information is required, o How this information will be used/protected, o What local privacy policies are applicable. This information will empower subscribing Users to decide whether the disclosure of this information is acceptable considering local laws and customs. 9.2 Minimizing Attribute Disclosure One important issue in the design of the NEA Reference Model and protocols is enabling Endpoints to disclose minimal information required to establish compliance with network policies. There are several models that could be considered as to how the disclosed Attribute set is established. Each model has benefits Sangster, et. al. Expires Sept 2007 [Page 48] Internet Draft NEA Requirements Mar 2007 and issues and these descriptions are provided to seed discussion as to whether each is feasible and whether a preferred approach will emerge potentially impacting the protocols and general privacy of NEA. These models assume a NEA Client resident on the Endpoint and thus able to access privacy sensitive information. If a Deployer wishes to support Endpoint Assessment without a NEA Client (e.g. basing Posture on network observed behaviors) this could improve the privacy but may limit what information is ascertainable thus impacting flexibility of NEA Server policy. The first model is easy to implement and deploy but has privacy and potentially latency and scalability implications. This approach effectively defaults the local policy to send all known NEA Posture Attributes when an Assessment occurs. While this might simplify deployment, it exposes a lot of information that is potentially not relevant to the security Assessment of the system and may introduce privacy issues. For example, is it really important that the enterprise know whether Firefox is being used on system instead of other browsers during the security Posture Assessment? The second model involves an out-of-band provisioning of the disclosure policy to all Endpoints. This model may involve the enterprise establishing policy that a particular list of Attributes must be provided when a NEA exchange occurs. Endpoint privacy policy may filter this Attribute list, but such changes could cause the Endpoint not to be given network or resource access. This model simplifies the network exchange as the Endpoint always sends the filtered list of Attributes when challenged by a particular network. However this approach requires an out-of-band management protocol to establish and manage the NEA disclosure policies of all system. The third model avoids the need for pre-provisioning of disclosure policy by allowing the NEA Server to specifically request what Attributes are required. This is somewhat analogous to the policy being provisioned during the NEA exchanges so is much easier to manage. This model allows for the NEA Server to iteratively ask for Attributes based on the values of prior Attributes. Note, even in this model the NEA protocols are not expected to be a general purpose query Sangster, et. al. Expires Sept 2007 [Page 49] Internet Draft NEA Requirements Mar 2007 language, but rather allow the NEA Server to request specific Attributes as only the defined Attributes are possible to request. For example, an enterprise might ask about the OS version in the initial Message Dialog and after learning the system is a Linux system, ask for a different/smaller set of Attributes specific to Linux then it would if the Endpoint was a Windows system. It's envisioned that this approach might minimize the set of Attributes sent over the network if the Assessment is of a complex system (such as trying to understand what patches are missing from an OS). In each model, the User could create a set of per-network privacy filter policies enforced by the NEA Client to prevent the disclosure of Attributes felt to be personal in nature or not relevant to a particular network. Such filters would protect the privacy of the User but might result in the User not being allowed access to the desired asset (or network) or being provided limited access. 10. References 10.1 Normative References [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [IPSEC] Kent, S., Seo, K., "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), IETF, March 1997. [RADIUS] Rigney, C., Willens, S., Rubens, A., and Simpson, W., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Sangster, et. al. Expires Sept 2007 [Page 50] Internet Draft NEA Requirements Mar 2007 [TLS] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 10.2 Informative References [CNAC] Cisco, Cisco's Network Admission Control Main Web Site, http://www.cisco.com/go/nac [NAP] Microsoft, NAP Main Web Site, http://www.microsoft.com/nap [TNC] Trusted Computing Group, Trusted Network Connect Main Web Site, https://www.trustedcomputinggroup.org/groups/net work/ Acknowledgments The authors of this draft would like to acknowledge the NEA working group members who have contributed to previous requirements and problem statement drafts that influenced the direction of this specification: Kevin_Amorin, Diana Arroyo, Uri Blumenthal, Alan DeKoK, Steve Hanna, Thomas Hardjono, Ravi Sahita, Mauricio Sanchez, Jeff Six, Susan Thompson, John Vollbrecht, Nancy Winget, Han Yin, Hao Zhou. Authors' Addresses Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 0334 Email: hormuzd.m.khosravi@intel.com Mahalingam Mani Avaya Inc. 1033 McCarthy Blvd. Milpitas, CA 95035 USA Phone: +1 408 321-4840 mmani@avaya.com Kaushik Narayan Sangster, et. al. Expires Sept 2007 [Page 51] Internet Draft NEA Requirements Mar 2007 Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 Phone: +1 408 526-8168 kaushik@cisco.com Paul Sangster Symantec Corporation 6825 Citrine Dr Carlsbad, CA 92009 USA Email: Paul_Sangster@symantec.com Joseph Tardo Nevis Networks 500 N. Bernardo Ave. Mountain View, CA 94043 USA Email: joseph.tardo@nevisnetworks.com Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Sangster, et. al. Expires Sept 2007 [Page 52] Internet Draft NEA Requirements Mar 2007 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Sangster, et. al. Expires Sept 2007 [Page 53]