 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi All, Here is the -00 rev of the Requirements draft that the
Requirements team has produced in just a couple of weeks. It has been submitted
to the IETF. I would like to thank everyone on the Requirements team for
their extraordinary effort in pulling this through in a short period of time! The team will continue working on this draft and we plan to
submit rev-01 of this draft by June 26th. Comments from the mailing list are welcome! Regards Hormuzd |
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 at intel.com
Paul Sangster (co-editor)
Symantec Corporation
6825 Citrine Dr
Carlsbad, CA 92009 USA
Email: paul_sangster at symantec.com
Kevin Amorin
Harvard University
79 JFK St.
Cambridge, MA 02138
Phone: +1 617-384-6699
Email: Kevin_Amorin at Harvard.edu
Diana Arroyo
IBM
11501 Burnet Road
Austin, Tx 78758
Phone: +1 512-838-0088
Email: darroyo at us.ibm.com
Uri Blumenthal
Intel Corporation
1515 Route 10,
Parsippany, NJ 07054
Phone: +1 973-967-6446
Email: uri.blumenthal at intel.com
Steve Hanna
Juniper Networks, Inc.
35 Forest Ridge Road
Concord, MA 01742
Phone: +1 978-371-3980
Email: shanna at 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 at signacert.com
Ravi Sahita
Intel Corporation
2111 NE 25th Ave
Hillsboro OR 97124
Email: Ravi.sahita at intel.com
Mauricio Sanchez
Email: mauricio.sanchez at hp.com
Jeff Six
Email: jeffsix at thematrix.ncsc.mil
Joseph Tardo
Nevis Networks
500 N. Bernardo Ave.
Mountain View, CA 94043
Email: joseph.tardo at nevisnetworks.com
Susan Thomson
Cisco Systems
499 Thornall Street, 8th floor
Edison, NJ 08837
U.S.A
Email: sethomso at cisco.com
John Vollbrecht
9682 Alice Hill Drive
Dexter, Mi. 48130
Email: jrv at merit.edu
Hao Zhou
Cisco Systems
4125 Highlander Parkway
Richfield, OH 44286
U.S.A.
Email: hzhou at 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]_______________________________________________ Nea mailing list Nea at ietf.org https://www1.ietf.org/mailman/listinfo/nea