Network Working Group S. Hanna Internet-Draft Juniper Networks Expires: December 26, 2006 T. Hardjono Signacert Inc S. Thomson Cisco Systems June 24, 2006 Network Endpoint Assessment (NEA) Problem Statement draft-thomson-nea-problem-statement-03.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. This Internet-Draft will expire on December 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Network Endpoint Assessment (NEA) architectures have been implemented in the industry, e.g. [TNC, NAP, NAC], to assess the software or hardware configuration of endpoint devices for the purposes of monitoring compliance of endpoints to an organization's policy for access to the network, and optionally restricting or denying access Hanna, et al. Expires December 26, 2006 [Page 1] Internet-Draft NEA Problem Statement June 2006 until the endpoint has been updated to satisfy the requirements. While these architectures share common components and interfaces to support network endpoint assessment, these components are not interoperable because not all required protocols are standards. This document describes the problem these architectures are intending to address, defines common terminology and concepts, and identifies interfaces that are candidates for standardization. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Hanna, et al. Expires December 26, 2006 [Page 2] Internet-Draft NEA Problem Statement June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7 5.1. Wired LAN access . . . . . . . . . . . . . . . . . . . . . 8 5.2. Wireless LAN Access . . . . . . . . . . . . . . . . . . . 8 5.3. Remote access VPN . . . . . . . . . . . . . . . . . . . . 8 5.4. Gateway Access . . . . . . . . . . . . . . . . . . . . . . 8 6. Components and Protocols . . . . . . . . . . . . . . . . . . . 9 6.1. Mapping to existing architectures . . . . . . . . . . . . 10 6.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2.1. NEA Client . . . . . . . . . . . . . . . . . . . . . . 11 6.2.2. Network enforcement device . . . . . . . . . . . . . . 13 6.2.3. NEA server . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Protocols . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. Posture Attribute Protocol (PA) . . . . . . . . . . . 14 6.3.2. Posture Broker Protocol (PB) . . . . . . . . . . . . 14 6.3.3. Posture Transport Protocol (PT) . . . . . . . . . . . 14 6.3.4. Network Enforcement Protocol (NE) . . . . . . . . . . 15 6.3.5. Posture Validation Protocol (PV) . . . . . . . . . . . 15 7. Scope of Standardization . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Hanna, et al. Expires December 26, 2006 [Page 3] Internet-Draft NEA Problem Statement June 2006 1. Introduction Network Endpoint Assessment (NEA) architectures have been implemented in the industry, e.g. [TNC, NAP, NAC], to assess the "posture" of endpoint devices for the purposes of monitoring compliance of endpoints to an organization's policy on access to the network, and optionally restricting or denying access until the endpoint has been updated to satisfy the requirements. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of software installed and their configurations, e.g. OS name and version, patch levels, and anti-virus signature file version. While these architectures share common components and interfaces to support the collection, reporting and evaluation of posture information, these components are not interoperable because not all required protocols are standards. This document describes the problem these architectures are intending to address, defines common terminology and concepts, and identifies interfaces that are candidates for standardization. Note that this document is not intended to define a new architecture or framework for network endpoint assessment. There are already several existing architectures for this purpose. The network endpoint assessment effort aims only to identify common interfaces that are used in these architectures, and define standard protocols that can be used by the existing architectures to reduce duplication and achieve interoperability. 2. Terminology Endpoint: An endpoint is a host connected to the network. This broad definition includes (but is not limited to) desktop or laptop computers, servers, phones, printers. Posture: Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. NEA client: The NEA client is a set of software components on the endpoint that request access to the network. The NEA client comprises three logical components: Posture collector, Posture broker client and Network access requestor. Hanna, et al. Expires December 26, 2006 [Page 4] Internet-Draft NEA Problem Statement June 2006 Posture collector: A Posture collector is the component of the NEA client that is responsible for collecting and maintaining posture information about the endpoint device. There may be multiple NEA Posture collectors on an endpoint device each targeted at a particular security application from a particular vendor. Posture broker client: A Posture broker client is the component of the NEA client that aggregates posture information from multiple Posture collectors. Network access requestor: The Network access requestor is the component of the NEA client responsible for requesting access to the network. Network enforcement device: The Network enforcement device is a network component that controls endpoint access to the upstream network. It enforces network authorization decisions from the network access authority. NEA server: The NEA server is a server that evaluates the posture of an endpoint device and provides network authorization decisions. The NEA server comprises three logical components: Posture validator, Posture broker server and Network access authority. Posture validator: A Posture validator is the logical component of the NEA server that assesses posture information from a Posture collector and determines the result of the assessment. There may be multiple Posture validators each targeted at a particular security application from a particular vendor. Posture broker server: A Posture broker server is the component of the NEA server that aggregates posture information from multiple posture servers. Network access authority: The Network access authority is the component of the NEA server that authorizes endpoints based on a number of criteria including the identity of an endpoint machine and/or user as well as the results of posture assessment. 3. Problem Statement NEA technology may be used for several purposes. One use is to facilitate endpoint compliance to an organization's security policy when endpoints connect 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 protection systems, personal firewalls, and patch Hanna, et al. Expires December 26, 2006 [Page 5] Internet-Draft NEA Problem Statement June 2006 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, 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 accesses the network and while connected, providing an opportunity to monitor compliance of all endpoints in a timely fashion, and facilitate endpoint upgrade where needed. The decision for how to handle non-compliant endpoints is up to the network administrator. Remediation instructions or warnings may be sent to the endpoint. Also, network access may be restricted (or denied completely) so that vulnerabilities can be addressed before a host is exposed to attack. Another use of NEA technology may be to supplement information in inventory databases. In organizations that attempt to keep track of their assets, inventory databases tend to be incomplete and out-of- date. NEA technology may be used to verify or supplement information stored about an organization's assets. An NEA system is intended to benefit endpoints that report accurate posture information in an effort to make them less vulnerable to compromised endpoints on the network . Handling compromised endpoints that report inaccurate posture information is out of scope. NEA architectures have been developed 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 or SSL VPN, or gateway access. Across all these architectures, there are a set of NEA-specific components and interfaces that are common. In particular, a NEA client on the endpoint contains components that collect and report posture information, and a NEA server contains components that validates posture and provides the result. Interoperability is needed between these client and server components. In addition, a protocol is needed to transport the encoded posture information between a NEA client and NEA server at the time of network access and while an endpoint is connected to the network. Many NEA architectures extend existing standards used in network access control, such as the EAP framework, to enable posture assessment to be done at the time of network admission, and also to allow endpoint authentication and posture assessment to be done at the same time. Posture assessment rules may depend on endpoint identity e.g. different assessment rules may be applied depending on Hanna, et al. Expires December 26, 2006 [Page 6] Internet-Draft NEA Problem Statement June 2006 whether a user is an employee or guest, and both the authentication and posture result (along with other criteria) may determine the level of network access received. To enable interoperability, requirements for protocols to transport posture information need to be specified. Note that, to the extent these transport protocols are not specific to NEA, and need to satisfy a broader range of requirements than just posture transport, it is likely that any needed standardization of such protocols would fall outside the NEA scope. 4. Goals The goals of architectures that support network assessment technology include some or all of the following: o Support assessment of endpoints across a range of network access technologies, leveraging existing technology to the extent possible o Support authorization decisions based on authentication of user or endpoint device, assessment of the state of the endpoint device, and other criteria o Support endpoint assessment at various locations in the network i.e. at a L2 hop or a L3 hop, both of which may be a single hop or multiple hops away from the endpoint. o Support endpoint assessment at possibly multiple hops on a path e.g. at both a L2 and a L3 hop o Support network isolation of non-compliant endpoints from compliant endpoints for remediation or other purposes o Support endpoint re-assessment when state of endpoints change, or rules in the NEA server change o Enable integration of 3rd-party security applications so that one or more applications can assess the posture of an endpoint and the aggregate of all results can be used in network admission decisions. 5. Deployment Scenarios Deployment scenarios for NEA include the following (not necessarily limited to these): Hanna, et al. Expires December 26, 2006 [Page 7] Internet-Draft NEA Problem Statement June 2006 5.1. Wired LAN access In this deployment scenario, network admission control would typically take place at the first L2 hop from the endpoint i.e. a switch port. However, there are cases where the first L2 device may not support network endpoint assessment for some reason, and network endpoint assessment may happen behind the first hop, e.g. a switch behind a wireless access point. Wired LAN access deployment scenarios may need to support single or multiple hosts per switch port. Deployment scenarios with multiple hosts per port include IP phones + PC, or multiple PCs connected behind a hub. 802.1X is an example of a standards-based network access technology that supports access control based on authentication for a single host per port in first L2 hop deployment scenarios. 5.2. Wireless LAN Access In this deployment scenario, network admission control would typically take place at the first L2 hop from the endpoint i.e. a wireless access point. Wireless LAN access supports multiple hosts per wireless access point. 802.1i is a standards-based network access technology that supports wireless access control based on authenticating the endpoint. 5.3. Remote access VPN In this deployment scenario, network admission control is done at the VPN concentrator that acts as the gateway between remote users and access to the enterprise network. IPSEC VPN and SSL VPN are example of network access technologies that support remote access VPN deployment scenarios. 5.4. Gateway Access In this deployment scenario, network admission control is enforced at a L3 boundary in a distributed campus network. The L3 boundary may be one or more L3 hops away from the endpoint. This deployment scenario may be used during the transition period while an organization gradually upgrades network equipment to support network endpoint assessment. In some cases, the technology may not be available immediately for first-hop L2 or L3 deployments and a general-purpose gateway deployment e.g. at a router behind a VPN Hanna, et al. Expires December 26, 2006 [Page 8] Internet-Draft NEA Problem Statement June 2006 concentrator, may be a reasonable first step. This deployment scenario may also be used between network security domains e.g. at the border between a less trusted/managed branch office and main campus, at the border between main campus or a visitor site and access to the Internet, at the border between extranet and intranet, and on access to protected servers in a data center. It follows from this deployment scenario that there may be multiple Network enforcement devices on any path that an endpoint may use in a network, thus resulting in it being authorized more than once. It is also possible that different posture rules may be assessed at different network locations and a different authorization decision made. 6. Components and Protocols This section provides a high-level overview of a general NEA architecture, describing the components and the interfaces. This architecture is generic in that it is independent of the underlying posture transport in use. In addition, this section also describes a particular instantiation of the architecture based on an EAP transport, to support deployments that use EAP for both authentication and posture assessment. (Note: This is not intended to preclude the usage of non-EAP posture transports.) Figure 1 shows the components of a general NEA system and identifies specific interfaces. Hanna, et al. Expires December 26, 2006 [Page 9] Internet-Draft NEA Problem Statement June 2006 |-------------| |----------------| | Posture | <---------PA--------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | | | PV | | |-------------| |----------------| | Posture | | Posture | | Broker | <--------PB---------> | Broker | | Client | | Server | |--------- ---| |----------------| | | | | |-------------| <--------PT--------> |----------------| | | |-----------| | | | Network | |Network | | Network | | Access |----|Enforcement|---------| Access | | Requestor | |Device | <-NE-> | Authority | |-------------| |-----------| |----------------| NEA CLIENT NEA SERVER Figure 1: NEA Components and Interfaces 6.1. Mapping to existing architectures For convenience, we map the terms used in this document with that of three architectures developed in the industry : Trusted Network Connect (TNC) architecture [TNC], Microsoft's Network Access Protection (NAP) architecture [NAP], and Cisco's Network Admission Control (NAC) architecture [NAC]. Hanna, et al. Expires December 26, 2006 [Page 10] Internet-Draft NEA Problem Statement June 2006 Table 1: Terminology used in various architectures NEA TNC NAP NAC Posture Integrity System Posture Collector Measurement Health Plug-in Collector Agent Posture TNC NAP Posture Broker Client Agent Agent Client Network Network NAP Posture Access Access Enforcement Agent Requestor Requestor Client Network Policy NAP Network Enforcement Enforcement Enforcement Access Device Point Server Device Posture Integrity System Posture Validator Measurement Health Validation Verifier Validator Server Posture TNC NAP Access Broker Server Administration Control Server Server Server Network Network Network Access Access Access Policy Control Authority Authority Server Server 6.2. Components 6.2.1. NEA Client The NEA client resides on an endpoint device and comprises the following components: o Posture collector o Posture broker client o Network access requestor Hanna, et al. Expires December 26, 2006 [Page 11] Internet-Draft NEA Problem Statement June 2006 6.2.1.1. Posture Collector The Posture collector is software that provides posture information about the endpoint device to the Posture broker client. There may be many Posture collectors on an endpoint, one per vendor and application type. Examples of Posture collectors include a host Posture collector that provides information about the OS and patch levels, anti-virus Posture collector that provides information about the anti-virus application, firewall Posture collector that provides information about the configuration of the personal firewall. A Posture collector is responsible for: o Receiving and responding to requests for posture information on a per vendor and application type basis o Receiving a notification of the result of the posture assessment and any information that may be needed by the endpoint to remediate itself , e.g. URL of a remediation server o Indicating when the posture of the host has changed 6.2.1.2. Posture broker client The Posture broker client aggregates posture information from multiple Posture collectors. There is one Posture broker client for every Network access requestor on the endpoint device (typically one for all Network access requestors). The Posture broker client is responsible for: o Maintaining a record of Posture collectors o Multiplexing and demultiplexing posture messages between the NEA server and the relevant Posture collectors o Determining from Posture collectors when posture has changed and triggering re-assessment where supported by the underlying transport o Providing user notifications 6.2.1.3. Network access requestor The Network access requestor is responsible for communicating with the NEA server to transport the necessary information to gain access to the network and for subsequent re-assessment. There may be multiple Network access requestors on an endpoint representing different technologies for accessing the network. Hanna, et al. Expires December 26, 2006 [Page 12] Internet-Draft NEA Problem Statement June 2006 6.2.2. Network enforcement device The Network enforcement device is a network component that controls access of endpoints to the upstream network. The Network enforcement device may be a network device or a logical component on an endpoint. The NEA enforcer enforces network authorization decisions from the Network access authority. There are different types of Network enforcement devices supporting different technologies for accessing the network. 6.2.3. NEA server The NEA server comprises the following logical components: o Network access authority o Posture broker server o Posture validator 6.2.3.1. Network access authority The Network access authority is responsible for authorizing endpoints based on a number of criteria including the identity of an endpoint and/or user as well as the results of posture assessment from the Posture broker server. 6.2.3.2. Posture broker server The Posture broker server aggregates posture information from potentially multiple Posture validators into an overall system result, and provides this information to the Network access authority. Responsibilities of the Posture broker server include: o Maintaining a record of Posture validators o Multiplexing and demultiplexing posture messages between the NEA client and the relevant Posture validators o Aggregating posture assessment results from all Posture validators into an overall system result o Triggering posture reassessment where supported 6.2.3.3. Posture validator A Posture validator is a server that is responsible for assessing information from the corresponding Posture collector and determining Hanna, et al. Expires December 26, 2006 [Page 13] Internet-Draft NEA Problem Statement June 2006 the result of the assessment. There may be multiple Posture validators each targeted at a particular security application from a particular vendor. A Posture validator is responsible for the following: o Requesting and receiving posture information from a particular Posture collector o Assessing the endpoint posture and providing a result to the Posture broker server o Sending to the Posture collector information on remediation actions to be taken o Indicating to the Posture broker server when posture reassessment may be needed 6.3. Protocols 6.3.1. Posture Attribute Protocol (PA) PA is a protocol between a Posture collector and the associated Posture validator for the particular vendor and application. The interface is used to pass information gathered by a Posture collector to the Posture validator, and to pass the results of the assessment and information needed for remediation from the Posture validator to the Posture collector. 6.3.2. Posture Broker Protocol (PB) PB is a protocol that carries aggregated posture information between all requested Posture collectors on an endpoint and the corresponding Posture validators. This protocol also carries the overall system posture result from the Posture broker server to the Posture broker client. 6.3.3. Posture Transport Protocol (PT) PT is a protocol (or stack of protocols) between the Network access requestor and the Network access authority that is suitable for carrying the PB protocol at or after network connection. In EAP instantiations of this architecture, the PT interfaces consists of two protocols: 1) Posture Transport Tunnel (PTT), which is an EAP tunneling method between the Network access requestor in the NEA client and the Network access authority in the NEA server that can carry posture information in addition to authentication Hanna, et al. Expires December 26, 2006 [Page 14] Internet-Draft NEA Problem Statement June 2006 information, and 2) Posture Transport Carrier (PTC), a protocol that carries EAP, e.g. EAP over 802.1X, EAP over RADIUS. Please see Figure 2. 6.3.4. Network Enforcement Protocol (NE) NE is the protocol between the Network enforcement device and Network access authority used to carry network authorization decisions between the Network enforcement device and the Network access authority. In EAP Instantiations of this architecture, existing standards for the NE interface include RADIUS and Diameter. 6.3.5. Posture Validation Protocol (PV) The components of the NEA server need not be co-located. The PV protocol between the Posture broker server and Posture validator forwards posture information and returns posture validation results. Hanna, et al. Expires December 26, 2006 [Page 15] Internet-Draft NEA Problem Statement June 2006 |-------------| |----------------| | Posture | <---------PA--------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | | | PV | | |-------------| |----------------| | Posture | | Posture | | Broker | <---------PB--------> | Broker | | Client | | Server | |--------- ---| |----------------| | | | | |-------------| <--------PTT-------> |----------------| | | |------------| | | | Network | |Network | | Network | | Access |------- |Enforcement |----| Access | | Requestor | |Device | | Authority | |-------------| |------------| |----------------| <-PTC-> <-PTC-> <-NE-> NEA CLIENT NEA SERVER Figure 2: EAP instantiation of general NEA architecture 7. Scope of Standardization Protocols that are candidates for standardization in the IETF (not necessarily in a NEA WG) include the following : o Posture attributes protocol (PA): This protocol is specific to NEA and can be defined independently of the underlying transport protocols, while keeping in mind performance and other constraints imposed by the underlying protocols. Many of the posture attributes will be vendor-specific and need only be understood by the corresponding Posture collector and its associated Posture validator. However, there may be common attributes that would benefit from standardization, e.g. commonly needed measurements such as software name, and the result of evaluating posture information from a Posture collector. o Posture broker protocol (PB): This protocol is specific to NEA and also largely independent of the underlying transport, although there are encapsulations that are posture transport-specific. It should be defined in such a way that it can be used in posture Hanna, et al. Expires December 26, 2006 [Page 16] Internet-Draft NEA Problem Statement June 2006 transport protocols that are likely to be used, such as EAP tunneling methods based on TLS. o Posture Transport protocol (PT): This protocol (or stack of protocols) is dependent on the instantiation of the NEA architecture used. In the case of the EAP instantiation, PT consists of PTT and PTC described below. PT is not likely to be specific to NEA since it may be designed to support the transport of information besides posture, such as authentication information. o Posture transport tunnel protocol (PTT): In an EAP instantiation of an NEA architecture, an EAP tunneling method is needed to carry posture information in addition to authentication credentials. Standardization of certain EAP methods for authentication is the proposed charter of the EMU WG. The need to support posture assessment in addition to authentication may place additional requirements on EAP methods. o Posture transport carrier protocol (PTC): Some EAP carrier methods are standards today e.g. 802.1X and RADIUS. Thus, for deployment scenarios that use these protocols, interoperability at this layer exists. However, there is no standard EAP transport to support gateway and other "multi-hop" deployment scenarios as defined in this document. The PANA WG [PANA] has proposed a specification of EAP over a UDP transport, although not explicitly for this use case. Other protocols have been designed and used for this purpose e.g. Network Access control Protocol [NACP]. o Network enforcement protocol (NE): Existing standards exist including RADIUS and Diameter. It is possible that new attributes may need to be defined in the future for certain deployment scenarios. The Radext WG has the charter to standardize new RADIUS attributes. o Posture validator protocol (PV): This protocol can be defined independently of the posture transport used between NEA client and server. There is no existing protocol for this protocol which acts as a carrier for posture attributes between a Posture broker server and a Posture validator that is not co-located in the NEA server. Given the large number of protocols involved a NEA system, it is likely that work will be chartered in stages to achieve interoperability between a NEA client and NEA server. While NEA may take on the task of specifying requirements for all the above protocols, any needed standardization of protocols that make up the PT layer and NE layer might well fall under the (re-)charter of Hanna, et al. Expires December 26, 2006 [Page 17] Internet-Draft NEA Problem Statement June 2006 existing or new WGs, since the protocols needed are not necessarily specific to NEA. The precise initial scope of the NEA effort will be defined as part of the normal WG chartering process. 8. IANA Considerations This document makes no request of IANA. 9. Security Considerations The intent of the protocols in the NEA architecture is to provide the ability to exchange posture-related information securely between the NEA client and NEA server over an untrusted network. The intent of the NEA architecture is not to provide integrity protection for the proper operation of the NEA client itself. In particular, the endpoint may be compromised in such a way that a Posture collector does not report accurate information. NEA does not address such endpoints; it is intended to benefit endpoints that do provide accurate posture measurements for the purpose of helping make such hosts less vulnerable to those endpoints on the network that are compromised. Posture information is considered sensitive information and should not be disclosed to unauthorized parties. To this end, the communications channel between the NEA client and NEA server should support integrity and confidentiality. In addition, the NEA server should be authenticated before the client provides posture information. It is also beneficial to authenticate the endpoint so the origin of the posture information is known and there is accountability. 10. Acknowledgements We acknowledge the contributions from members of the NEA mailing list. 11. Change Log Revision 01 to 02: o Section 7: Omitted specifying proposed initial scope of WG since this is the job of a charter. Replaced with more general text. Hanna, et al. Expires December 26, 2006 [Page 18] Internet-Draft NEA Problem Statement June 2006 o Clarified in Section 2 and 7 NEA-specific components/protocols from transport part of architecture o Updates to reflect Mauricio Sanchez's comments to mailing list 03/ 08/2006 and response 03/13/2006 o Updated figures to have "vertical" line for PV protocol o Editorial updates Revision 02 to 03: o Section 2: Updated terminology: Client broker -> Posture broker client; Server broker -> Posture broker server; Network enforcer -> Network enforcement device; Network access enforcement (NAE) protocol -> Network enforcement protocol (NE) o Section 3: Updated to clarify use case targeted at uncompromised hosts, and scope of NEA standards effort targeted at NEA-specific components and interfaces o Section 9: Updated to clarify scope of security considerations 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [802.1X] IEEE, "Local and Metropolitan Area Networks:Port-based Network Access Control", 2004. [I-D.ietf-pana-pana] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-11 (work in progress), March 2006. [I-D.thomson-nacp] Salowey, J., Thomson, S., Wu, F., Yarlagadda, V., and H. Zhou, "Network Access Control Protocol (NACP)", draft-thomson-nacp-02 (work in progress), March 2006. [NAC] Cisco Systems, "Network Admission Control Technical Overview", 2005. Hanna, et al. Expires December 26, 2006 [Page 19] Internet-Draft NEA Problem Statement June 2006 [NAP] Microsoft Corporation, "Network Access Protection Platform Architecture", February 2006. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [TNC] TCG, "TNC Architecture for Interoperability Specification v1.0", May 2005. Hanna, et al. Expires December 26, 2006 [Page 20] Internet-Draft NEA Problem Statement June 2006 Authors' Addresses Steve Hanna Juniper Networks 35 Forest Ridge Road Concord, MA 01742 U.S.A. Phone: 781-729-9559 Email: shanna@juniper.net Thomas Hardjono Signacert Inc 115 SW Ash Street Suite 430 Portland, OR 97204 U.S.A Phone: 781-729-9559 Email: thardjono@signacert.com Susan Thomson Cisco Systems 499 Thornall Street, 8th floor Edison, NJ 08837 U.S.A. Phone: 732-635-3086 Email: sethomso@cisco.com Hanna, et al. Expires December 26, 2006 [Page 21] Internet-Draft NEA Problem Statement June 2006 Intellectual Property Statement 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. 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hanna, et al. Expires December 26, 2006 [Page 22]