[要約] RFC 6678は、トンネルベースの拡張認証プロトコル（EAP）メソッドの要件を定義しています。その目的は、EAPメソッドの拡張性とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) K. Hoeper
Request for Comments: 6678 Motorola Solutions, Inc.
Category: Informational S. Hanna
ISSN: 2070-1721 Juniper Networks
H. Zhou
J. Salowey, Ed.
Cisco Systems, Inc.
July 2012
Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method
トンネルベースの拡張認証プロトコル（EAP）方式の要件
Abstract
概要
This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes.
このメモは、トンネルベースの拡張認証プロトコル（EAP）メソッドの要件を定義しています。このトンネル方式では、トランスポート層セキュリティ（TLS）を使用して安全なトンネルを確立します。トンネルは、パスワード認証、EAP認証、およびその他の目的での追加データの転送をサポートします。
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/rfc6678.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6678で入手できます。
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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 5
3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 5
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 6
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6
3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 7
3.7. Client Authentication during Tunnel Establishment . . . . 7
3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
3.9. Certificate-Less Authentication and Generic EAP Method
Extension . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10
4.2.1.1.3. Tunnel Authentication and Key Establishment . 11
4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 11
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12
4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13
4.3.4. Vendor-Specific Support . . . . . . . . . . . . . . . 13
4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13
4.3.6. Internationalization of Display Strings . . . . . . . 13
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14
4.5.1.3. Server Certificate Revocation Checking . . . . . . 14
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
4.5.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15
4.6. Requirements Associated with Carrying EAP Methods . . . . 15
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16
4.6.4. Peer-Initiated EAP Authentication . . . . . . . . . . 17
4.6.5. Method Metadata . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
5.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
5.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
5.4. Separation of TLS Tunnel and Inner Authentication
Termination . . . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . . 21
An Extensible Authentication Protocol (EAP) tunnel method is an EAP method that establishes a secure tunnel and executes other EAP methods under the protection of that secure tunnel. An EAP tunnel method can be used in any lower-layer protocol that supports EAP authentication. There are several existing EAP tunnel methods that use Transport Layer Security (TLS) to establish the secure tunnel. EAP methods supporting this include Protected EAP [PEAP], Tunneled Transport Layer Security EAP (TTLS) [RFC5281] and EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. In general, this has worked well so there is consensus to continue to use TLS as the basis for a tunnel method. There have been various reasons for employing a protected tunnel for EAP processes. They include protecting weak authentication exchanges, such as username and password. In addition, a protected tunnel can provide means to provide peer identity protection and EAP method chaining. Finally, systems have found it useful to transport additional types of data within the protected tunnel.
拡張認証プロトコル（EAP）トンネル方式は、セキュアトンネルを確立し、そのセキュアトンネルの保護下で他のEAP方式を実行するEAP方式です。 EAPトンネル方式は、EAP認証をサポートする任意の下位層プロトコルで使用できます。トランスポート層セキュリティ（TLS）を使用して安全なトンネルを確立する既存のEAPトンネル方式がいくつかあります。これをサポートするEAPメソッドには、保護されたEAP [PEAP]、トンネルトランスポート層セキュリティEAP（TTLS）[RFC5281]、およびセキュアトンネリングによるEAPフレキシブル認証（EAP-FAST）[RFC4851]が含まれます。一般に、これはうまく機能しているため、トンネル方式の基礎としてTLSを引き続き使用するというコンセンサスがあります。 EAPプロセスに保護されたトンネルを使用する理由はさまざまです。これには、ユーザー名やパスワードなどの弱い認証交換の保護が含まれます。さらに、保護されたトンネルは、ピアID保護とEAPメソッドチェーンを提供する手段を提供できます。最後に、システムは、保護されたトンネル内で追加のタイプのデータを転送することが有用であることを発見しました。
This document describes the requirements for a EAP tunnel method as well as for a password protocol supporting legacy password verification within the tunnel method.
このドキュメントでは、EAPトンネル方式と、トンネル方式内のレガシーパスワード検証をサポートするパスワードプロトコルの要件について説明します。
Use of each capitalized word within a sentence or phrase carries the following meaning during the EAP Method Update (EMU) WG's method selection process:
文または語句内の各大文字の単語の使用は、EAPメソッド更新（EMU）WGのメソッド選択プロセス中に次の意味を持ちます。
MUST - indicates an absolute requirement
必須-絶対要件を示します
MUST NOT - indicates something absolutely prohibited
してはいけないこと-絶対に禁止されていることを示します
SHOULD - indicates a strong recommendation of a desired result
SHOULD-望ましい結果の強力な推奨を示します
SHOULD NOT - indicates a strong recommendation against a result
すべきではない-結果に対する強い推奨を示す
MAY - indicates a willingness to allow an optional outcome
MAY-オプションの結果を許可する意欲を示します
Lowercase uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" carry their normal meaning and are not subject to these definitions.
「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、「MAY」の小文字の使用は通常の意味を持ち、これらの定義の対象ではありません。
To motivate and explain the requirements in this document, a representative set of use cases for the EAP tunnel method are supplied here. It is mandatory for a candidate tunnel method to support all of the use cases that are marked below as "MUST".
このドキュメントの要件を動機付けて説明するために、EAPトンネル方式の代表的な一連の使用例をここに示します。候補のトンネルメソッドは、以下で「必須」としてマークされているすべてのユースケースをサポートする必要があります。
Many legacy systems only support user authentication with passwords. Some of these systems require transport of the actual username and password to the authentication server. This is true for systems where the authentication server does not have access to the cleartext password or a consistent transform of the cleartext password. Examples of such systems are some one-time password (OTP) systems and other systems where the username and password are submitted to an external party for validation. The tunnel method MUST support transporting cleartext username and password to the EAP server. It MUST NOT reveal information about the username and password to parties in the communication path between the peer and the EAP server. The advantage any attacker gains against the tunnel method when employing a username and password for authentication MUST be through interaction and not computation. The tunnel MUST support protection from man-in-the-middle attacks. The combination of the tunnel authentication and password authentication MUST enable mutual authentication.
従来のシステムの多くは、パスワードによるユーザー認証のみをサポートしています。これらのシステムの一部では、実際のユーザー名とパスワードを認証サーバーに転送する必要があります。これは、認証サーバーがクリアテキストパスワードまたはクリアテキストパスワードの一貫した変換にアクセスできないシステムに当てはまります。このようなシステムの例としては、一部のワンタイムパスワード（OTP）システムや、検証のためにユーザー名とパスワードが外部の関係者に送信されるその他のシステムがあります。トンネル方式は、EAPサーバーへのクリアテキストのユーザー名とパスワードの転送をサポートする必要があります。ユーザー名とパスワードに関する情報を、ピアとEAPサーバー間の通信パスの関係者に開示してはなりません（MUST NOT）。認証にユーザー名とパスワードを使用する場合、トンネル方式に対して攻撃者が得る利点は、計算ではなく相互作用によるものでなければなりません。トンネルは、中間者攻撃からの保護をサポートする必要があります。トンネル認証とパスワード認証の組み合わせにより、相互認証を有効にする必要があります。
Since EAP authentication occurs before network access is granted the tunnel method SHOULD enable an inner exchange to provide support for minimal password management tasks including password change, "new PIN mode", and "next token mode" required by some systems.
EAP認証はネットワークアクセスが許可される前に行われるため、トンネル方式は、内部交換が、一部のシステムで必要なパスワード変更、「新しいPINモード」、「次のトークンモード」などの最小限のパスワード管理タスクをサポートできるようにする必要があります。
Some existing EAP methods have vulnerabilities that could be eliminated or reduced by running them inside a protected tunnel. For example, an EAP-MD5 method does not provide mutual authentication or protection from dictionary attacks. Without extra protection, EAP tunnel methods are vulnerable to a special type of tunnel man-in-the-middle (MitM) attack [TUNNEL-MITM]. This attack is referred to as "tunnel MitM attack" in the remainder of this document. The additional protection needed to thwart tunnel MitM attacks depends on the inner method executed within the tunnel. When weak methods are used, these attacks can be mitigated via security policies that require the method to be used only within a tunnel. On the other hand, a technical solution (so-called cryptographic bindings) can be used whenever the inner method derives key material and is not susceptible to attacks outside a tunnel. Only the latter mitigation technique can be made an actual requirement for EAP tunnel methods (see Section 4.6.3), while security policies are outside the scope of this requirement document. Please refer to the NIST "Recommendation for EAP Methods Used in Wireless Network Access Authentication" [NIST-SP-800-120] and [LCN-2010] for a discussion on security policies and complete solutions for thwarting tunnel MitM attacks.
既存の一部のEAPメソッドには脆弱性があり、保護されたトンネル内でそれらを実行することによって排除または削減できます。たとえば、EAP-MD5方式では、相互認証や辞書攻撃からの保護は提供されません。特別な保護がない場合、EAPトンネル方式は、特殊なタイプのトンネル中間者（MitM）攻撃[TUNNEL-MITM]に対して脆弱です。この攻撃は、このドキュメントの残りの部分では「トンネルMitM攻撃」と呼ばれます。トンネルMitM攻撃を阻止するために必要な追加の保護は、トンネル内で実行される内部メソッドによって異なります。脆弱なメソッドが使用されている場合、これらの攻撃は、メソッドがトンネル内でのみ使用されることを要求するセキュリティポリシーを介して軽減できます。一方、内部のメソッドがキーマテリアルを導き出し、トンネルの外側の攻撃を受けにくい場合はいつでも、技術的なソリューション（いわゆる暗号バインディング）を使用できます。セキュリティポリシーはこの要件ドキュメントの範囲外ですが、EAPトンネルメソッドの実際の要件にすることができるのは後者の緩和技術のみです（セクション4.6.3を参照）。トンネルのMitM攻撃を阻止するためのセキュリティポリシーと完全なソリューションについては、NISTの「ワイヤレスネットワークアクセス認証で使用されるEAP方式の推奨事項」[NIST-SP-800-120]および[LCN-2010]を参照してください。
The tunnel method MUST support protection of weak EAP methods. Cryptographic protection from tunnel MitM attacks MUST be provided for all key-generating methods. In combination with an appropriate security policy this will thwart MitM attacks against inner methods.
トンネル方式は、弱いEAP方式の保護をサポートする必要があります。トンネルMitM攻撃からの暗号保護は、すべてのキー生成方法に提供する必要があります。これは、適切なセキュリティポリシーと組み合わせることで、内部メソッドに対するMitM攻撃を阻止します。
Several circumstances are best addressed by using chained EAP methods. For example, it may be desirable to authenticate the user and also authenticate the device being used. However, chained EAP methods from different conversations can be redirected into the same conversation by an attacker giving the authenticator the impression that both conversations terminate at the same endpoint. Cryptographic binding can be used to bind the results of chained key-generating methods together or to an encompassing tunnel.
いくつかの状況は、連鎖EAP方式を使用することによって最もよく対処されます。たとえば、ユーザーを認証し、使用されているデバイスも認証することが望ましい場合があります。ただし、攻撃者は、異なる会話からの連鎖EAPメソッドを同じ会話にリダイレクトして、認証者に両方の会話が同じエンドポイントで終了するような印象を与えることができます。暗号バインディングを使用して、チェーンされた鍵生成メソッドの結果を一緒に、または包含トンネルにバインドできます。
The tunnel method MUST support chained EAP methods while including protection against attacks on method chaining.
トンネルメソッドは、メソッドチェーンへの攻撃に対する保護を含みながら、チェーンEAPメソッドをサポートする必要があります。
When performing an EAP authentication, the peer may want to protect its identity and only disclose it to a trusted EAP server. This helps to maintain peer privacy.
EAP認証を実行するとき、ピアはそのIDを保護し、信頼できるEAPサーバーにのみそれを開示したい場合があります。これは、ピアのプライバシーを維持するのに役立ちます。
The tunnel method MUST support identity protection, therefore the identity of the peer used for authentication purposes MUST NOT be obtainable by any entity other than the EAP server terminating the tunnel method. Peer identity protection provided by the tunnel method applies to the identities that are specific to the tunnel method and inner method being used. In a roaming scenario, note that the peer may need to expose the realm portion of the EAP outer identity in the Network Access Identifier (NAI) [RFC4282] in order to reach the appropriate authentication server.
トンネルメソッドはID保護をサポートする必要があるため、認証目的で使用されるピアのIDは、トンネルメソッドを終了するEAPサーバー以外のエンティティによって取得可能であってはなりません。トンネル方式によって提供されるピアID保護は、使用されているトンネル方式および内部方式に固有のIDに適用されます。ローミングのシナリオでは、ピアは、適切な認証サーバーに到達するために、ネットワークアクセス識別子（NAI）[RFC4282]でEAP外部IDの領域部分を公開する必要がある場合があることに注意してください。
When network service is provided, it is sometimes desirable for a user to gain network access in order to access limited services for emergency communication or troubleshooting information. To avoid eavesdropping, it's best to negotiate link-layer security as with any other authentication.
ネットワークサービスが提供されている場合、緊急通信またはトラブルシューティング情報のために限られたサービスにアクセスするために、ユーザーがネットワークアクセスを取得することが望ましい場合があります。盗聴を回避するには、他の認証と同様に、リンク層のセキュリティをネゴシエートすることをお勧めします。
Therefore, the tunnel method SHOULD allow anonymous peers or server-only authentication, while still deriving keys that can be used for link-layer security. The tunnel method MAY also allow for the bypass of server authentication processing on the client.
したがって、トンネル方式は、リンク層のセキュリティに使用できる鍵を導出しながら、匿名のピアまたはサーバーのみの認証を許可する必要があります（SHOULD）。トンネル方式では、クライアントでのサーバー認証処理のバイパスも許可される場合があります。
Foregoing user or server authentication increases the chance of man-in-the-middle and other types of attacks that can compromise the derived keys used for link-layer security. Therefore, passwords and other sensitive information MUST NOT be disclosed to an unauthenticated server, or to a server that is not authorized to authenticate the user.
ユーザーまたはサーバーの認証を回避すると、中間層攻撃や、リンク層セキュリティに使用される派生キーを危険にさらす可能性のあるその他のタイプの攻撃の可能性が高まります。したがって、パスワードやその他の機密情報は、認証されていないサーバーや、ユーザーの認証を許可されていないサーバーに開示してはなりません。
The Network Endpoint Assessment (NEA) protocols and reference model described in [RFC5209] provide a standard way to check the health ("posture") of a device at or after the time it connects to a network. If the device does not comply with the network's requirements, it can be denied access to the network or granted limited access to remediate itself. EAP is a convenient place for conducting an NEA exchange.
[RFC5209]で説明されているネットワークエンドポイントアセスメント（NEA）プロトコルと参照モデルは、デバイスがネットワークに接続した時点以降の正常性（「姿勢」）を確認する標準的な方法を提供します。デバイスがネットワークの要件に準拠していない場合、ネットワークへのアクセスが拒否されるか、デバイス自体を修復するための制限付きアクセスが許可されます。 EAPは、NEA交換を行うのに便利な場所です。
The tunnel method SHOULD support carrying NEA protocols such as a Posture Broker protocol compatible with Trusted Network Connect (PB-TNC) [RFC5793]. Depending on the specifics of the tunnel method, these protocols may be required to be carried in an EAP method.
トンネル方式は、Trusted Network Connect（PB-TNC）[RFC5793]と互換性のあるPosture BrokerプロトコルなどのNEAプロトコルの伝送をサポートする必要があります（SHOULD）。トンネル方式の詳細によっては、これらのプロトコルをEAP方式で実行する必要がある場合があります。
In some cases, the peer will have credentials that allow it to authenticate during tunnel establishment. These credentials may only partially authenticate the identity of the peer and additional authentication may be required inside the tunnel. For example, a communication device may be authenticated during tunnel establishment; in addition, user authentication may be required to satisfy authentication policy. The tunnel method MUST be capable of providing client-side authentication during tunnel establishment.
場合によっては、ピアは、トンネルの確立中に認証できる資格情報を持っています。これらの資格情報は、ピアのIDを部分的に認証するだけであり、トンネル内で追加の認証が必要になる場合があります。たとえば、トンネルの確立中に通信デバイスを認証できます。さらに、認証ポリシーを満たすためにユーザー認証が必要になる場合があります。トンネル方式は、トンネル確立中にクライアント側の認証を提供できる必要があります。
The tunnel method MUST provide extensibility so that additional data related to authentication, authorization, and network access can be carried inside the tunnel in the future. This removes the need to develop new tunneling methods for specific purposes.
トンネル方式は、認証、承認、およびネットワークアクセスに関連する追加データを将来トンネル内で伝送できるように拡張性を提供する必要があります。これにより、特定の目的のために新しいトンネリング方法を開発する必要がなくなります。
An application for extensibility is credential provisioning. When a peer has authenticated with EAP, this is a convenient time to distribute credentials to that peer that may be used for later authentication exchanges. For example, the authentication server can provide a private key or shared key to the peer that can be used by the peer to perform rapid re-authentication or roaming. In addition, there have been proposals to perform enrollment within EAP, such as [EAP-ENROLL]. Another use for extensibility is support for alternate authentication frameworks within the tunnel.
拡張性のアプリケーションは、資格情報のプロビジョニングです。ピアがEAPで認証されている場合、これは、後の認証交換に使用できる資格情報をそのピアに配布するのに便利な時間です。たとえば、認証サーバーは、ピアが秘密鍵または共有鍵を提供して、ピアが迅速な再認証またはローミングを実行するために使用できるようにすることができます。さらに、[EAP-ENROLL]など、EAP内で登録を実行する提案がありました。拡張性のもう1つの用途は、トンネル内の代替認証フレームワークのサポートです。
In some cases, the peer will not have a way to verify a server certificate and, in some cases, a server might not have a certificate to verify. Therefore, it is desirable to support certificate-less authentication. An application for this is credential provisioning where the peer and server authenticate each other with a shared password and credentials for subsequent authentication (e.g., a key pair and certificate, or a shared key) can be passed inside the tunnel. Another application is to extend existing EAP methods with new features such as EAP channel bindings.
場合によっては、ピアにサーバー証明書を検証する方法がなく、場合によっては、サーバーに検証する証明書がないことがあります。したがって、証明書なしの認証をサポートすることが望ましいです。このアプリケーションは、ピアとサーバーが共有パスワードでお互いを認証し、その後の認証（たとえば、キーペアと証明書、または共有キー）をトンネル内に渡すことができる資格情報のプロビジョニングです。別のアプリケーションは、EAPチャネルバインディングなどの新機能で既存のEAPメソッドを拡張することです。
Great care must be taken when using tunnels with no server authentication for the protection of an inner method. For example, the client may lack the appropriate trust roots to fully authenticate the server, but may still establish the tunnel to execute an inner EAP method to perform mutual authentication and key derivation. In these cases, the inner EAP method MUST provide resistance to dictionary attack and a cryptographic binding between the inner method and the tunnel method MUST be established. Furthermore, the cipher suite used to establish the tunnel MUST derive the master key using contributions from both client and server, as in ephemeral Diffie-Hellman cipher suites.
内部メソッドの保護のためにサーバー認証なしのトンネルを使用する場合は、細心の注意を払う必要があります。たとえば、クライアントには、サーバーを完全に認証するための適切な信頼ルートがなくても、トンネルを確立して内部EAPメソッドを実行し、相互認証とキーの導出を実行できます。これらの場合、内部EAPメソッドは辞書攻撃に対する耐性を提供しなければならず（MUST）、内部メソッドとトンネルメソッド間の暗号バインディングが確立されなければなりません（MUST）。さらに、トンネルの確立に使用される暗号スイートは、一時的なDiffie-Hellman暗号スイートのように、クライアントとサーバーの両方からの貢献を使用してマスターキーを派生させる必要があります。
The tunnel method MAY allow for certificate-less authentication.
トンネル方式は、証明書なしの認証を許可する場合があります。
The tunnel method MUST include a Security Claims section with all security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC 3748 that tunnel methods MUST support protection against man-in-the-middle attacks. Furthermore, the tunnel method MUST support identity protection as specified in Section 7.3 of RFC 3748.
トンネル方式には、RFC 3748 [RFC3748]のセクション7.2で指定されたすべてのセキュリティクレームを含むセキュリティクレームセクションを含める必要があります。さらに、トンネルメソッドは中間者攻撃に対する保護をサポートする必要があるというRFC 3748のセクション2.1および7.4の要件を満たさなければなりません（MUST）。さらに、トンネル方式は、RFC 3748のセクション7.3で指定されているID保護をサポートする必要があります。
The tunnel method MUST be unconditionally compliant with RFC 4017 [RFC4017] (using the definition of "unconditionally compliant" contained in Section 1.1 of RFC 4017). This means that the method MUST satisfy all the "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" requirements in RFC 4017.
トンネル方式は、無条件にRFC 4017 [RFC4017]に準拠する必要があります（RFC 4017のセクション1.1に含まれる「無条件に準拠」の定義を使用）。これは、メソッドがRFC 4017のすべての「MUST」、「MUST NOT」、「SHOULD」、および「SHOULD NOT」の要件を満たさなければならないことを意味します。
The tunnel method MUST meet all the "MUST" and "SHOULD" requirements relevant to EAP methods contained in the EAP key management framework [RFC5247] or any successor. This includes the generation of the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id, and Session-Id. These requirements will enable the tunnel method to properly fit into the EAP key management framework, maintaining all of the security properties and guarantees of that framework.
トンネルメソッドは、EAPキー管理フレームワーク[RFC5247]またはその後継に含まれるEAPメソッドに関連するすべての「必須」および「必須」の要件を満たさなければなりません（MUST）。これには、マスターセッションキー（MSK）、拡張マスターセッションキー（EMSK）、ピアID、サーバーID、およびセッションIDの生成が含まれます。これらの要件により、トンネル方式がEAPキー管理フレームワークに適切に適合し、そのフレームワークのすべてのセキュリティプロパティと保証が維持されます。
The tunnel method MUST NOT be tied to any single cryptographic algorithm. Instead, it MUST support run-time negotiation to select among an extensible set of cryptographic algorithms, such as algorithms used with certificates presented during tunnel establishment. This "cryptographic algorithm agility" provides several advantages. Most important, when a weakness in an algorithm is discovered or increased processing power overtakes an algorithm, users can easily transition to a new algorithm. Also, users can choose the algorithm that best meets their needs.
トンネル方式は、単一の暗号化アルゴリズムに関連付けてはなりません（MUST NOT）。代わりに、トンネルの確立中に提示される証明書で使用されるアルゴリズムなど、拡張可能な暗号化アルゴリズムのセットから選択するランタイムネゴシエーションをサポートする必要があります。この「暗号化アルゴリズムの俊敏性」には、いくつかの利点があります。最も重要なのは、アルゴリズムの弱点が発見された場合、または処理能力の向上がアルゴリズムを追い抜いた場合、ユーザーは新しいアルゴリズムに簡単に移行できることです。また、ユーザーは自分のニーズに最適なアルゴリズムを選択できます。
The tunnel method MUST meet the SHOULD and MUST requirements pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. This includes: cryptographic algorithm independence; strong, fresh session keys; replay detection; keying material confidentiality and integrity; and confirmation of cipher suite selection.
トンネル方式は、RFC 4962 [RFC4962]のセクション3に含まれているEAP方式に関連するSHOULDおよびMUST要件を満たす必要があります。これには、暗号化アルゴリズムの独立性が含まれます。強力で新鮮なセッションキー。リプレイ検出;重要な機密性と完全性をキーイングする。暗号スイートの選択の確認。
The following section discusses requirements for TLS tunnel establishment.
次のセクションでは、TLSトンネル確立の要件について説明します。
The tunnel-based method MUST support TLS version 1.2 [RFC5246] and may support earlier versions greater than SSL 2.0 in order to enable the possibility of backwards compatibility.
トンネルベースの方法はTLSバージョン1.2 [RFC5246]をサポートしなければならず（MUST）、後方互換性の可能性を有効にするためにSSL 2.0より前のバージョンをサポートするかもしれません。
Cipher suite negotiations always suffer from downgrading attacks when they are not secured by any kind of integrity protection. A common practice is a post-negotiation integrity check in which, as soon as available, the established keys (here, the tunnel key) are used to derive integrity keys. These integrity keys are then used by the peer and authentication server to verify whether the cipher suite negotiation has been maliciously altered by another party.
暗号スイートネゴシエーションは、いかなる種類の整合性保護によっても保護されていない場合、ダウングレード攻撃の影響を受けます。一般的な方法は、ネゴシエーション後の整合性チェックです。このチェックでは、確立されたキー（ここでは、トンネルキー）が使用可能になり次第、整合性キーを導出します。次に、これらの整合性キーは、ピアと認証サーバーによって使用され、暗号スイートのネゴシエーションが別のパーティによって悪意を持って変更されたかどうかを確認します。
Integrity checks prevent downgrading attacks only if the derived integrity keys and the employed integrity algorithms cannot be broken in real-time. See Section 5.1 or [HC07] for more information on this. Hence, the tunnel method MUST provide integrity-protected cipher suite negotiation with secure integrity algorithms and integrity keys.
整合性チェックは、派生した整合性キーと採用されている整合性アルゴリズムをリアルタイムで解読できない場合にのみ、ダウングレード攻撃を防止します。詳細については、セクション5.1または[HC07]を参照してください。したがって、トンネル方式は、安全な整合性アルゴリズムと整合性キーを使用して、整合性で保護された暗号スイートのネゴシエーションを提供する必要があります。
TLS provides protected cipher suite negotiation as long as all the cipher suites supported provide authentication, key establishment, and data integrity protection as discussed in Section 5.1.
セクション5.1で説明するように、サポートされるすべての暗号スイートが認証、鍵の確立、およびデータ整合性保護を提供する限り、TLSは保護された暗号スイートネゴシエーションを提供します。
In order to prevent attacks on the cryptographic algorithms employed by inner authentication methods, a tunnel protocol's protection needs to provide a basic level of algorithm strength. The tunnel method MUST provide at least one mandatory-to-implement cipher suite that provides the equivalent security of 128-bit AES for encryption and message authentication. See Part 1 of the NIST "Recommendation for Key Management" [NIST-SP-800-57] for a discussion of the relative strengths of common algorithms.
内部認証方式で採用されている暗号アルゴリズムへの攻撃を防ぐために、トンネルプロトコルの保護は、基本レベルのアルゴリズム強度を提供する必要があります。トンネル方式は、暗号化とメッセージ認証に128ビットAESと同等のセキュリティを提供する、実装に必須の暗号スイートを少なくとも1つ提供する必要があります。一般的なアルゴリズムの相対的な強みについては、NISTのパート1「キー管理の推奨」[NIST-SP-800-57]を参照してください。
A tunnel method MUST provide unidirectional authentication from authentication server to EAP peer and mutual authentication between authentication server and EAP peer. The tunnel method MUST provide at least one mandatory-to-implement cipher suite that provides certificate-based authentication of the server and provides optional certificate-based authentication of the client. Other types of authentication MAY be supported.
トンネル方式は、認証サーバーからEAPピアへの単方向認証と、認証サーバーとEAPピア間の相互認証を提供する必要があります。トンネル方式は、サーバーの証明書ベースの認証を提供し、オプションのクライアントの証明書ベースの認証を提供する、実装に必須の暗号スイートを少なくとも1つ提供する必要があります。他のタイプの認証はサポートされるかもしれません。
At least one mandatory-to-implement cipher suite MUST be approved by the NIST "Draft Recommendation for Key Management", Part 3 [NIST-SP-800-57p3], i.e., the cipher suite MUST be listed in Table 4-1, 4-2, or 4-3 in that document.
少なくとも1つの必須から実装までの暗号スイートは、NISTの「鍵管理のための推奨案」パート3 [NIST-SP-800-57p3]によって承認される必要があります。つまり、暗号スイートは表4-1にリストされている必要があります。そのドキュメントの4-2、または4-3。
The mandatory-to-implement cipher suites MUST only include cipher suites that use strong cryptographic algorithms. They MUST NOT include cipher suites providing mutually anonymous authentication or static Diffie-Hellman cipher suites.
実装が必須の暗号スイートには、強力な暗号アルゴリズムを使用する暗号スイートのみを含める必要があります。相互に匿名の認証を提供する暗号スイートまたは静的Diffie-Hellman暗号スイートを含めることはできません。
Other cipher suites MAY be selected following the security requirements for tunnel protocols in the NIST "Recommendation for EAP Methods Used in Wireless Network Access Authentication" [NIST-SP-800-120].
その他の暗号スイートは、NIST「ワイヤレスネットワークアクセス認証で使用されるEAP方式の推奨事項」[NIST-SP-800-120]のトンネルプロトコルのセキュリティ要件に従って選択される場合があります。
In order to prevent replay attacks on a tunnel protocol, the message authentication MUST be generated using a time-variant input such as timestamps, sequence numbers, nonces, or a combination of these, so that any reuse of the authentication data can be detected as invalid. TLS provides sufficient replay protection to meet this requirement as long as weak cipher suites discussed in Section 5.1 are avoided.
トンネルプロトコルでのリプレイアタックを防ぐために、タイムスタンプ、シーケンス番号、ノンス、またはこれらの組み合わせなどの時変入力を使用してメッセージ認証を生成する必要があります。これにより、認証データの再利用を次のように検出できます。無効。 TLSは、5.1節で説明した弱い暗号スイートが回避されている限り、この要件を満たすのに十分なリプレイ保護を提供します。
In order to meet the requirements in this document, TLS extensions MAY be used. For example, TLS extensions may be useful in providing certificate revocation information via the TLS Online Certificate Status Protocol (OCSP) extension [RFC6066] (thus meeting the requirement in Section 4.5.1.3).
このドキュメントの要件を満たすために、TLS拡張が使用される場合があります。たとえば、TLS拡張は、TLSオンライン証明書ステータスプロトコル（OCSP）拡張[RFC6066]（セクション4.5.1.3の要件を満たす）を介して証明書失効情報を提供するのに役立ちます。
A tunnel protocol MUST support peer privacy. This requires that the username and other attributes associated with the peer are not transmitted in the clear or to an unauthenticated, unauthorized party. Peer identity protection provided by the tunnel method applies to establishment of the tunnel and protection of inner method specific identities. If applicable, the peer certificate is sent confidentially (i.e., encrypted).
トンネルプロトコルは、ピアプライバシーをサポートする必要があります。これには、ピアに関連付けられているユーザー名と他の属性が平文で、または認証されていない無許可の当事者に送信されないことが必要です。トンネル方式によって提供されるピアID保護は、トンネルの確立と内部方式固有のIDの保護に適用されます。該当する場合、ピア証明書は機密情報として送信されます（つまり、暗号化されます）。
The tunnel method MUST support TLS session resumption as defined in [RFC5246]. The tunnel method MAY support other methods of session resumption such as those defined in [RFC5077].
[RFC5246]で定義されているように、トンネル方式はTLSセッション再開をサポートする必要があります。トンネル方式は、[RFC5077]で定義されているようなセッション再開の他の方式をサポートしてもよい（MAY）。
Tunnel establishment sometimes requires the exchange of information that exceeds what can be carried in a single EAP message. In addition, information carried within the tunnel may also exceed this limit. Therefore, a tunnel method MUST support fragmentation and reassembly.
トンネルの確立では、単一のEAPメッセージで伝送できる量を超える情報の交換が必要になる場合があります。さらに、トンネル内で伝送される情報もこの制限を超える可能性があります。したがって、トンネルメソッドは断片化と再構成をサポートする必要があります。
A man-in-the-middle attacker can modify cleartext values such as protocol version and type code information communicated outside the TLS tunnel. The tunnel method MUST provide implicit or explicit protection of the protocol version and type code. If modification of other information external to the tunnel can cause exploitable vulnerabilities, the tunnel method MUST provide protection against modification of this additional data.
中間者攻撃者は、TLSトンネルの外部で通信されるプロトコルバージョンやタイプコード情報などのクリアテキスト値を変更できます。トンネルメソッドは、プロトコルバージョンとタイプコードの暗黙的または明示的な保護を提供する必要があります。トンネル外部のその他の情報の変更が悪用可能な脆弱性を引き起こす可能性がある場合、トンネルメソッドはこの追加データの変更に対する保護を提供する必要があります。
This section describes the payload requirements inside the tunnel. These requirements frequently express features that a candidate protocol must be capable of offering so that a deployer can decide whether to make use of that feature. This section does not state requirements about what features of each protocol must be used during a deployment.
このセクションでは、トンネル内のペイロード要件について説明します。これらの要件は、候補プロトコルが提供できる必要がある機能を表すことが多く、そのため、デプロイヤーはその機能を使用するかどうかを決定できます。このセクションでは、展開中に各プロトコルのどの機能を使用する必要があるかについての要件については説明しません。
The payload MUST be extensible. Some standard payload attribute types will be defined to meet known requirements listed below, such as password authentication, inner EAP method, vendor-specific attributes, and result indication. Additional payload attributes MAY be defined in the future to support additional features and data types.
ペイロードは拡張可能でなければなりません。パスワード認証、内部EAPメソッド、ベンダー固有の属性、結果表示など、いくつかの標準ペイロード属性タイプは、以下にリストされている既知の要件を満たすように定義されます。追加のペイロード属性は、追加の機能とデータ型をサポートするために将来定義されるかもしれません。
The payload MUST support the request and response type of half-duplex operation typical of EAP. Multiple attributes may be sent in a single payload. The payload MAY support transporting multiple authentications in a single payload packet.
ペイロードは、EAPに典型的な半二重動作の要求および応答タイプをサポートする必要があります。複数の属性を単一のペイロードで送信できます。ペイロードは、単一のペイロードパケットで複数の認証の転送をサポートする場合があります。
It is expected that new attributes will be defined to be carried within the tunnel method. In some cases, it is necessary for the sender to know if the receiver did not understand the attribute. To support this, there MUST be a way for the sender to mark attributes such that the receiver will indicate if an attribute is not understood.
新しい属性がトンネルメソッド内で伝達されるように定義されることが期待されます。場合によっては、受信者が属性を理解していないかどうかを送信者が知る必要があります。これをサポートするには、属性が理解されていない場合に受信者が示すように、送信者が属性をマークする方法が必要です。
The payload MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identified vendor-specific namespaces. They can be used for experiments or vendor-specific features.
ペイロードは、ベンダー固有の属性の拡張可能なセットの通信をサポートする必要があります。これらの属性は、一意に識別されたベンダー固有の名前空間にセグメント化されます。実験やベンダー固有の機能に使用できます。
The payload MUST support result indication and its acknowledgement, so both the EAP peer and server will end up with a synchronized state. The result indication is needed after each chained inner authentication method and at the end of the authentication, so separate result indications for intermediate and final results MUST be supported.
ペイロードは結果表示とその確認をサポートする必要があるため、EAPピアとサーバーの両方が同期状態になります。各チェーン内部認証方式の後と認証の終わりに結果表示が必要となるため、中間結果と最終結果の個別の結果表示をサポートする必要があります。
The payload MAY provide a standard attribute format that supports international strings. This attribute format MUST support encoding strings in UTF-8 [RFC3629] format. Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference as indicated by RFC 5646 [RFC5646]. Note that in some cases, such as when transmitting error codes, it is acceptable to exchange numeric codes that can be translated by the client to support the particular local language. These numeric codes are not subject to internationalization during transmission.
ペイロードは、国際文字列をサポートする標準属性フォーマットを提供してもよい（MAY）。この属性フォーマットは、UTF-8 [RFC3629]フォーマットのエンコーディング文字列をサポートする必要があります。ユーザーへの表示を目的としたサーバーから送信される文字列はすべてUTF-8形式で送信する必要があり、言語情報でマークを付け、RFC 5646 [RFC5646]で示されているようにユーザーの言語設定に適合させる必要があります。エラーコードを送信する場合など、特定のローカル言語をサポートするためにクライアントが変換できる数値コードを交換することが許容される場合があることに注意してください。これらの数値コードは、送信中に国際化の対象にはなりません。
The tunnel method MUST be capable of meeting EAP channel binding requirements described in [RFC6677]. As discussed in [RFC5056], EAP channel bindings differ from channel bindings discussed in other contexts. Cryptographic binding between the TLS tunnel and the inner method discussed in Section 4.6.3 relates directly to the non-EAP channel binding concepts discussed in RFC 5056.
トンネル方式は、[RFC6677]で説明されているEAPチャネルバインディング要件を満たす必要があります。 [RFC5056]で説明されているように、EAPチャネルバインディングは、他のコンテキストで説明されているチャネルバインディングとは異なります。 TLSトンネルとセクション4.6.3で説明されている内部方式との間の暗号バインディングは、RFC 5056で説明されている非EAPチャネルバインディングの概念に直接関係しています。
This section describes the requirements associated with tunneled password authentication. The password authentication mentioned here refers to user or machine authentication using a legacy password database or verifier, such as the Lightweight Directory Access Protocol (LDAP) [RFC4511], OTP, etc. These typically require the password in its original text form in order to authenticate the peer; hence, they require the peer to send the cleartext username and password to the EAP server.
このセクションでは、トンネルパスワード認証に関連する要件について説明します。ここで言及するパスワード認証は、Lightweight Directory Access Protocol（LDAP）[RFC4511]、OTPなどのレガシーパスワードデータベースまたはベリファイアを使用したユーザーまたはマシン認証を指します。これらは通常、パスワードを元のテキスト形式で要求するピアを認証します。したがって、ピアはクリアテキストのユーザー名とパスワードをEAPサーバーに送信する必要があります。
Many internal EAP methods have the peer send its password in the clear to the EAP server. Other methods (e.g., challenge-response methods) are vulnerable to attacks if an eavesdropper can intercept the traffic. For any such methods, the security measures in the following sections MUST be met.
多くの内部EAP方式では、ピアがパスワードを平文でEAPサーバーに送信します。盗聴者がトラフィックを傍受できる場合、他の方法（チャレンジ/レスポンス方法など）は攻撃に対して脆弱です。このような方法の場合、次のセクションのセキュリティ対策を満たさなければなりません。
The cleartext password exchange MUST be integrity and confidentiality protected. As long as the password exchange occurs inside an authenticated and encrypted tunnel, this requirement is met.
クリアテキストのパスワード交換は、整合性と機密性を保護する必要があります。認証および暗号化されたトンネル内でパスワード交換が行われる限り、この要件は満たされます。
The EAP server MUST be authenticated before the peer sends the cleartext password to the server.
ピアがクリアテキストのパスワードをサーバーに送信する前に、EAPサーバーを認証する必要があります。
When certificate authentication is used during tunnel establishment, the EAP peer may need to present its password to the server before it has network access to check the revocation status of the server's credentials. Therefore, the tunnel method MUST support mechanisms to check the revocation status of a credential. The tunnel method SHOULD make use of Online Certificate Status Protocol (OCSP)
トンネルの確立時に証明書認証を使用する場合、サーバーの資格情報の失効ステータスを確認するために、ネットワークにアクセスする前に、EAPピアがサーバーにパスワードを提示する必要がある場合があります。したがって、トンネルメソッドは、資格情報の失効ステータスをチェックするメカニズムをサポートする必要があります。トンネル方式は、オンライン証明書ステータスプロトコル（OCSP）を利用する必要があります（SHOULD）。
[RFC2560] or Server-based Certificate Validation Protocol (SCVP) [RFC5055] to obtain the revocation status of the EAP server certificate.
[RFC2560]またはサーバーベースの証明書検証プロトコル（SCVP）[RFC5055]は、EAPサーバー証明書の失効ステータスを取得します。
The password authentication exchange MUST support usernames and passwords in international languages. It MUST support encoding of username and password strings in UTF-8 [RFC3629] format. The method MUST specify how username and password normalizations and/or comparisons are performed in reference to SASLprep [RFC4013], Net-UTF-8 [RFC5198], or their replacements.
パスワード認証交換では、国際言語のユーザー名とパスワードをサポートする必要があります。 UTF-8 [RFC3629]形式のユーザー名とパスワード文字列のエンコードをサポートする必要があります。メソッドは、SASLprep [RFC4013]、Net-UTF-8 [RFC5198]、またはそれらの置き換えを参照して、ユーザー名とパスワードの正規化または比較、あるいはその両方を実行する方法を指定する必要があります。
Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference as indicated by RFC 5646 [RFC5646]. Note that, in some cases, such as when transmitting error codes, it is acceptable to exchange numeric codes that can be translated by the client to support the particular local language. These numeric codes are not subject to internationalization during transmission.
ユーザーへの表示を目的としたサーバーから送信される文字列はすべてUTF-8形式で送信する必要があり、言語情報でマークを付け、RFC 5646 [RFC5646]で示されているようにユーザーの言語設定に適合させる必要があります。エラーコードを送信する場合など、特定のローカル言語をサポートするためにクライアントが変換できる数値コードを交換することが許容される場合があることに注意してください。これらの数値コードは、送信中に国際化の対象にはなりません。
The password authentication exchange SHOULD support additional associated metadata that can be used to indicate whether the authentication is for a user or a machine. This allows the EAP server and peer to request and negotiate authentication specifically for a user or machine. This is useful in the case of multiple inner authentications where the user and machine both need to be authenticated.
パスワード認証交換は、認証がユーザー用かマシン用かを示すために使用できる追加の関連メタデータをサポートする必要があります（SHOULD）。これにより、EAPサーバーとピアは、ユーザーまたはマシン専用の認証を要求およびネゴシエートできます。これは、ユーザーとマシンの両方を認証する必要がある複数の内部認証の場合に役立ちます。
The password authentication exchange MUST support password change. The exchange SHOULD be extensible to support other "housekeeping" functions, such as the management of PINs or other data, required by some systems.
パスワード認証交換は、パスワード変更をサポートする必要があります。交換は、一部のシステムで必要なPINやその他のデータの管理など、その他の「ハウスキーピング」機能をサポートするために拡張可能である必要があります。
The tunnel method MUST be able to carry inner EAP methods without modifying them. EAP methods MUST NOT be redefined inside the tunnel.
トンネルメソッドは、内部EAPメソッドを変更せずに伝送できる必要があります。 EAPメソッドはトンネル内で再定義してはいけません。
The tunnel method MUST support the protected negotiation of the inner EAP method. It MUST NOT allow the inner EAP method negotiation to be manipulated by intermediaries.
トンネル方式は、内部EAP方式の保護されたネゴシエーションをサポートする必要があります。内部のEAPメソッドネゴシエーションが中間者によって操作されることを許可してはなりません。
The tunnel method SHOULD support the chaining of multiple EAP methods. The tunnel method MUST allow for the communication of intermediate results and for the verification of compound binding between executed inner methods when chained methods are employed.
トンネル方式は、複数のEAP方式のチェーンをサポートする必要があります（SHOULD）。トンネルメソッドは、中間結果の通信と、チェーンメソッドが使用されている場合に実行される内部メソッド間の複合バインディングの検証を許可する必要があります。
The tunnel method MUST provide a mechanism to bind the tunnel protocol and the inner EAP method. This property is referred to as cryptographic binding. Such bindings are an important tool for mitigating the tunnel MitM attacks [TUNNEL-MITM]. Cryptographic bindings enable the complete prevention of tunnel MitM attacks without the need of additional security policies, as long as the inner method derives keys and is not vulnerable to attacks outside a protected tunnel [LCN-2010]. Even though weak or non-key-deriving inner methods may be permitted. Thus, security policies preventing tunnel MitM attacks are still necessary, and the tunnel method MUST provide cryptographic bindings, because only this allows migrating to more secure, policy-independent implementations.
トンネル方式は、トンネルプロトコルと内部EAP方式をバインドするメカニズムを提供する必要があります。このプロパティは、暗号バインディングと呼ばれます。このようなバインディングは、トンネルMitM攻撃を軽減するための重要なツールです[TUNNEL-MITM]。暗号化バインディングを使用すると、追加のセキュリティポリシーを必要とせずに、トンネルMitM攻撃を完全に防止できます。ただし、内部メソッドがキーを導出し、保護されたトンネル外の攻撃に対して脆弱でない[LCN-2010]。弱い、または非キー派生の内部メソッドが許可されている場合でも。したがって、トンネルMitM攻撃を防ぐセキュリティポリシーは依然として必要であり、これだけがより安全なポリシーに依存しない実装への移行を可能にするため、トンネル方式は暗号バインディングを提供する必要があります。
Cryptographic bindings are typically achieved by securely mixing the established keying material (say, tunnel key TK) from the tunnel protocol with the established keying material (say, method key MK) from the inner authentication method(s) in order to derive fresh keying material. If chained EAP methods are executed in the tunnel, all derived inner keys are combined with the tunnel key to create a new compound tunnel key (CTK). In particular, CTK is used to derive the EAP MSK, EMSK and other transient keys (shown as "TEK" below), such as transient encryption keys and integrity protection keys. The key hierarchy for tunnel method executions that derive compound keys for the purpose of cryptographic binding is depicted in Figure 1.
暗号バインディングは通常、新鮮なキー素材を導出するために、トンネルプロトコルからの確立されたキー素材（たとえば、トンネルキーTK）と内部認証方法からの確立されたキー素材（たとえば、メソッドキーMK）を安全に混合することによって実現されます。 。チェーンEAPメソッドがトンネルで実行される場合、派生したすべての内部キーがトンネルキーと結合され、新しい複合トンネルキー（CTK）が作成されます。特に、CTKは、EAP MSK、EMSK、および一時的な暗号化キーや整合性保護キーなどの他の一時的なキー（以下「TEK」と表示）を導出するために使用されます。暗号バインディングの目的で複合キーを導出するトンネルメソッド実行のキー階層を図1に示します。
In the case of the sequential executions of n inner methods, a chained compound key CTK_i MUST be computed upon the completion of each inner method i such that it contains the compound key of all previous inner methods, i.e., CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n and CTK_0=TK, where f() is a key derivation function, such as one that complies with the NIST "Recommendation for Key Derivation Using Pseudorandom Functions" [NIST-SP-800-108]. CTK_n SHOULD serve as the key to derive further keys. Figure 1 depicts the key hierarchy in the case of a single inner method. Transient keys derived from the compound key CTK are used in a cryptographic protocol to verify the integrity of the tunnel and the inner authentication method.
n個の内部メソッドの順次実行の場合、チェーンされた複合キーCTK_iは、各内部メソッドiの完了時に計算される必要があります。これにより、前のすべての内部メソッドの複合キーが含まれます。つまり、CTK_i = f（CTK_i-1 、MK_i）0 <i <= nおよびCTK_0 = TKで、f()はNISTの「擬似ランダム関数を使用した鍵導出の推奨事項」[NIST-SP-800-108]に準拠するものなどの鍵導出関数です。 ]。 CTK_nは、さらにキーを導出するためのキーとして機能する必要があります（SHOULD）。図1は、単一の内部メソッドの場合のキー階層を示しています。複合キーCTKから派生した一時キーは、暗号プロトコルで使用され、トンネルの完全性と内部認証方法を検証します。
-----------
| TK | MK |
-----------
| |
v v
--------
| CTK |
--------
|
v
----------------
| | |
v v v
------- ------ -------
| TEK | | MSK | | EMSK |
------- ------- --------
Figure 1: Compound Keys
図1：複合キー
Furthermore, all compound keys CTK_i and all keys derived from it SHOULD follow the recommendations for key derivations and key hierarchies as specified in [NIST-SP-800-108]. In particular, all derived keys MUST have a lifetime assigned that does not exceed the lifetime of any key higher in the key hierarchy. The derivation MUST prevent a compromise in one part of the system from leading to compromises in other parts of the system that relay on keys at the same or higher level in the hierarchy.
さらに、すべての複合キーCTK_iとそれから派生したすべてのキーは、[NIST-SP-800-108]で指定されているキーの派生とキー階層の推奨事項に従う必要があります（SHOULD）。特に、すべての派生キーには、キー階層でより高いキーのライフタイムを超えないライフタイムが割り当てられている必要があります。派生は、システムの一部での侵害が、階層内の同じレベルまたはより高いレベルでキーを中継するシステムの他の部分での侵害につながるのを防ぐ必要があります。
The tunnel method SHOULD allow for the peer to initiate an inner EAP authentication in order to meet its policy requirements for authenticating the server.
トンネル方式では、サーバーを認証するためのポリシー要件を満たすために、ピアが内部EAP認証を開始できるようにする必要があります（SHOULD）。
The tunnel method SHOULD allow for the communication of additional data associated with an EAP method. This can be used to indicate whether the authentication is for a user or a machine. This allows the EAP server and peer to request and negotiate authentication specifically for a user or machine. This is useful in the case of multiple inner EAP authentications where the user and machine both need to be authenticated.
トンネル方式は、EAP方式に関連付けられた追加データの通信を許可する必要があります（SHOULD）。これは、認証がユーザー用かマシン用かを示すために使用できます。これにより、EAPサーバーとピアは、ユーザーまたはマシン専用の認証を要求およびネゴシエートできます。これは、ユーザーとマシンの両方を認証する必要がある複数の内部EAP認証の場合に役立ちます。
A tunnel method is often deployed to provide mutual authentication between EAP Peer and EAP Server and to generate key material for use in protecting lower-layer protocols. In addition the tunnel is used to protect the communication of additional data, including peer identity between the EAP Peer and EAP Server from disclosure to or modification by an attacker. These sections cover considerations that affect the ability for a method to achieve these goals.
トンネル方式は多くの場合、EAPピアとEAPサーバー間の相互認証を提供し、下位層プロトコルの保護に使用するキーマテリアルを生成するために展開されます。さらに、トンネルは、EAPピアとEAPサーバー間のピアIDを含む追加データの通信を、攻撃者による開示または変更から保護するために使用されます。これらのセクションでは、メソッドがこれらの目標を達成する能力に影響する考慮事項について説明します。
TLS supports a wide range of cipher suites providing a variety of security properties. The selection of cipher suites is critical to the security of the tunnel method. Selection of a cipher suite with weak or no authentication, such as an anonymous Diffie-Hellman-based cipher suite, will greatly increase the risk of system compromise. Since a tunnel method uses the TLS tunnel to transport data, the selection of a cipher suite with weak data encryption and integrity algorithms will also increase the vulnerability of the method to attacks.
TLSは、さまざまなセキュリティプロパティを提供する幅広い暗号スイートをサポートしています。暗号方式の選択は、トンネル方式のセキュリティにとって重要です。匿名のDiffie-Hellmanベースの暗号スイートなど、認証が弱い、または認証のない暗号スイートを選択すると、システムが侵害されるリスクが大幅に増加します。トンネル方式はTLSトンネルを使用してデータを転送するため、弱いデータ暗号化と整合性アルゴリズムを備えた暗号スイートを選択すると、攻撃に対するメソッドの脆弱性も増加します。
A tunnel protocol is prone to downgrading attacks if the tunnel protocol supports any key establishment algorithm that can be broken on-line. In a successful downgrading attack, an adversary breaks the selected "weak" key establishment algorithm and optionally the "weak" authentication algorithm without being detected. Here, "weak" refers to a key establishment algorithm that can be broken in real-time, and an authentication scheme that can be broken off-line, respectively. See [HC07] for more details. The requirements in this document disapprove the use of key establishment algorithms that can be broken on-line.
トンネルプロトコルがオンラインで破られる可能性のあるキー確立アルゴリズムをサポートしている場合、トンネルプロトコルはダウングレード攻撃を受ける傾向があります。ダウングレード攻撃が成功すると、攻撃者は、選択された「弱い」鍵確立アルゴリズムと、オプションで「弱い」認証アルゴリズムを検出されずに破ります。ここで、「弱い」とは、リアルタイムで破られる可能性のある鍵確立アルゴリズムと、オフラインで破られる可能性のある認証方式をそれぞれ指します。詳細については、[HC07]を参照してください。このドキュメントの要件は、オンラインで破られる可能性があるキー確立アルゴリズムの使用を承認していません。
Mutually anonymous tunnel protocols are prone to man-in-the-middle attacks described in [HC07]. During such an attack, an adversary establishes one tunnel with the peer and one with the authentication server, while the peer and server believe that they established a tunnel with each other. Once both tunnels have been established, the adversary can eavesdrop on all communications within the tunnels, i.e., the execution of the inner authentication method(s). Consequently, the adversary can eavesdrop on the identifiers that are exchanged as part of the EAP method, and thus the privacy of peer and/or authentication server is compromised along with any other data transmitted within the tunnels. This document requires server authentication to avoid the risks associated with anonymous cipher suites.
相互に匿名のトンネルプロトコルは、[HC07]で説明されている中間者攻撃の傾向があります。このような攻撃の間、攻撃者はピアとの1つのトンネルと認証サーバーとの1つのトンネルを確立し、ピアとサーバーは相互にトンネルを確立したと信じます。両方のトンネルが確立されると、攻撃者はトンネル内のすべての通信、つまり内部認証方式の実行を傍受できます。その結果、攻撃者はEAP方式の一部として交換される識別子を盗聴できるため、トンネル内で送信される他のデータとともに、ピアや認証サーバーのプライバシーが侵害されます。このドキュメントでは、匿名の暗号スイートに関連するリスクを回避するためにサーバー認証が必要です。
In many cases, a tunnel method provides mutual authentication by authenticating the server during tunnel establishment and authenticating the peer within the tunnel using an EAP method. As described in [TUNNEL-MITM], this mode of operation can allow tunnel man-in-the-middle attackers to authenticate to the server as the peer by tunneling the inner EAP protocol messages to and from a peer that is executing the method outside a tunnel or with an untrustworthy server. Cryptographic binding between the established keying material from the inner authentication method(s) and the tunnel protocol verifies that the endpoints of the tunnel and the inner authentication method(s) are the same. This can thwart the attack if the inner-method-derived keys are of sufficient strength that they cannot be broken in real-time.
多くの場合、トンネル方式では、トンネルの確立中にサーバーを認証し、EAP方式を使用してトンネル内のピアを認証することにより、相互認証を提供します。 [TUNNEL-MITM]で説明されているように、この操作モードでは、トンネルの中間者攻撃者が、外部のメソッドを実行しているピアとの間で内部EAPプロトコルメッセージをトンネリングすることにより、ピアとしてサーバーを認証できます。トンネルまたは信頼できないサーバー。内部認証方式からの確立されたキー生成情報とトンネルプロトコルの間の暗号バインディングは、トンネルのエンドポイントと内部認証方式が同じであることを確認します。これは、内部メソッドから派生したキーが、リアルタイムで解読できないほどの強度を持つ場合に、攻撃を阻止できます。
In cases where the inner authentication method does not generate any key material or only weak key material, security policies MUST be enforced such that the peer cannot execute the inner method with the same credentials outside a protective tunnel or with an untrustworthy server.
内部認証方法でキーマテリアルが生成されない場合、または弱いキーマテリアルのみが生成される場合は、ピアが保護トンネルの外部または信頼できないサーバーで同じ資格情報を使用して内部メソッドを実行できないように、セキュリティポリシーを適用する必要があります。
The tunnel method will use data that is outside the TLS tunnel such as the EAP type code or version numbers. If an attacker can compromise the protocol by modifying these values, the tunnel method MUST protect this data from modification. In some cases, external data may not need additional protection because it is implicitly verified during the protocol operation.
トンネル方式では、EAPタイプコードやバージョン番号など、TLSトンネルの外部にあるデータを使用します。攻撃者がこれらの値を変更してプロトコルを危険にさらすことができる場合、トンネルメソッドはこのデータを変更から保護する必要があります。場合によっては、外部データはプロトコル操作中に暗黙的に検証されるため、追加の保護が必要ない場合があります。
Terminating the inner method at a different location than the outer tunnel needs careful consideration. The inner method data may be vulnerable to modification and eavesdropping between the server that terminates the tunnel and the server that terminates the inner method. For example, if a cleartext password is used, then it may be sent to the inner method server in a RADIUS password attribute, which uses weak encryption that may not be suitable protection for many environments.
内部メソッドを外部トンネルとは異なる場所で終了する場合は、慎重に検討する必要があります。内部メソッドのデータは、トンネルを終了するサーバーと内部メソッドを終了するサーバーの間の変更および盗聴に対して脆弱である可能性があります。たとえば、クリアテキストのパスワードを使用する場合、RADIUSパスワード属性で内部メソッドサーバーに送信される可能性があります。これは、多くの環境に適した保護ではない可能性がある弱い暗号化を使用します。
In some cases, terminating the tunnel at a different location may make it difficult for a peer to authenticate the server and trust it for further communication. For example, if the TLS tunnel is terminated by a different organization, the peer needs to be able to authenticate and authorize the tunnel server to handle secret credentials that the peer shares with the home server that terminates the inner method. This may not meet the security policy of many environments.
場合によっては、トンネルを別の場所で終了すると、ピアがサーバーを認証してそれ以上の通信を信頼することが困難になることがあります。たとえば、TLSトンネルが別の組織によって終了されている場合、ピアはトンネルサーバーを認証および承認して、内部メソッドを終了するホームサーバーとピアが共有する秘密の資格情報を処理できる必要があります。これは、多くの環境のセキュリティポリシーに適合しない場合があります。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]マイヤーズ、M。、アンクニー、R。、マルパニ、A。、ガルペリン、S。、およびC.アダムス、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」、RFC 2560、1999年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[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月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンリー、D。、ウォーカー、J。、およびB.アボバ、「ワイヤレスLANの拡張認証プロトコル（EAP）メソッドの要件」、RFC 4017、2005年3月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley、R。およびB. Aboba、「認証、承認、およびアカウンティング（AAA）キー管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055] Freeman、T.、Housley、R.、Malpani、A.、Cooper、D。、およびW. Polk、「Server-Based Certificate Validation Protocol（SCVP）」、RFC 5055、2007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、Simon、D。、およびP. Eronen、「Extensible Authentication Protocol（EAP）Key Management Framework」、RFC 5247、2008年8月。
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
[RFC6677] Hartman、S.、Ed。、Clancy、T.、and K. Hoeper、 "Channel Binding Support for Extensible Authentication Protocol（EAP）Methods"、RFC 6677、July 2012。
[EAP-ENROLL] Mahy, R., "An Extensible Authentication Protocol (EAP) Enrollment Method", Work in Progress, March 2006.
[EAP-ENROLL] Mahy、R。、「Extensible Authentication Protocol（EAP）Enrollment Method」、Work in Progress、2006年3月。
[HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", Institute for Computer Sciences, Social Informatics and Telecommunications Engineering (ICST), The Fourth International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness (QShine 2007), August 2007.
[HC07] Hoeper、K.およびL. Chen、「Where EAP Security Claims Fail」、コンピュータ科学研究所、社会情報通信技術研究所（ICST）、第4回国際質の異なるネットワーク会議、信頼性、セキュリティおよび堅牢性（ QShine 2007）、2007年8月。
[LCN-2010] Hoeper, K. and L. Chen, "An Inconvenient Truth about Tunneled Authentications", Proceedings of 35th Annual IEEE Conference on Local Computer Networks (LCN 2010), September 2009.
[LCN-2010] Hoeper、K。およびL. Chen、「トンネル認証に関する不都合な真実」、ローカルコンピュータネットワークに関する第35回年次IEEE会議の議事録（LCN 2010）、2009年9月。
[NIST-SP-800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", Draft NIST Special Publication 800-108, April 2008.
[NIST-SP-800-108]チェンL.、「擬似ランダム関数を使用した鍵導出の推奨」、ドラフトNIST特別刊行物800-108、2008年4月。
[NIST-SP-800-120] Hoeper, K. and L. Chen, "Recommendation for EAP Methods Used in Wireless Network Access Authentication", NIST Special Publication 800-120, September 2009.
[NIST-SP-800-120] Hoeper、K。およびL. Chen、「ワイヤレスネットワークアクセス認証で使用されるEAP方式の推奨」、NIST Special Publication 800-120、2009年9月。
[NIST-SP-800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, part 1, March 2007.
[NIST-SP-800-57] Barker、E.、Barker、W.、Burr、W.、Polk、W。、およびM. Smid、「鍵管理の推奨事項-パート1：一般（改訂）」、NIST特別刊行物800-57、パート1、2007年3月。
[NIST-SP-800-57p3] Barker, E., Burr, W., Jones, A., Polk, W., Rose, S., and M. Smid, "Recommendation for Key Management, Part 3 Application-Specific Key Management Guidance", Draft NIST Special Publication 800-57, part 3, October 2008.
[NIST-SP-800-57p3] Barker、E.、Burr、W.、Jones、A.、Polk、W.、Rose、S。、およびM. Smid、「鍵管理の推奨事項、パート3アプリケーション固有Key Management Guidance」、ドラフトNIST Special Publication 800-57、パート3、2008年10月。
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP) Specification", August 2009, <http:// download.microsoft.com/download/9/5/E/ 95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-PEAP%5D.pdf>.
[PEAP] Microsoft Corporation、「[MS-PEAP]：Protected Extensible Authentication Protocol（PEAP）Specification」、2009年8月、<http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0 -A41D-A4F81802D92C /％5BMS-PEAP％5D.pdf>。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、2005年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「The Network Access Identifier」、RFC 4282、2005年12月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J。、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル」、RFC 4511、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月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズN.、「セキュアチャネルへのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without Server-Side State」、RFC 5077、2008年1月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「Network InterchangeのUnicode形式」、RFC 5198、2008年3月。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[RFC5209] Sangster、P.、Khosravi、H.、Mani、M.、Narayan、K。、およびJ. Tardo、「Network Endpoint Assessment（NEA）：Overview and Requirements」、RFC 5209、2008年6月。
[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月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「Tags for Identificationing Languages」、BCP 47、RFC 5646、2009年9月。
[RFC5793] 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.
[RFC5793] 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月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。
[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
著者のアドレス
Katrin Hoeper Motorola Solutions, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 USA
かｔりん ほえぺｒ もとろぁ そぅちおんｓ、 いんｃ。 １３０１ え。 あｌごんくいん ろあｄ Ｓちゃうｍぶｒｇ、 いＬ ６０１９６ うさ
EMail: khoeper@motorolasolutions.com
Stephen Hanna Juniper Networks 3 Beverly Road Bedford, MA 01730 USA
Ｓてｐへん はんあ じゅにぺｒ ねとぉｒｋｓ ３ べゔぇｒｌｙ ろあｄ べｄふぉｒｄ、 ま ０１７３０ うさ
EMail: shanna@juniper.net
Hao Zhou Cisco Systems, Inc. 4125 Highlander Parkway Richfield, OH 44286 USA
Hao Zhou Cisco Systems、Inc. 4125 Highlander Parkway Richfield、OH 44286 USA
EMail: hzhou@cisco.com
Joseph Salowey (editor) Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA
Joseph Salowey（編集者）Cisco Systems、Inc. 2901 3番目。 Ave Seattle、WA 98121 USA
EMail: jsalowey@cisco.com