Network Working Group P. Funk
Request for Comments: 5281 Unaffiliated
Category: Informational S. Blake-Wilson
SafeNet
August 2008
Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)
拡張認証プロトコルトンネル型トランスポート層セキュリティ認証プロトコルバージョン0（EAP-TTLSv0）
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange.
EAP-TTLSはハンドシェークフェーズとデータフェーズからなる、TLS（トランスポート層セキュリティ）セッションをカプセル化するEAP（拡張認証プロトコル）方法です。ハンドシェークフェーズの間、サーバは、標準のTLS手順を使用して（または、クライアントとサーバが相互認証された）クライアントに認証され、鍵材料は、後続のデータフェーズにおける情報交換のための暗号的に安全なトンネルを作成するために生成されます。データフェーズの間、クライアントは、セキュアトンネル内にカプセル化され、任意の認証メカニズムを使用して（または、クライアントとサーバが相互認証された）サーバに認証されます。カプセル化された認証メカニズム自体がEAPであってもよく、またはそれは、PAP、CHAP、MS-CHAP、またはMS-CHAP-V2などの別の認証プロトコルであってもよいです。盗聴、のman-in-the-middle、およびその他の攻撃からこれらのレガシープロトコルのセキュリティを保護しながらこのように、EAP-TTLSは、既存の認証データベースに対して使用する従来のパスワードベースの認証プロトコルを可能にします。データフェーズは、追加の、任意のデータ交換のために使用することもできます。
Table of Contents
目次
1. Introduction ....................................................4
2. Motivation ......................................................5
3. Requirements Language ...........................................7
4. Terminology .....................................................7
5. Architectural Model .............................................9
5.1. Carrier Protocols .........................................10
5.2. Security Relationships ....................................10
5.3. Messaging .................................................11
5.4. Resulting Security ........................................12
6. Protocol Layering Model ........................................12
7. EAP-TTLS Overview ..............................................13
7.1. Phase 1: Handshake ........................................14
7.2. Phase 2: Tunnel ...........................................14
7.3. EAP Identity Information ..................................15
7.4. Piggybacking ..............................................15
7.5. Session Resumption ........................................16
7.6. Determining Whether to Enter Phase 2 ......................17
7.7. TLS Version ...............................................18
7.8. Use of TLS PRF ............................................18
8. Generating Keying Material .....................................19
9. EAP-TTLS Protocol ..............................................20
9.1. Packet Format .............................................20
9.2. EAP-TTLS Start Packet .....................................21
9.2.1. Version Negotiation ................................21
9.2.2. Fragmentation ......................................22
9.2.3. Acknowledgement Packets ............................22
10. Encapsulation of AVPs within the TLS Record Layer .............23
10.1. AVP Format ...............................................23
10.2. AVP Sequences ............................................25
10.3. Guidelines for Maximum Compatibility with AAA Servers ....25
11. Tunneled Authentication .......................................26
11.1. Implicit Challenge .......................................26
11.2. Tunneled Authentication Protocols ........................27
11.2.1. EAP ...............................................27
11.2.2. CHAP ..............................................29
11.2.3. MS-CHAP ...........................................30
11.2.4. MS-CHAP-V2 ........................................30
11.2.5. PAP ...............................................32
11.3. Performing Multiple Authentications ......................33
11.4. Mandatory Tunneled Authentication Support ................34
11.5. Additional Suggested Tunneled Authentication Support .....34
12. Keying Framework ..............................................35
12.1. Session-Id ...............................................35
12.2. Peer-Id ..................................................35
12.3. Server-Id ................................................35
13. AVP Summary ...................................................35
14. Security Considerations .......................................36
14.1. Security Claims ..........................................36
14.1.1. Authentication Mechanism ..........................36
14.1.2. Ciphersuite Negotiation ...........................37
14.1.3. Mutual Authentication .............................37
14.1.4. Integrity Protection ..............................37
14.1.5. Replay Protection .................................37
14.1.6. Confidentiality ...................................37
14.1.7. Key Derivation ....................................37
14.1.8. Key Strength ......................................37
14.1.9. Dictionary Attack Protection ......................38
14.1.10. Fast Reconnect ...................................38
14.1.11. Cryptographic Binding ............................38
14.1.12. Session Independence .............................38
14.1.13. Fragmentation ....................................38
14.1.14. Channel Binding ..................................38
14.2. Client Anonymity .........................................38
14.3. Server Trust .............................................39
14.4. Certificate Validation ...................................39
14.5. Certificate Compromise ...................................40
14.6. Forward Secrecy ..........................................40
14.7. Negotiating-Down Attacks .................................40
15. Message Sequences .............................................41
15.1. Successful Authentication via Tunneled CHAP ..............41
15.2. Successful Authentication via Tunneled
EAP/MD5-Challenge ........................................43
15.3. Successful Session Resumption ............................46
16. IANA Considerations ...........................................47
17. Acknowledgements ..............................................48
18. References ....................................................48
18.1. Normative References .....................................48
18.2. Informative References ...................................49
Extensible Authentication Protocol (EAP) [RFC3748] defines a standard message exchange that allows a server to authenticate a client using an authentication method agreed upon by both parties. EAP may be extended with additional authentication methods by registering such methods with IANA or by defining vendor-specific methods.
拡張認証プロトコル（EAP）[RFC3748]は、サーバが、両当事者が合意した認証方法を使用してクライアントを認証することを可能にする標準的なメッセージ交換を定義します。 EAPは、IANAとのこのような方法を登録することによって、またはベンダー固有のメソッドを定義することによって、追加の認証方法で拡張することができます。
Transport Layer Security (TLS) [RFC4346] is an authentication protocol that provides for client authentication of a server or mutual authentication of client and server, as well as secure ciphersuite negotiation and key exchange between the parties. TLS has been defined as an authentication protocol for use within EAP (EAP-TLS) [RFC5216].
トランスポート層セキュリティ（TLS）[RFC4346]は、サーバーまたはクライアントとサーバーの相互認証のクライアント認証だけでなく、セキュアな暗号スイートネゴシエーションと当事者間の鍵交換を提供する認証プロトコルです。 TLSは、EAP（EAP-TLS）内で使用する認証プロトコル[RFC5216]として定義されています。
Other authentication protocols are also widely deployed. These are typically password-based protocols, and there is a large installed base of support for these protocols in the form of credential databases that may be accessed by RADIUS [RFC2865], Diameter [RFC3588], or other AAA servers. These include non-EAP protocols such as PAP [RFC1661], CHAP [RFC1661], MS-CHAP [RFC2433], or MS-CHAP-V2 [RFC2759], as well as EAP protocols such as MD5-Challenge [RFC3748].
他の認証プロトコルも広く展開されています。これらは、典型的には、パスワードベースのプロトコルであり、RADIUS [RFC2865]、直径[RFC3588]、または他のAAAサーバによってアクセスすることができる資格データベースの形でこれらのプロトコルのためのサポートの大規模なインストールベースがあります。これらは、PAP [RFC1661]、CHAP [RFC1661]、MS-CHAP [RFC2433]、またはMS-CHAP-V2 [RFC2759]、ならびにMD5チャレンジ[RFC3748]などのEAPプロトコルのような非EAPプロトコルを含みます。
EAP-TTLS is an EAP method that provides functionality beyond what is available in EAP-TLS. EAP-TTLS has been widely deployed and this specification documents what existing implementations do. It has some limitations and vulnerabilities, however. These are addressed in EAP-TTLS extensions and ongoing work in the creation of standardized tunneled EAP methods at the IETF. Users of EAP-TTLS are strongly encouraged to consider these in their deployments.
EAP-TTLSはEAP-TLSで利用可能なものを超えて機能を提供EAP方式です。 EAP-TTLSは広く展開し、既存の実装は何をすべきか、この仕様書されています。しかし、いくつかの制限や脆弱性があります。これらは、IETFで標準化され、トンネリングEAP方式の作成にEAP-TTLSの拡張や進行中の作業で対処されています。 EAP-TTLSのユーザーが強く、その展開でこれらを考慮することが奨励されています。
In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP-TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS authentication may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely deployed authentication infrastructures. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2.
EAP-TLSでは、TLSハンドシェイクは、クライアントとサーバの相互認証に使用されています。 EAP-TTLSは、クライアントとサーバーの間の追加の情報を交換するために、TLSハンドシェイクによって確立された安全な接続を使用して、この認証のネゴシエーションを拡張します。 EAP-TTLSでは、TLS認証が相互であってもよいです。またはそれだけでサーバーがクライアントに認証されている一方通行であってもよいです。ハンドシェイクによって確立された安全な接続は、サーバは、既存の、広く展開されている認証インフラストラクチャを使用してクライアントを認証できるようにするために使用することができます。クライアントの認証自体がEAPであってもよく、またはそれは、PAP、CHAP、MS-CHAPまたはMS-CHAP-V2などの別の認証プロトコルであってもよいです。
Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks.
盗聴、のman-in-the-middle、およびその他の攻撃からこれらのレガシープロトコルのセキュリティを保護しながらこのように、EAP-TTLSは、既存の認証データベースに対して使用する従来のパスワードベースの認証プロトコルを可能にします。
EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake.
EAP-TTLSは、クライアントとサーバがクライアントとアクセスポイント間のデータ接続に使用する鍵材料を確立することができます。鍵材料は、TLSハンドシェイクに基づいて、クライアントとサーバの間で暗黙的に確立されています。
In EAP-TTLS, client and server communicate using attribute-value pairs encrypted within TLS. This generality allows arbitrary functions beyond authentication and key exchange to be added to the EAP negotiation, in a manner compatible with the AAA infrastructure.
EAP-TTLSでは、クライアントとサーバがTLS暗号化された内の属性と値のペアを使用して通信します。この一般性は、認証及び鍵交換を越えて任意の機能はAAAインフラストラクチャと互換性のある方法で、EAPネゴシエーションに追加されることを可能にします。
The main limitation of EAP-TTLS is that its base version lacks support for cryptographic binding between the outer and inner authentication. Please refer to Section 14.1.11 for details and the conditions where this vulnerability exists. It should be noted that an extension for EAP-TTLS [TTLS-EXT] fixed this vulnerability. Users of EAP-TTLS are strongly encouraged to adopt this extension.
EAP-TTLSの主な限界は、その基本バージョンは、外側と内側の認証との間の結合暗号化のサポートを欠いていることです。詳細およびこの脆弱性が存在する条件については、セクション14.1.11を参照してください。 EAP-TTLS [TTLS-EXT]の拡張は、この脆弱性を修正していることに留意すべきです。 EAP-TTLSのユーザが強く、この拡張機能を採用することを奨励されています。
Most password-based protocols in use today rely on a hash of the password with a random challenge. Thus, the server issues a challenge, the client hashes that challenge with the password and forwards a response to the server, and the server validates that response against the user's password retrieved from its database. This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5- Challenge, and EAP/One-Time Password.
使用されているほとんどのパスワードベースのプロトコル今日のランダムチャレンジとパスワードのハッシュに依存しています。このように、サーバはチャレンジを発行、クライアントはパスワードでその挑戦をハッシュし、サーバへの応答を転送し、サーバーは、ユーザーのパスワードに対する応答はそのデータベースから取得することを検証します。この一般的なアプローチは、CHAP、MS-CHAP、MS-CHAP-V2、EAP / MD5-チャレンジ、およびEAP /ワンタイムパスワードを記述しています。
An issue with such an approach is that an eavesdropper that observes both challenge and response may be able to mount a dictionary attack, in which random passwords are tested against the known challenge to attempt to find one which results in the known response. Because passwords typically have low entropy, such attacks can in practice easily discover many passwords.
このようなアプローチの問題は、チャレンジとレスポンスの両方を観察盗聴者がランダムなパスワードが知られている応答をもたらすものを見つけようとすることが知られている課題に対してテストされている辞書攻撃をマウントすることができるかもしれないということです。パスワードは通常、低エントロピーを持っているので、このような攻撃は、実際には簡単に多くのパスワードを発見することができます。
While this vulnerability has long been understood, it has not been of great concern in environments where eavesdropping attacks are unlikely in practice. For example, users with wired or dial-up connections to their service providers have not been concerned that such connections may be monitored. Users have also been willing to entrust their passwords to their service providers, or at least to allow their service providers to view challenges and hashed responses which are then forwarded to their home authentication servers using, for example, proxy RADIUS, without fear that the service provider will mount dictionary attacks on the observed credentials. Because a user typically has a relationship with a single service provider, such trust is entirely manageable.
この脆弱性は、長い間理解されてきたが、それは盗聴攻撃は、実際にそうしている環境に大きな懸念されていません。例えば、有線またはそのサービスプロバイダへのダイヤルアップ接続を持つユーザーは、このような接続を監視することが懸念されていません。また、ユーザーは自分のサービスプロバイダに自分のパスワードを委託して喜んでてきた、あるいは少なくともそのサービスプロバイダーが課題を表示できるようにして、サービスという恐れず、例えば、プロキシRADIUSを使用して自分のホーム認証サーバに転送された応答をハッシュ化プロバイダが観測された資格情報に辞書攻撃をマウントします。ユーザーは、典型的には、単一のサービスプロバイダと関係を持っているので、そのような信頼は完全に管理可能です。
With the advent of wireless connectivity, however, the situation changes dramatically:
ワイヤレス接続の出現で、しかし、状況は劇的に変化します：
- Wireless connections are considerably more susceptible to eavesdropping and man-in-the-middle attacks. These attacks may enable dictionary attacks against low-entropy passwords. In addition, they may enable channel hijacking, in which an attacker gains fraudulent access by seizing control of the communications channel after authentication is complete.
- ワイヤレス接続はかなり盗聴やman-in-the-middle攻撃を受けやすいです。これらの攻撃は、低エントロピーパスワードに対する辞書攻撃を可能にします。また、彼らは、攻撃者は、認証が完了した後、通信チャネルの制御を押収することにより不正アクセスを獲得したチャネルハイジャックを、有効にすることができます。
- Existing authentication protocols often begin by exchanging the client's username in the clear. In the context of eavesdropping on the wireless channel, this can compromise the client's anonymity and locational privacy.
- 既存の認証プロトコルは、多くの場合、明らかに、クライアントのユーザ名を交換することから始めます。無線チャネル上の盗聴のコンテキストでは、これはクライアントの匿名性と立地のプライバシーを侵害することができます。
- Often in wireless networks, the access point does not reside in the administrative domain of the service provider with which the user has a relationship. For example, the access point may reside in an airport, coffee shop, or hotel in order to provide public access via 802.11 [802.11]. Even if password authentications are protected in the wireless leg, they may still be susceptible to eavesdropping within the untrusted wired network of the access point.
- 多くの場合、無線ネットワークにおいて、アクセスポイントは、ユーザが関係を有するサービスプロバイダの管理ドメインに存在しません。たとえば、アクセスポイントは、802.11 [802.11]を介して公衆のアクセスを提供するために、空港、コーヒーショップ、またはホテル内に常駐することができます。パスワードの認証が無線区間で保護されている場合でも、彼らはまだ、アクセスポイントの信頼できない、有線ネットワーク内で盗聴の影響を受けやすいかもしれません。
- In the traditional wired world, the user typically intentionally connects with a particular service provider by dialing an associated phone number; that service provider may be required to route an authentication to the user's home domain. In a wireless network, however, the user does not get to choose an access domain, and must connect with whichever access point is nearby; providing for the routing of the authentication from an arbitrary access point to the user's home domain may pose a challenge.
- 伝統的な有線の世界では、ユーザは、典型的には、意図的に関連した電話番号をダイヤルすることにより、特定のサービスプロバイダに接続します。そのサービスプロバイダは、ユーザーのホームドメインにルート認証に必要な場合があります。ワイヤレスネットワークでは、しかし、利用者のアクセスドメインを選択するために取得していない、とどのアクセスポイントに接続する必要がありますが近くにあり、任意のアクセスポイントからユーザーのホームドメインに認証のルーティングを提供することが課題を提起することがあります。
Thus, the authentication requirements for a wireless environment that EAP-TTLS attempts to address can be summarized as follows:
次のようにこのように、EAP-TTLSが対処しようとする無線環境のための認証要件をまとめることができます。
- Legacy password protocols must be supported, to allow easy deployment against existing authentication databases.
- レガシーパスワードプロトコルは、既存の認証データベースに対する簡単な展開を可能にするために、サポートする必要があります。
- Password-based information must not be observable in the communications channel between the client node and a trusted service provider, to protect the user against dictionary attacks.
- パスワードベースの情報は、辞書攻撃からユーザーを保護するために、クライアントノードと信頼できるサービスプロバイダとの間の通信チャネルで観測可能であってはなりません。
- The user's identity must not be observable in the communications channel between the client node and a trusted service provider, to protect the user against surveillance, undesired acquisition of marketing information, and the like.
- ユーザのアイデンティティは、監視、マーケティング情報の望ましくない取得、などに対してユーザーを保護するために、クライアントノードと信頼できるサービスプロバイダとの間の通信チャネルで観測可能であってはなりません。
- The authentication process must result in the distribution of shared keying information to the client and access point to permit encryption and validation of the wireless data connection subsequent to authentication, to secure it against eavesdroppers and prevent channel hijacking.
- 認証プロセスは、盗聴者に対してそれを確保し、チャネルの乗っ取りを防ぐために、認証後に無線データ接続の暗号化と検証を可能にするために、クライアントとアクセスポイントへの共有鍵情報の配信になる必要があります。
- The authentication mechanism must support roaming among access domains with which the user has no relationship and which will have limited capabilities for routing authentication requests.
- 認証メカニズムは、ユーザーが何の関係を持っていないし、認証要求をルーティングするための限られた能力を持っているであろうするアクセスドメイン間ローミングをサポートしている必要があります。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
AAA
AAA
Authentication, Authorization, and Accounting - functions that are generally required to control access to a network and support billing and auditing.
認証、許可、アカウンティング - 一般に、ネットワークやサポート、課金及び監査へのアクセスを制御するために必要とされる機能。
AAA protocol
AAAプロトコル
A network protocol used to communicate with AAA servers; examples include RADIUS and Diameter.
AAAサーバと通信するために使用されるネットワークプロトコル。例としては、RADIUSと直径を含みます。
AAA server
AAAサーバ
A server which performs one or more AAA functions: authenticating a user prior to granting network service, providing authorization (policy) information governing the type of network service the user is to be granted, and accumulating accounting information about actual usage.
ユーザを認証する前に、ユーザが付与されるネットワークサービスのタイプを支配する許可（ポリシー）情報を提供するネットワークサービスを許可し、実際の使用状況に関する課金情報を蓄積する：一つ以上のAAA機能を実行するサーバ。
AAA/H
AAA / H
A AAA server in the user's home domain, where authentication and authorization for that user are administered.
そのユーザの認証および認可を投与されているユーザのホームドメインのAAAサーバ、。
access point
アクセス・ポイント
A network device providing users with a point of entry into the network, and which may enforce access control and policy based on information returned by a AAA server. Since the access point terminates the server side of the EAP conversation, for the purposes of this document it is therefore equivalent to the "authenticator", as used in the EAP specification [RFC3748]. Since the access point acts as a client to a AAA server, for the purposes of this document it is therefore also equivalent to the "Network Access Server (NAS)", as used in AAA specifications such as [RFC2865].
ネットワークデバイスは、ネットワークへのエントリポイントをユーザーに提供し、これは、AAAサーバによって返された情報に基づいてアクセス制御およびポリシーを実施することができます。アクセスポイントは、EAPの会話のサーバー側を終了するため、この文書の目的のためには、EAP仕様[RFC3748]で使用される、従って、「認証者」に相当します。アクセスポイントはAAAサーバに対するクライアントとして作用するため、この文書の目的のためには、[RFC2865]としてAAA仕様で使用されるように、したがって、「ネットワークアクセスサーバ（NAS）」に相当します。
access domain
アクセスドメイン
The domain, including access points and other devices, that provides users with an initial point of entry into the network; for example, a wireless hot spot.
ネットワークへのエントリの最初のポイントをユーザーに提供するアクセスポイントと他のデバイスを含むドメイン。例えば、無線ホットスポット。
client
クライアント
A host or device that connects to a network through an access point. Since it terminates the client side of the EAP conversation, for the purposes of this document, it is therefore equivalent to the "peer", as used in the EAP specification [RFC3748].
アクセスポイントを介してネットワークに接続するホストまたはデバイス。それはEAP対話のクライアント側を終了するので、EAP仕様[RFC3748]で使用されるように、本文書の目的のために、それは、「ピア」することと等価です。
domain
ドメイン
A network and associated devices that are under the administrative control of an entity such as a service provider or the user's home organization.
ネットワークと、サービスプロバイダやユーザのホーム組織としてエンティティの管理制御下にある関連デバイス。
link layer
リンク層
A protocol used to carry data between hosts that are connected within a single network segment; examples include PPP and Ethernet.
単一のネットワークセグメント内で接続されたホストとの間でデータを運ぶために使用されるプロトコル。例はPPPとイーサネットが含まれます。
NAI
ない
A Network Access Identifier [RFC4282], normally consisting of the name of the user and, optionally, the user's home realm.
通常、ユーザーの名前と、必要に応じて、ユーザーのホーム領域からなるネットワークアクセス識別子[RFC4282]、。
proxy
代理
A server that is able to route AAA transactions to the appropriate AAA server, possibly in another domain, typically based on the realm portion of an NAI.
おそらく別のドメインに、適切なAAAサーバにルーティングAAA取引することができるサーバは、典型的には、NAIのレルム部分に基づきます。
realm
分野
The optional part of an NAI indicating the domain to which a AAA transaction is to be routed, normally the user's home domain.
AAAトランザクションにドメインを示すNAIのオプション部分は、通常はユーザーのホームドメイン、ルーティングされます。
service provider
サービスプロバイダ
An organization (with which a user has a business relationship) that provides network or other services. The service provider may provide the access equipment with which the user connects, may perform authentication or other AAA functions, may proxy AAA transactions to the user's home domain, etc.
組織（ユーザーが業務上の関係を有する）ネットワークまたは他のサービスを提供しています。サービスプロバイダは、など、ユーザーが接続するとアクセス機器を提供することができる認証または他のAAA機能を実行することができる、ユーザのホームドメインにプロキシAAAの取引をしてもよいです
TTLS server
TTLSサーバ
A AAA server which implements EAP-TTLS. This server may also be capable of performing user authentication, or it may proxy the user authentication to a AAA/H.
EAP-TTLSを実装AAAサーバ。このサーバは、ユーザ認証を行うことが可能であってもよいし、AAA / Hへのプロキシユーザ認証をしてもよいです。
user
ユーザー
The person operating the client device. Though the line is often blurred, "user" is intended to refer to the human being who is possessed of an identity (username), password, or other authenticating information, and "client" is intended to refer to the device which makes use of this information to negotiate network access. There may also be clients with no human operators; in this case, the term "user" is a convenient abstraction.
クライアントデバイスを操作する人。ラインがしばしばぼやけているが、「利用者」はを利用したデバイスを指すことが意図されたアイデンティティ（ユーザー名）、パスワード、またはその他の認証情報、および「クライアント」を所有している人間を指すことを意図していますこの情報は、ネットワークへのアクセスを交渉します。また、無人間のオペレータを持つクライアントがあるかもしれません。この場合には、「ユーザ」という用語は、便利な抽象化です。
The network architectural model for EAP-TTLS usage and the type of security it provides is shown below.
EAP-TTLSを使用するためのネットワークアーキテクチャモデルとそれが提供するセキュリティのタイプを以下に示します。
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| client |<---->| access |<---->| TTLS AAA |<---->| AAA/H |
| | | point | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
<---- secure password authentication tunnel --->
<---- secure data tunnel ---->
The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the TTLS server and AAA/H server might be a single entity; the access point and TTLS server might be a single entity; or, indeed, the functions of the access point, TTLS server and AAA/H server might be combined into a single physical device. The above diagram illustrates the division of labor among entities in a general manner and shows how a distributed system might be constructed; however, actual systems might be realized more simply.
上に示したエンティティは、論理エンティティであり、又はネットワーク構成要素を分離するために対応してもしなくてもよいです。例えば、TTLSサーバとAAA / Hサーバは、単一のエンティティであるかもしれません。アクセスポイントとTTLSサーバは、単一のエンティティであるかもしれません。または、実際、アクセスポイント、TTLSサーバとAAA / Hサーバの機能は、単一の物理デバイスに統合されるかもしれません。上記の図は一般的な方法でエンティティ間分業を示し、分散システムを構築する方法を示し。しかし、実際のシステムでは、より簡単に実現される可能性があります。
Note also that one or more AAA proxy servers might be deployed between access point and TTLS server, or between TTLS server and AAA/H server. Such proxies typically perform aggregation or are required for realm-based message routing. However, such servers play no direct role in EAP-TTLS and are therefore not shown.
注また、1台のまたは複数のAAAプロキシサーバは、アクセスポイントとTTLSサーバの間、またはTTLSサーバとAAA / Hサーバの間に配備される可能性があります。そのようなプロキシは、典型的には、凝集を実行するか、またはレルムベースのメッセージルーティングのために必要とされます。しかし、そのようなサーバは、EAP-TTLSには直接的な役割を果たしていないため、表示されません。
The entities shown above communicate with each other using carrier protocols capable of encapsulating EAP. The client and access point communicate typically using a link layer carrier protocol such as PPP or EAPOL (EAP over LAN). The access point, TTLS server, and AAA/H server communicate using a AAA carrier protocol such as RADIUS or Diameter.
上に示したエンティティは、EAPをカプセル化することが可能なキャリアプロトコルを用いて互いに通信します。クライアントとアクセスポイントは、典型的には、PPPまたはEAPOL（LAN上EAP）などのリンク層のキャリア・プロトコルを使用して通信します。アクセスポイント、TTLSサーバとAAA / Hサーバは、RADIUSまたはDIAMETERなどのAAAキャリヤープロトコルを使用して通信します。
EAP, and therefore EAP-TTLS, must be initiated via the carrier protocol between client and access point. In PPP or EAPOL, for example, EAP is initiated when the access point sends an EAP-Request/Identity packet to the client.
EAP、したがって、EAP-TTLSは、クライアントとアクセスポイント間のキャリアプロトコルを介して開始する必要があります。アクセスポイントがクライアントにEAP-Request / Identityフレームを送信する際にPPPまたはEAPOLでは、例えば、EAPが開始されます。
The keying material used to encrypt and authenticate the data connection between the client and access point is developed implicitly between the client and TTLS server as a result of the EAP-TTLS negotiation. This keying material must be communicated to the access point by the TTLS server using the AAA carrier protocol.
クライアントとアクセスポイント間のデータ接続を暗号化し、認証するために使用されるキーイングマテリアルは、EAP-TTLS交渉の結果として、クライアントとTTLSサーバの間で暗黙のうちに開発されました。この鍵材料は、AAAキャリヤープロトコルを使用TTLSサーバによってアクセスポイントに通信されなければなりません。
The client and access point have no pre-existing security relationship.
クライアントとアクセスポイントには、既存のセキュリティ関係を持っていません。
The access point, TTLS server, and AAA/H server are each assumed to have a pre-existing security association with the adjacent entity with which it communicates. With RADIUS, for example, this is achieved using shared secrets. It is essential for such security relationships to permit secure key distribution.
アクセスポイント、TTLSサーバとAAA / Hサーバは、それぞれが通信すると、隣接するエンティティと既存のセキュリティアソシエーションを有すると仮定されます。 RADIUSを使用すると、例えば、これは、共有秘密を使用して達成されます。このようなセキュリティの関係は、安全な鍵の配布を許可することが不可欠です。
The client and AAA/H server have a security relationship based on the user's credentials such as a password.
クライアントとAAA / Hサーバは、パスワードなどのユーザーの資格情報に基づいてセキュリティ関係を有しています。
The client and TTLS server may have a one-way security relationship based on the TTLS server's possession of a private key guaranteed by a CA certificate which the user trusts, or may have a mutual security relationship based on certificates for both parties.
クライアントとTTLSサーバは、両当事者のための証明書に基づいた相互安全保障関係を有することができ、ユーザが信頼する、またはCA証明書により保証された秘密鍵のTTLSサーバの所有に基づく一方向の安全保障関係を有することができます。
The client and access point initiate an EAP conversation to negotiate the client's access to the network. Typically, the access point issues an EAP-Request/Identity to the client, which responds with an EAP-Response/Identity. Note that the client need not include the user's actual identity in this EAP-Response/Identity packet other than for routing purposes (e.g., realm information; see Section 7.3 and [RFC3748], Section 5.1); the user's actual identity need not be transmitted until an encrypted channel has been established.
クライアントとアクセスポイントはクライアントにネットワークへのアクセスを交渉するEAPの会話を開始します。一般的に、アクセスポイントは、EAP応答/アイデンティティで応答し、クライアントにEAP要求/アイデンティティを発行します。 （例えば、レルム情報;セクション7.3と[RFC3748]、セクション5.1を参照）クライアントがルーティング目的以外、このEAP応答/アイデンティティパケットにユーザーの実際の身元を含む必要はないことに注意してください。暗号化されたチャネルが確立されるまで、ユーザーの実際の身元を送信する必要はありません。
The access point now acts as a passthrough device, allowing the TTLS server to negotiate EAP-TTLS with the client directly.
アクセスポイントはTTLSサーバが直接クライアントにEAP-TTLSを交渉することができ、パススルーデバイスとして機能します。
During the first phase of the negotiation, the TLS handshake protocol is used to authenticate the TTLS server to the client and, optionally, to authenticate the client to the TTLS server, based on public/private key certificates. As a result of the handshake, client and TTLS server now have shared keying material and an agreed upon TLS record layer cipher suite with which to secure subsequent EAP-TTLS communication.
交渉の最初の段階では、TLSハンドシェイクプロトコルは、公開鍵/秘密鍵証明書に基づいて、TTLSサーバにクライアントを認証するために、必要に応じて、クライアントにTTLSサーバを認証するために使用されます。握手の結果として、クライアントとTTLSサーバは現在、材料をキーイング、その後のEAP-TTLSの通信を確保するとのTLSレコード層の暗号スイートで合意共有しています。
During the second phase of negotiation, client and TTLS server use the secure TLS record layer channel established by the TLS handshake as a tunnel to exchange information encapsulated in attribute-value pairs, to perform additional functions such as authentication (one-way or mutual), validation of client integrity and configuration, provisioning of information required for data connectivity, etc.
交渉の第二段階の間に、クライアントとTTLSサーバは、認証（一方向または相互）などの追加の機能を実行するために、属性値のペアにカプセル化された情報を交換するトンネルとしてTLSハンドシェイクによって確立された安全なTLSレコード層チャネルを使用しますなど、クライアントの整合性とコンフィギュレーションの検証、データ接続のために必要な情報の提供、
If a tunneled client authentication is performed, the TTLS server de-tunnels and forwards the authentication information to the AAA/H. If the AAA/H issues a challenge, the TTLS server tunnels the challenge information to the client. The AAA/H server may be a legacy device and needs to know nothing about EAP-TTLS; it only needs to be able to authenticate the client based on commonly used authentication protocols.
トンネリングクライアント認証は、TTLSサーバのデトンネルを行い、AAA / Hに認証情報を転送している場合。 AAA / Hは、チャレンジを発行した場合、TTLSサーバはクライアントにチャレンジ情報をトンネルします。 AAA / Hサーバは、レガシーデバイスであることと、EAP-TTLSについて何も知らないする必要があり、それだけで一般的に使用される認証プロトコルに基づいてクライアントを認証できるようにする必要があります。
Keying material for the subsequent data connection between client and access point (Master Session Key / Extended Master Session Key (MSK/EMSK); see Section 8) is generated based on secret information developed during the TLS handshake between client and TTLS server. At the conclusion of a successful authentication, the TTLS server may transmit this keying material to the access point, encrypted based on the existing security associations between those devices (e.g., RADIUS).
クライアントとアクセスポイント間の後続のデータ接続のための材料をキーイング（マスターセッションキー/拡張マスターセッションキー（MSK / EMSK）;セクション8を参照）は、クライアントとTTLSサーバ間のTLSハンドシェイク中に開発された秘密情報に基づいて生成されます。認証成功の終了時に、TTLSサーバは、それらのデバイス（例えば、RADIUS）との間の既存のセキュリティアソシエーションに基づいて暗号化されたアクセスポイントにこの鍵材料を、送信することができます。
The client and access point now share keying material that they can use to encrypt data traffic between them.
クライアントとアクセスポイントは、今、彼らはそれらの間のデータトラフィックを暗号化するために使用することができますキーイング材料を共有しています。
As the diagram above indicates, EAP-TTLS allows user identity and password information to be securely transmitted between client and TTLS server, and generates keying material to allow network data subsequent to authentication to be securely transmitted between client and access point.
図は、上記示したように、EAP-TTLSは、ユーザーIDとパスワード情報を確実クライアントとTTLSサーバの間で送信されることを可能に、かつ確実にクライアントとアクセスポイントの間で送信される認証に続いて、ネットワークデータを可能にするキーイングマテリアルを生成します。
EAP-TTLS packets are encapsulated within EAP, and EAP in turn requires a carrier protocol to transport it. EAP-TTLS packets themselves encapsulate TLS, which is then used to encapsulate attribute-value pairs (AVPs) which may carry user authentication or other information. Thus, EAP-TTLS messaging can be described using a layered model, where each layer is encapsulated by the layer beneath it. The following diagram clarifies the relationship between protocols:
EAP-TTLSパケットは、EAP内にカプセル化され、ひいてはEAPはそれを輸送するためのキャリアプロトコルを必要とします。 EAP-TTLSは、それ自体が、ユーザ認証または他の情報を運ぶことができる属性値ペア（AVPを）カプセル化するために使用されるTLSをカプセル化パケット。したがって、EAP-TTLSメッセージングは、各層がその下の層によってカプセル化された階層モデルを用いて記述することができます。次の図は、プロトコル間の関係を明確に：
+-----------------------------------------------------------+
| AVPs, including authentication (PAP, CHAP, MS-CHAP, etc.) |
+-----------------------------------------------------------+
| TLS |
+-----------------------------------------------------------+
| EAP-TTLS |
+-----------------------------------------------------------+
| EAP |
+-----------------------------------------------------------+
| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
+-----------------------------------------------------------+
When the user authentication protocol is itself EAP, the layering is as follows:
ユーザ認証プロトコルはEAP自体である場合、以下のように、階層化です。
+-----------------------------------------------------------+
| EAP Method (MD-Challenge, etc.) |
+-----------------------------------------------------------+
| AVPs, including EAP |
+-----------------------------------------------------------+
| TLS |
+-----------------------------------------------------------+
| EAP-TTLS |
+-----------------------------------------------------------+
| EAP |
+-----------------------------------------------------------+
| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
+-----------------------------------------------------------+
Methods for encapsulating EAP within carrier protocols are already defined. For example, PPP [RFC1661] or EAPOL [802.1X] may be used to transport EAP between client and access point; RADIUS [RFC2865] or Diameter [RFC3588] are used to transport EAP between access point and TTLS server.
キャリアプロトコル内でEAPをカプセル化するための方法は、すでに定義されています。例えば、PPP [RFC1661]またはEAPOL [802.1X]は、クライアントとアクセスポイント間でEAPを搬送するために使用することができます。 RADIUS [RFC2865]または直径[RFC3588]は、アクセスポイントとTTLSサーバの間でEAPを搬送するために使用されます。
A EAP-TTLS negotiation comprises two phases: the TLS handshake phase and the TLS tunnel phase.
TLSハンドシェイクフェーズとTLSトンネル相：EAP-TTLSネゴシエーションは、2つのフェーズを含みます。
During phase 1, TLS is used to authenticate the TTLS server to the client and, optionally, the client to the TTLS server. Phase 1 results in the activation of a cipher suite, allowing phase 2 to proceed securely using the TLS record layer. (Note that the type and degree of security in phase 2 depends on the cipher suite negotiated during phase 1; if the null cipher suite is negotiated, there will be no security!)
フェーズ1の間に、TLSは、TTLSサーバに、必要に応じて、クライアントをクライアントにTTLSサーバを認証するために使用されます。フェーズ2は、TLSレコード層を使用して安全に進行させる位相暗号スイートの活性化に1つの結果、。 （フェーズ2種類とセキュリティの程度はフェーズ1中にネゴシエートされた暗号スイートに依存することに注意してください。ヌル暗号スイートがネゴシエートされる場合、セキュリティは存在しません！）
During phase 2, the TLS record layer is used to tunnel information between client and TTLS server to perform any of a number of functions. These might include user authentication, client integrity validation, negotiation of data communication security capabilities, key distribution, communication of accounting information, etc. Information between client and TTLS server is exchanged via attribute-value pairs (AVPs) compatible with RADIUS and Diameter; thus, any type of function that can be implemented via such AVPs may easily be performed.
フェーズ2の間に、TLSレコード層は、多数の機能のいずれかを実行するために、クライアントとTTLSサーバとの間のトンネル情報に使用されます。クライアントとTTLSサーバは（のAVP）RADIUSと互換性があり、直径属性と値のペアを介して交換される間、これらは、ユーザ認証、クライアントの整合性の検証、データ通信セキュリティ機能の折衝、鍵配布、会計情報の通信、などの情報が含まれる場合があります。従って、このようなのAVPを介して実装することができる機能の任意の種類を容易に行うことができます。
EAP-TTLS specifies how user authentication may be performed during phase 2. The user authentication may itself be EAP, or it may be a legacy protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Phase 2 user authentication may not always be necessary, since the user may already have been authenticated via the mutual authentication option of the TLS handshake protocol.
EAP-TTLSは、ユーザ認証自体がEAPであってもよいフェーズ2ユーザ認証中に実行することができる方法を指定し、又はそのようなPAP、CHAP、MS-CHAP、またはMS-CHAP-V2としてレガシープロトコルであってもよいです。ユーザがすでにTLSハンドシェイクプロトコルの相互認証オプションを介して認証されている可能性があるため、フェーズ2のユーザ認証は常に、必要ではないかもしれません。
Functions other than authentication MAY also be performed during phase 2. This document does not define any such functions; however, any organization or standards body is free to specify how additional functions may be performed through the use of appropriate AVPs.
認証以外の機能も、この文書では、どのような機能を定義していないフェーズ2の間に実行することができます。しかし、どのような組織や標準化団体が適切なのAVPを使用して実行することができる方法を追加機能を指定して自由です。
EAP-TTLS specifies how keying material for the data connection between client and access point is generated. The keying material is developed implicitly between client and TTLS server based on the results of the TLS handshake; the TTLS server will communicate the keying material to the access point over the carrier protocol.
EAP-TTLSは、クライアントとアクセスポイント間のデータ接続のためのキーイング材料を生成する方法を指定します。キーイング材料は、TLSハンドシェイクの結果に基づいて、クライアントとTTLSサーバの間で暗黙のうちに開発されました。 TTLSサーバは、キャリアプロトコルを介してアクセスポイントにキーイングマテリアルを通信します。
In phase 1, the TLS handshake protocol is used to authenticate the TTLS server to the client and, optionally, to authenticate the client to the TTLS server.
フェーズ1では、TLSハンドシェイクプロトコルがTTLSサーバにクライアントを認証するために、必要に応じて、クライアントにTTLSサーバを認証するために使用されます。
The TTLS server initiates the EAP-TTLS method with an EAP-TTLS/Start packet, which is an EAP-Request with Type = EAP-TTLS and the S (Start) bit set. This indicates to the client that it should begin the TLS handshake by sending a ClientHello message.
TTLSサーバはEAP-TTLSおよびS（スタート）は、ビットセット=種類にEAP-要求であるEAP-TTLS /スタートパケットとEAP-TTLS方式を開始します。これは、ClientHelloメッセージを送信することによって、TLSハンドシェイクを開始すべきであることをクライアントに示します。
EAP packets continue to be exchanged between client and TTLS server to complete the TLS handshake, as described in [RFC5216]. Phase 1 is completed when the client and TTLS server exchange ChangeCipherSpec and Finished messages. At this point, additional information may be securely tunneled.
EAPパケットは、[RFC5216]で説明したように、TLSハンドシェイクを完了するために、クライアントとTTLSサーバの間で交換され続けています。フェーズ1が完了すると、クライアントとTTLSサーバの交換ChangeCipherSpecをとFinishedメッセージ。この時点で、追加の情報をセキュアにトンネリングすることがあります。
As part of the TLS handshake protocol, the TTLS server will send its certificate along with a chain of certificates leading to the certificate of a trusted CA. The client will need to be configured with the certificate of the trusted CA in order to perform the authentication.
TLSハンドシェイクプロトコルの一環として、TTLSサーバは、信頼できるCAの証明書につながる証明書のチェーンと一緒にその証明書を送信しますクライアントは、認証を実行するために、信頼できるCAの証明書を使用して設定する必要があります。
If certificate-based authentication of the client is desired, the client must have been issued a certificate and must have the private key associated with that certificate.
クライアントの証明書ベースの認証を希望する場合、クライアントは、証明書を発行されている必要があり、その証明書に関連付けられた秘密鍵を持っている必要があります。
In phase 2, the TLS record layer is used to securely tunnel information between client and TTLS server. This information is encapsulated in sequences of attribute-value pairs (AVPs), whose use and format are described in later sections.
フェーズ2では、TLSレコード層は、クライアントとTTLSサーバの間のセキュアトンネル情報ために使用されます。この情報を使用し、フォーマット後のセクションに記載されている属性値ペア（AVPの）の配列中にカプセル化されます。
Any type of information may be exchanged during phase 2, according to the requirements of the system. (It is expected that applications utilizing EAP-TTLS will specify what information must be exchanged and therefore which AVPs must be supported.) The client begins the phase 2 exchange by encoding information in a sequence of AVPs, passing this sequence to the TLS record layer for encryption, and sending the resulting data to the TTLS server.
任意のタイプの情報は、システムの要件に応じて、フェーズ2の間に交換されてもよいです。クライアントは、TLSレコード層にこの配列を渡す、のAVPの順序で情報を符号化することにより、位相2の交換を開始する（EAP-TTLSを利用するアプリケーションを交換しなければならないどのような情報、従ってサポートされなければならないのAVPを指定します。と予想されます）暗号化のために、とTTLSサーバへの結果のデータを送信します。
The TTLS server recovers the AVPs in clear text from the TLS record layer. If the AVP sequence includes authentication information, it forwards this information to the AAA/H server using the AAA carrier protocol. Note that the EAP-TTLS and AAA/H servers may be one and the same; in which case, it simply processes the information locally.
TTLSサーバは、TLSレコード層からクリアテキストでAVPを回復します。 AVP配列は、認証情報が含まれている場合、それはAAAキャリア・プロトコルを使用してAAA / Hサーバにこの情報を転送します。 EAP-TTLSおよびAAA / Hサーバは、同一であってもよいことに留意されたいです。その場合には、それは単に情報をローカルに処理します。
The TTLS server may respond with its own sequence of AVPs. The TTLS server passes the AVP sequence to the TLS record layer for encryption and sends the resulting data to the client. For example, the TTLS server may forward an authentication challenge received from the AAA/H.
TTLSサーバは、AVPの独自のシーケンスで応答することができます。 TTLSサーバは、暗号化のためのTLSレコード層にAVP列を渡し、クライアントに結果のデータを送信します。例えば、TTLSサーバは、AAA / Hから受信した認証チャレンジを転送することができます。
This process continues until the AAA/H either accepts or rejects the client, resulting in the TTLS server completing the EAP-TTLS negotiation and indicating success or failure to the encapsulating EAP protocol (which normally results in a final EAP-Success or EAP-Failure being sent to the client).
このプロセスは、AAA / Hまで続くいずれかTTLSサーバはEAP-TTLSのネゴシエーションを完了し、カプセル化するEAPプロトコルに成功または失敗を示す、その結果、クライアントを受け入れまたは拒否し（通常は最終EAP成功又はEAP-障害をもたらします）クライアントに送信されます。
The TTLS server distributes data connection keying information and other authorization information to the access point in the same AAA carrier protocol message that carries the final EAP-Success or other success indication.
TTLSサーバは、最終的なEAP-成功または他の成功指示を運ぶ同じAAAキャリア・プロトコル・メッセージ中のアクセスポイントへの情報及び他の認証情報をキーイングデータ接続を分配します。
The identity of the user is provided during phase 2, where it is protected by the TLS tunnel. However, prior to beginning the EAP-TTLS authentication, the client will typically issue an EAP-Response/Identity packet as part of the EAP protocol, containing a username in clear text. To preserve user anonymity against eavesdropping, this packet specifically SHOULD NOT include the actual name of the user; instead, it SHOULD use a blank or placeholder such as "anonymous". However, this privacy constraint is not intended to apply to any information within the EAP-Response/Identity that is required for routing; thus, the EAP-Response/Identity packet MAY include the name of the realm of a trusted provider to which EAP-TTLS packets should be forwarded; for example, "anonymous@myisp.com".
ユーザのアイデンティティは、それがTLSトンネルによって保護されているフェーズ2の間に設けられています。しかし、EAP-TTLS認証を開始する前に、クライアントは通常、クリアテキストでユーザー名を含む、EAPプロトコルの一部としてEAP応答/アイデンティティパケットを発行します。盗聴に対するユーザーの匿名性を維持するには、このパケットは、特にユーザーの実際の名前を含めるべきではありません。その代わり、それは空白または、そのような「匿名」としてプレースホルダを使用すべきです。しかし、このプライバシー制約をルーティングするために必要とされるEAP応答/アイデンティティ内の任意の情報に適用することを意図していません。このように、EAP応答/アイデンティティパケットは、EAP-TTLSパケットが転送されなければならないための信頼できるプロバイダのレルムの名前を含むことができ、例えば、 "anonymous@myisp.com"。
Note that at the time the initial EAP-Response/Identity packet is sent the EAP method is yet to be negotiated. If, in addition to EAP-TTLS, the client is willing to negotiate use of EAP methods that do not support user anonymity, then the client MAY include the name of the user in the EAP-Response/Identity to meet the requirements of the other candidate EAP methods.
時の初期EAP応答/アイデンティティパケットはEAP方式が交渉することがまだある送られることに注意してください。 、EAP-TTLSに加えて、クライアントはユーザーの匿名性をサポートしていないEAPメソッドの使用を交渉する意思がある場合、クライアントは、他の要件を満たすためにEAP応答/アイデンティティでユーザーの名前を含んでもよい（MAY）候補EAPメソッド。
While it is convenient to describe EAP-TTLS messaging in terms of two phases, it is sometimes required that a single EAP-TTLS packet contain both phase 1 and phase 2 TLS messages.
それは二つの相の点でEAP-TTLSメッセージングを記述するのに便利であるが、時々、単一のEAP-TTLSパケットが両方の相1及び相2 TLSメッセージを含むことが必要です。
Such "piggybacking" occurs when the party that completes the handshake also has AVPs to send. For example, when negotiating a resumed TLS session, the TTLS server sends its ChangeCipherSpec and
また、ハンドシェイクを完了する当事者が送信するAVPを持っているとき、そのような「ピギーバック」が発生します。再開TLSセッションをネゴシエートするとき、例えば、TTLSサーバはChangeCipherSpecをを送信し、
Finished messages first, then the client sends its own ChangeCipherSpec and Finished messages to conclude the handshake. If the client has authentication or other AVPs to send to the TTLS server, it MUST tunnel those AVPs within the same EAP-TTLS packet immediately following its Finished message. If the client fails to do this, the TTLS server will incorrectly assume that the client has no AVPs to send, and the outcome of the negotiation could be affected.
完成したメッセージは、まず、クライアントは握手を締結することを、自身のChangeCipherSpecを完成したメッセージを送信します。クライアントはTTLSサーバに送信する認証または他のAVPを持っている場合、それはトンネル同じEAP-TTLSパケット内のもののAVPは、直ちにそのFinishedメッセージを次のようしなければなりません。クライアントはこれを行うに失敗した場合、TTLSサーバが誤っクライアントが送るべきAVPを持っていないと仮定します、との交渉の結果が影響を受ける可能性があります。
When a client and TTLS server that have previously negotiated an EAP-TTLS session begin a new EAP-TTLS negotiation, the client and TTLS server MAY agree to resume the previous session. This significantly reduces the time required to establish the new session. This could occur when the client connects to a new access point, or when an access point requires reauthentication of a connected client.
以前にEAP-TTLSセッションを交渉しているクライアントとTTLSサーバが新しいEAP-TTLS交渉を開始すると、クライアントとTTLSサーバは、前のセッションを再開することに同意することができます。これはかなり新しいセッションを確立するのに必要な時間を削減します。クライアントが新しいアクセスポイントに接続したとき、またはアクセスポイントが接続されたクライアントの再認証を必要とするときにこれが発生する可能性があります。
Session resumption is accomplished using the standard TLS mechanism. The client signals its desire to resume a session by including the session ID of the session it wishes to resume in the ClientHello message; the TTLS server signals its willingness to resume that session by echoing that session ID in its ServerHello message.
セッション再開は、標準のTLSメカニズムを使用して達成されます。クライアントはClientHelloメッセージに再開したいセッションのセッションIDを含めることによって、セッションを再開するために、その願望を知らせます。 TTLSサーバは、そのServerHelloメッセージにそのセッションIDをエコーして、そのセッションを再開する意思を通知します。
If the TTLS server elects not to resume the session, it simply does not echo the session ID, causing a new session to be negotiated. This could occur if the TTLS server is configured not to resume sessions, if it has not retained the requested session's state, or if the session is considered stale. A TTLS server may consider the session stale based on its own configuration, or based on session-limiting information received from the AAA/H (e.g., the RADIUS Session-Timeout attribute).
TTLSサーバはセッションを再開しないことを選択した場合、それは単に新しいセッションが交渉させる、セッションIDをエコーしません。 TTLSサーバは、要求されたセッションの状態を保持していない場合、またはセッションが無効と見なされた場合、セッションを再開しないように構成されている場合に発生する可能性があります。 TTLSサーバは、セッションが失効した独自の設定に基づいて、又は（例えば、RADIUSセッションタイムアウト属性）AAA / Hから受信したセッション制限情報に基づいて考慮することができます。
Tunneled authentication is specifically not performed for resumed sessions; the presumption is that the knowledge of the master secret (as evidenced by the ability to resume the session) is authentication enough. This allows session resumption to occur without any messaging between the TTLS server and the AAA/H. If periodic reauthentication to the AAA/H is desired, the AAA/H must indicate this to the TTLS server when the original session is established, for example, using the RADIUS Session-Timeout attribute.
トンネリングされた認証は、特に再開セッションのために実行されていません。推定は（セッションを再開する能力によって証明されるように）マスターシークレットの知識が十分に認証があるということです。これは、セッションの再開がTTLSサーバとAAA / Hとの間のメッセージングなしで起こることを可能にします。 AAA / Hへの定期的な再認証が必要な場合は、元のセッションが確立されると、AAA / Hは、RADIUSセッションタイムアウト属性を使用して、例えば、TTLSサーバにこれを示さなければなりません。
The client MAY send other AVPs in its first phase 2 message of a session resumption, to initiate non-authentication functions. If it does not, the TTLS server, at its option, MAY send AVPs to the client to initiate non-authentication functions, or MAY simply complete the EAP-TTLS negotiation and indicate success or failure to the encapsulating EAP protocol.
クライアントは非認証機能を開始するために、セッションの再開の最初のフェーズ2のメッセージに他のAVPを送るかもしれません。そうでない場合は、TTLSサーバは、その選択により、非認証機能を開始するために、クライアントにAVPを送るかもしれ、または単にEAP-TTLS交渉を完了し、カプセル化するEAPプロトコルに成功または失敗を示すことがあります。
The TTLS server MUST retain authorization information returned by the AAA/H for use in resumed sessions. A resumed session MUST operate under the same authorizations as the original session, and the TTLS server must be prepared to send the appropriate information back to the access point. Authorization information might include the maximum time for the session, the maximum allowed bandwidth, packet filter information, and the like. The TTLS server is responsible for modifying time values, such as Session-Timeout, appropriately for each resumed session.
TTLSサーバは、セッションを再開に使用するためにAAA / Hにより返される認証情報を保持しなければなりません。 Aは、セッションは、元のセッションと同じ権限の下で動作しなければなら再開、およびTTLSサーバは、アクセスポイントに戻って適切な情報を送信するために用意されなければなりません。認証情報は、セッションの最大時間、最大許容帯域幅、パケットフィルタ情報などが含まれる場合があります。 TTLSサーバは、セッションタイムアウトなどの時間値を変更する責任があり、適切にそれぞれのためのセッションを再開しました。
A TTLS server MUST NOT permit a session to be resumed if that session did not result in a successful authentication of the user during phase 2. The consequence of incorrectly implementing this aspect of session resumption would be catastrophic; any attacker could easily gain network access by first initiating a session that succeeds in the TLS handshake but fails during phase 2 authentication, and then resuming that session.
TTLSサーバは、そのセッションはフェーズ2誤っ壊滅的だろうセッションの再開のこの局面を実装した結果の間にユーザの認証が成功には至らなかった場合には再開されるようにセッションを許可してはなりません。どんな攻撃者は簡単に最初のTLSハンドシェイクに成功しますが、フェーズ2認証中に失敗したセッションを開始し、そのセッションを再開することにより、ネットワークアクセスを取得する可能性があります。
[Implementation note: Toolkits that implement TLS often cache resumable TLS sessions automatically. Implementers must take care to override such automatic behavior, and prevent sessions from being cached for possible resumption until the user has been positively authenticated during phase 2.]
[実装上の注意：TLSを実装するツールキットは、多くの場合、自動的に再開可能なTLSセッションをキャッシュします。実装者は、このような自動動作をオーバーライドするために世話をして、ユーザーが積極的にフェーズ2の間に認証されるまで、可能な再開のためにキャッシュされてからセッションを防ぐ必要があります]
Entering phase 2 is optional, and may be initiated by either client or TTLS server. If no further authentication or other information exchange is required upon completion of phase 1, it is possible to successfully complete the EAP-TTLS negotiation without ever entering phase 2 or tunneling any AVPs.
フェーズ2の入力はオプションであり、クライアントまたはTTLSサーバのいずれかによって開始することができます。それ以上の認証やその他の情報の交換はフェーズ1の完了時に必要とされていない場合、成功し、これまでフェーズ2またはトンネリング任意のAVPを入力せずにEAP-TTLS交渉を完了することが可能です。
Scenarios in which phase 2 is never entered include:
フェーズ2は、入力されたことはありませんされているシナリオは、次のとおりです。
- Successful session resumption, with no additional information exchange required,
- 成功したセッションの再開、追加の情報交換は必要ありませんし、
- Authentication of the client via client certificate during phase 1, with no additional authentication or information exchange required.
- 必要のない追加の認証や情報交換の位相1中にクライアント証明書を介してクライアントの認証、。
The client always has the first opportunity to initiate phase 2 upon completion of phase 1. If the client has no AVPs to send, it either sends an Acknowledgement (see Section 9.2.3) if the TTLS server sends the final phase 1 message, or simply does not piggyback a phase 2 message when it issues the final phase 1 message (as will occur during session resumption).
クライアントは常にクライアントが送るべきAVPを持っていない場合はTTLSサーバは、最終フェーズ1のメッセージを送信した場合、または、それは（9.2.3項を参照してください）確認を送信するいずれかのフェーズ1の完了時にフェーズ2を開始する最初の機会を持っています（セッションの再開時に発生するように）、それは最終フェーズ1メッセージを発行した場合、単純に位相2メッセージをピギーバックしません。
If the client does not initiate phase 2, the TTLS server, at its option, may either complete the EAP-TTLS negotiation without entering phase 2 or initiate phase 2 by tunneling AVPs to the client.
クライアントはフェーズ2、TTLSサーバを開始しない場合は、そのオプションで、フェーズ2を入力せずにEAP-TTLS交渉を完了することがありいずれか、またはクライアントにAVPをトンネリングすることによって、フェーズ2を開始します。
For example, suppose a successful session resumption occurs in phase 1. The following sequences are possible:
例えば、成功したセッションの再開がフェーズ1.以下の配列が可能であり、中に発生したとします。
- Neither the client nor TTLS server has additional information to exchange. The client completes phase 1 without piggybacking phase 2 AVPs, and the TTLS server indicates success to the encapsulating EAP protocol without entering phase 2.
- どちらもクライアントもTTLSサーバーは、Exchangeへの追加的な情報を持っていません。クライアントは、2つのAVP相をピギーバックすることなく、フェーズ1を完了し、TTLSサーバは、フェーズ2を入力せずにカプセル化するEAPプロトコルの成功を示します。
- The client has no additional information to exchange, but the TTLS server does. The client completes phase 1 without piggybacking phase 2 AVPs, but the TTLS server extends the EAP-TTLS negotiation into phase 2 by tunneling AVPs in its next EAP-TTLS message.
- クライアントは、交換する追加の情報を持っていませんが、TTLSサーバはありません。クライアントは、フェーズ2つのAVPをピギーバックすることなく、フェーズ1を完了したが、TTLSサーバは、その次のEAP-TTLSメッセージでトンネリングのAVPによって2相にEAP-TTLSネゴシエーションを延びています。
- The client has additional information to exchange, and piggybacks phase 2 AVPs with its final phase 1 message, thus extending the negotiation into phase 2.
- クライアントは、交換する追加の情報を有しており、従って相2にネゴシエーションを拡張、その最終フェーズ1メッセージと第2相AVPをピギーバック。
TLS version 1.0 [RFC2246], 1.1 [RFC4346], or any subsequent version MAY be used within EAP-TTLS. TLS provides for its own version negotiation mechanism.
TLSバージョン1.0 [RFC2246]、1.1 [RFC4346]、またはEAP-TTLS内で使用することができる任意の後続のバージョン。 TLSは、独自のバージョン交渉メカニズムを提供します。
For maximum interoperability, EAP-TTLS implementations SHOULD support TLS version 1.0.
最大の相互運用性のため、EAP-TTLSの実装は、TLSバージョン1.0をサポートする必要があります。
EAP-TTLSv0 utilizes a pseudo-random function (PRF) to generate keying material (Section 8) and to generate implicit challenge material for certain authentication methods (Section 11.1). The PRF used in these computations is the TLS PRF used in the TLS handshake negotiation that initiates the EAP-TTLS exchange.
EAP-TTLSv0は、キーイング材料（セクション8）を生成すると、特定の認証方法（セクション11.1）のための暗黙のチャレンジ物質を生成する擬似ランダム関数（PRF）を利用します。これらの計算に使用されるPRFはEAP-TTLSの交換を開始TLSハンドシェイクのネゴシエーションで使用されるTLS PRFです。
TLS versions 1.0 [RFC2246] and 1.1 [RFC4346] define the same PRF function, and any EAP-TTLSv0 implementation based on these versions of TLS must use the PRF defined therein. It is expected that future versions of or extensions to the TLS protocol will permit alternative PRF functions to be negotiated. If an alternative PRF function is specified for the underlying TLS version or has been negotiated during the TLS handshake negotiation, then that alternative PRF function must be used in EAP-TTLSv0 computations instead of the TLS 1.0/1.1 PRF.
TLSのこれらのバージョンに基づいて、TLSバージョン1.0 [RFC2246]と1.1 [RFC4346]は同じPRF関数を定義し、任意のEAP-TTLSv0実装は、内部に画定されたPRFを使用しなければなりません。 TLSプロトコルへの将来のバージョンや拡張が交渉される代替PRF機能を可能にすることが期待されます。代替PRF関数は、基礎となるTLSバージョンに指定されるか、またはTLSハンドシェイクネゴシエーション中にネゴシエートされた場合、その代替PRF関数ではなくTLS 1.0 / 1.1 PRFのEAP-TTLSv0計算に使用されなければなりません。
The TLS PRF function used in this specification is denoted as follows:
次のように本明細書中で使用されるTLS PRF機能が表記されています。
PRF-nn(secret, label, seed)
PRF-NN（秘密、ラベル、種子）
where:
どこ：
nn is the number of generated octets
nnは生成されたオクテットの数です
secret is a secret key
秘密は秘密鍵であります
label is a string (without null-terminator)
ラベルは、（NULL終止符なし）の文字列であります
seed is a binary sequence.
種子は、バイナリシーケンスです。
The TLS 1.0/1.1 PRF has invariant output regardless of how many octets are generated. However, it is possible that alternative PRF functions will include the size of the output sequence as input to the PRF function; this means generating 32 octets and generating 64 octets from the same input parameters will no longer result in the first 32 octets being identical. For this reason, the PRF is always specified with an "nn", indicating the number of generated octets.
TLS 1.0 / 1.1 PRFは関係なく、どのように生成されるか、多くのオクテットの不変の出力を持っています。しかし、代替のPRF関数はPRF関数への入力として出力シーケンスのサイズを含むことが可能です。これは、32個のオクテットを生成し、同じ入力パラメーターからの64個のオクテットは、もはや最初の32個のオクテットが同一であるもたらすません生成手段。このため、PRFは常に生成されたオクテットの数を示す、「NN」と指定されています。
Upon successful conclusion of an EAP-TTLS negotiation, 128 octets of keying material are generated and exported for use in securing the data connection between client and access point. The first 64 octets of the keying material constitute the MSK, the second 64 octets constitute the EMSK.
クライアントとアクセスポイント間のデータ接続を確保するには、EAP-TTLS交渉の成功裡の妥結すると、鍵材料の128個のオクテットが生成され、使用のために輸出しました。鍵材料の最初の64個のオクテットは、MSKを構成し、第64オクテットは、EMSKを構成しています。
The keying material is generated using the TLS PRF function [RFC4346], with inputs consisting of the TLS master secret, the ASCII-encoded constant string "ttls keying material", the TLS client random, and the TLS server random. The constant string is not null-terminated.
鍵材料は、ASCII符号化された文字列定数ランダム、TLSクライアント「TTLSは材料を合わせる」TLSマスターシークレットからなる入力を、TLS PRF関数[RFC4346]を用いて、およびTLSサーバランダム生成されます。定数文字列は、NULLで終了ではありません。
Keying Material = PRF-128(SecurityParameters.master_secret, "ttls keying material", SecurityParameters.client_random + SecurityParameters.server_random)
キーイングマテリアル= PRF-128（SecurityParameters.client_random + SecurityParameters.server_random SecurityParameters.master_secret、 "鍵材料TTLS"）
MSK = Keying Material [0..63]
MSK =鍵材料[0 63]
EMSK = Keying Material [64..127]
EMSK =鍵材料[64..127]
Note that the order of client_random and server_random for EAP-TTLS is reversed from that of the TLS protocol [RFC4346]. This ordering follows the key derivation method of EAP-TLS [RFC5216]. Altering the order of randoms avoids namespace collisions between constant strings defined for EAP-TTLS and those defined for the TLS protocol.
EAP-TTLS用client_randomとserver_randomの順序は、TLSプロトコル[RFC4346]とは逆になることに留意されたいです。この順序は、EAP-TLS [RFC5216]の鍵導出方法に従います。 randomsの順序を変更すると、EAP-TTLSおよびTLSプロトコルに対して定義されたものに対して定義された定数文字列の間の名前空間の衝突を回避します。
The TTLS server distributes this keying material to the access point via the AAA carrier protocol. When RADIUS is the AAA carrier protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes [RFC2548] may be used to distribute the first 32 octets and second 32 octets of the MSK, respectively.
TTLSサーバは、AAAキャリヤープロトコルを介してアクセスポイントにこの鍵材料を配布します。 RADIUSは、AAAキャリヤープロトコルである場合、MPPE-Recv関数キーとMPPE-SENDキーは、[RFC2548]を属性それぞれ、MSKの最初の32個のオクテット及び第32オクテットを配布するために使用することができます。
The EAP-TTLS packet format is shown below. The fields are transmitted left to right.
EAP-TTLSパケットフォーマットは以下に示されています。フィールドは左から右へ送信されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code 1 for request, 2 for response.
要求、応答のための2のコード1。
Identifier The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed for each request packet and MUST be echoed in each response packet.
識別子ザ・識別子フィールドは、リクエストとレスポンスのマッチングで1つのオクテットとエイズです。識別子フィールドは、各要求パケットのために変更する必要があり、各応答パケットにエコーされなければなりません。
Length The Length field is two octets and indicates the number of octets in the entire EAP packet, from the Code field through the Data field.
長さ長さフィールドは2つのオクテットで、Codeフィールドからのデータフィールドを介して、全体のEAPパケットのオクテットの数を示します。
Type 21 (EAP-TTLS)
タイプ21（EAP-TTLS）
Flags
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| L | M | S | R | R | V |
+---+---+---+---+---+---+---+---+
L = Length included M = More fragments S = Start R = Reserved V = Version (000 for EAP-TTLSv0)
L =長さMは、複数の断片S =スタートR =予約V =バージョン（EAP-TTLSv0用000）=付属しました
The L bit is set to indicate the presence of the four-octet TLS Message Length field. The M bit indicates that more fragments are to come. The S bit indicates a Start message. The V field is set to the version of EAP-TTLS, and is set to 000 for EAP-TTLSv0.
Lビットは4オクテットTLSメッセージ長フィールドの存在を示すために設定されています。 Mビットは、複数の断片が来ていることを示しています。 Sビットは、開始メッセージを示します。 VフィールドはEAP-TTLSのバージョンに設定され、EAP-TTLSv0ために000に設定されています。
Message Length The Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the raw data message sequence prior to fragmentation.
メッセージ長は、メッセージ長フィールドは、4つのオクテットであり、Lビットが設定されている場合にのみ存在します。このフィールドは、フラグメンテーションの前に生データメッセージシーケンスの全体の長さを提供します。
Data For all packets other than a Start packet, the Data field consists of the raw TLS message sequence or fragment thereof. For a Start packet, the Data field may optionally contain an AVP sequence.
スタートパケット以外のすべてのパケットのためのデータ、データフィールドは、生のTLSメッセージ配列またはそのフラグメントから成ります。 Startパケットの場合、データフィールドは、必要に応じてAVP配列を含んでいてもよいです。
The S bit MUST be set on the first packet sent by the server to initiate the EAP-TTLS protocol. It MUST NOT be set on any other packet.
Sビットは、EAP-TTLSプロトコルを開始するためにサーバーによって送信された最初のパケットに設定しなければなりません。これは、任意の他のパケットに設定してはいけません。
This packet MAY contain additional information in the form of AVPs, which may provide useful hints to the client; for example, the server identity may be useful to the client to allow it to pick the correct TLS session ID for session resumption. Each AVP must begin on a four-octet boundary relative to the first AVP in the sequence. If an AVP is not a multiple of four octets, it must be padded with zeros to the next four-octet boundary.
このパケットは、クライアントに有益なヒントを提供することができるのAVPの形で追加の情報を含んでいてもよいです。例えば、サーバーIDは、セッション再開のための正しいTLSセッションIDを選択できるようにするために、クライアントに有用である可能性があります。各AVPは、シーケンスの最初のAVPに4オクテット境界相対的に開始しなければなりません。 AVPは4つのオクテットの倍数でない場合は、次の4オクテット境界にゼロで埋めなければなりません。
The version of EAP-TTLS is negotiated in the first exchange between server and client. The server sets the highest version number of EAP-TTLS that it supports in the V field of its Start message (in the case of EAP-TTLSv0, this is 0). In its first EAP message in response, the client sets the V field to the highest version number that it supports that is no higher than the version number offered by the server. If the client version is not acceptable to the server, it sends an EAP-Failure to terminate the EAP session. Otherwise, the version sent by the client is the version of EAP-TTLS that MUST be used, and both server and client MUST set the V field to that version number in all subsequent EAP messages.
EAP-TTLSのバージョンでは、サーバとクライアント間の最初の交換で交渉されています。サーバーは、そのStartメッセージ（EAP-TTLSv0の場合には、これは0である）のVフィールドにサポートしているEAP-TTLSの最も高いバージョン番号を設定します。応答では、その最初のEAPメッセージでは、クライアントは、それはそれは、サーバによって提供されるバージョン番号より高くないサポートされていることを最大のバージョン番号にVフィールドを設定します。クライアントのバージョンがサーバーに受け入れられない場合は、EAPセッションを終了するEAP-失敗を送信します。それ以外の場合は、クライアントから送信されたバージョンを使用しなければなりません、EAP-TTLSのバージョンで、サーバーとクライアントの両方が、後続のすべてのEAPメッセージでそのバージョン番号にVフィールドを設定しなければなりません。
Each EAP-TTLS message contains a single leg of a half-duplex conversation. The EAP carrier protocol (e.g., PPP, EAPOL, RADIUS) may impose constraints on the length of an EAP message. Therefore it may be necessary to fragment an EAP-TTLS message across multiple EAP messages.
各EAP-TTLSのメッセージは、半二重会話の単一の脚が含まれています。 EAPキャリアプロトコル（例えば、PPP、EAPOL、RADIUS）はEAPメッセージの長さに制約を課すことができます。したがって、複数のEAPメッセージを横切ってEAP-TTLSメッセージを断片化する必要があるかもしれません。
Each fragment except for the last MUST have the M bit set, to indicate that more data is to follow; the final fragment MUST NOT have the M bit set.
最後を除く各フラグメントは、より多くのデータが従うことがあることを示すために、Mビットセットを有していなければなりません。最後のフラグメントは、Mビットのセットを持ってはいけません。
If there are multiple fragments, the first fragment MUST have the L bit set and include the length of the entire raw message prior to fragmentation. Fragments other than the first MUST NOT have the L bit set. Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant).
複数のフラグメントが存在する場合、最初のフラグメントは、Lビットの組を有し、フラグメンテーションの前に全体の生メッセージの長さを含まなければなりません。最初以外のフラグメントは、Lビットセットを持ってはいけません。 （この情報は冗長であるが）断片化されていないメッセージは、Lビットセットを有し、メッセージの長さを含むことができます。
Upon receipt of a packet with the M bit set, the receiver MUST transmit an Acknowledgement packet. The receiver is responsible for reassembly of fragmented packets.
Mビットが設定されたパケットを受信すると、受信機は、肯定応答パケットを送信しなければなりません。受信機は、断片化されたパケットの再構築を担当しています。
An Acknowledgement packet is an EAP-TTLS packet with no additional data beyond the Flags octet, and with the L, M, and S bits of the Flags octet set to 0. (Note, however, that the V field MUST still be set to the appropriate version number.)
肯定応答パケットはフラグオクテットを超えない追加のデータとEAP-TTLSのパケットであり、Lと、M、および0に設定されたフラグのオクテットのSビット（ただし、Vフィールドは依然としてに設定しなければならないこと適切なバージョン番号。）
An Acknowledgement packet is sent for the following purposes:
謝辞パケットは、以下の目的のために送信されます。
- A Fragment Acknowledgement is sent in response to an EAP packet with the M bit set.
- フラグメント肯定応答はMビットが設定されたEAPパケットに応答して送信されます。
- When the final EAP packet of the EAP-TTLS negotiation is sent by the TTLS server, the client must respond with an Acknowledgement packet, to allow the TTLS server to proceed with the EAP protocol upon completion of EAP-TTLS (typically by sending or causing to be sent a final EAP-Success or EAP-Failure to the client).
- EAP-TTLS交渉の最終EAPパケットがTTLSサーバによって送信されると、クライアントはTTLSサーバは、一般的に送信することにより、EAP-TTLS（終了時のEAPプロトコルを続行できるようにするために、確認応答パケットで応答しなければなりませんか、 ）クライアントに、最終的なEAP-成功またはEAP-失敗を送信する原因となります。
Subsequent to the TLS handshake, information may be tunneled between client and TTLS server through the use of attribute-value pairs (AVPs) encrypted within the TLS record layer.
TLSハンドシェイクの後に、情報は、TLSレコード層内の暗号化された属性値ペア（AVPの）の使用を介してクライアントとTTLSサーバとの間でトンネリングすることができます。
The AVP format chosen for EAP-TTLS is compatible with the Diameter AVP format. This does not represent a requirement that Diameter be supported by any of the devices or servers participating in an EAP-TTLS negotiation. Use of this format is merely a convenience. Diameter is a superset of RADIUS and includes the RADIUS attribute namespace by definition, though it does not limit the size of an AVP as does RADIUS; RADIUS, in turn, is a widely deployed AAA protocol and attribute definitions exist for all commonly used password authentication protocols, including EAP.
EAP-TTLSのために選択されたAVPのフォーマットは、Diameter AVPフォーマットと互換性があります。これは、直径がEAP-TTLS交渉に参加するデバイスまたはサーバーのいずれかによってサポートされる要件を表すものではありません。このフォーマットの使用は、単に便利です。直径は、RADIUSのスーパーセットであり、それはRADIUSと同様にAVPのサイズを限定するものではないが、定義によってRADIUS属性の名前空間を含みます。 RADIUSは、順番に、広く展開されているAAAプロトコルと属性の定義は、EAPを含むすべての一般的に使用されるパスワード認証プロトコルのために存在しています。
Thus, Diameter is not considered normative except as specified in this document. Specifically, the representation of the Data field of an AVP in EAP-TTLS is identical to that of Diameter.
このように、直径はこの文書で指定された場合を除き、規範的とはみなされません。具体的には、EAP-TTLSでAVPのデータフィールドの表現は、直径のものと同一です。
Use of the RADIUS/Diameter namespace allows a TTLS server to easily translate between AVPs it uses to communicate to clients and the protocol requirements of AAA servers that are widely deployed. Plus, it provides a well-understood mechanism to allow vendors to extend that namespace for their particular requirements.
RADIUS /直径の名前空間を使用すると、TTLSサーバは簡単にそれがクライアントと広く展開されているAAAサーバのプロトコル要件に通信するために使用するのAVPの間で変換することができます。プラス、それはベンダーが特定の要件のためにその名前空間を拡張することを可能にする十分に理解のメカニズムを提供します。
It is expected that the AVP Codes used in EAP-TTLS will carry roughly the same meaning in EAP-TTLS as they do in Diameter and, by extension, RADIUS. However, although EAP-TTLS uses the same AVP Codes and syntax as Diameter, the semantics may differ, and most Diameter AVPs do not have any well-defined semantics in EAP-TTLS. A separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be used within EAP-TTLS and their semantics in this context (see Section 16 for details). A TTLS server copying AVPs between an EAP-TTLS exchange and a Diameter or RADIUS exchange with a backend MUST NOT make assumptions about AVPs whose usage in either EAP-TTLS or the backend protocol it does not understand. Therefore, a TTLS server MUST NOT copy an AVP between an EAP-TTLS exchange and a Diameter or RADIUS exchange unless the semantics of the AVP are understood and defined in both contexts.
EAP-TTLSで使用されるAVPコードは、彼らが直径でそうであるようにEAP-TTLSでほぼ同じ意味を運ぶと、拡張により、RADIUSことが期待されます。 EAP-TTLSは、直径と同じAVPコードと構文を使用していますが、しかし、セマンティクスが異なる可能性があり、最も直径のAVPは、EAP-TTLSのいずれかの明確に定義された意味を持っていません。別の「EAP-TTLS AVPの使用法」のレジストリは、（詳細はセクション16を参照）、この文脈でEAP-TTLSおよびその意味の範囲内で使用することができAVPを示しています。バックエンドでのEAP-TTLS交換及び直径またはRADIUS交換の間TTLSサーバーコピーのAVPは、使用EAP-TTLSまたはバックエンドプロトコルのいずれかで、それは理解していないのAVPについての仮定をしてはなりません。 AVPのセマンティクスを理解し、両方のコンテキストで定義されていない限りそのため、TTLSサーバはEAP-TTLS交換及び直径またはRADIUS交換の間AVPをコピーしてはいけません。
The format of an AVP is shown below. All items are in network, or big-endian, order; that is, they have the most significant octet first.
AVPの形式を以下に示します。すべての項目は、ネットワーク、またはビッグエンディアン、順序です。つまり、彼らは最初の最も重要なオクテットを持っています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code The AVP Code is four octets and, combined with the Vendor-ID field if present, identifies the attribute uniquely. The first 256 AVP numbers represent attributes defined in RADIUS [RFC2865]. AVP numbers 256 and above are defined in Diameter [RFC3588].
AVPコードザAVPコードが存在する場合ベンダーIDフィールドと合わせ4つのオクテットと、であり、一意の属性を識別する。第256 AVP番号がRADIUS [RFC2865]で定義された属性を表します。 AVP番号256及び上記直径[RFC3588]で定義されています。
AVP Flags
AVPフラグ
The AVP Flags field is one octet and provides the receiver with information necessary to interpret the AVP.
AVPフラグフィールドは1つのオクテットで、AVPを解釈するために必要な情報を持つ受信機を提供します。
The 'V' (Vendor-Specific) bit indicates whether the optional Vendor-ID field is present. When set to 1, the Vendor-ID field is present and the AVP Code is interpreted according to the namespace defined by the vendor indicated in the Vendor-ID field.
「V」（ベンダー固有の）ビットは、オプションのベンダーIDフィールドが存在するかどうかを示します。 1に設定すると、ベンダーIDフィールドが存在し、AVPコードは、ベンダーIDフィールドに示さベンダによって定義された名前空間に従って解釈されます。
The 'M' (Mandatory) bit indicates whether support of the AVP is required. If this bit is set to 0, this indicates that the AVP may be safely ignored if the receiving party does not understand or support it. If set to 1, this indicates that the receiving party MUST fail the negotiation if it does not understand the AVP; for a TTLS server, this would imply returning EAP-Failure, for a client, this would imply abandoning the negotiation.
「M」（必須）ビットは、AVPのサポートが必要であるかどうかを示します。このビットが0に設定されている場合、これは、受信者がそれを理解したり、サポートされていない場合AVPは無視できることを示しています。 1に設定した場合、これはAVPを理解していない場合、受信側は交渉に失敗しなければなりませんことを示しています。 TTLSサーバのために、これはクライアントのために、これは交渉を放棄暗示する、EAP-失敗を返す暗示します。
The 'r' (reserved) bits are unused and MUST be set to 0 by the sender and MUST be ignored by the receiver.
「R」（予約）ビットは未使用であり、送信側で0に設定しなければならなくて、受信機で無視しなければなりません。
AVP Length
AVPの長さ
The AVP Length field is three octets and indicates the length of this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID (if present), and Data.
AVP長フィールドは3つのオクテットであり、AVPコードを含むこのAVP、AVP長、AVPフラグ、ベンダーID（存在する場合）、およびデータの長さを示します。
Vendor-ID
ベンダーID
The Vendor-ID field is present if the V bit is set in the AVP Flags field. It is four octets and contains the vendor's IANA-assigned "SMI Network Management Private Enterprise Codes" [RFC3232] value. Vendors defining their own AVPs must maintain a consistent namespace for use of those AVPs within RADIUS, Diameter, and EAP-TTLS.
VビットがAVPフラグフィールドに設定されている場合、ベンダーIDフィールドが存在します。それは4つのオクテットで、ベンダーのIANAによって割り当てられた「SMIネットワークマネージメント私企業コード」[RFC3232]の値が含まれています。自分のAVPを定義するベンダーはRADIUS、直径、およびEAP-TTLS内のもののAVPを使用するための一貫した名前空間を維持する必要があります。
A Vendor-ID value of zero is equivalent to absence of the Vendor-ID field altogether.
ゼロのベンダーID値は、完全ベンダーIDフィールドが存在しないことと等価です。
Note that the M bit provides a means for extending the functionality of EAP-TTLS while preserving backward compatibility when desired. By setting the M bit of the appropriate AVP(s) to 0 or 1, the party initiating the function indicates that support of the function by the other party is either optional or required.
Mビットは、所望の場合に下位互換性を維持しながら、EAP-TTLSの機能を拡張するための手段を提供することに留意されたいです。 0または1に適切なAVP（複数可）のMビットを設定することにより、機能を開始する当事者が他の当事者による機能のサポートはオプションまたは必須のいずれかであることを示しています。
Data encapsulated within the TLS record layer must consist entirely of a sequence of zero or more AVPs. Each AVP must begin on a four-octet boundary relative to the first AVP in the sequence. If an AVP is not a multiple of four octets, it must be padded with zeros to the next four-octet boundary.
TLSレコード層内にカプセル化されたデータは、完全にゼロ以上のAVPの配列から構成されなければなりません。各AVPは、シーケンスの最初のAVPに4オクテット境界相対的に開始しなければなりません。 AVPは4つのオクテットの倍数でない場合は、次の4オクテット境界にゼロで埋めなければなりません。
Note that the AVP Length does not include the padding.
AVPの長さは、パディングが含まれていないことに注意してください。
For maximum compatibility with AAA servers, the following guidelines for AVP usage are suggested:
AAAサーバとの最大の互換性のために、AVPの使用については、次のガイドラインが推奨されています。
- Non-vendor-specific AVPs intended for use with AAA servers should be selected from the set of attributes defined for RADIUS; that is, attributes with codes less than 256. This provides compatibility with both RADIUS and Diameter.
- AAAサーバとの使用を意図非ベンダー固有のAVPはRADIUSのために定義された属性のセットから選択されるべきです。すなわち、これは、RADIUSおよび直径の両方との互換性を提供して256未満のコードで属性。
- Vendor-specific AVPs intended for use with AAA servers should be defined in terms of RADIUS. Vendor-specific RADIUS attributes translate to Diameter (and, hence, to EAP-TTLS) automatically; the reverse is not true. RADIUS vendor-specific attributes use RADIUS attribute 26 and include Vendor-ID, vendor-specific attribute code, and length; see [RFC2865] for details.
- AAAサーバでの使用を意図ベンダー固有のAVPはRADIUSの用語で定義する必要があります。ベンダー固有のRADIUS属性が自動的に（EAP-TTLSに、したがって、と）の直径に変換します。逆は真ではありません。 RADIUSベンダー固有の属性26属性とベンダーID、ベンダー固有の属性コード、および長さを含むRADIUSを使用します。詳細については、[RFC2865]を参照してください。
EAP-TTLS permits user authentication information to be tunneled within the TLS record layer between client and TTLS server, ensuring the security of the authentication information against active and passive attack between the client and TTLS server. The TTLS server decrypts and forwards this information to the AAA/H over the AAA carrier protocol.
EAP-TTLSは、ユーザーの認証情報がクライアントとTTLSサーバの間のアクティブおよびパッシブ攻撃に対する認証情報のセキュリティを確保し、クライアントとTTLSサーバ間のTLSレコード層内でトンネリングすることを可能にします。 TTLSサーバは、AAAキャリヤプロトコルを介してAAA / Hにこの情報を復号化し、転送します。
Any type of password or other authentication may be tunneled. Also, multiple tunneled authentications may be performed. Normally, tunneled authentication is used when the client has not been issued a certificate, and the TLS handshake provides only one-way authentication of the TTLS server to the client; however, in certain cases it may be desired to perform certificate authentication of the client during the TLS handshake as well as tunneled user authentication afterwards.
パスワードまたは他の認証の任意のタイプは、トンネルすることができます。また、複数のトンネリングされた認証が行われてもよいです。通常、トンネル化認証は、クライアントが証明書を発行されていないときに使用され、TLSハンドシェイクは、クライアントにTTLSサーバの一方向のみの認証を提供しています。しかし、特定の場合には、後でTLSハンドシェイク中にクライアントの証明書認証だけでなく、トンネリングされたユーザ認証を行うことが望まれます。
Certain authentication protocols that use a challenge/response mechanism rely on challenge material that is not generated by the authentication server, and therefore the material requires special handling.
チャレンジ/レスポンスメカニズムを使用して、特定の認証プロトコルは、認証サーバによって生成されていないチャレンジ材料に依存しているので、材料は特別な取り扱いが必要です。
In CHAP, MS-CHAP, and MS-CHAP-V2, for example, the access point issues a challenge to the client, the client then hashes the challenge with the password and forwards the response to the access point. The access point then forwards both challenge and response to a AAA server. But because the AAA server did not itself generate the challenge, such protocols are susceptible to replay attack.
例えば、アクセスポイントはクライアントにチャレンジを発行CHAP、MS-CHAP、およびMS-CHAP-V2では、クライアントは、パスワードを使用して挑戦をハッシュし、アクセスポイントへの応答を転送します。アクセスポイントは、次に挑戦とAAAサーバへの応答の両方を転送します。 AAAサーバは、自身がチャレンジを生成していなかったので、しかし、そのようなプロトコルは攻撃を再生するために影響を受けやすいです。
If the client were able to create both challenge and response, anyone able to observe a CHAP or MS-CHAP exchange could pose as that user, even using EAP-TTLS.
クライアントは、チャレンジとレスポンスの両方を作成することができました場合は、CHAPまたはMS-CHAPの交換を観察することができ、誰でもEAP-TTLSを使用して、そのユーザーのふりができます。
To make these protocols secure under EAP-TTLS, it is necessary to provide a mechanism to produce a challenge that the client cannot control or predict. This is accomplished using the same technique described above for generating data connection keying material.
EAP-TTLSの下でこれらのプロトコルを安全にするためには、クライアントが制御または予測することはできない挑戦を生成するためのメカニズムを提供することが必要です。これは、材料を合わせるデータ接続を生成するための上記と同じ技術を使用して達成されます。
When a challenge-based authentication mechanism is used, both client and TTLS server use the pseudo-random function to generate as many octets as are required for the challenge, using the constant string "ttls challenge", based on the master secret and random values established during the handshake:
挑戦ベースの認証メカニズムを使用する場合の課題のために必要とされるように、両方のクライアントとTTLSサーバは、マスターシークレットと、ランダムな値に基づいて、定数文字列「TTLSの挑戦」を使用して、できるだけ多くのオクテットを生成する擬似ランダム関数を使用しますハンドシェイク中に確立：
EAP-TTLS_challenge = PRF-nn(SecurityParameters.master_secret, "ttls challenge", SecurityParameters.client_random + SecurityParameters.server_random);
EAP-TTLS_challenge = PRF-NN（SecurityParameters.master_secret、 "TTLSチャレンジ"、SecurityParameters.client_random + SecurityParameters.server_random）。
The number of octets to be generated (nn) depends on the authentication method, and is indicated below for each authentication method requiring implicit challenge generation.
生成されるオクテットの数（NN）は、認証方式に依存し、暗黙のチャレンジの生成を必要とする各認証方法については、以下に示されます。
This section describes the methods for tunneling specific authentication protocols within EAP-TTLS.
このセクションでは、EAP-TTLS内の特定の認証プロトコルをトンネリングする方法について説明します。
For the purpose of explication, it is assumed that the TTLS server and AAA/H use RADIUS as a AAA carrier protocol between them. However, this is not a requirement, and any AAA protocol capable of carrying the required information may be used.
解説の目的のために、TTLSサーバとAAA / Hは、それらの間のAAAキャリアプロトコルとしてRADIUSを使用することを想定しています。しかし、これは必要条件ではなく、必要な情報を運ぶことができる任意のAAAプロトコルを使用することができます。
The client determines which authentication protocol will be used via the initial AVPs it sends to the server, as described in the following sections.
クライアントは、次のセクションで説明するように、それはサーバに送信する初期のAVPを経由して使用される認証プロトコルを決定します。
Note that certain of the authentication protocols described below utilize vendor-specific AVPs originally defined for RADIUS. RADIUS and Diameter differ in the encoding of vendor-specific AVPs: RADIUS uses the vendor-specific attribute (code 26), while Diameter uses setting of the V bit to indicate the presence of Vendor-ID. The RADIUS form of the vendor-specific attribute is always convertible to a Diameter AVP with V bit set. All vendor-specific AVPs described below MUST be encoded using the preferred Diameter V bit mechanism; that is, the AVP Code of 26 MUST NOT be used to encode vendor-specific AVPs within EAP-TTLS.
以下に説明する認証プロトコルの特定が元々RADIUS用に定義されたベンダー固有のAVPを利用することに留意されたいです。 RADIUSおよび直径は、ベンダー固有のAVPの符号が異なる：直径がベンダーIDの存在を示すために、Vビットの設定を使用しながら、RADIUSは、ベンダー固有の属性（コード26）を使用します。ベンダー固有の属性のRADIUS形態は常にVビットが設定された直径AVPに変換可能です。以下に記載されているすべてのベンダー固有のAVPは、好ましい直径Vビット機構を使用して符号化されなければなりません。つまり、26のAVPコードは、EAP-TTLS内のベンダー固有AVPを符号化するために使用してはいけません。
When EAP is the tunneled authentication protocol, each tunneled EAP packet between the client and TTLS server is encapsulated in an EAP-Message AVP, prior to tunneling via the TLS record layer.
EAPは、トンネリング認証プロトコルである場合、クライアントとTTLSサーバの間の各トンネリングEAPパケットは、TLSレコード層を介してトンネリングする前に、EAP-メッセージのAVPにカプセル化されます。
Note that because Diameter AVPs are not limited to 253 octets of data, as are RADIUS attributes, the RADIUS mechanism of concatenating multiple EAP-Message attributes to represent a longer-than-253-octet EAP packet is not appropriate in EAP-TTLS. Thus, a tunneled EAP packet within a single EAP-TTLS message MUST be contained in a single EAP-Message AVP.
RADIUSは、複数のEAP-メッセージを連結するRADIUS機構が長いより-253オクテットEAPパケットをEAP-TTLSに適切でない表現する属性、属性がそうであるように、直径のAVPは、データの253個のオクテットに限定されるものではないのでことに留意されたいです。したがって、単一EAP-TTLSメッセージ内トンネリングEAPパケットは、単一のEAP-メッセージのAVPに含まれなければなりません。
The client initiates EAP by tunneling EAP-Response/Identity to the TTLS server. Depending on the requirements specified for the inner method, the client MAY now place the actual username in this packet; the privacy of the user's identity is now guaranteed by the TLS encryption. This username is typically a Network Access Identifier (NAI) [RFC4282]; that is, it is typically in the following format:
クライアントはTTLSサーバにEAP応答/アイデンティティをトンネリングすることによってEAPを開始します。内側のメソッドに対して指定要件に応じて、クライアントは、このパケットの実際のユーザ名を入れることができます。ユーザのアイデンティティのプライバシーは今TLS暗号化によって保証されています。このユーザ名は、典型的には、ネットワークアクセス識別子（NAI）[RFC4282]です。つまり、それは次の形式で一般的です。
username@realm
ユーザ名@レルム
The @realm portion is optional, and is used to allow the TTLS server to forward the EAP packet to the appropriate AAA/H.
@realm部分はオプションであり、TTLSサーバは適切なAAA / HにEAPパケットを転送できるようにするために使用されます。
Note that the client has two opportunities to specify realms. The first, in the initial, untunneled EAP-Response/Identity packet prior to starting EAP-TTLS, indicates the realm of the TTLS server. The second, occurring as part of the EAP exchange within the EAP-TTLS tunnel, indicates the realm of the client's home network. Thus, the access point need only know how to route to the realm of the TTLS server; the TTLS server is assumed to know how to route to the client's home realm. This serial routing architecture is anticipated to be useful in roaming environments, allowing access points or AAA proxies behind access points to be configured only with a small number of realms. (Refer to Section 7.3 for additional information distinguishing the untunneled and tunneled versions of the EAP-Response/Identity packets.)
クライアントがレルムを指定するには、2つの機会を持っていることに注意してください。最初は、EAP-TTLSを開始する前に初期、untunneled EAP応答/アイデンティティパケットに、TTLSサーバの領域を示しています。第二は、EAP-TTLSトンネル内のEAP交換の一部として発生し、クライアントのホームネットワークの領域を示しています。このように、アクセスポイントはどのようにTTLSサーバの領域への経路に知っている必要があります。 TTLSサーバは、どのようにクライアントのホーム領域への経路に知っていると想定されます。このシリアルルーティングアーキテクチャのみレルムの少数で構成するアクセスポイントの背後にあるアクセスポイントまたはAAAプロキシを可能にする環境をローミングするのに有用であることが予想されます。 （EAP応答/アイデンティティパケットのuntunneledとトンネル化バージョンの区別の追加情報については、7.3節を参照してください。）
Note that TTLS processing of the initial identity exchange is different from plain EAP. The state machine of TTLS is different. However, it is expected that the server side is capable of dealing with client initiation, because even normal EAP protocol runs are client-initiated over AAA. On the client side, there are various implementation techniques to deal with the differences. Even a TTLS-unaware EAP protocol run could be used, if TTLS makes it appear as if an EAP-Request/Identity message was actually received. This is similar to what authenticators do when operating between a client and a AAA server.
初期ID交換のTTLS処理が平野EAPとは異なることに注意してください。 TTLSのステートマシンは異なっています。しかし、それも、通常のEAPプロトコルを実行すると、クライアントが開始したAAAの上にあるため、サーバ側は、クライアントの開始を扱うことが可能であることが予想されます。クライアント側では、相違点に対処するための様々な実装技術があります。 TTLSはEAP-Request / Identityメッセージが実際に受信されたかのように見せる場合でも、TTLS非対応EAPプロトコルの実行には、使用することができます。これは、クライアントとAAAサーバの間で動作しているときのオーセンティケータが何に似ています。
Upon receipt of the tunneled EAP-Response/Identity, the TTLS server forwards it to the AAA/H in a RADIUS Access-Request.
トンネリングされたEAP応答/アイデンティティを受信すると、RADIUSアクセス要求におけるAAA / HにTTLSサーバに転送して。
The AAA/H may immediately respond with an Access-Reject; in which case, the TTLS server completes the negotiation by sending an EAP-Failure to the access point. This could occur if the AAA/H does not recognize the user's identity, or if it does not support EAP.
AAA / Hは直ちに拒否アクセスで応答することができます。その場合には、TTLSサーバは、アクセスポイントにEAP-失敗を送信することによって、ネゴシエーションを完了します。 AAA / Hは、ユーザーのIDを認識しない場合、またはそれがEAPをサポートしていない場合、これが発生する可能性があります。
If the AAA/H does recognize the user's identity and does support EAP, it responds with an Access-Challenge containing an EAP-Request, with the Type and Type-Data fields set according to the EAP protocol with which the AAA/H wishes to authenticate the client; for example MD5- Challenge, One-Time Password (OTP), or Generic Token Card.
AAA / Hは、ユーザーのIDを認識しないとEAPをサポートしている場合、それはタイプで、EAP-Requestを含むアクセスチャレンジで応答し、タイプ - データフィールドは、AAA / HがしたいれるEAPプロトコルに従って設定しますクライアントを認証。たとえばMD5-チャレンジ、ワンタイムパスワード（OTP）、または一般的なトークンカードについて。
The EAP authentication between client and AAA/H proceeds normally, as described in [RFC3748], with the TTLS server acting as a passthrough device. Each EAP-Request sent by the AAA/H in an Access-Challenge is tunneled by the TTLS server to the client, and each EAP-Response tunneled by the client is decrypted and forwarded by the TTLS server to the AAA/H in an Access-Request.
TTLSサーバは、パススルーデバイスとして動作して、[RFC3748]に記載されているように、クライアントとAAA / Hとの間のEAP認証が正常に進行します。アクセスチャレンジにAAA / Hによって送られた各EAP-RequestがクライアントにTTLSサーバによってトンネリングされ、そしてクライアントでのトンネリング各EAP-応答が解読され、AccessでAAA / HにTTLSサーバによって転送されます-要求。
This process continues until the AAA/H issues an Access-Accept or Access-Reject.
AAA / Hが発行されるまで、このプロセスは継続アクセスを、受け入れるか、またはアクセスが拒否。
Note that EAP-TTLS does not impose special rules on EAP Notification packets; such packets MAY be used within a tunneled EAP exchange according to the rules specified in [RFC3748].
EAP-TTLSはEAP通知パケットに特別なルールを課していないことに注意してください。そのようなパケットは、[RFC3748]で指定された規則に従ってトンネリングEAP交換内で使用することができます。
EAP-TTLS provides a reliable transport for the tunneled EAP exchange. However, [RFC3748] assumes an unreliable transport for EAP messages (see Section 3.1), and provides for silent discard of any EAP packet that violates the protocol or fails a method-specific integrity check, on the assumption that such a packet is likely a counterfeit sent by an attacker. But since the tunnel provides a reliable transport for the inner EAP authentication, errors that would result in silent discard according to [RFC3748] presumably represent implementation errors when they occur within the tunnel, and SHOULD be treated as such in preference to being silently discarded. Indeed, silently discarding an EAP message within the tunnel effectively puts a halt to the progress of the exchange, and will result in long timeouts in cases that ought to result in immediate failures.
EAP-TTLSは、トンネルEAP交換のための信頼性の高いトランスポートを提供します。ただし、[RFC3748]はEAPメッセージ（3.1節を参照）のための信頼性の低い輸送を想定し、そのようなパケットがそうであることを前提に、メソッド固有の整合性チェックをプロトコルに違反したか失敗した任意のEAPパケットをサイレント破棄を提供します攻撃者により送信された偽造。トンネル内部EAP認証のための信頼性の高いトランスポートを提供するためしかし、に係るサイレント破棄をもたらすエラー[RFC3748]は、おそらくそれらがトンネル内で発生したときの実装誤差を表し、黙って破棄されることに優先して、そのようなものとして扱われるべきです。実際に、静かにトンネル内のEAPメッセージを廃棄することは効果的交換の進行に停止を置き、その即時の障害をもたらすべきである場合には、長いタイムアウトをもたらすであろう。
The CHAP algorithm is described in [RFC1661]; RADIUS attribute formats are described in [RFC2865].
CHAPアルゴリズムは[RFC1661]に記載されています。 RADIUS属性フォーマットは、[RFC2865]に記載されています。
Both client and TTLS server generate 17 octets of challenge material, using the constant string "ttls challenge" as described above. These octets are used as follows:
クライアントとTTLSサーバの両方が上記のように定数文字列「TTLSの挑戦」を使用して、チャレンジ材料の17個のオクテットを生成します。次のようにこれらのオクテットが使用されます。
CHAP-Challenge [16 octets] CHAP Identifier [1 octet]
CHAPチャレンジ[16個のオクテット] CHAP識別子[1つのオクテット]
The client initiates CHAP by tunneling User-Name, CHAP-Challenge, and CHAP-Password AVPs to the TTLS server. The CHAP-Challenge value is taken from the challenge material. The CHAP-Password consists of
クライアントはTTLSサーバへのトンネリングユーザー名、CHAPチャレンジ、およびCHAP-パスワードのAVPでCHAPを開始します。 CHAPチャレンジ値は、チャレンジ材料から取られています。 CHAP-パスワードで構成されてい
CHAP Identifier, taken from the challenge material; and CHAP response, computed according to the CHAP algorithm.
CHAP識別子、チャレンジ材料から取られました。およびCHAP応答は、CHAPアルゴリズムに従って計算します。
Upon receipt of these AVPs from the client, the TTLS server must verify that the value of the CHAP-Challenge AVP and the value of the CHAP Identifier in the CHAP-Password AVP are equal to the values generated as challenge material. If either item does not match exactly, the TTLS server must reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request.
クライアントからこれらのAVPを受信すると、TTLSサーバは、CHAPチャレンジのAVPの値とCHAPパスワードのAVPにCHAP識別子の値は、チャレンジ材料として生成された値に等しいことを確認しなければなりません。いずれかの項目が正確に一致しない場合は、TTLSサーバはクライアントを拒否しなければなりません。それ以外の場合は、アクセス要求にAAA / HにAVPを転送します。
The AAA/H will respond with an Access-Accept or Access-Reject.
AAA / Hは、アクセス-受け入れるか、またはアクセス拒否で応答します。
The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute formats are described in [RFC2548].
MS-CHAPアルゴリズムは[RFC2433]に記載されています。 RADIUS属性フォーマットは、[RFC2548]に記載されています。
Both client and TTLS server generate 9 octets of challenge material, using the constant string "ttls challenge" as described above. These octets are used as follows:
クライアントとTTLSサーバの両方が上記のように定数文字列「TTLSの挑戦」を使用して、チャレンジ材料の9つのオクテットを生成します。次のようにこれらのオクテットが使用されます。
MS-CHAP-Challenge [8 octets] Ident [1 octet]
MS-CHAPチャレンジ[8つのオクテット]のIdent [1つのオクテット]
The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-Challenge and MS-CHAP-Response AVPs to the TTLS server. The MS-CHAP-Challenge value is taken from the challenge material. The MS-CHAP-Response consists of Ident, taken from the challenge material; Flags, set according the client preferences; and LM-Response and NT-Response, computed according to the MS-CHAP algorithm.
クライアントはTTLSサーバへのトンネリングユーザー名、MS-CHAPチャレンジおよびMS-CHAP-レスポンスのAVPでMS-CHAPを開始します。 MS-CHAPチャレンジ値は、チャレンジ材料から取られています。 MS-CHAP-Responseチャレンジ材料から取られたIdent、で構成されています。国旗、クライアントの好みに従って設定します。そしてLM-応答およびNT-応答は、MS-CHAPアルゴリズムに従って計算します。
Upon receipt of these AVPs from the client, the TTLS server MUST verify that the value of the MS-CHAP-Challenge AVP and the value of the Ident in the client's MS-CHAP-Response AVP are equal to the values generated as challenge material. If either item does not match exactly, the TTLS server MUST reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request.
クライアントからこれらのAVPを受信すると、TTLSサーバは、MS-CHAP-チャレンジAVPの値とクライアントのMS-CHAP-応答AVP中のIdentの値が挑戦の材料として生成された値に等しいことを確かめなければなりません。いずれかの項目が正確に一致しない場合は、TTLSサーバはクライアントを拒絶しなければなりません。それ以外の場合は、アクセス要求にAAA / HにAVPを転送します。
The AAA/H will respond with an Access-Accept or Access-Reject.
AAA / Hは、アクセス-受け入れるか、またはアクセス拒否で応答します。
The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute formats are described in [RFC2548].
MS-CHAP-V2アルゴリズムは[RFC2759]に記載されています。 RADIUS属性フォーマットは、[RFC2548]に記載されています。
Both client and TTLS server generate 17 octets of challenge material, using the constant string "ttls challenge" as described above. These octets are used as follows:
クライアントとTTLSサーバの両方が上記のように定数文字列「TTLSの挑戦」を使用して、チャレンジ材料の17個のオクテットを生成します。次のようにこれらのオクテットが使用されます。
MS-CHAP-Challenge [16 octets] Ident [1 octet]
MS-CHAPチャレンジ[16個のオクテット]のIdent [1つのオクテット]
The client initiates MS-CHAP-V2 by tunneling User-Name, MS-CHAP-Challenge, and MS-CHAP2-Response AVPs to the TTLS server. The MS-CHAP-Challenge value is taken from the challenge material. The MS-CHAP2-Response consists of Ident, taken from the challenge material; Flags, set to 0; Peer-Challenge, set to a random value; and Response, computed according to the MS-CHAP-V2 algorithm.
クライアントはTTLSサーバへのトンネリングユーザー名、MS-CHAPチャレンジ、およびMS-CHAP2・レスポンスのAVPでMS-CHAP-V2を開始します。 MS-CHAPチャレンジ値は、チャレンジ材料から取られています。 MS-CHAP2-Responseチャレンジ材料から取られたIdent、で構成されています。 0に設定するフラグ、。ランダムな値に設定ピアチャレンジ、;応答は、MS-CHAP-V2アルゴリズムに従って計算します。
Upon receipt of these AVPs from the client, the TTLS server MUST verify that the value of the MS-CHAP-Challenge AVP and the value of the Ident in the client's MS-CHAP2-Response AVP are equal to the values generated as challenge material. If either item does not match exactly, the TTLS server MUST reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request.
クライアントからこれらのAVPを受信すると、TTLSサーバは、MS-CHAP-チャレンジAVPの値とクライアントのMS-CHAP2-応答AVP中のIdentの値が挑戦の材料として生成された値に等しいことを確かめなければなりません。いずれかの項目が正確に一致しない場合は、TTLSサーバはクライアントを拒絶しなければなりません。それ以外の場合は、アクセス要求にAAA / HにAVPを転送します。
If the authentication is successful, the AAA/H will respond with an Access-Accept containing the MS-CHAP2-Success attribute. This attribute contains a 42-octet string that authenticates the AAA/H to the client based on the Peer-Challenge. The TTLS server tunnels this AVP to the client. Note that the authentication is not yet complete; the client must still accept the authentication response of the AAA/H.
認証が成功した場合は、AAA / Hは、アクセス-受け入れMS-CHAP2 - 成功の属性を含むで応答します。この属性は、ピア・チャレンジに基づいて、クライアントにAAA / Hを認証する42オクテット文字列が含まれています。 TTLSサーバトンネルクライアントにこのAVP。認証が完了していないことに注意してください。クライアントはAAA / Hの認証応答を受け入れる必要があります。
Upon receipt of the MS-CHAP2-Success AVP, the client is able to authenticate the AAA/H. If the authentication succeeds, the client sends an EAP-TTLS packet to the TTLS server containing no data (that is, with a zero-length Data field). Upon receipt of the empty EAP-TTLS packet from the client, the TTLS server considers the MS-CHAP-V2 authentication to have succeeded.
MS-CHAP2-成功AVPを受信すると、クライアントは、AAA / Hを認証することができます。認証が成功した場合、クライアントは、（それはゼロ長のデータフィールドに、である）データを含まないTTLSサーバにEAP-TTLSパケットを送信します。クライアントからの空のEAP-TTLSパケットを受信すると、TTLSサーバは、MS-CHAP-V2認証が成功したとみなします。
If the authentication fails, the AAA/H will respond with an Access-Challenge containing the MS-CHAP-Error attribute. This attribute contains a new Ident and a string with additional information such as the error reason and whether a retry is allowed. The TTLS server tunnels this AVP to the client. If the error reason is an expired password and a retry is allowed, the client may proceed to change the user's password. If the error reason is not an expired password or if the client does not wish to change the user's password, it simply abandons the EAP-TTLS negotiation.
認証に失敗した場合は、AAA / Hは、MS-CHAP-エラー属性を含むアクセスチャレンジで応答します。この属性は、このようなエラーの理由として、リトライが許可されているかどうか、新規のIdentや追加情報を含む文字列が含まれています。 TTLSサーバトンネルクライアントにこのAVP。エラーの理由が期限切れのパスワードであると再試行が許可されている場合、クライアントは、ユーザーのパスワードを変更するに進むことができます。エラーの理由は、期限切れのパスワードではありませんか、クライアントがユーザーのパスワードを変更したくない場合は、それは単にEAP-TTLS交渉を放棄した場合。
If the client does wish to change the password, it tunnels MS-CHAP-NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS server. The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge received in the MS-CHAP-Error AVP. The MS-CHAP-Challenge AVP simply echoes the new Challenge.
クライアントがパスワードを変更したいならば、それはTTLSサーバにMS-CHAP-NT-ENC-PW、MS-CHAP2-CPW、およびMS-CHAP-チャレンジAVPをトンネルします。 MS-CHAP2-CPW AVPは、新規のIdentとチャレンジから導出されたMS-CHAP-エラーAVPで受信。 MS-CHAPチャレンジAVPは、単純に新しいチャレンジをエコーします。
Upon receipt of these AVPs from the client, the TTLS server MUST verify that the value of the MS-CHAP-Challenge AVP and the value of the Ident in the client's MS-CHAP2-CPW AVP match the values it sent in the MS-CHAP-Error AVP. If either item does not match exactly, the TTLS server MUST reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request.
クライアントからこれらのAVPを受信すると、TTLSサーバは、MS-CHAP-チャレンジAVPとクライアントのMS-CHAP2-CPW AVP中のIdentの値の値は、それがMS-CHAPに送信された値と一致していることを確かめなければなりません-error AVP。いずれかの項目が正確に一致しない場合は、TTLSサーバはクライアントを拒絶しなければなりません。それ以外の場合は、アクセス要求にAAA / HにAVPを転送します。
If the authentication is successful, the AAA/H will respond with an Access-Accept containing the MS-CHAP2-Success attribute. At this point, the negotiation proceeds as described above; the TTLS server tunnels the MS-CHAP2-Success to the client, and the client authenticates the AAA/H based on this AVP. Then, the client either abandons the negotiation on failure or sends an EAP-TTLS packet to the TTLS server containing no data (that is, with a zero-length Data field), causing the TTLS server to consider the MS-CHAP-V2 authentication to have succeeded.
認証が成功した場合は、AAA / Hは、アクセス-受け入れMS-CHAP2 - 成功の属性を含むで応答します。上述したように、この時点で、交渉が進められます。 TTLSサーバはクライアントへのMS-CHAP2-成功をトンネリングし、クライアントは、このAVPに基づくAAA / Hを認証します。次に、クライアントのいずれかの故障でネゴシエーションを放棄またはMS-CHAP-V2認証を検討するTTLSサーバを引き起こし、データ（すなわちゼロ長データフィールドである）を含まないTTLSサーバへのEAP-TTLSパケットを送信します成功しました。
Note that additional AVPs associated with MS-CHAP-V2 may be sent by the AAA/H; for example, MS-CHAP-Domain. The TTLS server MUST tunnel such authentication-related attributes along with the MS-CHAP2- Success.
MS-CHAP-V2に関連する追加のAVPは、AAA / Hによって送信されてもよいことに留意されたいです。例えば、MS-CHAPドメイン。 MS-CHAP2-成功と共にTTLSサーバMUSTトンネル、認証関連の属性。
The client initiates PAP by tunneling User-Name and User-Password AVPs to the TTLS server.
クライアントはTTLSサーバにユーザー名とユーザー・パスワードのAVPをトンネリングすることによってPAPを開始します。
Normally, in RADIUS, User-Password is padded with nulls to a multiple of 16 octets, then encrypted using a shared secret and other packet information.
通常、RADIUSで、ユーザのパスワードは、その後、共有秘密およびその他のパケット情報を使用して暗号化され、16オクテットの倍数にヌルが埋め込まれます。
An EAP-TTLS client, however, does not RADIUS-encrypt the password since no such RADIUS variables are available; this is not a security weakness since the password will be encrypted via TLS anyway. The client SHOULD, however, null-pad the password to a multiple of 16 octets, to obfuscate its length.
そのようなRADIUS変数が用意されていないので、EAP-TTLSクライアントが、しかし、パスワードをRADIUS、暗号化されません。パスワードはとにかくTLSで暗号化されますので、これはセキュリティ上の弱点ではありません。クライアントは、しかし、ヌル・パッド16オクテットの倍数にパスワードは、その長さを難読化するべきです。
Upon receipt of these AVPs from the client, the TTLS server forwards them to the AAA/H in a RADIUS Access-Request. (Note that in the Access-Request, the TTLS server must encrypt the User-Password attribute using the shared secret between the TTLS server and AAA/H.)
クライアントからこれらのAVPを受信すると、TTLSサーバは、RADIUSアクセス要求にAAA / Hに転送します。 （アクセス要求で、TTLSサーバがTTLSサーバとAAA / Hの間の共有秘密を使用してユーザー・パスワード属性を暗号化する必要があることに注意してください。）
The AAA/H may immediately respond with an Access-Accept or Access-Reject. The TTLS server then completes the negotiation by sending an EAP-Success or EAP-Failure to the access point using the AAA carrier protocol.
AAA / Hは、直ちにアクセス-受け入れるか、またはアクセス拒否で応答することができます。 TTLSサーバは、AAA・キャリア・プロトコルを使用してアクセスポイントにEAP-成功またはEAP-失敗を送信することによって、ネゴシエーションを完了します。
The AAA/H may also respond with an Access-Challenge. The TTLS server then tunnels the AVPs from the AAA/H's challenge to the client. Upon receipt of these AVPs, the client tunnels User-Name and User-Password again, with User-Password containing new information in response to the challenge. This process continues until the AAA/H issues an Access-Accept or Access-Reject.
AAA / Hはまた、アクセスチャレンジで応答することができます。 TTLSサーバは、クライアントにAAA / Hの挑戦からAVPをトンネリングします。これらのAVPを受信すると、クライアントは、ユーザーのパスワードがチャレンジに応答して、新たな情報が含まれていると、再びユーザー名とユーザーパスワードをトンネルします。 AAA / Hが発行されるまで、このプロセスは継続アクセスを、受け入れるか、またはアクセスが拒否。
At least one of the AVPs tunneled to the client upon challenge MUST be Reply-Message. Normally, this is sent by the AAA/H as part of the challenge. However, if the AAA/H has not sent a Reply-Message, the TTLS server MUST issue one, with null value. This allows the client to determine that a challenge response is required.
挑戦時にクライアントにトンネルのAVPの少なくとも一つは、返信メッセージでなければなりません。通常、これは挑戦の一環として、AAA / Hによって送信されます。 AAA / Hは、返信メッセージを送信していない場合は、TTLSサーバは、ヌル値で、1を発行しなければなりません。これは、クライアントがチャレンジ応答が必要であることを決定することができます。
Note that if the AAA/H includes a Reply-Message as part of an Access-Accept or Access-Reject, the TTLS server does not tunnel this AVP to the client. Rather, this AVP and all other AVPs sent by the AAA/H as part of Access-Accept or Access-Reject are sent to the access point via the AAA carrier protocol.
AAA / Hは、接続許可またはアクセス拒否の一部として返信メッセージを含む場合、TTLSサーバはクライアントへのトンネルこのAVPはないことに留意されたいです。むしろ、このAVPの一部としてAAA / Hによって送信された他のすべてのAVP接続許可またはアクセス拒否AAAキャリアプロトコルを介してアクセスポイントに送信されます。
In some cases, it is desirable to perform multiple user authentications. For example, a AAA/H may want first to authenticate the user by password, then by token card.
いくつかの例では、複数のユーザ認証を行うことが望ましいです。例えば、AAA / Hは、トークンカードによって、パスワードでユーザーを認証する最初とよいでしょう。
The AAA/H may perform any number of additional user authentications using EAP, simply by issuing a EAP-Request with a new EAP type once the previous authentication completes. Note that each new EAP method is subject to negotiation; that is, the client may respond to the EAP request for a new EAP type with an EAP-Nak, as described in [RFC3748].
AAA / Hは、単純に以前の認証が完了すると、新しいEAPタイプのEAP-Requestを発行することによって、EAPを使用して追加のユーザ認証の任意の数を実行することができます。それぞれの新しいEAPメソッドは、交渉の対象であることに注意してください。つまり、クライアントは、[RFC3748]に記載されているように、EAP-Nakを有する新しいEAPタイプのEAP要求に応答することができます。
For example, a AAA/H wishing to perform an MD5-Challenge followed by Generic Token Card would first issue an EAP-Request/MD5-Challenge and receive a response. If the response is satisfactory, it would then issue an EAP-Request/Generic Token Card and receive a response. If that response were also satisfactory, it would accept the user.
例えば、一般的なトークンカードに続いてMD5チャレンジを行いたいAAA / Hは、最初のEAP要求/ MD5チャレンジを発行し、応答を受け取ることになります。応答が満足のいくものであるならば、それは、EAP要求/ジェネリックトークンカードを発行し、応答を受け取ることになります。そのレスポンスも良好であった場合、それはユーザーを受け入れるだろう。
The entire inner EAP exchange comprising multiple authentications is considered a single EAP sequence, in that each subsequent request MUST contain distinct a EAP Identifier from the previous request, even as one authentication completes and another begins.
後続の各要求はつの認証が完了すると、別のが始まったとしても、以前の要求からの異なるEAP識別子を含まなければならないという点で、複数の認証を含む全体の内部EAP交換は、単一のEAPシーケンスであると考えられます。
The peer identity indicated in the original EAP-Response/Identity that initiated the EAP sequence is intended to apply to each of the sequential authentications. In the absence of an application profile standard specifying otherwise, additional EAP-Identity exchanges SHOULD NOT occur.
EAPシーケンスを開始し、元のEAP応答/アイデンティティに示されているピアのアイデンティティは、逐次認証のそれぞれに適用することが意図されています。そうでなければ特定のアプリケーションプロファイル規格の非存在下で、追加のEAPアイデンティティ交換が発生してはなりません。
The conditions for overall success or failure when multiple authentications are used are a matter of policy on client and server; thus, either party may require that all inner authentications succeed, or that at least one inner authentication succeed, as a condition for success of the overall authentication.
複数の認証が使用されている全体の成功または失敗のための条件は、クライアントとサーバー上の政策の問題です。このように、いずれかの当事者は、認証全体の成功のための条件として、すべての内部認証が成功、またはその少なくとも1つの内側の認証が成功することを要求することができます。
Each EAP method is intended to run to completion. Should the TTLS server abandon a method and start a new one, client behavior is not defined in this document and is a matter of client policy.
各EAPメソッドが完了するまで実行することを意図しています。 TTLSサーバは、メソッドを放棄し、新しいものを開始する必要があり、クライアントの動作は、このドキュメントで定義され、クライアントのポリシーの問題ではありません。
Note that it is not always feasible to use the same EAP method twice in a row, since it may not be possible to determine when the first authentication completes and the new authentication begins if the EAP type does not change. Certain EAP methods, such as EAP-TLS, use a Start bit to distinguish the first request, thus allowing each new authentication using that type to be distinguished from the previous. Other methods, such as EAP-MS-CHAP-V2, terminate in a well-defined manner, allowing a second authentication of the same type to commence unambiguously. While use of the same EAP method for multiple authentications is relatively unlikely, implementers should be aware of the issues and avoid cases that would result in ambiguity.
最初の認証が完了し、EAPの種類が変更されない場合は、新しい認証の開始時に決定することが可能ではないかもしれないから、2回連続で同じEAPメソッドを使用することが常に可能ではないことに注意してください。そのようなEAP-TLSなどの特定のEAPメソッドは、このように前と区別するために、そのタイプを使用して、各新しい認証を可能にする、第1の要求を区別するためにスタートビットを使用します。そのようなEAP-MS-CHAP-V2などの他の方法は、同じタイプの第二の認証が明確に開始することができ、明確に定義された方法で終端します。複数の認証のために同じEAPメソッドの使用は比較的低いですが、実装者は問題を認識し、あいまいさにつながるケースを避ける必要があります。
Multiple authentications using non-EAP methods or a mixture of EAP and non-EAP methods is not defined in this document, nor is it known whether such an approach has been implemented.
非EAPメソッドまたはEAPおよび非EAPメソッドの混合物を使用して複数の認証は、この文書で定義されていない、またそのようなアプローチが実装されているかどうか知られています。
To ensure interoperability, in the absence of an application profile standard specifying otherwise, an implementation compliant with this specification MUST implement EAP as a tunneled authentication method and MUST implement MD5-Challenge as an EAP type. However, such an implementation MAY allow the use of EAP, any EAP type, or any other tunneled authentication method to be enabled or disabled by administrative action on either client or TTLS server.
そうでなければ特定のアプリケーションプロファイル規格の非存在下で、相互運用性を確保するために、この仕様に準拠した実装は、トンネル認証方式としてEAPを実装しなければならなくて、EAPタイプとしてMD5チャレンジを実装しなければなりません。しかし、このような実装は、EAP、任意のEAPタイプ、またはクライアントまたはTTLSサーバーのいずれかの管理操作によって有効または無効にするには、他のトンネリングされた認証方法の使用を可能にすることができます。
In addition, in the absence of an application profile standard specifying otherwise, an implementation compliant with this specification MUST allow an administrator to configure the use of tunneled authentication without the M (Mandatory) bit set on any AVP.
また、そうでなければ特定のアプリケーションプロファイル規格が存在しない場合に、この仕様に準拠した実装では、管理者が任意のAVPに設定されたビットM（必須）なしでトンネリング認証の使用を構成することを可能にしなければなりません。
The following information is provided as non-normative guidance based on the experience of the authors and reviewers of this specification with existing implementations of EAP-TTLSv0.
以下の情報は、EAP-TTLSv0の既存の実装で、この仕様書の著者と査読の経験に基づいて、非規範的指針として提供されます。
The following authentication methods are commonly used, and servers wishing for broad interoperability across multiple media should consider implementing them:
次の認証方法が一般的に使用されており、複数のメディアにわたる幅広い相互運用性のために希望のサーバはそれらの実装を検討すべきです：
- PAP (both for password and token authentication)
- PAP（両方のパスワードとトークン認証用）
- MS-CHAP-V2
- MS-CHAP-V2
- EAP-MS-CHAP-V2
- EAP-MS-CHAP-V2
- EAP-GTC
- EAP-GTC
In compliance with [RFC5247], Session-Id, Peer-Id, and Server-Id are here defined.
[RFC5247]に準拠して、セッションID、ピアID、およびサーバIDは、ここで定義されています。
The Session-Id uniquely identifies an authentication exchange between the client and TTLS server. It is defined as follows:
セッションIDは、クライアントとTTLSサーバの間で認証交換を識別します。これは次のように定義されます。
Session-Id = 0x15 || client.random || server.random
セッションId = 0x15の|| client.random || server.random
The Peer-Id represents the identity to be used for access control and accounting purposes. When the client presents a certificate as part of the TLS handshake, the Peer-Id is determined based on information in the certificate, as specified in Section 5.2 of [RFC5216]. Otherwise, the Peer-Id is null.
ピアIDは、アクセス制御と会計目的のために使用するIDを表します。クライアントは、TLSハンドシェイクの一部として証明書を提示すると[RFC5216]のセクション5.2で指定されるように、ピアIDは、証明書の情報に基づいて決定されます。そうでない場合は、ピアIDはnullです。
The Server-Id identifies the TTLS server. When the TTLS server presents a certificate as part of the TLS handshake, the Server-Id is determined based on information in the certificate, as specified in Section 5.2 of [RFC5216]. Otherwise, the Server-Id is null.
サーバIDは、TTLSサーバを識別します。 TTLSサーバは、TLSハンドシェイクの一部として証明書を提示すると[RFC5216]のセクション5.2で指定されるように、サーバIDは、証明書の情報に基づいて決定されます。それ以外の場合は、サーバIDはnullです。
The following table lists each AVP defined in this document, whether the AVP may appear in a packet from server to client ("Request") and/or in a packet from client to server ("Response"), and whether the AVP MUST be implemented ("MI").
次の表は、AVPは、クライアントからサーバー（「応答」）におよび/またはパケットに（「要求」）、サーバからクライアントへのパケットに表示され、AVPはしなければならないかどうかかどうか、この文書で定義された各AVP、 （ "MI"）を実施。
Name Request Response MI
---------------------------------------------------
User-Name X
User-Password X
CHAP-Password X
Reply-Message X
CHAP-Challenge X
EAP-Message X X X
MS-CHAP-Response X
MS-CHAP-Error X
MS-CHAP-NT-Enc-PW X
MS-CHAP-Domain X
MS-CHAP-Challenge X
MS-CHAP2-Response X
MS-CHAP2-Success X
MS-CHAP2-CPW X
Pursuant to RFC 3748, security claims for EAP-TTLSv0 are as follows:
次のようにRFC 3748に基づき、EAP-TTLSv0のセキュリティ主張は以下のとおりです。
Authentication mechanism: TLS plus arbitrary additional protected authentication(s) Ciphersuite negotiation: Yes Mutual authentication: Yes, in recommended implementation Integrity protection: Yes Replay protection: Yes Confidentiality: Yes Key derivation: Yes Key strength: Up to 384 bits Dictionary attack prot.: Yes Fast reconnect: Yes Cryptographic binding: No Session independence: Yes Fragmentation: Yes Channel binding: No
認証メカニズム：TLSプラス任意の追加の保護された認証（S）たciphersuite交渉：はい相互認証：はい、推奨実装完全性保護で：はいリプレイ保護：はい機密性：はいキー派生：はいキー強度：384ビット辞書攻撃PROTまで。 ：はい高速再接続：はい暗号バインディング：いいえSession独立：はいフラグメンテーション：はいチャンネルバインディング：いいえ
EAP-TTLSv0 utilizes negotiated underlying authentication protocols, both in the phase 1 TLS handshake and the phase 2 tunneled authentication. In a typical deployment, at a minimum the TTLS server authenticates to the client in phase 1, and the client authenticates to the AAA/H server in phase 2. Phase 1 authentication of the TTLS server to the client is typically by certificate; the client may optionally authenticate to the TTLS server by certificate as well. Phase 2 authentication of the client to the AAA/H server is typically by password or security token via an EAP or supported non-EAP authentication mechanism; this authentication mechanism may provide authentication of the AAA/H server to the client as well (mutual authentication).
EAP-TTLSv0はフェーズ1 TLSハンドシェイクとフェーズ2トンネルされた認証の両方で、基本的な認証プロトコルを交渉し利用します。典型的な展開では、最低でTTLSサーバは、フェーズ1でクライアントに認証し、クライアントは、クライアントにTTLSサーバの2フェーズ1の認証証明書によって、典型的には位相にAAA / Hサーバに認証し、クライアントは、必要に応じて、同様の証明書によってTTLSサーバへの認証を行ってもよいです。 AAA / Hサーバへのクライアントのフェーズ2認証は、EAPまたはサポートされている非EAP認証機構を介してパスワードやセキュリティトークンにより、一般的です。この認証メカニズムは、クライアントにAAA / Hサーバの認証も（相互認証）を提供することができます。
Ciphersuite negotiation is inherited from TLS.
暗号スイートネゴシエーションはTLSから継承されます。
In the recommended minimum configuration, the TTLS server is authenticated to the client in phase 1, and the client and AAA/H server mutually authenticate in phase 2.
推奨される最小構成では、TTLSサーバは、フェーズ1でクライアントに認証され、クライアントとAAA / Hサーバは、互いに相2に認証します。
Integrity protection is inherited from TLS.
完全性保護はTLSから継承されます。
Replay protection is inherited from TLS.
リプレイ保護はTLSから継承されます。
Confidentiality is inherited from TLS. Note, however, that EAP-TTLSv0 contains no provision for encryption of success or failure EAP packets.
機密性は、TLSから継承されます。 EAP-TTLSv0が成功または失敗EAPパケットを暗号化するための規定が含まれていないこと、しかし、注意してください。
Both MSK and EMSK are derived. The key derivation PRF is inherited from TLS, and cryptographic agility of this mechanism depends on the cryptographic agility of the TLS PRF.
MSKとEMSKの両方が導出されています。鍵導出PRFはTLSから継承されており、このメカニズムの暗号敏捷性は、TLS PRFの暗号敏捷性に依存します。
Key strength is limited by the size of the TLS master secret, which for versions 1.0 and 1.1 is 48 octets (384 bits). Effective key strength may be less, depending on the attack resistance of the negotiated Diffie-Helman (DH) group, certificate RSA/DSA group, etc. BCP 86 [RFC3766], Section 5, offers advice on the required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
キー強度はバージョン1.0と1.1のために48個のオクテット（384ビット）であるTLSマスターシークレットのサイズによって制限されます。有効鍵強度はネゴシエートディフィー・ヘルマン（DH）グループ、証明書RSA / DSA基等BCP 86 [RFC3766]、セクション5は、必要なRSA上の助言やDHモジュールを提供するの攻撃性に応じて、小さくすることができるとビットにおける攻撃性の所定のレベルのためのビットでDSAサブグループサイズ。例えば、2048ビットのRSA鍵は128ビットの同等キー強度を提供することが推奨されます。標準技術研究所（NIST）は、[SP800-57]で適切なキーのサイズについてアドバイスを提供しています。
Phase 2 password authentication is protected against eavesdropping and therefore against offline dictionary attack by TLS encryption.
フェーズ2パスワード認証が盗聴ので、TLS暗号化により、オフライン辞書攻撃から保護されています。
Fast reconnect is provided by TLS session resumption.
高速再接続は、TLSセッション再開により提供されます。
[MITM] describes a vulnerability that is characteristic of tunneled authentication protocols, in which an attacker authenticates as a client via a tunneled protocol by posing as an authenticator to a legitimate client using a non-tunneled protocol. When the same proof of credentials can be used in both authentications, the attacker merely shuttles the credential proof between them. EAP-TTLSv0 is vulnerable to such an attack. Care should be taken to avoid using authentication protocols and associated credentials both as inner TTLSv0 methods and as untunneled methods.
【MITM]攻撃者は、非トンネリングプロトコルを使用して、正当なクライアントとオーセンティケータとしてポーズによってトンネリングプロトコルを介してクライアントとして認証するトンネリング認証プロトコルの特性である脆弱性が記載されています。同じ資格情報の証明は、両方の認証に使用することができた場合、攻撃者は、単にそれらの間の資格証明を往復します。 EAP-TTLSv0は、このような攻撃に対して脆弱です。ケアは、内側TTLSv0方法として、およびuntunneled方法として、両方の認証プロトコルおよび関連する資格情報を使用しないように注意する必要があります。
Extensions to EAP-TTLSv0 or a future version of EAP-TTLS should be defined to perform a cryptographic binding of keying material generated by inner authentication methods and the keying material generated by the TLS handshake. This avoids the man-in-the-middle problem when used with key-generating inner methods. Such an extension mechanism has been proposed [TTLS-EXT].
EAP-TTLSv0またはEAP-TTLSの将来のバージョンへの拡張は、内部認証方法及びTLSハンドシェークによって生成された鍵材料によって生成された鍵材料の暗号結合を実行するように定義されるべきです。これは、鍵生成内部方式で使用のman-in-the-middle問題を回避できます。そのような拡張機構が提案されている[TTLS-EXT]。
TLS guarantees the session independence of its master secret, from which the EAP-TTLSv0 MSK/EMSK is derived.
TLSは、EAP-TTLSv0 MSK / EMSKが由来するそのマスターシークレットのセッションの独立性を保証します。
Provision is made for fragmentation of lengthy EAP packets.
提供は長いEAPパケットの断片化のために作られています。
Support for channel binding may be added as a future extension, using appropriate AVPs.
結合チャネルのサポートは適切なAVPを使用して、将来の拡張として添加してもよいです。
Unlike other EAP methods, EAP-TTLS does not communicate a username in the clear in the initial EAP-Response/Identity. This feature is designed to support anonymity and location privacy from attackers eavesdropping the network path between the client and the TTLS server. However, implementers should be aware that other factors -- both within EAP-TTLS and elsewhere -- may compromise a user's identity. For example, if a user authenticates with a certificate during phase 1 of EAP-TTLS, the subject name in the certificate may reveal the user's identity. Outside of EAP-TTLS, the client's fixed MAC address, or in the case of wireless connections, the client's radio signature, may also reveal information. Additionally, implementers should be aware that a user's identity is not hidden from the EAP-TTLS server and may be included in the clear in AAA messages between the access point, the EAP-TTLS server, and the AAA/H server.
他のEAP方式とは異なり、EAP-TTLSは、最初のEAP応答/アイデンティティで明らかにユーザ名を通信しません。この機能は、クライアントとTTLSサーバ間のネットワークパスを盗聴攻撃者からの匿名性と場所のプライバシーをサポートするように設計されています。 EAP-TTLS内の他の場所の両方 - - ユーザーの身元を損なう可能性がしかし、実装者は、他の要因があることに注意する必要があります。ユーザーはEAP-TTLSのフェーズ1の間、証明書で認証する場合、例えば、証明書のサブジェクト名は、ユーザの身元を明らかにすることができます。 EAP-TTLS、クライアントの固定MACアドレス、または無線接続の場合は、クライアントのラジオ署名の外でも、情報を公開してもよいです。また、実装者は、ユーザーのアイデンティティがEAP-TTLSサーバから隠されていないとアクセスポイント間のAAAメッセージ、EAP-TTLSサーバ、およびAAA / Hサーバに明確に含まれていてもよいことに注意する必要があります。
Note that if a client authenticating with a certificate wishes to shield its certificate, and hence its identity, from eavesdroppers, it may use the technique described in Section 2.1.4 ("Privacy") of [RFC5216], in which the client sends an empty certificate list, the TTLS server issues a ServerHello upon completion of the TLS handshake to begin a second, encrypted handshake, during which the client will send its certificate list. Note that for this feature to work the client must know in advance that the TTLS server supports it.
証明書で認証クライアントは、盗聴者から、その証明書、およびしたがってそのアイデンティティを保護したい場合、それはクライアントが送信した[RFC5216]のセクション2.1.4（「プライバシー」）に記載された技術を使用することができることに注意してください空の証明書リスト、TTLSサーバは、クライアントがその証明書のリストを送信します、その間二、暗号化されたハンドシェイクを、開始するためにTLSハンドシェイクが完了した時点でのServerHelloを発行します。この機能のために、クライアントはTTLSサーバがそれをサポートしていることを事前に知っていなければならない作業することに注意してください。
Trust of the server by the client is established via a server certificate conveyed during the TLS handshake. The client should have a means of determining which server identities are authorized to act as a TTLS server and may be trusted, and should refuse to authenticate with servers it does not trust. The consequence of pursuing authentication with a hostile server is exposure of the inner authentication to attack; e.g., offline dictionary attack against the client password.
クライアントがサーバーのトラストは、TLSハンドシェイク中に伝えサーバー証明書を介して確立されます。クライアントは、サーバのアイデンティティはTTLSサーバとして動作するように許可されている、信頼できるかを決定する手段を持っている必要があり、それは信頼していないサーバで認証することを拒否すべきです。敵対的なサーバとの認証を追求した結果は、攻撃に内部認証の暴露です。例えば、クライアントのパスワードに対するオフライン辞書攻撃。
When either client or server presents a certificate as part of the TLS handshake, it should include the entire certificate chain minus the root to facilitate certificate validation by the other party.
クライアントまたはサーバがTLSハンドシェイクの一部として証明書を提示すると、それは他の当事者による証明書の検証を容易にするために、証明書チェーン全体マイナスルートを含める必要があります。
When either client or server receives a certificate as part of the TLS handshake, it should validate the certification path to a trusted root. If intermediate certificates are not provided by the sender, the receiver may use cached or pre-configured copies if available, or may retrieve them from the Internet if feasible.
クライアントまたはサーバがTLSハンドシェイクの一部として証明書を受け取ると、それは信頼されたルートへの証明書パスを検証する必要があります。中間証明書が送信者によって提供されていない場合は利用可能な場合、受信機は、キャッシュされたか、事前に設定されたコピーを使用することができ、または可能であれば、インターネットからそれらを検索することができます。
Clients and servers should implement policies related to the Extended Key Usage (EKU) extension [RFC5280] of certificates it receives, to ensure that the other party's certificate usage conforms to the certificate's purpose. Typically, a client EKU, when present, would be expected to include id-kp-clientAuth; a server EKU, when present, would be expected to include id-kp-serverAuth. Note that absence of the EKU extension or a value of anyExtendedKeyUsage implies absence of constraint on the certificate's purpose.
クライアントとサーバーは、それが相手の証明書の使用方法は、証明書の目的に適合することを確保するために、受信した証明書の拡張キー使用法（EKU）拡張[RFC5280]に関連するポリシーを実装する必要があります。典型的には、クライアントEKUは、存在する場合、ID-KP-CLIENTAUTHを含むことが予想されます。サーバEKU、存在する場合、ID-KP-serverAuthを含むと予想されます。 EKU拡張子またはanyExtendedKeyUsageの値が存在しない場合は、証明書の目的上の制約がないことを意味することに注意してください。
Certificates should be checked for revocation to reduce exposure to imposture using compromised certificates.
証明書は、妥協の証明書を使用して詐欺行為への露出を減らすために失効をチェックする必要があります。
Checking a server certificate against the most recent revocation list during authentication is not always possible for a client, as it may not have network access until completion of the authentication. This problem can be alleviated through the use of the Online Certificate Status Protocol (OCSP) [RFC2560] during the TLS handshake, as described in [RFC4366].
認証中に最新の失効リストに対してサーバ証明書をチェックすることは、認証が完了するまで、ネットワークへのアクセスを持っていないかもしれないとして、クライアントのために常に可能ではありません。 [RFC4366]で説明したように、この問題は、TLSハンドシェイク中にオンライン証明書状態プロトコル（OCSP）[RFC2560]を使用して軽減することができます。
With forward secrecy, revelation of a secret does not compromise session keys previously negotiated based on that secret. Thus, when the TLS key exchange algorithm provides forward secrecy, if a TTLS server certificate's private key is eventually stolen or cracked, tunneled user password information will remain secure as long as that certificate is no longer in use. Diffie-Hellman key exchange is an example of an algorithm that provides forward secrecy. A forward secrecy algorithm should be considered if attacks against recorded authentication or data sessions are considered to pose a significant threat.
転送秘密を使用すると、秘密の啓示は、以前にその秘密をもとに交渉セッションキーを損ないません。 TLS鍵交換アルゴリズムは、前進の秘密保持を提供する場合TTLSサーバ証明書の秘密鍵は、最終的に盗まれたり割れている場合はこのように、、、トンネリングされたユーザーのパスワード情報がある限り、その証明書が使用されなくなったとして安全なままになります。 Diffie-Hellman鍵交換は、前方機密性を提供するアルゴリズムの一例です。記録された認証やデータのセッションへの攻撃が大きな脅威をもたらすと考えられる場合には前進の秘密保持アルゴリズムを検討する必要があります。
EAP-TTLS negotiates its own protocol version prior to, and therefore outside the security established by the TLS tunnel. In principle, therefore, it is subject to a negotiating-down attack, in which an intermediary modifies messages in transit to cause a lower version of the protocol to be agreed upon, each party assuming that the other does not support as high a version as it actually does.
EAP-TTLS前に、したがって、TLSトンネルによって確立されたセキュリティ外部独自プロトコルバージョンをネゴシエート。原則として、そのため、プロトコルの下位バージョンでは、各当事者が他のと同じくらい高いバージョンをサポートしていないと仮定して合意させるように仲介者が輸送中にメッセージを修正する交渉ダウン攻撃、対象となりますそれは実際にはありません。
The version of the EAP-TTLS protocol described in this document is 0, and is therefore not subject to such an attack. However, any new version of the protocol using a higher number than 0 should define a mechanism to ensure against such an attack. One such mechanism might be the TTLS server's reiteration of the protocol version that it proposed in an AVP within the tunnel, such AVP to be inserted with M bit clear even when version 0 is agreed upon.
この文書に記載されEAP-TTLSプロトコルのバージョンは0であり、したがって、そのような攻撃を受けません。ただし、0よりも大きい数を使用して、プロトコルの新しいバージョンでは、そのような攻撃を確実にするメカニズムを定義しなければなりません。そのような機構の1つは、それがトンネル内AVPで提案されているプロトコルのバージョン、そのようなAVPのTTLSサーバの繰り返しは、バージョン0が合意されている場合でもクリアMビットで挿入されるかもしれません。
This section presents EAP-TTLS message sequences for various negotiation scenarios. These examples do not attempt to exhaustively depict all possible scenarios.
このセクションでは、さまざまな交渉のシナリオのためのEAP-TTLSのメッセージ・シーケンスを示しています。これらの例は、徹底的にすべての可能なシナリオを描くしようとしないでください。
It is assumed that RADIUS is the AAA carrier protocol both between access point and TTLS server, and between TTLS server and AAA/H.
RADIUSアクセスポイントとTTLSサーバとの間、およびTTLSサーバとAAA / Hとの間の両方のAAAキャリヤプロトコルであると仮定されます。
EAP packets that are passed unmodified between client and TTLS server by the access point are indicated as "passthrough". AVPs that are securely tunneled within the TLS record layer are enclosed in curly braces ({}). Items that are optional are suffixed with question mark (?). Items that may appear multiple times are suffixed with plus sign (+).
アクセスポイントによって、クライアントとTTLSサーバの間にそのまま渡されるEAPパケットは、「パススルー」として示されています。安全TLSレコード層内にトンネリングされたAVPは、中括弧で囲まれ（{}）。疑問符接尾辞されているオプションの項目（？）。複数回表示されることがありますアイテムは、プラス記号（+）接尾辞います。
In this example, the client performs one-way TLS authentication of the TTLS server. CHAP is used as a tunneled user authentication mechanism.
この例では、クライアントはTTLSサーバの一方向TLS認証を行います。 CHAPは、トンネルユーザ認証メカニズムとして使用されています。
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{User-Name}
{CHAP-Challenge}
{CHAP-Password}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
User-Name
CHAP-Challenge
CHAP-Password
-------------------->
RADIUS Access-Accept
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------
In this example, the client performs one-way TLS authentication of the TTLS server and EAP/MD5-Challenge is used as a tunneled user authentication mechanism.
この例では、クライアントはTTLSサーバの一方向TLS認証を実行し、EAP / MD5チャレンジは、トンネリングユーザ認証メカニズムとして使用されます。
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{EAP-Response/Identity}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response/Identity
-------------------->
RADIUS Access-Challenge
EAP-Request/
MD5-Challenge
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
{EAP-Request/MD5-Challenge}
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{EAP-Response/MD5-Challenge}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge
EAP-Response/
MD5-Challenge
-------------------->
RADIUS Access-Accept
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------
In this example, the client and server resume a previous TLS session. The ID of the session to be resumed is sent as part of the ClientHello, and the server agrees to resume this session by sending the same session ID as part of ServerHello.
この例では、クライアントとサーバは、以前のTLSセッションを再開します。セッションIDは、のClientHelloの一部として送信され再開されると、サーバはServerHelloメッセージの一部として、同じセッションIDを送信することによってこのセッションを再開することに同意します。
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------
IANA has assigned the number 21 (decimal) as the method type of the EAP-TTLS protocol. Mechanisms for defining new RADIUS and Diameter AVPs and AVP values are outlined in [RFC2865] and [RFC3588], respectively. No additional IANA registrations are specifically contemplated in this document.
IANAはEAP-TTLSプロトコルのメソッドタイプとして番号21（10進数）を割り当てました。新しいRADIUSとDiameterのAVPとAVPの値を定義するための機構は、それぞれ、[RFC2865]及び[RFC3588]に概説されています。追加のIANA登録は、具体的には、この文書に意図されていません。
Section 11 of this document specifies how certain authentication mechanisms may be performed within the secure tunnel established by EAP-TTLS. New mechanisms and other functions MAY also be performed within this tunnel. Where such extensions use AVPs that are not vendor-specific, their semantics must be specified in new RFCs; that is, there are TTLS-specific processing rules related to the use of each individual AVP, even though such AVPs have already been defined for RADIUS or DIAMETER.
このドキュメントのセクション11は、特定の認証メカニズムは、EAP-TTLSによって確立された安全なトンネル内で実行することができる方法を指定します。新しいメカニズムおよび他の機能は、このトンネル内で実行されてもよいです。そのような拡張は、ベンダー固有ではないAVPを使用する場合、その意味は、新しいRFCで指定する必要があります。つまり、このようなのAVPが既にRADIUSまたはDIAMETERのために定義されているにもかかわらず、それぞれの個々のAVPの使用に関連するTTLS特定処理ルールがあります。
This specification requires the creation of a new registry -- EAP-TTLS AVP Usage -- to be managed by IANA, listing each non-vendor-specific RADIUS/Diameter AVP that has been defined for use within EAP-TTLS, along with a reference to the RFC or other document that specifies its semantics. The initial list of AVPs shall be those listed in Section 13 of this document. The purpose of this registry is to avoid potential ambiguity resulting from the same AVP being utilized in different functional contexts. This registry does not assign numbers to AVPs, as the AVP numbers are assigned out of the RADIUS and Diameter namespaces as outlined in [RFC2865] and [RFC3588]. Only top-level AVPs -- that is, AVPs not encapsulated within Grouped AVPs -- will be registered. AVPs should be added to this registry based on IETF Review as defined in [RFC5226].
参照とともに、IANAによって管理される、EAP-TTLS内で使用するために定義されている各非ベンダー固有のRADIUS /直径AVPをリスト - EAP-TTLS AVPの使用 - この仕様は、新しいレジストリを作成する必要がありますその意味論を指定するRFCや他のドキュメントへ。 AVPの最初のリストは、このドキュメントのセクション13に列挙されているものでなければなりません。このレジストリの目的は、異なる機能のコンテキストで使用される同じAVPから生じる潜在的なあいまいさを回避することです。 [RFC2865]及び[RFC3588]に概説されるようAVP番号がRADIUSとDiameter名前空間から割り当てられるように、このレジストリは、のAVPに番号を割り当てません。唯一のトップレベルのAVP - つまり、グループ化されたAVPの中にカプセル化されていないのAVPは - 登録されます。 [RFC5226]で定義されたAVPは、IETFレビューに基づいて、このレジストリに追加する必要があります。
Thanks to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen Hanna, Ryan Hurst, Avi Lior, and Gabriel Montenegro for careful reviews and useful comments.
慎重な口コミや有益なコメントについてバーナードAboba、ヤリArkko、Lakshminath Dondeti、スティーブン・ハンナ、ライアン・ハースト、アビLIOR、とガブリエルモンテネグロに感謝します。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433]ソーン、G.とS.コブ、 "マイクロソフトPPP CHAP拡張機能"、RFC 2433、1998年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]ソーン、G.、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759]ソーン、G.、 "マイクロソフトPPP CHAP拡張、Version 2"、RFC 2759、2000年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]レイノルズ、J.、エド、。：、RFC 3232、2002年1月 "割り当て番号RFC 1700は、オンラインデータベースで置き換えられます"。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[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、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]サイモン、D.、Aboba、B.、およびR.ハースト、 "EAP-TLS認証プロトコル"、RFC 5216、2008年3月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、サイモン、D.、およびP. Eronen、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、RFC 5247、2008年8月。
[802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004.
電気電子技術者の[802.1X]研究所、「ローカルおよびメトロポリタンエリアネットワーク：ポートベースのネットワークアクセス制御」、IEEE標準802.1X-2004、2004年12月。
[802.11] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2007.
[802.11]電気電子技術者協会、「情報技術 - 地方とメトロポリタンエリアネットワーク - - 電気通信及びシステム間の情報交換の固有の要件パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様」、IEEE標準802.11、2007。
[TTLS-EXT] Hanna, S. and P. Funk, "Key Agility Extensions for EAP-TTLSv0", Work in Progress, September 2007.
[TTLS-EXT]ハンナ、S.とP.ファンク、 "EAP-TTLSv0のキー敏捷性の拡張"、進歩、2007年9月での作業。
[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.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、BCP 86、RFC 3766、2004年4月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、2006年4月。
[MITM] Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the-Middle in Tunneled Authentication", http://www.saunalahti.fi/~asokan/research/mitm.html, Nokia Research Center, Finland, October 24, 2002.
【MITM] Asokan、N.、ニエミ、V.、およびニベルグ、K.、 "のman-in-the-middleトンネルされた認証中"、http://www.saunalahti.fi/~asokan/research/mitm.html 、ノキア・リサーチ・センター、フィンランド、2002年10月24日。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
[SP800-57]米国国立標準技術研究所、「キー管理のための勧告」、特別な公表800-57、2006年5月。
Authors' Addresses
著者のアドレス
Paul Funk 43 Linnaean St. Cambridge, MA 02138 EMail: PaulFunk@alum.mit.edu
ポール・ファンク43リンネセントケンブリッジ、MA 02138 Eメール：PaulFunk@alum.mit.edu
Simon Blake-Wilson SafeNet Amstelveenseweg 88-90 1054XV, Amsterdam The Netherlands EMail: sblakewilson@nl.safenet-inc.com
サイモン・ブレイク・ウィルソンSafeNetのAmstelveenseweg 88-90 1054XV、アムステルダムオランダ電子メール：sblakewilson@nl.safenet-inc.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。