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