One document matched: draft-thomson-nea-problem-statement-01.txt
Differences from draft-thomson-nea-problem-statement-00.txt
Network Working Group S. Hanna
Internet-Draft Juniper Networks
Expires: September 5, 2006 T. Hardjono
Signacert Inc
S. Thomson
Cisco Systems
March 4, 2006
Network Endpoint Assessment (NEA) Problem Statement
draft-thomson-nea-problem-statement-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Architectures have been implemented in the industry 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 fully interoperable since some of the protocols used to
Hanna, et al. Expires September 5, 2006 [Page 1]
Internet-Draft NEA Problem Statement March 2006
implement the architecture are not 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 September 5, 2006 [Page 2]
Internet-Draft NEA Problem Statement March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7
5.1. Wired LAN access . . . . . . . . . . . . . . . . . . . . . 7
5.2. Wireless LAN Access . . . . . . . . . . . . . . . . . . . 7
5.3. Remote access VPN . . . . . . . . . . . . . . . . . . . . 8
5.4. Gateway Access . . . . . . . . . . . . . . . . . . . . . . 8
6. Components and Interfaces . . . . . . . . . . . . . . . . . . 8
6.1. Mapping to existing architectures . . . . . . . . . . . . 9
6.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. NEA Client . . . . . . . . . . . . . . . . . . . . . . 10
6.2.2. Network enforcer . . . . . . . . . . . . . . . . . . . 11
6.2.3. NEA server . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.1. Posture Attribute interface (IF-PA) . . . . . . . . . 13
6.3.2. Posture Broker Interface (IF-PB) . . . . . . . . . . . 13
6.3.3. Posture Transport Interface (IF-PT) . . . . . . . . . 13
6.3.4. Network Access Enforcement Interface (IF-NAE) . . . . 13
6.3.5. Posture Validation Interface (IF-PV) . . . . . . . . . 14
7. Scope of Standardization . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. Secure channel between the Client Broker and Server
Broker . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Authorization for Plug-in/Broker interaction . . . . . . . 16
9.3. Self-Integrity of the NEA Client and NEA Server . . . . . 16
9.4. Protection of parameters exchanged across Interfaces . . . 16
9.5. Identity authentication of communicating end-points . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Hanna, et al. Expires September 5, 2006 [Page 3]
Internet-Draft NEA Problem Statement March 2006
1. Introduction
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 or enforcing compliance of
endpoints to an organization's policy on access to the network.
These architectures are not fully interoperable since some of the
protocols used to implement the architecture are not 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, Client broker
and Network access requestor.
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.
Client broker: A Client broker is the component of the NEA client
that aggregates posture information from multiple Posture collectors.
Hanna, et al. Expires September 5, 2006 [Page 4]
Internet-Draft NEA Problem Statement March 2006
Network access requestor: The Network access requestor is the
component of the NEA client responsible for requesting access to the
network.
Network enforcer: The Network enforcer 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,
Server broker 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.
Server broker: A Server broker 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
Network endpoint assessment (NEA) architectures are systems that
enable the network to learn the posture of an endpoint device, and
optionally use that information in addition to machine or user
authentication to influence a network admission decision. Endpoint
posture may include information about the operating system as well as
information about security applications running on the endpoint such
as anti-virus software, personal firewalls and host intrusion
protection systems.
NEA technology may be used for several purposes. One purpose is to
monitor or enforce compliance of endpoints to the organization's
security policy. Organizations often require endpoints that are
vulnerable to attack through viruses, worms and other exploits 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 management
software. Without NEA technology, ensuring compliance of endpoints
to corporate policy is a time-consuming and difficult task. Not all
Hanna, et al. Expires September 5, 2006 [Page 5]
Internet-Draft NEA Problem Statement March 2006
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 when it
accesses the network and while connected, providing an opportunity to
monitor compliance of all endpoints using the network as well as
providing the opportunity to improve endpoint compliance. 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 to
protect the endpoint from infection and to protect the network in
case the endpoint is already infected.
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.
As has been mentioned, many NEA architectures have been developed in
the industry to addess the above purposes. Certain instantiations of
these architectures leverage the EAP framework to enable network
admission decisions to be based on both authentication and posture
assessment. However, while these instantiations leverage standard
protocols to the extent possible, e.g. 802.1X[802.1X], EAP[EAP] and
RADIUS[RADIUS], these architectures are still not fully interoperable
because other needed protocols have not been standardized. The
intent of the proposed NEA effort is to identify those interfaces
where standarization is needed in the IETF, define requirements for
these interfaces, and work within the IETF to define standards to
meet these requirements.
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,
or both
Hanna, et al. Expires September 5, 2006 [Page 6]
Internet-Draft NEA Problem Statement March 2006
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.
o Support endpoints with a NEA client and without a client
5. Deployment Scenarios
Network assessment architectures have been targeted primarily at
enterprise deployment scenarios to date.The deployment scenarios
include:
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
Hanna, et al. Expires September 5, 2006 [Page 7]
Internet-Draft NEA Problem Statement March 2006
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.11 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
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 enforcers 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 Interfaces
This section provides a general overview of NEA architectures, with a
particular emphasis on the EAP/RADIUS instantantiation of these
architectures, since this is the focus of the initial standards
Hanna, et al. Expires September 5, 2006 [Page 8]
Internet-Draft NEA Problem Statement March 2006
effort. (Other instantiations of the high-level architecture may be
standardized in future.)
Figure 1 shows the components of an NEA system and identifies
specific interfaces.
|-------------| |----------------|
| Posture | <-------IF-PA-------> | Posture |
| Collectors | | Validators |
| (1 ...N) | | (1 ...N) |
|-------------| |----------------|
| |
| <------IF-PV-------->
| |
|-------------| |----------------|
| Client | <-------IF-PB-------> | Server |
| Broker | | Broker |
|--------- ---| |----------------|
| |
| |
|-------------| <------IF-PT-------> |----------------|
| | | |
| Network | |--------| | Network |
| Access |----|Network |------------| Access |
| Requestor | |Enforcer| <-IF-NAE-> | 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 September 5, 2006 [Page 9]
Internet-Draft NEA Problem Statement March 2006
Table 1: Terminology used in various architectures
NEA TNC NAP NAC
Posture Integrity System Posture
Collector Measurement Health Plug-in
Collector Agent
Client TNC NAP Posture
Broker Client Agent Agent
Network Network NAP Posture
Access Access Enforcement Agent
Requestor Requestor Client
Network Policy NAP Network
Enforcer Enforcement Enforcement Access
Point Server Device
Posture Integrity System Posture
Validator Measurement Health Validation
Verifier Validator Server
Server TNC NAP Access
Broker Server Administration Control
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 Client broker
o Network access requestor
6.2.1.1. Posture Collector
The Posture collector is software that provides posture information
about the endpoint device to the Client broker. There may be many
Hanna, et al. Expires September 5, 2006 [Page 10]
Internet-Draft NEA Problem Statement March 2006
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 information about any actions to perform, e.g. URL of a
remediation server
o Indicating when the posture of the host has changed
6.2.1.2. Client Broker
The Client broker aggregates posture information from multiple
Posture collectors. The Client broker 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.
6.2.2. Network enforcer
The Network enforcer is a network component that controls access of
endpoints to the upstream network. The Network enforcer may be a
network device or a logical component on an endpoint. The NEA
enforcer enforces network authorization decisions from the Network
Hanna, et al. Expires September 5, 2006 [Page 11]
Internet-Draft NEA Problem Statement March 2006
access authority. There are different types of Network enforcers
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 Server broker
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
Server broker.
6.2.3.2. Server broker
The Server broker 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 Server broker 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
the result of the assessment. There may be multiple Posture
validators each targeted at a particular security application from a
particular vendor. In some architectures, the Posture validators are
not co-located with the NEA server.
A Posture validator is responsible for the following:
Hanna, et al. Expires September 5, 2006 [Page 12]
Internet-Draft NEA Problem Statement March 2006
o Requesting and receiving posture information from a particular
Posture collector
o Assessing the endpoint posture and providing a result to the
Server broker
o Sending to the Posture collector information on remediation
actions to be taken
o Indicating to the Server broker when posture reassessment may be
needed
6.3. Interfaces
6.3.1. Posture Attribute interface (IF-PA)
The IF-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 Interface (IF-PB)
The IF-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 Server broker to the Client
broker.
6.3.3. Posture Transport Interface (IF-PT)
The IF-PT is the transport protocol between the Network access
requestor and the Network access authority that carries the IF-PB
protocol.
In EAP instantiations of this architecture, the IF-PT interfaces
consists of two protocols: 1) Posture Transport Tunnel (IF-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
information, and 2) Posture Transport Carrier (IF-PTC), a protocol
that carries EAP, e.g. EAP over 802.1X, EAP over RADIUS.
6.3.4. Network Access Enforcement Interface (IF-NAE)
The IF-NAE is the protocol between the Network enforcer and Network
Hanna, et al. Expires September 5, 2006 [Page 13]
Internet-Draft NEA Problem Statement March 2006
access authority used to carry network authorization decisions
between the Network enforcer and the Network access authority.
In EAP Instantiations of this architecture, the IF-NAE interface is
RADIUS.
6.3.5. Posture Validation Interface (IF-PV)
In some instantiations of the architecture, the Server broker and the
Posture validators are not co-located. The IF-PV protocol between
the Server broker and Posture validator forwards posture information
and returns posture validation results.
7. Scope of Standardization
Protocols that are candidates for standardization in the IETF include
the following :
o Posture attributes interface (IF-PA): This interface can be
defined independently of the underlying transport interfaces,
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. an attribute representing the result of
evaluating posture information from a Posture collector.
o Posture broker interface (IF-PB): This interface is also largely
independent of the underlying transport, although it should be
defined in such a way that it can be used in posture transport
protocols that are likely to be used, such as EAP tunneling
methods based on TLS.
o Posture transport tunnel interface (IF-PTT): As described in the
section above, 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 the EAP
methods that need to be standardized. In particular,
standardization of EAP tunneling methods is a high priority.
o Posture transport carrier interface (IF-PTC): Some EAP carrier
methods are standards today e.g. 802.1X. However, there is no
standard EAP transport to support gateway and other "multi-hop"
Hanna, et al. Expires September 5, 2006 [Page 14]
Internet-Draft NEA Problem Statement March 2006
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 access enforcement interface (IF-NAE): Existing standards
exist including RADIUS and Diameter. The initial focus of the
proposed NEA standardization effort is on RADIUS. The Radext WG
has the charter to standardize RADIUS extensions. It's not clear
that NEA would require any extensions that fall outside of the
scope of the existing charter of that WG.
o Posture validator interface (IF-PV): This protocol acts as a
carrier for posture attributes between a Server broker and a
Posture validator that is not co-located in the NEA server.
Depending on the choice of protocol for this purpose, this may or
may not fall within the scope of the IETF.
The proposed initial scope of the NEA effort is the following:
o IF-PTT
o IF-NAE
o IF-PB
o IF-PTC
The remaining interfaces, IF-PA and IF-PV, may be addressed at a
later date.
8. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Security Considerations
NEA systems include a number of functional components and interfaces,
and thus there are a number of security aspects pertaining to the
system as a whole which need to be highlighted. Some of these are
discussed in the following sections.
Hanna, et al. Expires September 5, 2006 [Page 15]
Internet-Draft NEA Problem Statement March 2006
9.1. Secure channel between the Client Broker and Server Broker
The Client broker needs to be able to communicate the posture
information regarding the endpoint to the Server broker with
communications integrity and confidentiality. One possible avenue
towards establishing this secure channel (at the peer layer of the
Client broker and Server broker) is to establish it end-to-end
between Network access requestor (NAR) and the Network access
authority (NAA). This end-to-end secure channel would prevent any
intermediate entity, including the Network enforcer from gaining
access to the posture information. The exact implementation of this
secure channel is dependent on the domain of application and network
configuration.
9.2. Authorization for Plug-in/Broker interaction
There is a functional separation between the Posture collector and
the Client broker (at the NEA client side) and also between Posture
validator and the Server broker (at the NEA Server side). It is
important that a Client broker be allowed to communicate with only
the authorized Posture collectors. Similarly, the Server broker
should only communicate with authorized Posture validators. Recall
that the Posture collector is software that provides posture
information about the endpoint device to the Client broker. Note
that there may be many Posture collectors in a NEA client, one per
vendor and application type. Without protection, a bogus Posture
collector (Posture validator) can open communications with the Client
broker (Server broker), thereby opening the possibility of a Denial-
of-Service attack (at the very least) against the Client broker and
Server broker respectively.
9.3. Self-Integrity of the NEA Client and NEA Server
The trustworthiness of the posture information being reported by the
NEA client to the NEA Server is dependent on and is only as good as
the self-integrity of the NEA client and NEA Server respectively. If
malicious code or other malware are present in the NEA client
actively modifying posture information being communicated by the NEA
client, the NEA Server may be basing its decision-making on
inaccurate or bogus posture information. Thus, it is important that
both the NEA client and the NEA Server are protected against attacks
that illegally modify the system configurations and system components
of these entities.
9.4. Protection of parameters exchanged across Interfaces
An important aspect of an NEA system is the protection of parameters
being communicated between the various interfaces defined in the
Hanna, et al. Expires September 5, 2006 [Page 16]
Internet-Draft NEA Problem Statement March 2006
architecture. Examples of the parameters being exchanged include,
but are not limited to, state change notifications between the Client
broker and Posture collector, state change notifications between the
Server broker and Posture validator, the parameters and messages
exchanged between two peer entities (on the NEA client and NEA Server
respectively) across IF-PA and IF-PB, and in general parameters and
messages exchanged across interfaces IF-PT, and IF-NAE.
9.5. Identity authentication of communicating end-points
In order for the NEA Server to accept access requests and posture
information being reported to by the NEA client, the NEA Server may
need to authenticate the NEA client in some manner. Similarly,
within some network environments there may be the requirement that
the NEA client also authenticate the NEA Server with whom it is
communicating. Although the process of evaluating an access request
may combine together the notion of authentication and integrity state
evaluation (through posture information), it is important from a
security perspective and useful from a good engineering practices
perspective to be able to separate end-point authentication
(including both machine and user authentication) from end-point
posture assessment.
10. Acknowledgements
We acknowledge the contributions from members of the NEA mailing
list.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
Hanna, et al. Expires September 5, 2006 [Page 17]
Internet-Draft NEA Problem Statement March 2006
11.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.
[NAP] Microsoft Corporation, "Network Access Protection Platform
Architecture", February 2006.
[TNC] TCG, "TNC Architecture for Interoperability Specification
v1.0", May 2005.
Hanna, et al. Expires September 5, 2006 [Page 18]
Internet-Draft NEA Problem Statement March 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 September 5, 2006 [Page 19]
Internet-Draft NEA Problem Statement March 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 September 5, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:41 |