Internet Draft Hormuzd Khosravi, Intel Expires: November 2006 Paul Sangster, Symantec Working Group: NEA May 2006 Requirements for Network Endpoint Access (NEA) draft-khosravi-nea-requirements-00.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 Internet Society (2006). 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 [RFC-2119]. Abstract This document defines the interface requirements between the components of the NEA (Network Endpoint Assessment) conceptual architecture. NEA provides owners of networks (e.g. an enterprise Khosravi, et. al. Expires November 2006 [Page 1] Internet Draft NEA Requirements May 2006 offering remote access) a mechanism to learn the operational state or posture of a system requesting network access and then apply this knowledge to the network admission decision. In this case, operational posture refers to information about the configuration and use of hardware and software capabilities available or running on the system. This 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 conceptual architecture and terminology is introduced. This architecture is provided for informational purposes but is based on the models used by NAC[9], NAP[10] and TNC[8]. Authors The participants in the NEA Requirements Team who were instrumental in the creation of this requirements draft are: Kevin_Amorin, Diana Arroyo, Uri Blumenthal, Steve Hanna, Thomas Hardjono, Hormuzd Khosravi, Ravi Sahita, Mauricio Sanchez, Paul Sangster, Jeff Six, Joseph Tardo, Susan Thompson, John Vollbrecht, Hao Zhou 1. Introduction....................................................2 2. Definitions.....................................................3 3. Architecture and Components.....................................4 4. Common Architectural Requirements...............................4 5. Interface Requirements..........................................5 5.1. Posture Attribute (PA) interface Requirements...................5 5.2. Posture Broker (PB) Interface Requirements......................6 5.3. Posture Transport (PT)Interface Requirements....................8 6. Security Analysis/Requirements..................................9 7. Operational Considerations.....................................10 8. Security Considerations........................................11 8.1. Scope and Overlap..............................................11 8.2. Interesting Attack Classes.....................................12 8.2.1. Man-in-the-Middle (MITM)....................................12 8.2.2. Message Modification........................................13 8.2.3. Message Replay or Theft.....................................13 9. References.....................................................14 9.1. Normative References...........................................14 9.2. Informative References.........................................14 Authors' Addresses & Acknowledgments..............................15 1.Introduction Khosravi, et. al. Expires November 2006 [Page 2] Internet Draft NEA Requirements May 2006 Today, most network providers can leverage existing standards-based technologies to restrict access to the network based upon the requesting system's user or host-based identity, source IP address or physical access point. However these approaches still leave the network prone 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 the ability to preemptively detect systems that are prone or already contain malware potentially dangerous to the network. If a system is determined to be prone to attack by lacking proper defensive mechanisms such as the absence of up to date firewall and anti-virus software, there should be a way to safely repair (remediate) the system so that it can be subsequently trusted to join and operate on the network. The Network Endpoint Assessment (NEA) system is a complementary technology to existing authentication and authorization approaches allowing the network to have visibility into the contents of the system (security posture) requesting access so that its risk profile can be factored into the admission decision. NEA typically involves the use of trusted agents running on the requesting machine which observe and report on the posture of the system to network infrastructure. The infrastructure has equivalent components which are capable of evaluating the posture information and feeding the result to an appropriate network admission decision maker. Finally 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. Architectures, similar to NEA, have been defined in the industry (e.g. TNC, NAP, NAC) to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy on access to the network. These architectures are not interoperable since most of the technologies used to implement the architecture are not standards. The NEA working group is working on defining standard interface 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. 2.Definitions Please refer to [3] for the NEA terminology. Khosravi, et. al. Expires November 2006 [Page 3] Internet Draft NEA Requirements May 2006 3.Architecture and Components The major components of NEA architecture are as follows. |-------------| |----------------| | Posture | <--------PA---------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | | PV | | |-------------| |----------------| | Client | <--------PB---------> | Server | | Broker | | Broker | |--------- ---| |----------------| | | | | |-------------| <--------PT---------> |----------------| | | | | | Network | |--------| | Network | | Access |----|Network |------------| Access | | Requestor | |Enforcer| <---NAE--> | Authority | |-------------| |--------| |----------------| NEA CLIENT NEA SERVER Figure 1: NEA Components and Interfaces 4.Common Architectural Requirements The following are the common architectural requirements across all NEA interfaces/protocols: 1. NEA protocols MUST be capable of performing a multi-round posture exchange between the client (agent) and server. This enables the server to request additional information or updates to the posture data already reported. The updates allow for detection of recent changes in the client state (e.g. possibly due to a remediation.) 2. NEA protocols MUST allow the NEA server to initiate requests for posture information prior to network access and at any time after the client has established an identity on the network (e.g. IP address.) This enables the NEA server to evaluate posture prior to allowing access and to periodically re-validate systems already admitted to the network to assure they are still in compliance with the current policies. 3. NEA protocols MUST provide a way for the NEA client to initiate a posture re-evaluation request as needed. This allows the client to Khosravi, et. al. Expires November 2006 [Page 4] Internet Draft NEA Requirements May 2006 proactively request a posture re-evaluation by the NEA Server after detection of a potentially suspicious event. 4. NEA protocols MUST provide protection against active and passive attacks by intermediaries (e.g. man-in-the-middle.) Such protection might come from a strong (e.g. cryptographic) binding between the authenticated identity of the requesting system and the reported posture information. This protection MUST prevent replay based attacks (preventing a malicious machine from later replaying a healthy posture report.) 5. The PA, PB & PV interfaces defined by NEA MUST be agnostic of the transport i.e. PT interface. For example, the PB protocol must provide a transport (PT) 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.) 6. NEA protocols MUST reuse existing open standards for its interfaces before defining new ones. 7. NEA protocols MUST be highly scalable in terms of adding multiple servers, clients, Posture Collectors, Posture Validators, etc. 5.Interface Requirements 5.1.Posture Attribute (PA) interface Requirements The PA protocol defines the control and data model to carry posture and validation information between a particular Posture Collector associated with a NEA client and a Posture Validator associated with a NEA Server. The Posture Attribute protocol consists of core attributes and vendor defined attributes. The PA protocol will be carried inside the Posture Broker (PB) protocol. 1. The PA protocol MUST support transport of the required (core) attributes defined in the data model to report information received by a Posture Collector. Examples of core attributes include Vendor id, Application version, and Operational status. 2. The PA protocol MUST support the transport of vendor defined attributes. 3. The PA protocol MUST support the transport of core (required) attributes between a Posture Collector and a Posture Validator. Example of such control messages are timestamp, transaction id, reset, (re)start evaluation, validation results and (re)start remediation. Khosravi, et. al. Expires November 2006 [Page 5] Internet Draft NEA Requirements May 2006 4. The PA protocol MAY support control attributes that group sub attributes for a collector, for example, attributes that report health of all sub-components including vendor, application, version, and operational status. 5. The PA protocol MUST use open standards as far as possible for example, structured formats such as XML. 6. The PA protocol SHOULD support expression of core attributes to describe remediation state of components for example, last update time, remediation server used. These attributes are used after remediation so that a Posture Validator can synchronize with a Posture Collector and continue remediation. 7. The PA protocol SHOULD support returning validation and remediation parameters from a Posture Validator to a Posture Collector, for example, remediation server URL. 8. The PA protocol MUST support authentication, integrity and confidentiality of attributes sent between a Posture Collector and Validator. Deployers of Posture Collectors and Posture Validators should use at least authentication and integrity protection for their messages, and may also employ confidentiality protection if necessary for their environment. 9. The PA protocol SHOULD optimize transport of messages and minimize Posture Broker protocol round trips. To achieve this, the PA protocol should support configuration/negotiation of the maximum size and timeout period for interaction of a Posture Collector with a Posture Validator. 5.2.Posture Broker (PB) Interface Requirements The PB protocol supports multiplexing of Posture Attributes (based on PA protocol) from multiple Posture Collectors associated with a NEA client and de-multiplexing these messages to multiple Posture Validators associated with a NEA server. The PB protocol supports multiplexing of posture assessment results from multiple Posture Validators associated with a NEA server and de-multiplexing results to multiple Posture Collectors associated with a NEA client. The PB protocol also aggregates remediation attributes from one or more Posture Validators. 1. The PB protocol SHOULD allow carrying decisions identified as global decisions from the NEA server along with Posture Validator specific information reported by multiple Posture Validators. Khosravi, et. al. Expires November 2006 [Page 6] Internet Draft NEA Requirements May 2006 2. The PB protocol MUST contain information used by the Brokers to route messages between particular types of Posture Collectors and Posture Validators. Such message routing information should support dynamic (de)registration of Posture Collectors and Validators receive appropriate messages. For example, a dynamically registered Anti-Virus Posture Validator should be able subscribe to receive messages from its peer Anti-Virus Posture Collector. 3. The PB protocol MUST support subscription messages on the NEA server so that Posture Validators can receive asynchronous information from Posture Collectors, for example, events or posture attributes. 4. The PB protocol MUST support subscription messages on the NEA client so that Posture Collectors can receive asynchronous information from Posture Validators, for example, validation reports. 5. The PB protocol MUST support multiple rounds of posture collection within a transaction between a Posture Collector and a Posture Validator. 6. The PB protocol MUST support asynchronous pull of posture information from Posture Collectors on an event from a Posture Validators or a NEA server. The NEA server may override the pull request of a Posture Validator. 7. The PB protocol MUST support ranking/priority ordering of Posture Collector reports and Posture Validator reports to resolve conflicts or dependency issues at the NEA client and/or NEA server. 8. The PB protocol MUST support reporting of error codes and sub- codes back to the NEA client, for example, to avoid multiplexing attributes for a misbehaving Posture Collector or to repeat the attributes for a specific Posture Collector only. 9. The PB protocol MUST support authentication, integrity and confidentiality of multiplexed Posture attributes and Validation attributes. Implementers of Posture Brokers should use authentication and integrity of messages, and may support confidentiality of messages. 10. The PB protocol SHOULD support grouping of attributes to optimize transport of messages and minimize round trips. The PB protocol should support configuration/negotiation of the maximum size and timeout period for interaction between a NEA server and client. Khosravi, et. al. Expires November 2006 [Page 7] Internet Draft NEA Requirements May 2006 5.3.Posture Transport (PT) Interface Requirements The PT is the transport protocol between the Network Access Requestor (NAR) in the NEA Client and the Network Access Authority (NAA) within the NEA Server present on the network owner’s infrastructure. PT is responsible for providing a protected transport (frequently using a tunnel) for the PB protocol. The PT protocol may in turn be transported by a lower layer protocol such as: 802.1x, RADIUS, TLS, IKE/IPsec or TCP,UDP/IP. This section defines the requirements which candidate PT protocols must be capable of supporting. The deployer’s policy will dictate how these apply to a particular environment. 1. The PT protocol SHOULD use existing standard based protocols whenever possible. If no standard exists to support the target use cases, NEA WG will request appropriate standards groups develop necessary standard protocols. 2. The PT protocol SHOULD incur low overhead to accommodate for use on low bandwidth links. 3. The PT protocol SHOULD be capable of supporting a half duplex communication environment. 4. The PT protocol MUST NOT attempt to interpret the contents of the PB messages being transported, i.e. the data it is carrying must be opaque to it. 5. The PT protocol MUST be capable of protecting the integrity and confidentiality of the PB messages being transported between the NAR and NAA. 6. The PT protocol MUST provide reliable delivery of PB messages. This includes the ability to perform fragmentation, detect duplicates, and reorder data, if necessary. 7. The PT protocol MUST be capable of supporting mutual authentication of the communicating parties. This MAY occur by initially authenticating the NEA Server and leveraging byproducts (e.g. keys) associated with this authentication to construct a confidential channel where the NEA Client can authenticate. 8. The PT protocol MUST be able to establish a restricted session between the NAR and the NAA prior to the NAR granting general network access. 9. The PT protocol MUST allow the NAR or NAA to initiate the establishment of a restricted session for use by NEA when both parties have necessary network addresses established. Khosravi, et. al. Expires November 2006 [Page 8] Internet Draft NEA Requirements May 2006 6.Security Analysis/Requirements There are several entities that comprise the described NEA conceptual architecture. From security viewpoint, their relations and communications should adhere to the following requirements. End-points must be able to authenticate their peers (i.e. Posture Collector and Posture Validator), for without that no meaningful posture information exchange is possible. 1. PA interface - Posture Validator MUST be able to ascertain that the traffic (posture) it received is "fresh". This freshness prevents a third party from replaying the posture information produced by an earlier Posture Collector use without detection. - It may be necessary (especially in case of multiple exchanges between Posture Collector and Posture Validator) that Posture Collector "recognizes" and trusts the given Posture Validator. This ensures that Posture Collector is doing work on behalf of authentic Posture Validator. 2. PB interface - Communications between Client Broker and Server Broker MAY need to be protected at least from active attacker (integrity, confidentiality, timeliness). Integrity and timeliness are of the utmost importance, to prevent third parties (any parties - including Network Enforcer) from interfering with posture validation and affecting PDP decisions. Confidentiality may be useful here, for example to prevent attackers from determining which host would be the most vulnerable target based on its posture information. However there is privacy concern that the host should be able to "see" what potentially privacy sensitive information about it is being sent out. This concern may prevent encryption from being used or force a pre-screening of the posture information against a privacy policy before allowing it to be sent over the network. 3. PT interface - This communication channel MUST be protected: endpoint mutual authentication with subsequent secure pipe establishment. Otherwise third parties could launch a variety of attacks. 4. PV interface - Communications between Server Broker and Posture Validators SHOULD be protected because the Validators are likely running on different systems on the network. Unless the Server Broker is able to securely determine that each the Posture Validator is authentic and authoritative, validation decisions could be forged and allow bypassing the entire network access policy. Khosravi, et. al. Expires November 2006 [Page 9] Internet Draft NEA Requirements May 2006 5. Interfaces/communications between Posture Collector(s) and Client Broker MAY need protection, especially if those are different software entities. It is important that a Client Broker be allowed to communicate with only the authorized Posture Collectors because of the trust issue. Denial of Service is the most obvious threat here. Forging a posture should not be feasible because of PA interface. 6. Interface/communication between Client Broker and Network Access Requestor MAY need protection. 7. Interface/communication between Server Broker and Network Access Authority MAY be protected. 7.Operational Considerations The NEA technology intends to address a major issue for owners of networks by extending their existing ability to limit admission to the network by inspection of the security posture of the system. In order to offer a solution to this issue, NEA needs to provide a scalable solution addressing a vast majority of the systems deployed while remaining manageable. This introduces several issues which should be considered during the definition of the protocols, interfaces, architecture and their policies. 1. Some network devices (e.g. printers, legacy systems) will not have support for NEA agents present. In this situation, the NEA server must be able to detect that the system requesting access is incapable of responding to NEA protocols and thus will not be able to report its security posture. The NEA architecture should allow for this event to be detected and reported to other components which might be able to evaluate risk via other mechanisms (e.g. using scanning techniques) and report back a suggested action. 2. Admission policy should be capable of being combined with authentication policy so differentiated posture evaluation is possible based on the identity and other factors about the requesting system. For example, in many cases customers may wish to allow certain individuals (e.g. executives) to always be allowed access to the network even if NEA detects a problem. Similarly, different posture checking profiles might be applied depending on the requesting system or user’s identity. 3. Due to the potentially large number of systems offering and/or evaluating posture information and the quantity of enforcement devices, this presents a distributed policy issue for NEA deployers. The NEA components should be manageable using data model definitions associated within existing management protocol environments (e.g. SNMP, CIM.) Khosravi, et. al. Expires November 2006 [Page 10] Internet Draft NEA Requirements May 2006 4. Because the NEA infrastructure is involved in making decisions about every system’s request to join and remain on the network, NEA deployments should have mechanisms that protect it from direct attack or operational situations where it might be unavailable. Highly available, distributed deployment architectures should help minimize downtown and avoid single point of failure scenarios. However NEA solutions may need to offer deployers some policy-driven flexibility in how the NEA components respond when faced with an unavailable NEA Server component. 8.Security Considerations This document defines the requirements for the interfaces (protocols) for a security mechanism assessment and enforcement scheme. As such, it does not define a specific solution or set of technologies, so this section will highlight security issues that may apply to NEA in general or to particular aspects of the eventual technical architecture. 8.1. Scope and Overlap Inherent in the requirements is a desire for NEA candidate protocols throughout the architecture to accommodate the use of strong security mechanisms as dictated by the deployer. In some cases, these mechanisms may appear to provide overlapping protections. The overlaps may be desired by deployer to offer a defense in depth approach; however because of the layering of the protocols each mechanism offers slightly different protection 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 a Posture Collector's set of reported attributes at the PA layer to allow the peer Posture Verifier to achieve end to end confidentiality. In particular, this might be desired when the NEA Server side decision point spans several systems so the NAA is on a different system from the Verifier. In general, the NEA architecture's protocols are intending to provide to the Posture Collector the ability to safely send its measurement attributes across an untrustworthy network to a peer Posture Validator and receive protected requests/responses. The architecture is not intending to provide local integrity protection for the proper operation of the Posture Collector itself. For example, NEA technologies do not claim to prevent a carefully Khosravi, et. al. Expires November 2006 [Page 11] Internet Draft NEA Requirements May 2006 crafted piece of malware (e.g. rootkit) from tricking the Posture Collector into inaccurately reporting the state of the system so it can remain undetected. Such integrity protection of the Collector and other aspects of the system might be offered by orthogonal security mechanisms leveraging security hardware and/or protected trusted software. 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 assessment use cases. 8.2. Interesting Attack Classes A variety of attacks are possible against current assessment technologies. This section does not include a full threat analysis, but wishes to highlight a few attacks which influenced the requirement definition and should be considered by deployers selecting use of protective mechanisms within the conceptual architecture. The following types of attacks are possible against each of the network protocols defined in the conceptual architecture and thus should be considered by deployers. 8.2.1. Man-in-the-Middle (MITM) MITM attacks against a network protocol exist when a 3rd party can sit between two legitimate communicating parties without detection. For example, a malware infested machine might wish to join the network using measurements collected by a clean system by inserting itself into and proxying an assessment message exchange. The impact of the damage caused by the MITM can be limited or prevented by selection of appropriate protective mechanisms. The requirement for PT to be capable of supporting bi-directional authentication 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. However the MITM might still act as a message relay between the parties and change, eavesdrop, or steal and replay the communications. These forms of attack require additional protections discussed below. Khosravi, et. al. Expires November 2006 [Page 12] Internet Draft NEA Requirements May 2006 8.2.2. Message Modification Without message protection, an attacker capable of interception of an assessment message would be capable of modifying the contents and causing an incorrect action to occur. For example, the attacker might change the measurement attributes to always reflect incorrect values and thus prevent a system from joining the network. Unless the NEA Server could detect this change, the attacker could prevent network admission to large numbers of clean systems. Conversely, the attacker could allow malware infested machine to be admitted by changing the attributes. In order to protect against such attacks, the PT includes a requirement for strong integrity protection (e.g. including a protected hash of the message) so this change will be detected. PA includes a similar requirement to enable end to end integrity protection of the message. It is important that integrity protection schemes leverage secret information (not known by the attacker) that are bound to the transaction such as an encrypted message hash or HMAC [REF] linked to the authentication. Message hash keys from prior transactions possibly involving other systems must not be re-usable without detection. 8.2.3. Message Replay or Theft A passive attacker might listen to the network recording messages from a healthy client for later re-use to the same NEA Server or just to build an inventory of software running on other systems. The NEA Server needs to be capable of detecting the replay or the architecture must assure that the eavesdropper can not obtain the attribute values in the first place. The protection of the PT, PB or PA messages using encryption prevents the passive listener from learning the exchanged attribute values for theft or replay. By linking the encrypted transaction to the authentication event and leveraging a per-transaction freshness exchange, this prevents a replay of the encrypted transaction. 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 architecture 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. Khosravi, et. al. Expires November 2006 [Page 13] Internet Draft NEA Requirements May 2006 9.References 9.1.Normative References 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, October 1996. 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), IETF, March 1997. 3. S. Hanna, et. al., "Network Endpoint Assessment (NEA) Problem Statement", draft-thomson-nea-problem-statement-01.txt, March 2006. 4. Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 5. Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 6. T. Dierks, E. Rescorla, ‘‘The Transport Layer Security (TLS) Protocol Version 1.1’’, RFC 4346, April 2006. 7. S. Kent, R. Atkinson, ‘‘Security Architecture for the Internet Protocol’’, RFC 2401, November 1998. (IPSec) 9.2.Informative References 8. ‘‘TCG Trusted Network Connect (TNC) Architecture for Interoperability’’, https://www.trustedcomputinggroup.org/specs/TNC/TNC_Architecture_v1 _1_r2.pdf, May 2006. 9. Cisco Network Admission Control (NAC), http://www.cisco.com/go/nac 10. Microsoft Network Access Protection (NAP), http://www.microsoft.com/technet/itsolutions/network/nap/default.ms px 11. IEEE, "Local and Metropolitan Area Networks: Port-based Network Access Control", 2004. (802.1x) Khosravi, et. al. Expires November 2006 [Page 14] Internet Draft NEA Requirements May 2006 12. Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-11 (work in progress), March 2006. Authors' Addresses & Acknowledgments Hormuzd Khosravi (co-editor) Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 0334 Email: hormuzd.m.khosravi@intel.com Paul Sangster (co-editor) Symantec Corporation 6825 Citrine Dr Carlsbad, CA 92009 USA Email: paul_sangster@symantec.com Kevin Amorin Harvard University 79 JFK St. Cambridge, MA 02138 Phone: +1 617-384-6699 Email: Kevin_Amorin@Harvard.edu Diana Arroyo IBM 11501 Burnet Road Austin, Tx 78758 Phone: +1 512-838-0088 Email: darroyo@us.ibm.com Uri Blumenthal Intel Corporation 1515 Route 10, Parsippany, NJ 07054 Phone: +1 973-967-6446 Email: uri.blumenthal@intel.com Steve Hanna Juniper Networks, Inc. 35 Forest Ridge Road Concord, MA 01742 Phone: +1 978-371-3980 Email: shanna@juniper.net Thomas Hardjono Khosravi, et. al. Expires November 2006 [Page 15] Internet Draft NEA Requirements May 2006 SignaCert, Inc. 707 SW Washington St./Suite 700, Portland, OR 97205 Phone: +1 503-227-2207 Email: thardjono@signacert.com Ravi Sahita Intel Corporation 2111 NE 25th Ave Hillsboro OR 97124 Email: Ravi.sahita@intel.com Mauricio Sanchez Email: mauricio.sanchez@hp.com Jeff Six Email: jeffsix@thematrix.ncsc.mil Joseph Tardo Nevis Networks 500 N. Bernardo Ave. Mountain View, CA 94043 Email: joseph.tardo@nevisnetworks.com Susan Thomson Cisco Systems 499 Thornall Street, 8th floor Edison, NJ 08837 U.S.A Email: sethomso@cisco.com John Vollbrecht 9682 Alice Hill Drive Dexter, Mi. 48130 Email: jrv@merit.edu Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 U.S.A. Email: hzhou@cisco.com 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. Khosravi, et. al. Expires November 2006 [Page 16] Internet Draft NEA Requirements May 2006 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. Khosravi, et. al. Expires November 2006 [Page 17]