[要約] RFC 6813は、ネットワークエンドポイント評価（NEA）のAsokan攻撃分析に関するものであり、その目的はAsokan攻撃の特徴と影響を調査し、ネットワークセキュリティの向上に役立つ情報を提供することです。
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）麻生攻撃分析
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 Attackとして知られるようになった微妙な転送攻撃の影響を受けます。このドキュメントでは、実装される可能性のある攻撃と対策について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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.
Network Endpoint Assessment（NEA）[2]プロトコルは、NEA Asokan Attackとして知られるようになった微妙な転送攻撃の影響を受けます。このドキュメントでは、実装される可能性のある攻撃と対策について説明します。 NEAワーキンググループによって開発されたポスチャトランスポート（PT）プロトコルであるPT-TLS [5]およびPT-EAP [6]には、暗号バインディングおよびアイデンティティバインディングの対策を提供できるメカニズムが含まれています。
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 Attackは、Asokan、Niemi、およびNybergによって書かれた2002年の論文に記載されている攻撃のバリエーションです[1]。図1は、元の阿蘇館攻撃の1つのバージョンを示しています。この攻撃には、認証済みユーザーをだまし、認証、承認、およびアカウンティング（AAA）サーバーへの認証に誘い、認証プロトコルをあるトンネルから別のトンネルに転送し、実際のAAAサーバーをだまして、攻撃者が制御するマシンから発信されたこれらのメッセージを信じ込ませます。 。その結果、実際のAAAサーバーは、攻撃者が制御するマシンへのアクセスを許可します。
+-------------+ ========== +----------+
| Attacker |-AuthProto--|AAA Server|
+-------------+ ========== +----------+
|
AuthProto
|
+--------------+ ========== +----------------+
|AuthorizedUser|-AuthProto--|Decoy AAA Server|
+--------------+ ========== +----------------+
Figure 1: One Example of Original Asokan Attack
図1：元の阿蘇館攻撃の一例
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）プロトコルは、PTプロトコルにネストされているポスチャブローカ（PB）プロトコルにネストされています。これらのプロトコルを一緒に使用すると、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麻生攻撃を示しています。攻撃者は、GoodServerをだまして、DirtyEndpointのセキュリティ状態が良好であると信じ込ませたいと考えています。これにより、たとえば、攻撃者は感染したマシンをネットワークに持ち込み、他のマシンに感染する可能性があります。この目標を達成するために、攻撃者はCleanEndpointからBadServerを経由してPAメッセージをDirtyEndpointに転送し、DirtyEndpointがGoodServerに送信します。 GoodServerは、PAメッセージがDirtyEndpointから送信されたものだと勘違いして、DirtyEndpointがクリーンであると見なします。
+-------------+ ========== +----------+
|DirtyEndpoint|-----PA-----|GoodServer|
+-------------+ ========== +----------+
|
PA
|
+-------------+ ========== +---------+
|CleanEndpoint|-----PA-----|BadServer|
+-------------+ ========== +---------+
Figure 2: NEA Asokan Attack
図2：NEW阿蘇館アタック
Countermeasures against an NEA Asokan Attack are described in Section 4.
NEA阿蘇館攻撃への対策については、4章で述べる。
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).
一部の人は、嘘つきエンドポイント攻撃など、Asokan攻撃よりも単純なNEAシステムに対する他の攻撃があると主張するかもしれません。それは本当です。エンドポイントがその姿勢について単に嘘をつくことは簡単です。ただし、外部測定エージェント（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に使用される場合、エンドポイントポスチャを確実かつ安全に確立するPAメッセージは、EMA自体とNEAサーバーのポスチャバリデーターの間で交換されます。エンドポイントのポスチャコレクタ、および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を開発した組織は、通常、これらのプロパティを提供するリモート認証プロトコルを開発しています（例：Trusted Computing Group（TCG）のプラットフォームトラストサービス（PTS）プロトコルのIF-Mへのバインド[7]）。嘘つきエンドポイント検出テクノロジーの開発はNEAの範囲外ですが、これらのテクノロジーはNEAプロトコルでサポートされている必要があります。そのため、NEAプロトコルは、NEA Asokan Attackに対する対策をサポートする必要があります。
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攻撃を軽減する1つの方法は、トンネルの確立に使用されるIDをPA層の暗号交換にバインドすることです。これは攻撃を防ぐのに役立ちますが、交換を特定のTLS交換にバインドしないため、望ましい方法です。さらに、TLSセッションからIDを抽出する標準的な方法がないため、実装が困難になる可能性があります。
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交換と、これら2つの交換の結果として付与されたすべてのキー関連情報または特権に暗号でバインドすることです。これにより、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.
Keying Material Export-RFC 5705 [8]では、TLSのKeying Material Exportersを定義して、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-unique Channel Binding Data-RFC 5929 [9]は、TLSセッションから抽出してTLSセッションを他のプロトコルにバインドできるいくつかの量を定義しています。 tls-uniqueバインディングは、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.
キーイングマテリアルエクスポートバインディングエクスポートメカニズムを使用しているときに中間者攻撃の可能性を排除し、麻生館攻撃を阻止するには、どちらのTLSエンドポイントもTLSプリマスターシークレットを単独で制御しないことが重要です。 RSA暗号スイートなどのキー転送に基づく暗号スイートは、この要件を満たしていません。代わりに、このメカニズムを使用する場合は、RSA-DHEなどのDiffie-Hellman暗号スイートが必要です。
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 Attackに対処するための推奨事項は次のとおりです。
1. Protocols should make use of cryptographic binding; in addition, binding identities of the tunnel endpoints in the EMA may be useful.
1. プロトコルは暗号バインディングを利用する必要があります。さらに、EMA内のトンネルエンドポイントのバインドIDが役立つ場合があります。
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-unique値は、それを使用する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麻生攻撃の分析と対策の提案に関係しています。これは、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、「Network Endpoint Assessment（NEA）：Overview and Requirements」、RFC 5209、2008年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：A Posture Attribute（PA）Protocol Compatible with Trusted Network Connect（TNC）」、RFC 5792、2010年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：A Posture Broker（PB）Protocol Compatible with Trusted Network Connect（TNC）」、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：A TCP-based Posture Transport（PT）Protocol」、Work in Progress、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：Posture Transport（PT）Protocol For EAP Tunnel Methods」、Work in Progress、2012年7月。
[7] Trusted Computing Group, "TCG Attestation PTS Protocol: Binding to TNC IF-M", Version 1.0, Revision 27, August 2011.
[7] Trusted Computing Group、「TCG Attestation PTS Protocol：Binding to 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 5705、2010年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 5929、2010年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、「The EAP-TLS Authentication Protocol」、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 Design Teamのメンバーは、このドキュメントの開発に不可欠でした。NancyCam-Winget、Steve Hanna、Joe Salowey、および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.
著者はまた、このタイプの攻撃に関する最初の論文を発表したN. Asokan、Valtteri Niemi、Kaisa Nyberg、およびこの攻撃をNEAプロトコルに拡張したPasi Eronenを認識したいと思います。
Authors' Addresses
著者のアドレス
Joseph Salowey Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA EMail: jsalowey@cisco.com
ジョセフSaloweyシスコシステムズ社2901 3位。 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
Steve Hanna Juniper Networks、Inc. 79 Parsons Street Brighton、MA 02135 USAメール：shanna@juniper.net