Internet Engineering Task Force (IETF) J. Salowey
Request for Comments: 6813 Cisco Systems
Category: Informational S. Hanna
ISSN: 2070-1721 Juniper Networks
December 2012
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
网络端点评估（NEA）Asokan攻击分析
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.
网络端点评估（NEA）协议受到一种被称为NEA Asokan攻击的微妙转发攻击。本文件描述了可能采取的攻击和对策。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
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.
网络端点评估（NEA）[2]协议受到被称为NEA Asokan攻击的微妙转发攻击。本文件描述了可能采取的攻击和对策。NEA工作组PT-TLS[5]和PT-EAP[6]开发的姿态传输（PT）协议包括可提供密码绑定和身份绑定对抗的机制。
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.
NEA-Asokan攻击是Asokan、Niemi和Nyberg[1]在2002年撰写的论文中描述的攻击的变体。图1描述了原始Asokan攻击的一个版本。此攻击涉及诱使授权用户向诱饵身份验证、授权和记帐（AAA）服务器进行身份验证，该服务器将身份验证协议从一个隧道转发到另一个隧道，诱使真实的AAA服务器相信这些消息来自攻击者控制的机器。因此，真正的AAA服务器授予攻击者控制的机器访问权限。
+-------------+ ========== +----------+
| Attacker |-AuthProto--|AAA Server|
+-------------+ ========== +----------+
|
AuthProto
|
+--------------+ ========== +----------------+
|AuthorizedUser|-AuthProto--|Decoy AAA Server|
+--------------+ ========== +----------------+
+-------------+ ========== +----------+
| Attacker |-AuthProto--|AAA Server|
+-------------+ ========== +----------+
|
AuthProto
|
+--------------+ ========== +----------------+
|AuthorizedUser|-AuthProto--|Decoy AAA Server|
+--------------+ ========== +----------------+
Figure 1: One Example of Original Asokan Attack
图1：原始Asokan攻击的一个示例
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.
如NEA概述[2]所述，NEA参考模型由多个嵌套协议组成。姿态属性（PA）协议嵌套在姿态代理（PB）协议中，该协议嵌套在PT协议中。当成功地结合使用时，这些协议允许NEA服务器评估端点的安全态势。NEA服务器可以使用此信息来决定是否应授予网络访问权限，或者将此信息用于其他目的。
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.
图2显示了NEA Asokan攻击。攻击者想欺骗GoodServer，使其相信DirtyEndpoint具有良好的安全态势。例如，这可能允许攻击者将受感染的计算机带到网络上并感染其他计算机。为了实现这一目标，攻击者将PA消息从CleanEndpoint通过BadServer转发到DirtyEndpoint，再由DirtyEndpoint发送到GoodServer。GoodServer被欺骗，认为PA消息来自DirtyEndpoint，因此认为DirtyEndpoint是干净的。
+-------------+ ========== +----------+
|DirtyEndpoint|-----PA-----|GoodServer|
+-------------+ ========== +----------+
|
PA
|
+-------------+ ========== +---------+
|CleanEndpoint|-----PA-----|BadServer|
+-------------+ ========== +---------+
+-------------+ ========== +----------+
|DirtyEndpoint|-----PA-----|GoodServer|
+-------------+ ========== +----------+
|
PA
|
+-------------+ ========== +---------+
|CleanEndpoint|-----PA-----|BadServer|
+-------------+ ========== +---------+
Figure 2: NEA Asokan Attack
图2:NEA Asokan攻击
Countermeasures against an NEA Asokan Attack are described in Section 4.
第4节描述了针对NEA Asokan攻击的对策。
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).
有些人可能会认为，针对NEA系统的其他攻击比Asokan攻击更简单，例如说谎端点攻击。这是真的。端点很容易就其姿势撒谎。但是，存在针对说谎端点攻击的防御措施，例如使用外部度量代理（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.
EMA是一种硬件、软件或固件，特别安全、不易泄露，设计用于准确报告端点配置。EMA观察并报告端点姿态的关键方面，例如加载了哪些安全相关固件和软件。
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.
当EMA用于NEA时，在EMA本身和NEA服务器上的姿势验证器之间交换可靠且安全地建立端点姿势的PA消息。端点上的姿态采集器以及EMA和NEA服务器上的姿态验证器之间的任何其他中介不受信任。它们只是作为不受信任的中介传递消息。
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.
为确保将EMA的消息准确传达给姿势验证器，即使姿势收集器或其他中介已被破坏，这些PA消息必须在EMA和姿势验证器之间提供完整性保护、重播保护和源身份验证。不需要保密保护，至少对于端点上的软件而言，但完整性保护应包括防止消息删除和会话截断的保护。开发了EMA的组织通常开发了提供这些属性的远程认证协议（例如，与IF-M绑定的可信计算组（TCG）平台信任服务（PTS）协议[7]）。虽然NEA无法开发卧位端点检测技术，但这些技术必须得到NEA协议的支持。因此，NEA协议必须支持针对NEA Asokan攻击的对策。
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.
缓解Asokan攻击的一种方法是将隧道建立中使用的身份绑定到PA层的加密交换中。虽然这可以大大防止攻击，但它不会将exchange绑定到特定的TLS exchange，这是可取的。此外，没有从TLS会话中提取身份的标准方法，这可能会使实现变得困难。
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.
另一种挫败NEA Asokan攻击的方法是将PA交换以加密方式绑定到PT交换以及由于这两种交换而授予的任何密钥材料或特权。这允许NEA服务器确保PA消息与终止PT交换的一方属于同一个端点，并且没有其他方从该交换中获得任何访问权或优势。
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.
本节讨论绑定协议解决方案选项并提供分析。由于PT-TLS和PT-EAP涉及TLS，因此本文档重点介绍基于TLS的解决方案，这些解决方案可以与任何一种传输方式一起使用。
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.
TLS握手在TLS客户端和TLS服务器之间建立加密状态。有几种机制可用于导出从此状态派生的信息。客户端和服务器独立地在计算中包含此信息，以将隧道实例绑定到PA协议中。
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.
密钥材料导出-RFC 5705[8]定义了TLS的密钥材料导出器，允许从TLS主密钥中提取额外的密钥材料。
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.
tls唯一通道绑定数据-RFC 5929[9]定义了几个可以从tls会话中提取的量，以将tls会话绑定到其他协议。tls唯一绑定由从tls握手完成消息中提取的数据组成。
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.
为了消除中间人攻击的可能性，并在使用密钥材料导出绑定导出机制时挫败Asokan攻击，两个TLS端点都不能单独控制TLS主密钥。基于密钥传输的密码套件（如RSA密码套件）不符合此要求；相反，当采用这种机制时，需要Diffie-Hellman密码套件，如RSA-DHE。
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.
在某些情况下，密钥材料从TLS隧道中提取，并用于导出另一协议中使用的加密密钥。例如，EAP-TLS[10]在较低层加密中使用从TLS中提取的关键材料。在这种情况下，提取的密钥不能由一方控制，因此前一节中的注意事项很重要。
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.
EMA需要从TLS交换中获取绑定数据，并在具有完整性保护、源身份验证和重播保护的交换中证明对绑定数据的了解。
The recommendations for addressing the NEA Asokan Attack are as follows:
应对NEA Asokan攻击的建议如下：
1. Protocols should make use of cryptographic binding; in addition, binding identities of the tunnel endpoints in the EMA may be useful.
1. 协议应使用加密绑定；此外，EMA中隧道端点的绑定标识可能有用。
2. In particular, L2 and L3 TLS-based PT transports (e.g., PT-TLS and PT-EAP) should use the same cryptographic binding mechanism.
2. 特别是，基于L2和L3 TLS的PT传输（例如，PT-TLS和PT-EAP）应使用相同的加密绑定机制。
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.
3. 首选方法是使用[9]中的tls唯一通道绑定数据。tls唯一值将提供给将使用它的EMA。这种方法可以利用任何基于强密码算法的TLS密码套件。
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].
本文件主要涉及分析和提出NEA Asokan攻击的对策。这并不意味着它涵盖了针对NEA协议或NEA参考模型的所有可能攻击。有关更广泛的安全分析，请参见NEA概述[2]、PA-TNC[3]、PB-TNC[4]、PT-TLS[5]和PT-EAP[6]中的安全注意事项部分。
[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.
[1] Asokan，N.，Niemi，V.，和K.Nyberg，“隧道认证协议中的中间人攻击”，诺基亚研究中心，芬兰，2002年11月11日，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.
[2] Sangster，P.，Khosravi，H.，Mani，M.，Narayan，K.，和J.Tardo，“网络端点评估（NEA）：概述和要求”，RFC 52092008年6月。
[3] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
[3] Sangster，P.和K.Narayan，“PA-TNC：与可信网络连接（TNC）兼容的姿态属性（PA）协议”，RFC 57922010年3月。
[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.
[4] Sahita，R.，Hanna，S.，Hurst，R.，和K.Narayan，“PB-TNC：与可信网络连接（TNC）兼容的姿态代理（PB）协议”，RFC 5793，2010年3月。
[5] Sangster, P., N. Cam-Winget, and J. Salowey, "PT-TLS: A TCP-based Posture Transport (PT) Protocol", Work in Progress, October 2012.
[5] Sangster，P.，N.Cam Winget和J.Salowey，“PT-TLS：基于TCP的姿态传输（PT）协议”，正在进行的工作，2012年10月。
[6] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Work in Progress, July 2012.
[6] Cam Winget，N.和P.Sangster，“PT-EAP：EAP隧道方法的姿态传输（PT）协议”，正在进行的工作，2012年7月。
[7] Trusted Computing Group, "TCG Attestation PTS Protocol: Binding to TNC IF-M", Version 1.0, Revision 27, August 2011.
[7] 可信计算小组，“TCG认证PTS协议：与TNC IF-M的绑定”，1.0版，第27版，2011年8月。
[8] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.
[8] Rescorla，E.，“传输层安全（TLS）关键材料出口商”，RFC 57052010年3月。
[9] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[9] Altman，J.，Williams，N.，和L.Zhu，“TLS的通道绑定”，RFC 59292010年7月。
[10] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[10] Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，2008年3月。
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.
NEA Asokan设计团队的成员对本文件的编制至关重要：南希·坎温杰、史蒂夫·汉娜、乔·萨洛维和保罗·桑斯特。
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.
作者还想感谢N.Asokan、Valtteri Niemi和Kaisa Nyberg，他们发表了关于此类攻击的原始论文，以及Pasi Eronen，他们将这种攻击扩展到了NEA协议。
Authors' Addresses
作者地址
Joseph Salowey Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA EMail: jsalowey@cisco.com
Joseph Salowey Cisco Systems，Inc.2901第3页。华盛顿州西雅图大道98121美国电子邮件：jsalowey@cisco.com
Steve Hanna Juniper Networks, Inc. 79 Parsons Street Brighton, MA 02135 USA EMail: shanna@juniper.net
Steve Hanna Juniper Networks，Inc.美国马萨诸塞州布莱顿帕森斯街79号02135电子邮件：shanna@juniper.net