wdiff rfc6813.original rfc6813.txt

Network Working Group
Internet Engineering Task Force (IETF) J. Salowey
Internet Draft
Request for Comments: 6813 Cisco Systems
Intended status:
Category: Informational S. Hanna
Expires: April 2013
ISSN: 2070-1721 Juniper Networks
October 19,
November 2012

NEA

The Network Endpoint Assessment (NEA) Asokan Attack Analysis
draft-ietf-nea-asokan-02.txt

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 This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product 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
(IETF). It represents the consensus of six
months the IETF community. It has
received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
Internet Engineering Steering Group (IESG). Not all documents
at
approved by the IESG are a candidate for any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list level of Internet
Standard; see Section 2 of RFC 5741.

Information about the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list status of Internet-Draft Shadow Directories can this document, any errata,
and how to provide feedback on it may be accessed obtained at
http://www.ietf.org/shadow.html

This Internet-Draft will expire on April 19, 2013.
http://www.rfc-editor.org/info/rfc6813.

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 Introduction ....................................................2
2. NEA Asokan Attack Explained....................................2 Explained .....................................2
3. Lying Endpoints................................................4 Endpoints .................................................4
4. Countermeasures Against The against the NEA Asokan Attack..................4 Attack ...................4
4.1. Identity Binding..........................................4 Binding ...........................................4
4.2. Cryptographic Binding.....................................5 Binding ......................................5
4.2.1. Binding Options......................................5 Options .....................................5
5. Conclusions....................................................6 Conclusions .....................................................6
6. IANA Considerations............................................6
7. Security Considerations........................................6
8. References.....................................................6
8.1. Considerations .........................................6
7. Informative References....................................6
9. Acknowledgments................................................7 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 Posture Transport (PT) protocols developed by
the NEA working group, PT-TLS [5] and PT-EAP [6], include mechanisms
that can provide cryptographic binding cryptographic-binding and identity binding 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
AAA 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
attacker-controlled machine. As a
result result, the real AAA server grants
access to the attacker controlled attacker-controlled machine.

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 PA Posture Attribute (PA)
protocol is nested in the PB Posture Broker (PB) protocol, which is
nested in the PT protocol. When used together successfully, these
protocols allow a 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 granted, or it may use this information for
other purposes.

Figure 2 illustrates a an NEA Asokan Attack. The attacker wants to
trick GoodServer into believing that DirtyEndpoint has good security
posture. This might allow allow, for example, the attacker to bring an
infected machine onto a network and infect others, for example. 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 a an NEA Asokan Attack are described in section 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 But, there are defenses against lying endpoint attacks,
such as using an external measurement agent 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 but to be especially secure and
hard to compromise.
configuration. The EMA observes and reports on critical aspects of
endpoint posture posture, such as which security-relevant firmware and
software has 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 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 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. TCG's PTS (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 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 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

One

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 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 transport, such as RSA cipher suites suites, do not meet this
requirement, instead
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 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 lower-layer
ciphering. In this case case, the extracted keys must not be under the
control of a single party party, so the considerations in the previous
section are important.

4.2.1.4. EMA assumptions 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 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, binding; in addition 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. (e.g., PT-TLS
and PT-EAP) should use the same cryptographic binding mechanism mechanism.

3. The preferred approach is to use the tls-unique channel binding
data from RFC 5929 [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. IANA Considerations

This document has no actions for IANA.

7. 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
PA-TNC [3], PB-TNC [4], PT-TLS [5], and PT-EAP [6].

8. References

8.1.

7. Informative References

[1] N. Asokan, Valtteri N., Niemi, Kaisa V., and K. Nyberg, "Man in the Middle "Man-in-the-Middle Attacks
in Tunneled Authentication Protocols", Nokia Research Center,
Finland, Nov. 11, 2002,
http://eprint.iacr.org/2002/163.pdf 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., 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", draft-ietf-nea-pt-tls-
07.txt (work Work in progress), August Progress,
October 2012.

[6] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT)
Protocol For EAP Tunnel Methods", draft-ietf-nea-pt-eap-
03.txt (work Work in progress), 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.

This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

Joseph Salowey
Cisco Systems, Inc.
2901 3rd. Ave
Seattle, WA 98121
USA
Email:
EMail: jsalowey@cisco.com

Steve Hanna
Juniper Networks, Inc.
79 Parsons Street
Brighton, MA 02135
USA
Email:
EMail: shanna@juniper.net