Internet Draft Hormuzd Khosravi, Intel
Expires: January 2007 Paul Sangster, Symantec
Working Group: NEA July 2006
Requirements for Network Endpoint Assessment (NEA)
draft-khosravi-nea-requirements-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.
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 (protocol) 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 January 2007 [Page 1]
Internet Draft NEA Requirements July 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 Requirements Across Architecture.........................5
5. Protocol Requirements...........................................6
5.1
.Pos
ture
At
tr
ibute
(PA)
Protocol
Requirements.....................6
5.2
.Pos
ture
Broker
(PB)
Protocol Requirements........................7
5.3
.Posture
Transpor
t (PT)
Protocol
Requirements.....................8
5.3
.1
.EAP Usage Within
PT............................................9
6. Security Analysis/Requirements.................................10
7. Operational Considerations.....................................12
8. Security Considerations........................................13
8.1
.Scope
and Over
lap...............................................13
8.2.Relevant
Classes
of
At
tack......................................14
8.2
.1
.Man-
in-the-Middle
(MITM).....................................14
8.2
.2
.Message Modification.........................................14
8.2.3
.Message Replay or
Theft......................................15
9. References.....................................................15
9.1
. Normat
ive
References...........................................15
9.2. Informat
ive
References.........................................16
Authors' Addresses & Acknowledgments..............................16
1.
Introduction
Khosravi, et. al. Expires January 2007 [Page 2]
Internet Draft NEA Requirements July 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 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
Component Software, hardware or firmware entity performing a
particular logical function within the NEA conceptual architecture.
Khosravi, et. al. Expires January 2007 [Page 3]
Internet Draft NEA Requirements July 2006
For the purposes of assessment, a component may be a particular
vendor product (e.g. Symantec Anti-Virus), class of application
(e.g. Firewall), or be more general to represent groupings of
software services (e.g. Operating System kernel.)
Dialog Sequence of request/response messages exchanged over one or
more sessions.
Message Self contained unit of communication between components.
For example, a PA message might carry a set of attributes from a
Posture Collector to a Validator.
Session Common PB transport connection capable of carrying one or
more messages from multiple subscribed Posture Collectors and
Validators.
Please refer to [3] for the NEA terminology.
3.
Architecture and Components
The major components of NEA architecture are shown in Figure 1. The
PV and NAE protocols are identified for completeness but are not the
focus of the initial phase of NEA work items.
|-------------| |----------------|
| 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 Protocols
Khosravi, et. al. Expires January 2007 [Page 4]
Internet Draft NEA Requirements July 2006
4.
Common Requirements Across Architecture
The following are the common requirements that apply to the PA, PB
and PT protocols in NEA conceptual architecture:
1. NEA protocols MUST be capable of performing a multiple message
dialog 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
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 and PB protocols defined by NEA MUST be agnostic of the
transport i.e. PT protocol. For example, the PB protocol must
provide a transport 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. The selection process for NEA protocols MUST evaluate and prefer
the reuse of existing open standards that meet the requirements
before defining new ones. The goal of NEA is not to create
additional alternative protocols where acceptable solutions already
exist.
7. NEA protocols MUST be highly scalable allowing for many Posture
Collectors on large deployments of NEA Clients to be assessed by
numerous Posture Validators residing on multiple NEA Servers. For
example, the protocols need to be capable of naming large numbers of
types of collectors, validators, and components.
Khosravi, et. al. Expires January 2007 [Page 5]
Internet Draft NEA Requirements July 2006
5.
Protocol Requirements
5.1.Posture Attribute (PA) Protocol Requirements
The PA protocol defines the transport 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 carries
collections of core attributes and vendor defined attributes. The PA
protocol will be carried inside the Posture Broker (PB) protocol.
The following requirements define the desired properties that form
the basis for the working groups comparison and evaluation of
candidate PA protocols. The requirements do not require that
deployers use these properties merely that the candidate protocol be
capable of offering the property should it be needed.
1. The PA protocol MUST support transport of the required (core)
attributes defined in the data model to report information
determined 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 enabling communication of a richer, potentially vendor
specific set of attributes describing the requested component.
3. The PA protocol MUST enable the Posture Validator to request
posture information about particular components on the NEA Client
system. The posture information may be represented as one or more
attributes (core and/or vendor specific) that describe the
operational properties of the component.
4. The PA protocol MUST allow for the Posture Validator to request
posture information on more then one occasion using an existing or
if unavailable on a new session. This enables the Posture Validator
to re-assess the posture of a particular component (in case it has
changed) or to request information about additional components
(possibly due to something learned from an earlier request.)
5. The PA protocol MUST be capable of returning the Posture
Validators results and any necessary remediation instructions.
This allows the Posture Collector to learn the specific reason for a
failed assessment to aid in remediation and notification of the
system owner.
6. The selection process for the PA protocol MUST evaluate and
prefer the reuse of existing open standards that are applicable to
the transport and representation of an extensible set of attributes.
Khosravi, et. al. Expires January 2007 [Page 6]
Internet Draft NEA Requirements July 2006
In particular, extensible structured data formats such as XML should
be considered.
7. 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.
8. The PA protocol MUST support authentication, integrity and
confidentiality of attributes, results and remediation instructions
sent between a Posture Collector and Validator. This enables end to
end security across an NEA deployment that might involve the
traversal of several systems. 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) Protocol Requirements
The PB protocol supports multiplexing of Posture Attribute messages
(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
transports the global decision made by the Server Broker, taking
into account the results of the Posture Validators involved in the
assessment, to the Client Broker.
The PB protocol also transports the aggregated remediation
instructions from one or more Posture Validators.
1. The PB protocol MUST be capable of carrying the global decision
and, if appropriate, the global remediation instructions from the
Server Broker to the Client Broker.
2. The PB protocol MUST contain information used by the Brokers to
route (deliver) messages between particular types of Posture
Collectors and Posture Validators. Such message routing information
should enable dynamically (de)registered Posture Collectors and
Validators to receive appropriate messages. For example, a
dynamically registered Anti-Virus Posture Validator should be able
to subscribe to receive messages from its respective Anti-Virus
Posture Collector on NEA Clients.
Khosravi, et. al. Expires January 2007 [Page 7]
Internet Draft NEA Requirements July 2006
3. The PB protocol MUST support a message dialog to occur between
one or more Posture Collectors and Posture Validators. This allows
each party to send multiple messages before the dialog is complete.
4. The PB protocol MUST support authentication, integrity and
confidentiality of the PA messages, broker global decision and
remediation instructions sent between an NEA Client and Server.
This provides security protection for the aggregated set of PA
messages exchanged and the result between the NEA Client and Server.
Such protection is orthogonal to PA protections (which are end to
end) and allow for simpler Posture Collector and Validators to be
implemented and consolidation of cryptographic operations possibly
improving scalability and manageability.
5. The PB protocol SHOULD support grouping of attributes to optimize
transport of messages and minimize round trips.
5.3.Posture Transport (PT) Protocol 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 owners
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 deployers policy will dictate how these
apply to a particular environment.
1. The PT protocol SHOULD incur low overhead to accommodate for use
on low bandwidth links.
2. The PT protocol SHOULD be capable of supporting a half duplex
communication environment.
3. 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.
4. The PT protocol MUST be capable of protecting the integrity and
confidentiality of the PB messages being transported between the NAR
and NAA.
5. The PT protocol MUST provide reliable delivery of PB messages.
This includes the ability to perform fragmentation, detect
duplicates, and reorder data, if necessary.
Khosravi, et. al. Expires January 2007 [Page 8]
Internet Draft NEA Requirements July 2006
6. 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.
7. 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.
8. 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.
5.3.1. EAP Usage Within PT
When EAP is being used within PT, the PT protocol can be split into
two groups: Posture Transport Tunnel (PTT) and Posture Transport
Carrier (PTC). PTT is the EAP method used between the NAR and NAA
(e.g. EAP-FAST, PEAP, EAP-TTLS), and PTC is the transport protocol
carrying EAP. When Network Enforcer (NE) is a separate entity from
Network Access Authority, PTC is further broken into two protocols,
one between NAR and NE (named NRE) and one between NE and NAA (named
NAE). Examples of NRE are EAPOL, PPP, IPSec etc. Examples of NAE are
RADIUS, Diameter, etc. This section defines the requirements which
candidate PTT and PTC protocols must be capable of supporting, in
addition to those outlined in Section 4 Common Requirements Across
Architecture. The deployer's policy will dictate how these apply to
a particular environment.
PTT EAP Method Requirements:
1. The PTT EAP Method SHOULD be standardized from one or more
existing methods if possible or modifying existing methods if where
necessary to make them appropriate to be standardized. The use of
existing standard EAP method for PTT SHOULD be giving preference
over creating a new EAP method.
2. The PTT EAP Method 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. This is mapped to PT Requirement 3.
3. The PTT EAP Method MUST support integrity and confidentiality to
protect key material and data. This is mapped to PT Requirement 4.
Khosravi, et. al. Expires January 2007 [Page 9]
Internet Draft NEA Requirements July 2006
4. The PTT EAP Method MUST support fragmentation of payloads larger
then the minimum EAP MTU, and reassembly. This is mapped to PT
Requirement 5.
5. The PTT EAP Method MUST have support for mutual authentication.
This is mapped to PT Requirement 6.
6. The PTT EAP Method MUST have support and have protection for PB
protocol in the form of "inner EAP methods" or TLV/AVP. It SHOULD
support transporting of arbitrarily large posture data or
fragmentation of the data.
7. The PTT EAP Method MUST be lower layer agnostic and have support
for multiple carrier protocols (RADIUS, Diameter, EAPOL, etc.).
8. The PTT EAP Method MUST be able to dynamically generate key
material.
9. The PTT EAP Method MUST support transport PB with or without
identity authentication, before or after identity authentication.
10. The PTT EAP Method MUST support multiple message dialogs of PB
protocol.
11. The PTT EAP Method SHOULD use open (publicly available and
proven) algorithms in its encryption and key creation.
12. The PTT EAP Method SHOULD be able to perform key negotiation,
and cipher suite negotiation.
PTC Requirements
PTC MUST meet the following requirements, in addition to the
requirements described in RFC 3748 Section 3 Lower Layer Behavior.
1. The PTC protocol MUST be able to establish an assessment session
between the NAR and the NAA prior to the NAR being granted general
network access. This is mapped to PT Requirement 7.
2. The PTC protocol MUST allow the NAR or NAA to trigger
reassessment when there are changes in client posture and/or server
policy after network access is granted. This is mapped to PT
Requirement 8.
6.
Security Analysis/Requirements
Khosravi, et. al. Expires January 2007 [Page 10]
Internet Draft NEA Requirements July 2006
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 Protocol
- 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 Protocol
- 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 Protocol
- This communication channel MUST be protected: endpoint mutual
authentication with subsequent secure pipe establishment. Otherwise
third parties could launch a variety of attacks.
4. 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 protocol.
5. Communication between Client Broker and Network Access Requestor
MAY need protection.
Khosravi, et. al. Expires January 2007 [Page 11]
Internet Draft NEA Requirements July 2006
6. 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 users 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.)
4. Because the NEA infrastructure is involved in making decisions
about every systems 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.
Khosravi, et. al. Expires January 2007 [Page 12]
Internet Draft NEA Requirements July 2006
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
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
Khosravi, et. al. Expires January 2007 [Page 13]
Internet Draft NEA Requirements July 2006
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. Relevant Classes of Attack
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.
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
Khosravi, et. al. Expires January 2007 [Page 14]
Internet Draft NEA Requirements July 2006
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.
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.
Khosravi, et. al. Expires January 2007 [Page 15]
Internet Draft NEA Requirements July 2006
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)
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
Khosravi, et. al. Expires January 2007 [Page 16]
Internet Draft NEA Requirements July 2006
Email: hormuzd.m.khosravi@intel.com
Paul Sangster (co-editor)
Symantec Corporation
6825 Citrine Dr
Carlsbad, CA 92009 USA
Email: paul_sangster@symantec.com
Kevin Amorin
Harvard University
79 JFK St.
Cambridge, MA 02138
Phone: +1 617-384-6699
Email: Kevin_Amorin@Harvard.edu
Diana Arroyo
IBM
11501 Burnet Road
Austin, Tx 78758
Phone: +1 512-838-0088
Email: darroyo@us.ibm.com
Uri Blumenthal
Intel Corporation
1515 Route 10,
Parsippany, NJ 07054
Phone: +1 973-967-6446
Email: uri.blumenthal@intel.com
Steve Hanna
Juniper Networks, Inc.
35 Forest Ridge Road
Concord, MA 01742
Phone: +1 978-371-3980
Email: shanna@juniper.net
Thomas Hardjono
SignaCert, Inc.
707 SW Washington St./Suite 700,
Portland, OR 97205
Phone: +1 503-227-2207
Email: thardjono@signacert.com
Ravi Sahita
Intel Corporation
2111 NE 25th Ave
Hillsboro OR 97124
Email: Ravi.sahita@intel.com
Khosravi, et. al. Expires January 2007 [Page 17]
Internet Draft NEA Requirements July 2006
Mauricio Sanchez
Email: mauricio.sanchez@hp.com
Jeff Six
Email: jeffsix@thematrix.ncsc.mil
Joseph Tardo
Nevis Networks
500 N. Bernardo Ave.
Mountain View, CA 94043
Email: joseph.tardo@nevisnetworks.com
Susan Thomson
Cisco Systems
499 Thornall Street, 8th floor
Edison, NJ 08837
U.S.A
Email: sethomso@cisco.com
John Vollbrecht
9682 Alice Hill Drive
Dexter, Mi. 48130
Email: jrv@merit.edu
Hao Zhou
Cisco Systems
4125 Highlander Parkway
Richfield, OH 44286
U.S.A.
Email: hzhou@cisco.com
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
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 January 2007 [Page 18]