[要約] RFC 7029は、Extensible Authentication Protocol (EAP)の相互暗号バインディングに関する技術仕様を定めた文書です。このRFCの目的は、EAP認証プロセス中に、クライアントとサーバー間で相互に認証情報を確認し、保護するための暗号的なバインディング手法を提供することにあります。これは、特に無線LANやVPN接続など、セキュリティが重要視される環境での認証強化に利用されます。関連するRFCには、EAPの基本を定めたRFC 3748や、EAPの様々なメソッドを拡張するためのRFC 5247などがあります。
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7029 M. Wasserman
Category: Informational Painless Security
ISSN: 2070-1721 D. Zhang
Huawei
October 2013
Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding
拡張認証プロトコル（EAP）相互暗号バインディング
Abstract
概要
As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.
拡張認証プロトコル（EAP）が進化するにつれて、EAPピアは、EAPサーバーから受信した情報にますます依存するようになります。チャネルバインディングやネットワークポスチャ情報などのEAP拡張機能は、多くの場合、トンネル方式で伝送されます。ピアはこの情報に依存する可能性があります。暗号バインディングはRFC 3748で説明されている機能であり、トンネル方式を中間者攻撃から保護します。ただし、暗号バインディングは、ピアではなくサーバーの保護に重点を置いています。このメモは、ピアが中間者攻撃から保護されていない場合に発生する可能性のある攻撃を調査し、拡張マスターセッションキーに基づく暗号バインディングを推奨します。これは、ピアとサーバーの両方を他の緩和策とともに保護する新しい形式の暗号バインディングです。
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/rfc7029.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7029で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 ....................................................3
1.1. Keywords for Requirement Levels ............................5
2. An Example Problem ..............................................5
3. The Server Insertion Attack .....................................6
3.1. Conditions for the Attack ..................................7
3.2. Mitigation Strategies ......................................8
3.2.1. Server Authentication ...............................8
3.2.2. Server Policy .......................................9
3.2.3. Existing Cryptographic Binding .....................12
3.2.4. Introducing EMSK-Based Cryptographic Binding .......12
3.2.5. Mix Key into Long-Term Credentials .................14
3.3. Intended Intermediates ....................................14
4. Recommendations ................................................15
4.1. Mutual Cryptographic Binding ..............................15
4.2. State Tracking ............................................15
4.3. Certificate Naming ........................................16
4.4. Inner Mixing ..............................................16
5. Survey of Tunnel Methods .......................................16
5.1. Tunnel EAP (TEAP) Method ..................................16
5.2. Flexible Authentication via Secure Tunneling (FAST) .......17
5.3. EAP Tunneled Transport Layer Security (EAP-TTLS) ..........17
6. Security Considerations ........................................17
7. Acknowledgements ...............................................18
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
The Extensible Authentication Protocol (EAP) [RFC3748] provides authentication between a peer (a party accessing some service) and a authentication server. Traditionally, peers have not relied significantly on information received from EAP servers. However, facilities such as EAP channel binding [RFC6677] provide the peer with confirmation of information about the resource it is accessing. Other facilities such as EAP Posture Transport [PT-EAP] permit a peer and EAP server to discuss the security properties of accessed networks. Both of these facilities provide peers with information they need to rely on and provide attackers who are able to impersonate an EAP server to a peer with new opportunities for attack.
拡張認証プロトコル（EAP）[RFC3748]は、ピア（サービスにアクセスするパーティ）と認証サーバー間の認証を提供します。従来、ピアはEAPサーバーから受信した情報に大きく依存していませんでした。ただし、EAPチャネルバインディング[RFC6677]などの機能は、ピアがアクセスしているリソースに関する情報の確認をピアに提供します。 EAPポスチャトランスポート[PT-EAP]などの他の機能を使用すると、ピアとEAPサーバーがアクセスしたネットワークのセキュリティプロパティについて議論できます。これらの機能はどちらも、ピアに依存する必要のある情報をピアに提供し、ピアにEAPサーバーを偽装できる攻撃者に新しい攻撃の機会を提供します。
Instead of adding these new facilities to all EAP methods, work has focused on adding support to tunnel methods [RFC6678]. There are numerous tunnel methods, including [RFC4851] and [RFC5281], and work on building a Standards Track tunnel method [TEAP]. These tunnel methods are extensible. By adding an extension to support a facility such as channel binding to a tunnel method, an extension can be used with any inner method carried in the tunnel.
これらの新しいファシリティをすべてのEAPメソッドに追加する代わりに、トンネルメソッドへのサポートの追加に焦点が当てられています[RFC6678]。 [RFC4851]や[RFC5281]を含む多数のトンネル方式があり、Standards Trackトンネル方式[TEAP]の構築に取り組んでいます。これらのトンネル方式は拡張可能です。トンネルメソッドへのチャネルバインディングなどの機能をサポートする拡張機能を追加することにより、拡張機能は、トンネルで実行される任意の内部メソッドで使用できます。
Tunnel methods need to be careful about man-in-the-middle attacks. See [RFC6678] (Sections 3.2 and 4.6.3) and [TUNNEL-MITM] for a detailed description of these attacks. For example, an attack can happen when a peer is willing to perform authentication inside and outside a tunnel. An attacker can impersonate the EAP server and offer the inner method to the peer. However, on the other side, the attacker acts as a man-in-the-middle and opens a tunnel to the real EAP server. Figure 1 illustrates this attack. At the end of the attack, the EAP server believes it is talking to the peer. At the inner method level, this is true. At the outer method level, however, the server is talking to the attacker.
トンネル方式では、中間者攻撃に注意する必要があります。これらの攻撃の詳細については、[RFC6678]（セクション3.2および4.6.3）および[TUNNEL-MITM]を参照してください。たとえば、ピアがトンネルの内外で認証を実行しようとする場合、攻撃が発生する可能性があります。攻撃者はEAPサーバーになりすまし、内部メソッドをピアに提供できます。ただし、反対側では、攻撃者は中間者として機能し、実際のEAPサーバーへのトンネルを開きます。図1は、この攻撃を示しています。攻撃の終わりに、EAPサーバーはピアと通信していると考えます。内部メソッドレベルでは、これは真実です。ただし、外部メソッドレベルでは、サーバーは攻撃者と通信しています。
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+-------X-------->| |
| (Intercepted by an Attacker) | |
| | | |
| | Tunnel Establishment |
| |<-------------------------------->|
| | | |
| |..................................|
| | Tunnel |
| Non-Tunneled | | |
| Method | Tunneled Authentication Method |
|<===================>|<================================>|
| | | |
| |..................................|
| | | |
| | Attacker |<--- MSK keys --|
| | Connected as | |
| | Peer | |
| |<--------------->| |
A classic tunnel attack where the attacker inserts an extra tunnel between the attacker and EAP server.
攻撃者とEAPサーバーの間に追加のトンネルを挿入する、古典的なトンネル攻撃。
Figure 1: Classic Tunnel Attack
図1：クラシックトンネル攻撃
There are two mitigation strategies for this classic attack. First, security policy can be set up so that the same method is not offered by a server both inside and outside a tunnel. Second, a technical solution is available if the inner method is sufficiently strong: cryptographic binding is a security property of a tunnel method under which the EAP server confirms that the inner and outer parties are the same. Cryptographic binding is typically implemented by requiring the outer party (the other end of the tunnel) to prove knowledge of the Master Session Key (MSK) of the inner method. This proves to the server that the inner and outer exchanges are with the same party. RFC 3748's definition of cryptographic binding allows for an optional proof to the peer that the inner and outer exchanges are with the same party. As discussed below, proving knowledge of the MSK is insufficient to prove to the peer that the inner and outer exchanges are with the same party.
この古典的な攻撃には、2つの緩和戦略があります。まず、セキュリティポリシーを設定して、同じ方法がトンネルの内外のサーバーで提供されないようにすることができます。 2つ目は、内部方式が十分に強力な場合に技術的な解決策を利用できることです。暗号化バインディングはトンネル方式のセキュリティプロパティであり、EAPサーバーは内部と外部の関係者が同じであることを確認します。暗号バインディングは通常、内部メソッドのマスターセッションキー（MSK）の知識を証明するように外部パーティ（トンネルのもう一方の端）に要求することによって実装されます。これは、内部と外部の交換が同じパーティと行われていることをサーバーに証明します。 RFC 3748の暗号化バインディングの定義により、内部と外部の交換が同じ関係者であるというピアへのオプションの証明が可能になります。以下で説明するように、MSKの知識を証明することは、内部と外部の交換が同じパーティであることをピアに証明するには不十分です。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The GSS-EAP (Generic Security Service Extensible Authentication Protocol) mechanism [GSS-EAP] provides application authentication using EAP. A peer could reasonably trust some applications significantly more than others. If the peer sends confidential information to some applications, an attacker may gain significant value from convincing the peer that the attacker is the trusted application. Channel bindings are used to provide information to the peer about the application service to which the peer connects. Prior to channel bindings, peers could not distinguish one Network Access Service (NAS) from another, so attacks where one NAS impersonated another were out of scope. However, channel bindings add this capability and thus expands the threat model of EAP. The GSS-EAP mechanism requires distinguishing one service from another.
GSS-EAP（Generic Security Service Extensible Authentication Protocol）メカニズム[GSS-EAP]は、EAPを使用したアプリケーション認証を提供します。ピアは、一部のアプリケーションを他のアプリケーションよりもかなり信頼できるでしょう。ピアが機密情報をいくつかのアプリケーションに送信する場合、攻撃者は、攻撃者が信頼されたアプリケーションであることをピアに説得することで大きな価値を得る可能性があります。チャネルバインディングは、ピアが接続するアプリケーションサービスに関する情報をピアに提供するために使用されます。チャネルバインディングの前は、ピアはネットワークアクセスサービス（NAS）を別のNASと区別できなかったため、あるNASが別のNASになりすました攻撃は対象外でした。ただし、チャネルバインディングによってこの機能が追加され、EAPの脅威モデルが拡張されます。 GSS-EAPメカニズムでは、サービスを区別する必要があります。
Consider the following example. A relatively untrusted service, say a print server, has been compromised. A user is attempting to connect to a trusted service such as a financial application. Both the print server and the financial application use an Authentication, Authorization, and Accounting protocol (AAA) to transport EAP authentication back to the user's EAP server. The print server mounts a man-in-the-middle attack on the user's connection to the financial application and claims to be the application.
次の例を考えてみましょう。比較的信頼できないサービス、たとえばプリントサーバーが侵害されました。ユーザーが金融アプリケーションなどの信頼できるサービスに接続しようとしています。プリントサーバーと金融アプリケーションはどちらも、認証、承認、会計プロトコル（AAA）を使用して、EAP認証をユーザーのEAPサーバーに転送します。プリントサーバーは、金融アプリケーションへのユーザーの接続に対して中間者攻撃を仕掛け、アプリケーションであると主張します。
The print server offers a tunnel method towards the peer. The print server extracts the inner method from the tunnel and sends it on towards the AAA server. Channel binding happens at the tunnel method though. So, the print server is happy to confirm that it is the financial application. After the inner method completes, the EAP server sends the MSK to the print server over the AAA protocol. If only the MSK is needed for cryptographic binding, then the print server can successfully perform cryptographic binding and may be able to impersonate the financial application to the peer.
プリントサーバーは、ピアへのトンネル方式を提供します。プリントサーバーはトンネルから内部メソッドを抽出し、AAAサーバーに送信します。ただし、トンネル方式ではチャネルバインディングが発生します。したがって、プリントサーバーは、それが金融アプリケーションであることを確認できます。内部方式が完了すると、EAPサーバーはAAAプロトコルを介してMSKをプリントサーバーに送信します。 MSKのみが暗号化バインディングに必要な場合、プリントサーバーは暗号化バインディングを正常に実行でき、金融アプリケーションをピアに偽装できる可能性があります。
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| | |
|<------------------->| | |
|.....................| | |
| Tunnel | | |
| | |
| Tunneled | Non-Tunneled |
| Method | Authentication Method |
|<===================>|<================================>|
| |(Same as Inner Method from Tunnel)|
|.....................| | |
| | | |
| Peer | | |
| Connected to |<----------------------MSK keys --|
| Attacker | | |
|<------------------->| | |
| | | |
A modified tunnel attack when an extra server rather than extra client is inserted.
追加のクライアントではなく追加のサーバーが挿入された場合の変更されたトンネル攻撃。
Figure 2: Channel Binding Requires More than Cryptographic Binding
図2：チャネルバインディングには暗号化バインディング以上のものが必要
This attack is not specific to GSS-EAP. The channel bindings specification [RFC6677] describes a number of situations where channel bindings are important for network access. In these situations, one NAS could impersonate another by using a similar attack.
この攻撃はGSS-EAPに固有のものではありません。チャネルバインディング仕様[RFC6677]には、チャネルバインディングがネットワークアクセスにとって重要である多くの状況が記載されています。これらの状況では、あるNASが同様の攻撃を使用して別のNASになりすます可能性があります。
The previous section described an example of the server insertion attack. In this attack, one party adds a layer of tunneling such that from the perspective of the EAP peer, there are more methods than from the perspective of the EAP server. This attack is most beneficial when the party inserting the extra tunnel is a legitimate NAS, so mitigations need to be able to prevent a legitimate NAS from inappropriately adding a layer of tunneling. Some deployments utilize an intentional intermediary that adds an extra level of EAP tunneling between the peer and the EAP server; see Section 3.3 for a discussion.
前のセクションでは、サーバー挿入攻撃の例を説明しました。この攻撃では、一方の当事者がトンネリングの層を追加するため、EAPピアの観点からは、EAPサーバーの観点からよりも多くの方法があります。この攻撃は、追加のトンネルを挿入する当事者が正当なNASである場合に最も有益です。そのため、緩和策は、正当なNASが不適切にトンネリングレイヤーを追加するのを防ぐ必要があります。一部の展開では、意図的な仲介を利用して、ピアとEAPサーバー間のEAPトンネリングのレベルを追加します。議論についてはセクション3.3を参照してください。
For an inserted server attack to have value, the attacker needs to gain an advantage from its attack. An attacker could gain an advantage in the following ways:
挿入されたサーバー攻撃に価値があるためには、攻撃者は攻撃から利益を得る必要があります。攻撃者は次の方法で利点を得る可能性があります。
o The attacker can send information to a peer that the peer would trust from the EAP server but not the attacker. Examples of this include channel-binding responses.
o 攻撃者は、ピアがEAPサーバーから信頼する情報をピアに送信できますが、攻撃者は送信できません。この例には、チャネルバインディング応答が含まれます。
o The peer sends information to the attacker that was intended for the EAP server. For example, the inner user identity may disclose privacy-sensitive information. The channel-binding request may disclose what service the peer wishes to connect to.
o ピアは、EAPサーバー向けの情報を攻撃者に送信します。たとえば、内部ユーザーIDはプライバシーに敏感な情報を開示する場合があります。チャネルバインディング要求は、ピアが接続したいサービスを開示する場合があります。
o The attacker may influence session parameters. For example, if the attacker can influence the MSK, then the attacker may be able to read or influence session traffic and mount an attack on the confidentiality or integrity of the resulting session.
o 攻撃者はセッションパラメータに影響を与える可能性があります。たとえば、攻撃者がMSKに影響を与えることができる場合、攻撃者はセッショントラフィックを読み取ったり影響を与えたりして、結果のセッションの機密性または整合性に攻撃を仕掛けることができます。
o An attacker may impact availability of the session. In practice though, an attacker that can mount a server insertion attack is likely to be able to impact availability in other ways.
o 攻撃者はセッションの可用性に影響を与える可能性があります。ただし実際には、サーバー挿入攻撃を仕掛けることができる攻撃者は、他の方法で可用性に影響を与える可能性があります。
For this attack to be possible, the following conditions need to hold:
この攻撃を可能にするには、次の条件が満たされている必要があります。
1. The attacker needs to be able to establish a tunnel method with the peer over which the peer will authenticate.
1. 攻撃者は、ピアが認証するピアとのトンネル方式を確立できる必要があります。
2. The attacker needs to be able to respond to any inner authentication. For example, an attacker who is a legitimate NAS can forward the inner authentication over AAA towards the EAP server. Note that the inner authentication may not be EAP.
2. 攻撃者は、内部認証に応答できる必要があります。たとえば、正当なNASである攻撃者は、AAAを介して内部認証をEAPサーバーに転送できます。内部認証はEAPではない場合があることに注意してください。
3. Typically, the attacker needs to be able to complete the tunnel method after inner authentication. This may not be necessary if the attacker is gaining advantage from information sent by the peer over the tunnel.
3. 通常、攻撃者は内部認証後にトンネル方式を完了する必要があります。これは、攻撃者がトンネルを介してピアから送信された情報を利用している場合は必要ありません。
4. In some cases, the attacker may need to complete a Secure Association Protocol (SAP) or otherwise demonstrate knowledge of the MSK after the tunnel method successfully completes.
4. 場合によっては、トンネルメソッドが正常に完了した後で、攻撃者はSecure Association Protocol（SAP）を完了するか、MSKの知識を示す必要がある場合があります。
Attackers who are legitimate NASes are the primary focus of this memo. Previous work has provided mitigation against attackers who are not NASes; these mitigations are briefly discussed.
正当なNASである攻撃者がこのメモの主な焦点です。以前の研究では、NASではない攻撃者に対する緩和策が提供されています。これらの緩和策について簡単に説明します。
If the peer confirms the identity of the party that the tunnel method is established with, the peer prevents the first condition (attacker establishing a tunnel method). Many tunnel methods rely on Transport Layer Security (TLS) [RFC5281] [TEAP]. The specifications for these methods tend to encourage or mandate certificate checking. If the TLS certificate is validated back to a trust anchor and the identity of the tunnel method server confirmed, then the first attack condition cannot be met.
ピアがトンネル方式の確立に使用したパーティのIDを確認すると、ピアは最初の条件（攻撃者がトンネル方式を確立する）を防ぎます。多くのトンネル方式は、トランスポート層セキュリティ（TLS）[RFC5281] [TEAP]に依存しています。これらの方法の仕様は、証明書の確認を推奨または義務付ける傾向があります。 TLS証明書がトラストアンカーに対して検証され、トンネル方式サーバーのIDが確認された場合、最初の攻撃条件は満たされません。
Many challenges make server authentication difficult. There is not an obvious name by which to identify a tunnel method server. It is not obvious where in the tunnel server certificate the name should be found. One particularly problematic practice is to use a certificate that names the host on which the tunnel server runs. Given such a name, it is very difficult for a peer to understand whether that server is intended to be a tunnel method server for the realm.
多くの課題がサーバー認証を難しくしています。トンネル方式サーバーを識別するための明確な名前はありません。トンネルサーバー証明書のどこに名前を配置するかは明らかではありません。特に問題の多いプラクティスの1つは、トンネルサーバーが実行されているホストに名前を付ける証明書を使用することです。そのような名前が与えられた場合、ピアがそのサーバーがレルムのトンネル方式サーバーであることを意図しているかどうかを理解することは非常に困難です。
It's not clear what trust anchors to use for tunnel servers. Using commercial Certificate Authorities (CAs) is probably undesirable because tunnel servers often operate in a closed community and are often provisioned with certificates issued by that community. Using commercial CAs can be particularly problematic with peers that support hostnames in certificates. Then anyone who can obtain a certificate for any host in the domain being contacted can impersonate a tunnel server.
トンネルサーバーにどのトラストアンカーを使用するかは明確ではありません。トンネルサーバーは多くの場合、閉じたコミュニティで動作し、そのコミュニティによって発行された証明書がプロビジョニングされていることが多いため、商用認証局（CA）の使用はおそらく望ましくありません。商用CAを使用すると、証明書でホスト名をサポートするピアで特に問題が発生する可能性があります。次に、接続されているドメイン内の任意のホストの証明書を取得できるユーザーは、トンネルサーバーになりすますことができます。
These difficulties lead to poor deployment of good certificate validation. Many peers make it easy to disable certificate validation. Other peers validate back to trust anchors but do not check names of certificates. What name types are supported and what configuration is easy to perform depend significantly on the peer in question.
これらの困難は、適切な証明書検証の不十分な展開につながります。多くのピアでは、証明書の検証を簡単に無効にすることができます。他のピアはトラストアンカーを検証しますが、証明書の名前はチェックしません。サポートされている名前タイプと、実行が容易な構成は、問題のピアに大きく依存します。
Specifications also make the problem worse. For example, [RFC5281] indicates that the only impact of failing to perform certificate validation is that the inner method can be attacked. Administrators and implementors believing this claim may believe that protection from passive attacks is sufficient.
仕様も問題を悪化させます。たとえば、[RFC5281]は、証明書の検証に失敗した場合の唯一の影響は、内部のメソッドが攻撃される可能性があることを示しています。この主張を信じている管理者と実装者は、受動的攻撃からの保護で十分であると信じているかもしれません。
In addition, some deployments such as provisioning or strong inner methods are designed to work without certificate validation. Section 3.9 of the tunnel requirements document [RFC6678] discusses this requirement.
さらに、プロビジョニングや強力な内部メソッドなどの一部のデプロイメントは、証明書の検証なしで機能するように設計されています。トンネル要件ドキュメント[RFC6678]のセクション3.9は、この要件について説明しています。
Server policy can potentially prevent the second condition (attacker being able to respond to inner authentication) from being possible. If the server only performs a particular inner authentication within a tunnel, then the attacker cannot gain a response to the inner authentication without there being such a tunnel. The attacker may be able to add a second layer of tunnels; see Figure 3. The inner tunnel may limit the attacker's capabilities; for example, if channel binding is performed over tunnel t2 in the figure, then an attacker cannot observe or influence it.
サーバーポリシーにより、2番目の条件（攻撃者が内部認証に応答できる）ができなくなる可能性があります。サーバーがトンネル内で特定の内部認証のみを実行する場合、攻撃者はそのようなトンネルがなければ内部認証への応答を得ることができません。攻撃者は、トンネルの2番目の層を追加できる可能性があります。図3を参照してください。内部トンネルが攻撃者の能力を制限する可能性があります。たとえば、図のトンネルt2を介してチャネルバインディングが実行された場合、攻撃者はそれを観察したり影響したりすることはできません。
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| | |
|<------------------->| | |
|.....................| | |
| Tunnel t1 | | |
| | | |
|.......................................... .............|
| Tunnel t2 |
| |
| |
| Inner Method |
|<======================================================>|
| |
|.......................................... .............|
| | | |
|.....................| | |
| | | |
| Peer | | |
| Connected to |<----------------------MSK keys --|
| Attacker | | |
|<------------------->| | |
| | | |
A tunnel t1 from the peer to the attacker contains a tunnel t2 from the peer to the home EAP server. Inside tunnel t2 is an inner authentication.
ピアから攻撃者へのトンネルt1には、ピアからホームEAPサーバーへのトンネルt2が含まれています。内部トンネルt2は内部認証です。
Figure 3: Multiple Layered Tunnels
図3：複数の階層化されたトンネル
Peer policy can be combined with this server policy to help prevent conditions 1 (attacker can establish a tunnel the peer will use) and 2 (attacker can respond to inner authentication). If the peer requires exactly one tunnel of a particular type and the EAP server only performs inner authentication over a tunnel of this type, then the attacker cannot establish tunnel t1 in the figure above. Configuring this peer policy may be more challenging than configuring policy on the EAP server.
ピアポリシーをこのサーバーポリシーと組み合わせて、条件1（攻撃者がピアが使用するトンネルを確立できる）および2（攻撃者が内部認証に応答できる）を防ぐことができます。ピアが特定のタイプのトンネルを1つだけ必要とし、EAPサーバーがこのタイプのトンネルを介して内部認証のみを実行する場合、攻撃者は上の図のトンネルt1を確立できません。このピアポリシーの構成は、EAPサーバーでのポリシーの構成よりも難しい場合があります。
An attacker may be able to mount a more traditional man-in-the-middle attack in this instance; see Figure 4. This policy on the peer and EAP server combined with a tunnel method that supports cryptographic binding will allow the EAP server to detect the attacker. This means the attacker cannot act as a legitimate NAS and, in particular, does not obtain the MSK. So, if the tunnel between the attacker and peer also requires cryptographic binding and if the cryptographic binding requires both the EAP server and peer to prove knowledge of the inner MSK, then the authentication will fail. If cryptographic binding is not performed, then this attack may succeed.
この場合、攻撃者は従来の中間者攻撃を仕掛けることができます。図4を参照してください。ピアとEAPサーバーのこのポリシーと、暗号化バインディングをサポートするトンネル方式を組み合わせることにより、EAPサーバーは攻撃者を検出できます。これは、攻撃者が正当なNASとして行動できず、特にMSKを取得できないことを意味します。したがって、攻撃者とピア間のトンネルにも暗号化バインディングが必要であり、暗号化バインディングでEAPサーバーとピアの両方が内部MSKの知識を証明する必要がある場合、認証は失敗します。暗号バインディングが実行されない場合、この攻撃は成功する可能性があります。
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| Tunnel Establishment |
|<------------------->|<-------------------------------->|
|.....................|.................... .............|
| Tunnel t1 | Tunnel t2 |
| | |
| Tunneled | |
| Method | Tunneled Method |
|<===================>|<================================>|
| | |
|.....................|..................................|
| | | |
| Peer | | |
| Connected to | | |
| Attacker | | |
|<------------------->| | |
| | | |
A tunnel t1 extends from the peer to the attacker. A tunnel t2 extends from the attacker to the home EAP server. An inner EAP authentication is forwarded unmodified by the attacker from tunnel t1 to tunnel t2. The attacker can observe this inner authentication.
トンネルt1は、ピアから攻撃者まで伸びています。トンネルt2は、攻撃者からホームEAPサーバーまで伸びています。内部EAP認証は、攻撃者によって変更されずにトンネルt1からトンネルt2に転送されます。攻撃者はこの内部認証を観察できます。
Figure 4: A Traditional Man-in-the-Middle Attack
図4：従来の中間者攻撃
Cryptographic binding is only a valuable component of a defense if the inner authentication is a key-deriving EAP method. Most tunnel methods also support non-EAP inner authentication such as Microsoft CHAP version 2 [RFC2759]. This may undermine cryptographic binding in a number of ways. An attacker may be able to convert an EAP method into a compatible non-EAP form of the same credential to suppress cryptographic binding. In addition, an inner authentication may be available through an entirely different means. For example, a Lightweight Directory Access Protocol [RFC4510] or other directory server may provide an attacker a way to get challenges and provide responses for an authentication mechanism entirely outside of the AAA/EAP context. An attacker with this capability may be able to get around server policy requiring an inner authentication be used only in a given type of tunnel.
内部認証がキー派生EAP方式である場合、暗号化バインディングは防御の貴重なコンポーネントにすぎません。ほとんどのトンネル方式は、Microsoft CHAPバージョン2 [RFC2759]などの非EAP内部認証もサポートしています。これは、いくつかの方法で暗号バインディングを弱体化させる可能性があります。攻撃者は、EAPメソッドを同じ資格情報の互換性のある非EAP形式に変換して、暗号バインディングを抑制できる可能性があります。さらに、内部認証は、まったく異なる手段で利用できる場合があります。たとえば、ライトウェイトディレクトリアクセスプロトコル[RFC4510]または他のディレクトリサーバーは、攻撃者にチャレンジを取得し、AAA / EAPコンテキストの外部で認証メカニズムの応答を提供する可能性があります。この機能を持つ攻撃者は、内部認証を特定のタイプのトンネルでのみ使用することを要求するサーバーポリシーを回避できる可能性があります。
To recap, the following policy conditions appear sufficient to prevent a server insertion attack:
要約すると、次のポリシー条件は、サーバー挿入攻撃を防ぐのに十分であるように見えます。
1. Peer and EAP server require a particular inner EAP method used within a particular tunnel method.
1. ピアとEAPサーバーには、特定のトンネル方式内で使用される特定の内部EAP方式が必要です。
2. The inner EAP method's authentication is only available within the tunnel and through no other means including non-EAP means.
2. 内部EAP方式の認証は、トンネル内でのみ使用でき、非EAP手段を含む他の手段では使用できません。
3. The inner EAP method produces a key.
3. 内部EAP方式はキーを生成します。
4. The tunnel method uses cryptographic binding and the peer requires the other end of the tunnel to prove knowledge of the inner MSK.
4. トンネル方式は暗号バインディングを使用し、ピアは内部MSKの知識を証明するためにトンネルのもう一方の端を必要とします。
The most advanced examples of cryptographic binding today work at two levels. First, the server and peer prove to each other knowledge of the inner MSK. Then, the inner MSK is combined with some outer key material to form the tunnel's EAP keys. This is sufficient to detect an inserted server or peer provided that the attacker does not learn the inner MSK. This seems sufficient to defend against attackers who cannot act as a legitimate NAS.
今日の暗号バインディングの最も先進的な例は、2つのレベルで機能します。まず、サーバーとピアが内部MSKの知識を互いに証明します。次に、内側のMSKがいくつかの外側のキーマテリアルと組み合わされて、トンネルのEAPキーが形成されます。これは、攻撃者が内部MSKを学習しない限り、挿入されたサーバーまたはピアを検出するのに十分です。これは、正当なNASとして機能できない攻撃者を防御するのに十分なようです。
The definition of cryptographic binding in [RFC3748] does not require these steps. To meet that definition, it would be sufficient for a peer to prove knowledge of the inner key to the EAP server. This would open some additional attacks. For example, by indicating success, an attacker might be able to mask a cryptographic binding failure. The peer is unlikely to be able to detect the failure, especially if only the tunnel key material is used for the final keys.
[RFC3748]での暗号バインディングの定義では、これらの手順は必要ありません。その定義を満たすには、ピアが内部キーの知識をEAPサーバーに証明するだけで十分です。これにより、いくつかの追加の攻撃が開かれます。たとえば、成功を示すことにより、攻撃者は暗号バインディングの失敗をマスクできる可能性があります。特に最終的なキーにトンネルキーマテリアルのみが使用されている場合は、ピアが障害を検出できない可能性があります。
As discussed in the previous section, cryptographic binding is only effective when the inner method is EAP.
前のセクションで説明したように、暗号化バインディングは、内部方式がEAPの場合にのみ有効です。
Cryptographic binding can be strengthened when the inner EAP method supports an Extended Master Session Key (EMSK). The EMSK is never disclosed to any party other than the EAP server or peer, so even a legitimate NAS cannot learn the EMSK. So, if the same techniques currently applied to the inner MSK are applied to the inner EMSK, then condition 3 (completing tunnel authentication) will not hold because the attacker cannot complete this new form of cryptographic binding. This does not prevent the attacker from learning confidential information such as a channel-binding request sent over the tunnel prior to cryptographic binding.
内部EAP方式が拡張マスターセッションキー（EMSK）をサポートしている場合、暗号化バインディングを強化できます。 EMSKがEAPサーバーまたはピア以外の当事者に開示されることはないため、正当なNASでもEMSKを学習できません。したがって、現在内部MSKに適用されているのと同じ手法を内部EMSKに適用すると、攻撃者はこの新しい形式の暗号化バインディングを完了できないため、条件3（トンネル認証の完了）は成立しません。これは、攻撃者が暗号化バインディングの前にトンネルを介して送信されたチャネルバインディング要求などの機密情報を学習することを妨げるものではありません。
Obviously, as with all forms of cryptographic binding, cryptographic binding only works for key-deriving inner EAP methods. Also, some deployments (see Section 3.3) insert intermediates between the peer and the EAP server. EMSK-based cryptographic binding is incompatible with these deployments because the intermediate cannot learn the EMSK.
明らかに、暗号化バインディングのすべての形式と同様に、暗号化バインディングは、キーを派生する内部EAPメソッドに対してのみ機能します。また、一部の展開（セクション3.3を参照）では、ピアとEAPサーバーの間に中間体が挿入されます。 EMSKベースの暗号バインディングは、中間体がEMSKを学習できないため、これらのデプロイメントと互換性がありません。
Formally, EMSK-based cryptographic binding is a security claim for EAP tunnel methods that holds when:
正式には、EMSKベースの暗号バインディングは、次の場合に成立するEAPトンネルメソッドのセキュリティ要求です。
1. The peer proves to the server that the peer participating in any inner method is the same as the peer for the tunnel method.
1. ピアは、内部メソッドに参加しているピアがトンネルメソッドのピアと同じであることをサーバーに証明します。
2. The server proves to the peer that the server for any inner method is the same as the server for the tunnel method.
2. サーバーは、内部メソッドのサーバーがトンネルメソッドのサーバーと同じであることをピアに証明します。
3. The MSK and EMSK for the tunnel depend on the MSK and EMSK of inner methods.
3. トンネルのMSKおよびEMSKは、内部メソッドのMSKおよびEMSKに依存します。
4. The peer MUST be able to force the authentication to fail if the peer is unable to confirm the identity of the server.
4. ピアがサーバーのIDを確認できない場合、ピアは認証を強制的に失敗させることができる必要があります。
5. Proofs offered need to be secure even against attackers who know the inner method MSK.
5. 提供される証拠は、MSK内部手法を知っている攻撃者に対しても安全である必要があります。
If EMSK-based cryptographic binding is not an optional facility, it provides a strong defense against server insertion attacks and other tunnel man-in-the-middle (MITM) attacks for inner methods that provide an EMSK. The strength of the defense is dependent on the strength of the inner method. EMSK-based cryptographic binding MAY be provided as an optional facility. The value of EMSK-based cryptographic binding is reduced somewhat if it is an optional feature. It permits configurations where a peer uses other means to authenticate the server if the peer has sufficient information configured to validate the certificate and identity of an EAP server while using EMSK-based cryptographic binding for deployments where that is possible.
EMSKベースの暗号バインディングがオプションの機能ではない場合、サーバー挿入攻撃や、EMSKを提供する内部メソッドに対するその他のトンネル中間者（MITM）攻撃に対する強力な防御を提供します。防御の強さは、内側の方法の強さに依存します。 EMSKベースの暗号バインディングは、オプション機能として提供される場合があります。オプションの機能である場合、EMSKベースの暗号バインディングの価値は多少低下します。可能な場合は、EMSKベースの暗号バインディングを使用してEAPサーバーの証明書とIDを検証するように構成された十分な情報がピアにある場合、ピアが他の手段を使用してサーバーを認証する構成を許可します。
If EMSK-based cryptographic binding is an optional facility, the negotiation of whether to use it MUST be protected by the inner MSK or EMSK. Typically, the MSK will be used because the primary advantage of making EMSK-based cryptographic binding an optional facility is to permit intermediates who know only the MSK to decline to use EMSK-based cryptographic binding. The peer MUST have an opportunity to fail the authentication after the server declines to use EMSK-based cryptographic binding.
EMSKベースの暗号バインディングがオプションの機能である場合、それを使用するかどうかのネゴシエーションは、内部のMSKまたはEMSKによって保護されている必要があります。通常、MSKが使用されるのは、EMSKベースの暗号バインディングをオプションの機能にする主な利点は、MSKのみを知っている中間者がEMSKベースの暗号バインディングの使用を拒否できることです。サーバーがEMSKベースの暗号バインディングの使用を拒否した後、ピアは認証に失敗する機会を持つ必要があります。
Another defense against tunnel MITM attacks, potentially including server insertion attacks, is to use a different credential for tunneled methods from other authentications. This may prevent the second condition (attacker being able to respond to inner authentication) from taking place. For example, if key material from the tunnel is mixed into a shared secret or password that is the basis of the inner authentication, then the second condition will not hold unless the attacker already knows this shared secret. The advantage of this approach is that it seems to be the only way to strengthen non-EAP inner authentications within a tunnel.
トンネルMITM攻撃に対する別の防御策は、サーバー挿入攻撃を含む可能性があり、他の認証とは異なるトンネル方式の認証情報を使用することです。これにより、2番目の条件（攻撃者が内部認証に応答できる）の発生を防ぐことができます。たとえば、トンネルからのキーマテリアルが内部認証の基礎である共有シークレットまたはパスワードに混在している場合、攻撃者がこの共有シークレットをすでに知らない限り、2番目の条件は成立しません。このアプローチの利点は、それがトンネル内の非EAP内部認証を強化する唯一の方法であると思われることです。
There are several disadvantages. Choosing a function to mix the tunnel key material into the inner authentication will be very dependent on the inner authentication. In addition, this appears to involve a layering violation. However, exploring the possibility of providing a solution like this seems important because it can function for inner authentications where no other approach will work.
いくつかの欠点があります。トンネルキーマテリアルを内部認証に混合する機能の選択は、内部認証に大きく依存します。さらに、これにはレイヤー化違反が含まれているようです。ただし、このようなソリューションを提供する可能性を探ることは、他のアプローチが機能しない内部認証で機能する可能性があるため、重要と思われます。
Some deployments introduce a tunnel server separate from the EAP server; see [RFC5281] for an example of this style of deployment. The tunnel server is between the NAS and the EAP server. The only difference between such an intermediate and an attacker is that the intermediate provides some function valuable to the peer or EAP server and that the intermediate is trusted by the peer. If peers are configured with the necessary information to validate certificates of these intermediates and to confirm their identity, then tunnel MITM and inserted server attacks can be defended against. The intermediates need to be trusted with regard to channel binding and other services that the peer depends on.
一部の展開では、EAPサーバーとは別のトンネルサーバーが導入されています。この展開スタイルの例については、[RFC5281]を参照してください。トンネルサーバーは、NASとEAPサーバーの間にあります。このような中間体と攻撃者の唯一の違いは、中間体がピアまたはEAPサーバーに役立つ機能を提供することと、中間体がピアによって信頼されていることです。ピアがこれらの中間体の証明書を検証し、それらのIDを確認するために必要な情報で構成されている場合、トンネルMITMおよび挿入されたサーバー攻撃を防御できます。中間体は、ピアが依存するチャネルバインディングやその他のサービスに関して信頼されている必要があります。
Support for trusted intermediates is not a requirement according to the tunnel method requirements.
信頼できる中間体のサポートは、トンネル方式の要件による要件ではありません。
It seems reasonable to treat trusted intermediates as a special case if they are supported and to focus on the security of the case where there are not intermediates in the tunnel as the common case.
信頼できる中間体がサポートされている場合は、信頼できる中間体を特別なケースとして扱い、トンネルに中間体がない場合のセキュリティに焦点を当てることは一般的なケースとして理にかなっているようです。
The Tunnel EAP method [TEAP] should gain support for EMSK-based cryptographic binding.
トンネルEAPメソッド[TEAP]は、EMSKベースの暗号化バインディングのサポートを取得する必要があります。
As channel-binding support is added to existing EAP methods, EMSK-based cryptographic binding or some other form of cryptographic binding that protects against server insertion should also be added to these methods. Mutual cryptographic binding may also be valuable when other services are added to EAP methods that may require a peer trust an EAP server.
チャネルバインディングサポートが既存のEAPメソッドに追加されるため、EMSKベースの暗号バインディングまたはサーバーの挿入から保護するその他の形式の暗号バインディングもこれらのメソッドに追加する必要があります。ピアがEAPサーバーを信頼することを必要とする可能性のある他のサービスがEAPメソッドに追加された場合、相互暗号化バインディングも価値があります。
Today, mutual authentication in EAP is thought of as a security claim about a method. However, in practice, it's an attribute of a particular exchange. Mutual authentication can be obtained via checking certificates, through mutual cryptographic binding, or in very controlled cases through carefully crafted peer and server policy combined with existing cryptographic binding. Using services like channel binding that involve the peer trusting the EAP server should require mutual authentication be present in the session.
今日、EAPでの相互認証は、メソッドに関するセキュリティ要求と見なされています。ただし、実際には、それは特定の交換の属性です。相互認証は、証明書のチェック、相互の暗号バインディング、または非常に制御されたケースでは、既存の暗号バインディングと組み合わせた慎重に作成されたピアおよびサーバーポリシーを通じて取得できます。 EAPサーバーを信頼するピアを含むチャネルバインディングなどのサービスを使用するには、セッションに相互認証が存在する必要があります。
To accomplish this, implementations including channel binding or other peer services MUST track whether mutual authentication has happened. They SHOULD default to not permitting these peer services unless mutual authentication has happened. They SHOULD support a configuration where the peer fails to authenticate unless mutual authentication takes place. Discussion of whether this configuration should be recommended as a default is required.
これを実現するには、チャネルバインディングまたは他のピアサービスを含む実装で、相互認証が発生したかどうかを追跡する必要があります。相互認証が行われない限り、デフォルトでこれらのピアサービスを許可しないようにする必要があります。相互認証が行われない限り、ピアは認証に失敗する構成をサポートする必要があります（SHOULD）。この構成をデフォルトとして推奨すべきかどうかの議論が必要です。
The Tunnel EAP method [TEAP] should permit peers to force authentication failure if they are unable to perform mutual authentication. The protocol should permit this to be deferred until after mutual cryptographic binding is considered.
トンネルEAPメソッド[TEAP]では、ピアが相互認証を実行できない場合に、認証の失敗を強制することができます。プロトコルは、相互の暗号バインディングが検討されるまでこれを延期することを許可する必要があります。
Services such as channel binding should be deferred until after cryptographic binding or mutual cryptographic binding.
チャネルバインディングなどのサービスは、暗号化バインディングまたは相互暗号化バインディングの後まで延期する必要があります。
An additional complication arises when a tunnel method authenticates multiple parties such as authenticating both the peer machine and the peer user to the EAP server. Depending on how mutual authentication is achieved, only some of these parties may have confidence in it. For example, if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties that have achieved mutual authentication need to be considered when evaluating whether to use peer services.
トンネル方式がピアマシンとピアユーザーの両方をEAPサーバーに対して認証するなど、複数のパーティを認証する場合、さらに複雑になります。相互認証がどのように達成されるかに応じて、これらの当事者の一部のみがそれを信頼することができます。たとえば、強力な共有シークレットを使用してユーザーとEAPサーバーを相互認証する場合、マシンが共有シークレットを攻撃者に開示しないとユーザーを信頼できない場合、マシンはEAPサーバーが認証された当事者であるとは確信できません。 。これらの場合、相互認証を達成した当事者は、ピアサービスを使用するかどうかを評価するときに考慮する必要があります。
Work is required to promote interoperable deployment of server certificate validation by peers. A standard way to name EAP servers is required. Recommendations for what name forms peers should implement is required.
ピアによるサーバー証明書検証の相互運用可能な展開を促進するための作業が必要です。 EAPサーバーに名前を付ける標準的な方法が必要です。ピアが実装する必要のある名前の形式に関する推奨事項が必要です。
More consideration of the proposal to mix some key material into inner authentications is desired. Currently, the proposal is under-defined and fairly invasive. Are there versions of this proposal that would be valuable? Is there a way to view it as something more abstract so that it does not involve a combinatorial explosion as a result of considering specific tunnels and inner methods?
いくつかの主要な資料を内部認証に混合するという提案をさらに検討することが望まれます。現在、提案は定義が不十分で、かなり侵略的です。この提案の価値のあるバージョンはありますか？特定のトンネルと内部メソッドを検討した結果としての組み合わせの爆発を含まないように、それをより抽象的なものとして見る方法はありますか？
The Tunnel EAP method [TEAP] provides several features designed to limit man-in-the-middle vulnerabilities and provide a safe platform for peer services.
トンネルEAPメソッド[TEAP]は、中間者の脆弱性を制限し、ピアサービスに安全なプラットフォームを提供するように設計されたいくつかの機能を提供します。
TEAP implementations support checking the Network Access Identifier (NAI) realm portion against a DNS subjectAlternativeName in the certificate of the TEAP server. TEAP supports EMSK-based cryptographic binding as a way to achieve mutual cryptographic binding. TEAP also supports MSK-based cryptographic binding for cases where the EMSK is not available; this cryptographic binding does not provide sufficient assurance for peer services. TEAP provides recommendations on conditions that need to be met prior to using peer services. These recommendations explicitly address when the MSK-based cryptographic binding is sufficient and when EMSK-based cryptographic binding is required. TEAP meets the recommendations for implementations outlined in this memo.
TEAP実装は、ネットワークアクセス識別子（NAI）領域の部分をTEAPサーバーの証明書のDNS subjectAlternativeNameと照合することをサポートしています。 TEAPは、相互暗号バインディングを実現する方法として、EMSKベースの暗号バインディングをサポートしています。 TEAPは、EMSKが利用できない場合のMSKベースの暗号バインディングもサポートしています。この暗号バインディングは、ピアサービスに十分な保証を提供しません。 TEAPは、ピアサービスを使用する前に満たす必要がある条件に関する推奨事項を提供します。これらの推奨事項は、MSKベースの暗号バインディングが十分である場合、およびEMSKベースの暗号バインディングが必要な場合を明示的に扱っています。 TEAPは、このメモで概説されている実装の推奨事項を満たしています。
EAP-FAST [RFC4851] provides MSK-based cryptographic binding. EAP-FAST requires that server certificates be validated. However, no guidance is given on how servers are named, so the specification does not provide enough guidance to interoperably enforce this requirement.
EAP-FAST [RFC4851]は、MSKベースの暗号バインディングを提供します。 EAP-FASTでは、サーバー証明書を検証する必要があります。ただし、サーバーの命名方法に関するガイダンスは提供されていないため、仕様では、この要件を相互運用的に適用するための十分なガイダンスを提供していません。
EAP-FAST does not support channel binding or other peer services, although the protocol is extensible and TLVs could be defined for peer services. If the certificates are actually validated and names checked, then EAP-FAST would provide security guarantees sufficient to use these peer services. However, the cryptographic binding in EAP-FAST is not strong enough to secure peer services if the server certificate is not validated and name checked.
EAP-FASTはチャネルバインディングやその他のピアサービスをサポートしていませんが、プロトコルは拡張可能であり、ピアサービスに対してTLVを定義できます。証明書が実際に検証され、名前がチェックされる場合、EAP-FASTはこれらのピアサービスを使用するのに十分なセキュリティ保証を提供します。ただし、サーバー証明書が検証されず、名前がチェックされない場合、EAP-FASTの暗号バインディングは、ピアサービスを保護するほど強力ではありません。
The EAP Tunneled Transport Layer Security Version 0 (EAP-TTLS) [RFC5281] does not support cryptographic binding. It also does not support peer services such as channel binding although they could be added using extensible AVPs.
EAP Tunneled Transport Layer Securityバージョン0（EAP-TTLS）[RFC5281]は暗号化バインディングをサポートしていません。拡張可能なAVPを使用して追加することもできますが、チャネルバインディングなどのピアサービスもサポートしていません。
EAP-TTLS recommends that implementations SHOULD validate certificates but gives no guidance on how to handle naming. Even if certificates are validated, EAP-TTLS is not generally suited to peer services. As an example, EAP-TTLS does not include protected result indication. So, an unprotected EAP success packet can end the authentication. In addition, it is difficult for a peer to request services such as channel binding because the server ends the authentication as soon as authentication is successful.
EAP-TTLSは、実装が証明書を検証する必要があることを推奨していますが、命名の処理方法に関するガイダンスは提供していません。証明書が検証されたとしても、EAP-TTLSは一般にピアサービスには適していません。例として、EAP-TTLSには保護された結果表示は含まれていません。そのため、保護されていないEAP成功パケットが認証を終了する可能性があります。さらに、サーバーは認証が成功するとすぐに認証を終了するため、ピアがチャネルバインディングなどのサービスを要求することは困難です。
A variety of extensions, including EAP-TTLS version 1, improve some of these concerns. Specification and implementation issues complicate analysis of these extensions. As an example, most implementations can be tricked into using EAP-TTLS version 0.
EAP-TTLSバージョン1を含むさまざまな拡張機能により、これらの問題の一部が改善されています。仕様と実装の問題は、これらの拡張機能の分析を複雑にします。例として、ほとんどの実装はEAP-TTLSバージョン0を使用するようにだまされる可能性があります。
This memo examines the security considerations of providing new classes of service within EAP methods. Traditionally, the primary focus of EAP is authenticating the peer to the network. However, as the peer places trust in the EAP server, mutual authentication becomes more important. This memo examines the security of mutual authentication for EAP tunnel methods.
このメモは、EAPメソッド内で新しいサービスクラスを提供する場合のセキュリティに関する考慮事項を検証します。従来、EAPの主な焦点は、ネットワークへのピアの認証です。ただし、ピアがEAPサーバーを信頼するようになると、相互認証がより重要になります。このメモは、EAPトンネル方式の相互認証のセキュリティを調べます。
The authors would like to thank Alan DeKok for helping to explore these attacks. Alan focused the discussion on the importance of inner authentications that are not EAP and proposed mixing in key material as a way to resolve these authentications.
著者は、これらの攻撃を調査する手助けをしてくれたAlan DeKokに感謝します。 Alanは、EAP以外の内部認証の重要性についての議論に焦点を当て、これらの認証を解決する方法として、キーマテリアルの混合を提案しました。
Jari Arkko provided a review of the attack and valuable context on past efforts in developing cryptographic binding.
Jari Arkkoは、攻撃のレビューと暗号バインディングの開発における過去の取り組みに関する貴重なコンテキストを提供しました。
Sam Hartman's and Margaret Wasserman's work on this memo is funded by Huawei.
サムハートマンとマーガレットワッサーマンのこのメモに関する作業は、ファーウェイから資金提供を受けています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[GSS-EAP] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", Work in Progress, August 2012.
[GSS-EAP] Hartman、S.およびJ. Howlett、「Extensible Authentication ProtocolのGSS-APIメカニズム」、Work in Progress、2012年8月。
[PT-EAP] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Work in Progress, March 2013.
[PT-EAP] Cam-Winget、N。およびP. Sangster、「PT-EAP：Posture Transport（PT）Protocol For EAP Tunnel Methods」、Work in Progress、2013年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759] Zorn、G。、「Microsoft PPP CHAP Extensions、Version 2」、RFC 2759、2000年1月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：Technical Specification Road Map」、RFC 4510、2006年6月。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC4851] Cam-Winget、N.、McGrew、D.、Salowey、J。、およびH. Zhou、「Secure Tunneling Extensible Authentication Protocol Method（EAP-FAST）による柔軟な認証」、RFC 4851、2007年5月。
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5281] Funk、P。およびS. Blake-Wilson、「Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0（EAP-TTLSv0）」、RFC 5281、2008年8月。
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
[RFC6677] Hartman、S.、Clancy、T。、およびK. Hoeper、「拡張可能な認証プロトコル（EAP）メソッドのチャネルバインディングサポート」、RFC 6677、2012年7月。
[RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey, "Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method", RFC 6678, July 2012.
[RFC6678] Hoeper、K.、Hanna、S.、Zhou、H。、およびJ. Salowey、「Tunnel-Based Extensible Authentication Protocol（EAP）Methodの要件」、RFC 6678、2012年7月。
[TEAP] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel EAP Method (TEAP) Version 1", Work in Progress, September 2013.
[TEAP] Zhou、H.、Cam-Winget、N.、Salowey、J。、およびS. Hanna、「Tunnel EAP Method（TEAP）Version 1」、Work in Progress、2013年9月。
[TUNNEL-MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunnelled Authentication Protocols", Cryptology ePrint Archive: Report 2002/163, November 2002.
[TUNNEL-MITM] Asokan、N.、Niemi、V。、およびK. Nyberg、「トンネル認証プロトコルの中間者」、Cryptology ePrint Archive：Report 2002 / 163、2002年11月。
Authors' Addresses
著者のアドレス
Sam Hartman Painless Security
サムハートマンの痛みのないセキュリティ
EMail: hartmans-ietf@mit.edu
Margaret Wasserman Painless Security
マーガレットワッサーマン痛みのないセキュリティ
EMail: mrw@painless-security.com
URI: http://www.painless-security.com/
Dacheng Zhang Huawei
DAがZhang hu Aになる
EMail: zhangdacheng@huawei.com