The Network Endpoint Assessment (NEA) Asokan Attack Analysis
How an attacker can make a sick computer look healthy to a network access check, and how to stop it.
Salowey, J. and S. Hanna, "The Network Endpoint Assessment (NEA) Asokan Attack Analysis", RFC 6813, DOI 10.17487/RFC6813, December 2012, <https://www.rfc-editor.org/info/rfc6813>.
@misc{rfc6813,
series = {Request for Comments},
number = 6813,
howpublished = {RFC 6813},
publisher = {RFC Editor},
doi = {10.17487/RFC6813},
url = {https://www.rfc-editor.org/info/rfc6813},
author = {J. Salowey and S. Hanna},
title = {{The Network Endpoint Assessment (NEA) Asokan Attack Analysis}},
pagetotal = 8,
year = 2012,
month = dec,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Salowey
Request for Comments: 6813 Cisco Systems
Category: Informational S. Hanna
ISSN: 2070-1721 Juniper Networks
December 2012
The Network Endpoint Assessment (NEA) Asokan Attack Analysis
Abstract
The Network Endpoint Assessment (NEA) protocols are subject to a
subtle forwarding attack that has become known as the NEA Asokan
Attack. This document describes the attack and countermeasures that
may be mounted.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6813.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. NEA Asokan Attack Explained .....................................2
3. Lying Endpoints .................................................4
4. Countermeasures against the NEA Asokan Attack ...................4
4.1. Identity Binding ...........................................4
4.2. Cryptographic Binding ......................................5
4.2.1. Binding Options .....................................5
5. Conclusions .....................................................6
6. Security Considerations .........................................6
7. Informative References ..........................................7
8. Acknowledgments .................................................7
1. Introduction
The Network Endpoint Assessment (NEA) [2] protocols are subject to a
subtle forwarding attack that has become known as the NEA Asokan
Attack. This document describes the attack and countermeasures that
may be mounted. The Posture Transport (PT) protocols developed by
the NEA working group, PT-TLS [5] and PT-EAP [6], include mechanisms
that can provide cryptographic-binding and identity-binding
countermeasures.
2. NEA Asokan Attack Explained
The NEA Asokan Attack is a variation on an attack described in a 2002
paper written by Asokan, Niemi, and Nyberg [1]. Figure 1 depicts one
version of the original Asokan attack. This attack involves tricking
an authorized user into authenticating to a decoy Authentication,
Authorization, and Accounting (AAA) server, which forwards the
authentication protocol from one tunnel to another, tricking the real
AAA server into believing these messages originated from the
attacker-controlled machine. As a result, the real AAA server grants
access to the attacker-controlled machine.
+-------------+ ========== +----------+
| Attacker |-AuthProto--|AAA Server|
+-------------+ ========== +----------+
|
AuthProto
|
+--------------+ ========== +----------------+
|AuthorizedUser|-AuthProto--|Decoy AAA Server|
+--------------+ ========== +----------------+
Figure 1: One Example of Original Asokan Attack
As described in the NEA Overview [2], the NEA Reference Model is
composed of several nested protocols. The Posture Attribute (PA)
protocol is nested in the Posture Broker (PB) protocol, which is
nested in the PT protocol. When used together successfully, these
protocols allow an NEA Server to assess the security posture of an
endpoint. The NEA Server may use this information to decide whether
network access should be granted, or it may use this information for
other purposes.
Figure 2 illustrates an NEA Asokan Attack. The attacker wants to
trick GoodServer into believing that DirtyEndpoint has good security
posture. This might allow, for example, the attacker to bring an
infected machine onto a network and infect others. To accomplish
this goal, the attacker forwards PA messages from CleanEndpoint
through BadServer to DirtyEndpoint, which sends them on to
GoodServer. GoodServer is tricked into thinking that the PA messages
came from DirtyEndpoint and therefore considers DirtyEndpoint to be
clean.
+-------------+ ========== +----------+
|DirtyEndpoint|-----PA-----|GoodServer|
+-------------+ ========== +----------+
|
PA
|
+-------------+ ========== +---------+
|CleanEndpoint|-----PA-----|BadServer|
+-------------+ ========== +---------+
Figure 2: NEA Asokan Attack
Countermeasures against an NEA Asokan Attack are described in Section
4.
3. Lying Endpoints
Some may argue that there are other attacks against NEA systems that
are simpler than the Asokan attack, such as lying endpoint attacks.
That is true. It's easy for an endpoint to simply lie about its
posture. But, there are defenses against lying endpoint attacks,
such as using an External Measurement Agent (EMA).
An EMA is hardware, software, or firmware that is especially secure,
hard to compromise, and designed to accurately report on endpoint
configuration. The EMA observes and reports on critical aspects of
endpoint posture, such as which security-relevant firmware and
software have been loaded.
When an EMA is used for NEA, the PA messages that reliably and
securely establish endpoint posture are exchanged between the EMA
itself and a Posture Validator on the NEA Server. The Posture
Collector on the endpoint and any other intermediaries between the
EMA and the Posture Validator on the NEA Server are not trusted.
They just pass messages along as untrusted intermediaries.
To ensure that the EMA's messages are accurately conveyed to the
Posture Validator, even if the Posture Collector or other
intermediaries have been compromised, these PA messages must provide
integrity protection, replay protection, and source authentication
between the EMA and the Posture Validator. Confidentiality
protection is not needed, at least with respect to the software on
the endpoint, but integrity protection should include protection
against message deletion and session truncation. Organizations that
have developed EMAs have typically developed remote attestation
protocols that provide these properties (e.g., the Trusted Computing
Group's (TCG's) Platform Trust Service (PTS) Protocol Binding to IF-M
[7]). While the development of lying endpoint detection technologies
is out of scope for NEA, these technologies must be supported by the
NEA protocols. Therefore, the NEA protocols must support
countermeasures against the NEA Asokan Attack.
4. Countermeasures against the NEA Asokan Attack
4.1. Identity Binding
One way to mitigate the Asokan attack is to bind the identities used
in tunnel establishment into a cryptographic exchange at the PA
layer. While this can go a long way to preventing the attack, it
does not bind the exchange to a specific TLS exchange, which is
desirable. In addition, there is no standard way to extract an
identity from a TLS session, which could make implementation
difficult.
4.2. Cryptographic Binding
Another way to thwart the NEA Asokan Attack is for the PA exchange to
be cryptographically bound to the PT exchange and to any keying
material or privileges granted as a result of these two exchanges.
This allows the NEA Server to ensure that the PA messages pertain to
the same endpoint as the party terminating the PT exchange and that
no other party gains any access or advantage from this exchange.
4.2.1. Binding Options
This section discusses binding protocol solution options and provides
analysis. Since PT-TLS and PT-EAP involve TLS, this document focuses
on TLS-based solutions that can work with either transport.
4.2.1.1. Information from the TLS Tunnel
The TLS handshake establishes a cryptographic state between the TLS
client and TLS server. There are several mechanisms that can be used
to export information derived from this state. The client and server
independently include this information in calculations to bind the
instance of the tunnel into the PA protocol.
Keying Material Export - RFC 5705 [8] defines Keying Material
Exporters for TLS that allow additional secret key material to be
extracted from the TLS master secret.
tls-unique Channel Binding Data - RFC 5929 [9] defines several
quantities that can be extracted from the TLS session to bind the TLS
session to other protocols. The tls-unique binding consists of data
extracted from the TLS handshake finished message.
4.2.1.2. TLS Cipher Suites
In order to eliminate the possibility of a man-in-the-middle attack
and thwart the Asokan attack when using the keying material export
binding export mechanism, it is important that neither TLS endpoint
be in sole control of the TLS pre-master secret. Cipher suites based
on key transport, such as RSA cipher suites, do not meet this
requirement; instead, Diffie-Hellman Cipher Suites, such as RSA-DHE,
are required when this mechanism is employed.
4.2.1.3. Using Additional Key Material from TLS
In some cases, key material is extracted from the TLS tunnel and used
to derive ciphering keys used in another protocol. For example,
EAP-TLS [10] uses key material extracted from TLS in lower-layer
ciphering. In this case, the extracted keys must not be under the
control of a single party, so the considerations in the previous
section are important.
4.2.1.4. EMA Assumptions
The EMA needs to obtain the binding data from the TLS exchange and
prove knowledge of the binding data in an exchange that has integrity
protection, source authentication, and replay protection.
5. Conclusions
The recommendations for addressing the NEA Asokan Attack are as
follows:
1. Protocols should make use of cryptographic binding; in addition,
binding identities of the tunnel endpoints in the EMA may be
useful.
2. In particular, L2 and L3 TLS-based PT transports (e.g., PT-TLS
and PT-EAP) should use the same cryptographic binding mechanism.
3. The preferred approach is to use the tls-unique channel binding
data from [9]. The tls-unique value will be made available to
the EMA that will use it. This approach can utilize any TLS
cipher suite based on a strong cipher algorithm.
6. Security Considerations
This document is primarily concerned with analyzing and proposing
countermeasures for the NEA Asokan Attack. That does not mean that
it covers all the possible attacks against the NEA protocols or
against the NEA Reference Model. For a broader security analysis,
see the Security Considerations section of the NEA Overview [2],
PA-TNC [3], PB-TNC [4], PT-TLS [5], and PT-EAP [6].
7. Informative References
[1] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle Attacks
in Tunneled Authentication Protocols", Nokia Research Center,
Finland, Nov. 11, 2002, http://eprint.iacr.org/2002/163.pdf.
[2] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo,
"Network Endpoint Assessment (NEA): Overview and Requirements",
RFC 5209, June 2008.
[3] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA)
Protocol Compatible with Trusted Network Connect (TNC)", RFC
5792, March 2010.
[4] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A
Posture Broker (PB) Protocol Compatible with Trusted Network
Connect (TNC)", RFC 5793, March 2010.
[5] Sangster, P., N. Cam-Winget, and J. Salowey, "PT-TLS: A TCP-
based Posture Transport (PT) Protocol", Work in Progress,
October 2012.
[6] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT)
Protocol For EAP Tunnel Methods", Work in Progress, July 2012.
[7] Trusted Computing Group, "TCG Attestation PTS Protocol: Binding
to TNC IF-M", Version 1.0, Revision 27, August 2011.
[8] Rescorla, E., "Keying Material Exporters for Transport Layer
Security (TLS)", RFC 5705, March 2010.
[9] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for
TLS", RFC 5929, July 2010.
[10] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication
Protocol", RFC 5216, March 2008.
8. Acknowledgments
The members of the NEA Asokan Design Team were critical to the
development of this document: Nancy Cam-Winget, Steve Hanna, Joe
Salowey, and Paul Sangster.
The authors would also like to recognize N. Asokan, Valtteri Niemi,
and Kaisa Nyberg who published the original paper on this type of
attack and Pasi Eronen who extended this attack to NEA protocols.
Authors' Addresses
Joseph Salowey
Cisco Systems, Inc.
2901 3rd. Ave
Seattle, WA 98121
USA
EMail: jsalowey@cisco.com
Steve Hanna
Juniper Networks, Inc.
79 Parsons Street
Brighton, MA 02135
USA
EMail: shanna@juniper.net
ISO Plain Language
On this page
§1A Relay Attack Against Network Access Checks
The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack. This RFC describes the attack and the countermeasures that may be mounted against it. The posture transport protocols developed by the NEA working group, PT-TLS and PT-EAP, include mechanisms that can provide cryptographic-binding and identity-binding countermeasures.
NEA is built from nested protocols. The Posture Attribute (PA) protocol is nested inside the Posture Broker (PB) protocol, which is nested inside the Posture Transport (PT) protocol. Used together, they let an NEA Server assess the security posture of an endpoint, and the server may then decide whether to grant network access or use the information for other purposes.
The RFC is not a specification and it does not change any protocol. Its purpose is to show that the attack is real, to set out the defences that are available, and to say which of them the transport protocols should use. Its scope is narrow on purpose: the analysis covers this one attack, not every possible attack on NEA.
Before a device is let onto a network, the network can check that it is healthy. This RFC describes a way to cheat that check by relaying it between two machines the attacker controls, and then sets out the defences.
- Posture Transport (PT)Carries the whole exchange: PT-TLS or PT-EAP
- Posture Broker (PB)The broker protocol, such as PB-TNC
- Posture Attribute (PA)The attributes that describe the endpoint's posture
§2How the Attack Works
The NEA Asokan Attack is a variation on an attack described in a 2002 paper by Asokan, Niemi and Nyberg. In the original attack, an authorized user is tricked into authenticating to a decoy Authentication, Authorization, and Accounting (AAA) server. That decoy forwards the authentication protocol from one tunnel to another, so the real AAA server believes the messages originated from the attacker's machine and grants it access.
The NEA version of the attack works the same way with posture messages. The attacker wants to trick GoodServer into believing that DirtyEndpoint has good security posture, which could allow, for example, an infected machine onto a network where it could infect others. The attacker forwards PA messages from CleanEndpoint through BadServer to DirtyEndpoint, which sends them on to GoodServer. GoodServer is then tricked into thinking that the PA messages came from DirtyEndpoint, and therefore considers DirtyEndpoint to be clean.
Two things make the relay work. The posture messages carry no proof of which endpoint they came from, and the server has no way to tell that the exchange it is taking part in is the same one the endpoint is taking part in. Fixing either of those gaps breaks the attack.
The attacker owns two machines. A clean one answers the health check, and a dirty one forwards that answer to the server. The server believes the healthy answer came from the dirty machine and lets it in.
- PACleanEndpoint sends its posture attributes to BadServer.
- PABadServer forwards the attributes to DirtyEndpoint.
- PADirtyEndpoint passes them on, so GoodServer believes DirtyEndpoint is clean.
§3Lying Endpoints and the Measurement Agent
There are simpler attacks against NEA than the Asokan attack, such as lying endpoint attacks, where an endpoint simply lies about its posture. That is easy to do, but there are defences against it. One is the External Measurement Agent (EMA): hardware, software or firmware that is especially secure, hard to compromise, and designed to report accurately on the configuration of the endpoint it lives in. It observes and reports on critical aspects of endpoint posture, such as which security-relevant firmware and software have been loaded.
When an EMA is used, the PA messages that reliably and securely establish the endpoint's posture are exchanged between the EMA itself and a Posture Validator on the NEA Server. The Posture Collector on the endpoint, and any other intermediaries between the EMA and the Posture Validator, are not trusted; they pass messages along as untrusted intermediaries.
To make sure the EMA's messages reach the validator accurately even if the collector or another intermediary has been compromised, those PA messages must provide integrity protection, replay protection and source authentication between the EMA and the Posture Validator. Confidentiality is not needed, at least with regard to the software on the endpoint, but the integrity protection should also cover message deletion and session truncation. Organisations that have built EMAs have typically also built remote attestation protocols with these properties, such as the Trusted Computing Group's Platform Trust Service protocol binding to IF-M. Detecting lying endpoints is out of scope for NEA, but the NEA protocols have to support the technologies that make it possible, which is why they must also support countermeasures against the Asokan attack.
A device can simply lie about its own health, so some setups put the health check inside a small trusted part of the device that is hard to tamper with. The RFC says that this trusted part must still prove where its answers really came from, or the relay attack works just as well.
§4Two Ways to Bind the Answer to the Connection
The first countermeasure is identity binding. One way to mitigate the Asokan attack is to bind the identities used when the tunnel was set up into a cryptographic exchange at the PA layer. That goes a long way towards preventing the attack, but it does not bind the exchange to a specific TLS session, which is desirable. There is also no standard way to extract an identity from a TLS session, which could make implementation difficult.
The second countermeasure is cryptographic binding. The PA exchange is cryptographically bound to the PT exchange and to any keying material or privileges granted as a result of the two exchanges. This allows the NEA Server to be sure that the PA messages pertain to the same endpoint as the party that terminated the PT exchange, and that no other party gains any access or advantage from the exchange.
The two work at different levels. Identity binding says which names were used when the tunnel was created; cryptographic binding says that the posture conversation and the tunnel conversation are the same conversation. The RFC's conclusion favours the second, with the first as a possible addition, because the second is what actually prevents the messages from being carried from one endpoint to another.
Two defences are available. One mixes the names used when the secure connection was made into the health check. The other ties the health check to that exact secure connection, so a relayed answer no longer matches.
§4.2.1Where the Binding Data Can Come From
Both PT-TLS and PT-EAP involve TLS, so the RFC concentrates on TLS-based solutions that work with either transport. The TLS handshake establishes a cryptographic state between the TLS client and the TLS server, and several mechanisms can export information derived from that state. The client and server each include that information in their own calculations, which binds the instance of the tunnel into the PA protocol.
Two export mechanisms are described. Keying material export, defined in RFC 5705, lets additional secret key material be extracted from the TLS master secret. The tls-unique channel binding value, defined in RFC 5929, is data extracted from the TLS handshake finished message, and RFC 5929 defines several quantities that can be extracted from a TLS session to bind that session to other protocols.
The choice of cipher suite matters. To eliminate the possibility of a man-in-the-middle attack, and to thwart the Asokan attack when the keying material export mechanism is used, neither TLS endpoint may be in sole control of the TLS pre-master secret. Cipher suites based on key transport, such as the RSA cipher suites, do not meet this requirement, so Diffie-Hellman cipher suites such as RSA-DHE are required. The same applies when key material extracted from the tunnel is used to derive ciphering keys in another protocol, as EAP-TLS does. Finally, the EMA needs to obtain the binding data from the TLS exchange and to prove knowledge of it in an exchange that has integrity protection, source authentication and replay protection.
The value that ties the two conversations together comes from the secure connection itself. The RFC compares two ways of extracting it, and warns that the connection must use a key agreement method in which neither side alone controls the secret, or the binding proves nothing.
| Option | What it uses | Limitation |
|---|---|---|
| Identity binding | The identities used when the tunnel was set up, mixed into the posture exchange | Not tied to one specific TLS session |
| Cryptographic binding | The posture exchange tied to the transport exchange and the keys it produced | Needs the transport to be TLS |
| Keying material export | Extra secret key material taken from the TLS master secret | Key transport cipher suites are ruled out |
| tls-unique | Data taken from the TLS handshake finished message | The RFC's preferred approach |
§5Conclusions and Recommendations
The RFC makes three recommendations. Protocols should make use of cryptographic binding, and binding the identities of the tunnel endpoints in the EMA may also be useful. In particular, the layer 2 and layer 3 TLS-based posture transports, PT-TLS and PT-EAP, should use the same cryptographic binding mechanism. The preferred approach is to use the tls-unique channel binding value, which will be made available to the EMA that will use it. This approach can use any TLS cipher suite based on a strong cipher algorithm, because it does not depend on the keying material export mechanism.
On security, the RFC is explicit about its own limits. Analysing and proposing countermeasures for the NEA Asokan Attack does not mean it covers all the possible attacks against the NEA protocols or the NEA Reference Model. For a broader security analysis, the reader is pointed to the Security Considerations sections of the NEA Overview, PA-TNC, PB-TNC, PT-TLS and PT-EAP.
The RFC's advice is to tie the health check to the secure connection in one consistent way across the transport protocols, using a value taken from the TLS handshake. It also says plainly that it has analysed one attack, not all of them.