[要約] RFC 5281は、EAP-TTLSバージョン0 (EAP-TTLSv0) に関する文書で、Extensible Authentication Protocol (EAP) の一形態を定義しています。このプロトコルは、Transport Layer Security (TLS) トンネルを使用してクライアント認証情報を保護しながら、追加の認証方法をサポートすることを目的としています。EAP-TTLSv0は主に無線LANやリモートアクセスサービスなど、広範なネットワーク環境での認証に利用されます。関連するRFCには、EAPの基本を定義するRFC 3748や、TLSの仕様を定義するRFC 5246などがあります。
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などの別の認証プロトコルである場合があります。したがって、EAP-TTLは、レガシーパスワードベースの認証プロトコルを既存の認証データベースに対して使用することができ、これらのレガシープロトコルのセキュリティを盗聴、中間者、およびその他の攻撃から保護します。データフェーズは、追加の任意のデータ交換にも使用できます。
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].
Transport Layer Security（TLS）[RFC4346]は、サーバーのクライアント認証またはクライアントとサーバーの相互認証を提供する認証プロトコルであり、当事者間の安全性の高いCiphersuite交渉と主要な交換を提供する認証プロトコルです。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]などの非EAPプロトコル、およびMD5-Challenge [RFC3748]などの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-TTLのユーザーは、これらを展開で考慮することを強くお勧めします。
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.
したがって、EAP-TTLは、レガシーパスワードベースの認証プロトコルを既存の認証データベースに対して使用することができ、これらのレガシープロトコルのセキュリティを盗聴、中間者、およびその他の攻撃から保護します。
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-TTLのユーザーは、この拡張機能を採用することを強くお勧めします。
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.
この脆弱性は長い間理解されてきましたが、実際に盗聴する攻撃がありそうにない環境では大きな関心事ではありませんでした。たとえば、サービスプロバイダーへの有線またはダイヤルアップ接続を持つユーザーは、そのような接続が監視されることを心配していません。また、ユーザーは自分のパスワードをサービスプロバイダーに委ねることをいとわない、または少なくともサービスプロバイダーが課題とハッシュされた応答を表示できるようにして、その後、プロキシ半径を使用して自宅認証サーバーに転送されることを許可しています。プロバイダーは、観測された資格情報に辞書攻撃をマウントします。ユーザーは通常、単一のサービスプロバイダーと関係があるため、そのような信頼は完全に管理可能です。
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.
- ワイヤレス接続は、盗聴や中間の攻撃の影響を受けやすくなります。これらの攻撃により、低エントロピーパスワードに対する辞書攻撃が可能になる場合があります。さらに、チャンネルハイジャックを可能にする場合があります。チャンネルハイジャックでは、攻撃者が認証が完了した後に通信チャネルの制御を押収することにより不正なアクセスを獲得します。
- 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.
- ユーザーのIDは、クライアントノードと信頼できるサービスプロバイダーの間の通信チャネルで観察できないようにして、ユーザーを監視、望ましくないマーケティング情報の取得などから保護する必要があります。
- 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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サーバーとの通信に使用されるネットワークプロトコル。例には、半径と直径が含まれます。
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.
1つ以上の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
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.
通常、NAIのレルム部分に基づいて、おそらく別のドメイン内の適切なAAAサーバーにAAAトランザクションをルーティングできるサーバー。
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サーバーは、半径や直径などの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は、クライアントとアクセスポイントの間のキャリアプロトコルを介して開始する必要があります。たとえば、PPPまたはEapolでは、アクセスポイントがEAP-Request/IDパケットをクライアントに送信したときに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-Request/IDを発行し、EAP応答/IDで応答します。クライアントは、ルーティングの目的以外のこのEAP応答/IDパケットにユーザーの実際のIDを含める必要はないことに注意してください（例：レルム情報;セクション7.3および[RFC3748]、セクション5.1を参照）。ユーザーの実際のIDは、暗号化されたチャネルが確立されるまで送信する必要はありません。
The access point now acts as a passthrough device, allowing the TTLS server to negotiate EAP-TTLS with the client directly.
アクセスポイントはパススルーデバイスとして機能し、TTLSサーバーがクライアントと直接EAP-TTLをネゴシエートできるようにします。
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.
交渉の第1フェーズでは、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.
交渉の第2段階では、クライアントと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サーバーは、これらのデバイス間の既存のセキュリティ関連（半径など）に基づいて暗号化されたアクセスポイントにこのキーイング資料を送信する場合があります。
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-TTLはユーザーの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パケット自体はTLSをカプセル化します。TLSは、ユーザー認証またはその他の情報を運ぶ可能性のある属性値ペア（AVP）をカプセル化するために使用されます。したがって、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.
A EAP-TTLS negotiation comprises two phases: the TLS handshake phase and the TLS tunnel phase.
EAP-TTLS交渉は、TLSハンドシェイクフェーズとTLSトンネルフェーズの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サーバーに認証します。フェーズ1の結果、暗号スイートがアクティブ化され、フェーズ2がTLSレコードレイヤーを使用して安全に進むことができます。（フェーズ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）を介して交換されます。したがって、このような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は、フェーズ2でユーザー認証の実行方法を指定します。ユーザー認証自体がEAPであるか、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/STARTパケットを使用してEAP-TTLSメソッドを開始します。これは、Type = EAP-TTLSとS（Start）ビットセットを備えたEAP-Requestです。これは、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.
[RFC5216]に記載されているように、TLSハンドシェイクを完了するために、EAPパケットは引き続きクライアントサーバーとTTLSサーバー間で交換されます。フェーズ1は、クライアントとTTLSサーバーがChangeciphersPecと完了したメッセージを交換するときに完了します。この時点で、追加情報が安全にトンネリングされる場合があります。
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の間にあらゆる種類の情報を交換することができます。（EAP-TTLSを使用するアプリケーションは、どの情報を交換する必要があるかを指定し、したがってどのAVPをサポートする必要があるかが予想されます。）クライアントは、AVPのシーケンスで情報をエンコードし、このシーケンスをTLSレコードレイヤーに渡すことにより、フェーズ2交換を開始することが期待されます。暗号化用、結果のデータを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サーバーは、独自のAVPSシーケンスで応答する場合があります。TTLSサーバーは、暗号化のためにAVPシーケンスをTLSレコードレイヤーに渡し、結果のデータをクライアントに送信します。たとえば、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-SUCSESまたはEAP-Failureが発生しますクライアントに送信される）。
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".
ユーザーのIDは、TLSトンネルによって保護されているフェーズ2で提供されます。ただし、EAP-TTLS認証を開始する前に、クライアントは通常、EAPプロトコルの一部としてEAP Response/IDパケットを発行し、クリアテキストにユーザー名を含みます。盗聴に対するユーザーの匿名性を保持するために、このパケットは特にユーザーの実際の名前を含めるべきではありません。代わりに、「匿名」などの空白またはプレースホルダーを使用する必要があります。ただし、このプライバシーの制約は、ルーティングに必要なEAP応答/アイデンティティ内の情報に適用することを意図していません。したがって、EAP応答/IDパケットには、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応答/IDパケットが送信された時点で、EAPメソッドはまだ交渉されていないことに注意してください。EAP-TTLSに加えて、クライアントがユーザーの匿名性をサポートしないEAPメソッドの使用を交渉することをいとわない場合、クライアントはEAP応答/IDにユーザーの名前を含めて、他の人の要件を満たすことができます候補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.
2つのフェーズの観点から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 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.
このような「ピギーバック」は、握手を完了するパーティーにも送信するAVPがあるときに発生します。たとえば、再開されたTLSセッションを交渉するとき、TTLSサーバーは最初にChangeciphersPecと完成したメッセージを送信し、次にクライアントは独自のChangeciphersPecを送信し、メッセージを完成させて握手を終了します。クライアントがTTLSサーバーに送信する認証または他のAVPを持っている場合、完成したメッセージの直後に同じEAP-TTLSパケット内のそれらのAVPをトンネルする必要があります。クライアントがこれを行わなかった場合、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サーバーは、独自の構成に基づいて、またはAAA/Hから受け取ったセッション制限情報（たとえば、RADIUS SESSION-TIMEOUT属性など）に基づいてセッションを古くないと考えることができます。
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サーバーはそのオプションで、AVPSをクライアントに送信して非認証関数を開始するか、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によって返された承認情報を保持する必要があります。再開されたセッションは、元のセッションと同じ承認の下で動作する必要があり、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.
- 追加の認証または情報交換は必要ありません。
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).
クライアントは、フェーズ1の完了時にフェーズ2を開始する最初の機会を常に持っています。クライアントに送信するAVPがない場合、TTLSサーバーが最終フェーズ1メッセージを送信する場合、確認（セクション9.2.3を参照）を送信します。最終フェーズ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サーバーも、交換するための追加情報を持っていません。クライアントは、フェーズ2 AVPSをピギーバックせずにフェーズ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 AVPSをピギーバックなしでフェーズ1を完了しますが、TTLSサーバーは、次のEAP-TTLSメッセージでAVPをトンネリングすることにより、EAP-TTLS交渉をフェーズ2に拡張します。
- 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.
- クライアントには、交換するための追加情報があり、最終フェーズ1メッセージでフェーズ2 AVPSをピギーバックし、交渉をフェーズ2に拡張します。
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は、擬似ランダム関数（PRF）を利用してキーイング材料を生成し（セクション8）、特定の認証方法に暗黙的なチャレンジ材料を生成します（セクション11.1）。これらの計算で使用される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バージョン1.0 [RFC2246]および1.1 [RFC4346]は同じPRF関数を定義し、これらのバージョンのTLSに基づくEAP-TTLSV0実装は、そこに定義されたPRFを使用する必要があります。TLSプロトコルの将来のバージョンまたは拡張機能により、代替PRF関数が交渉できるようになることが予想されます。基礎となるTLSバージョンに代替PRF関数が指定されているか、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を構成し、2番目の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.
キーイング材料は、TLS PRF関数[RFC4346]を使用して生成され、TLS Master Secret、Ascii-Encoded Constant String "TTLSキーイング素材」、TLSクライアントランダム、TLSサーバーランダムで構成されます。定数文字列はヌル終端ではありません。
Keying Material = PRF-128(SecurityParameters.master_secret, "ttls keying material", SecurityParameters.client_random + SecurityParameters.server_random)
キーイングマテリアル= PRF-128（SecurityParameters.Master_Secret、 "TTLSキーイングマテリアル"、SecurityParameters.Client_Random SecurityParameters.Server_Random）
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]の重要な派生方法に従います。ランダムの順序を変更すると、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キャリアプロトコルを介してアクセスポイントに配布します。半径がAAAキャリアプロトコルである場合、MPPE-RECV-KEYおよびMPPE-SEND-KEY属性[RFC2548]を使用して、それぞれMSKの最初の32オクテットと2番目の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.
リクエストのコード1、応答用2。
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オクテットで、コードフィールドからデータフィールドを介して、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 = start r = reserved v = version（000 for eap-ttlsv0）
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メッセージシーケンスまたはそのフラグメントで構成されています。開始パケットの場合、データフィールドにはオプションで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の形式の追加情報が含まれている場合があり、クライアントに便利なヒントを提供する場合があります。たとえば、サーバーのアイデンティティは、セッション再開のために正しい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のバージョンは、サーバーとクライアントの間の最初の交換で交渉されます。サーバーは、開始メッセージのVフィールドでサポートするEAP-TTLの最高バージョン数を設定します（EAP-TTLSV0の場合、これは0です）。応答した最初のEAPメッセージで、クライアントは、サーバーが提供するバージョン番号よりも高くないサポートする最高のバージョン番号にVフィールドを設定します。クライアントバージョンがサーバーに受け入れられない場合、EAPセッションを終了するためにEAPフェイルを送信します。それ以外の場合、クライアントが送信したバージョンは、使用する必要があるEAP-TTLのバージョンであり、サーバーとクライアントの両方がVフィールドをその後のすべてのEAPメッセージのバージョン番号に設定する必要があります。
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ビットセットを持たないでください。fragmented -fragmentedメッセージには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.)
確認パケットは、Flags Octetを超えて追加データがなく、フラグのL、M、およびSビットが0に設定されたEAP-TTLSパケットであり、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-SUCSESSまたは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形式は、直径AVP形式と互換性があります。これは、EAP-TTLS交渉に参加しているデバイスまたはサーバーのいずれかによって直径がサポートされるという要件を表すものではありません。この形式の使用は、単なる便利さです。直径は半径のスーパーセットであり、定義上、半径属性名空間を含みますが、半径と同様にAVPのサイズを制限しません。RADIUSは、EAPを含む一般的に使用されるすべてのパスワード認証プロトコルに対して、広く展開されているAAAプロトコルと属性定義が存在します。
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サーバーは、クライアントと通信するために使用するAVPと広く展開されているAAAサーバーのプロトコル要件を簡単に翻訳できます。さらに、ベンダーが特定の要件のためにその名前空間を拡張できるように、よく理解されているメカニズムを提供します。
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コードは、直径、さらにはradiusで行うのと同じ意味でほぼ同じ意味を持つことが予想されます。ただし、EAP-TTLSは直径と同じAVPコードと構文を使用しますが、セマンティクスは異なる場合があり、ほとんどの直径AVPにはEAP-TTLに明確に定義されたセマンティクスはありません。個別の「EAP-TTLS AVP使用」レジストリには、EAP-TTLS内で使用できるAVPとこのコンテキストでのセマンティクスがリストされています（詳細についてはセクション16を参照）。EAP-TTLS交換とバックエンドとの直径または半径の交換の間でAVPをコピーするTTLSサーバーは、EAP-TTLSまたはバックエンドプロトコルのいずれかで使用されていないAVPについて仮定してはなりません。したがって、TTLSサーバーは、AVPのセマンティクスが両方のコンテキストで理解および定義されていない限り、EAP-TTLS交換と直径または半径交換の間に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コードは4オクテットで、存在する場合はベンダーIDフィールドと組み合わせて、属性を一意に識別します。最初の256 AVP番号は、半径[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フラグ、ベンダーID（存在する場合）、およびデータを含むこのAVPの長さを示します。
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を定義するベンダーは、半径、直径、およびEAP-TTL内でこれらの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の機能を拡張するための手段を提供することに注意してください。適切なAVPのMビットを0または1に設定することにより、関数を開始する当事者は、相手による関数のサポートがオプションまたは必要であることを示します。
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は、半径に対して定義された一連の属性から選択する必要があります。つまり、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は、半径の観点から定義する必要があります。ベンダー固有の半径属性は、直径（したがって、EAP-TTL）に自動的に変換されます。逆は真実ではありません。RADIUSベンダー固有の属性は、RADIUS属性26を使用し、ベンダーID、ベンダー固有の属性コード、および長さを含みます。詳細については、[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サーバーの間のTLSレコードレイヤー内でトンネル化され、クライアントとTTLSサーバー間のアクティブおよびパッシブ攻撃に対する認証情報のセキュリティを確保します。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 challenge"、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キャリアプロトコルとして半径を使用していると想定されています。ただし、これは要件ではなく、必要な情報を運ぶことができる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を利用することに注意してください。半径と直径は、ベンダー固有のAVPのエンコードが異なります。RADIUSはベンダー固有の属性（コード26）を使用し、直径はVビットの設定を使用してベンダーIDの存在を示します。ベンダー固有の属性の半径形式は、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がトンネル付き認証プロトコルである場合、TLSレコードレイヤーを介してトンネリングする前に、クライアントとTTLSサーバーの間の各トンネリングEAPパケットが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.
直径AVPは253オクテットのデータに限定されないため、半径属性と同様に、複数のEAPメッセージ属性を連結して253より長いOCTET EAPパケットを表すことは、EAP-TTLSでは適切ではないことに注意してください。したがって、単一の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:
クライアントは、EAP応答/アイデンティティをTTLSサーバーにトンネリングすることにより、EAPを開始します。内部方法で指定された要件に応じて、クライアントはこのパケットに実際のユーザー名を配置することができます。ユーザーのIDのプライバシーは、TLS暗号化によって保証されます。このユーザー名は通常、ネットワークアクセス識別子（NAI）[RFC4282]です。つまり、通常、次の形式です。
username@realm
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サーバーがEAPパケットを適切なAAA/Hに転送できるようにするために使用されます。
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を開始する前に、最初の、最初の、目つれたEAP応答/IDパケットで最初に、TTLSサーバーの領域を示します。2番目は、EAP-TTLSトンネル内のEAP交換の一部として発生するもので、クライアントのホームネットワークの領域を示しています。したがって、アクセスポイントは、TTLSサーバーの領域にルーティングする方法を知る必要があります。TTLSサーバーは、クライアントのホームレルムへのルーティング方法を知っていると想定されています。このシリアルルーティングアーキテクチャは、ローミング環境に役立つと予想されており、アクセスポイントまたはアクセスポイントの背後にあるAAAプロキシを少数の領域でのみ構成できます。（EAP Response/Identity PacketsのAntnneledおよびTunneledバージョンを区別する追加情報については、セクション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-UNAWARE EAPプロトコルの実行でさえ使用できます。これは、クライアントとAAAサーバーの間で操作するときに認証器が行うことに似ています。
Upon receipt of the tunneled EAP-Response/Identity, the TTLS server forwards it to the AAA/H in a RADIUS Access-Request.
TTLSサーバーは、トンネル付きのEAP応答/アイデンティティを受信すると、RADIUS Access-RequestでAAA/Hに転送します。
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をサポートしている場合、AAA/Hが望むEAPプロトコルに従ってタイプとタイプデータフィールドを設定して、EAP要求を含むアクセスチャレンジで応答します。クライアントを認証します。たとえば、MD5-チャレンジ、1回限りのパスワード（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.
[RFC3748]で説明されているように、クライアントとAAA/Hの間のEAP認証は正常に進行し、TTLSサーバーはパススルーデバイスとして機能します。アクセスチャレンジでAAA/Hによって送信された各EAP-Requestは、TTLSサーバーによってクライアントにトンネル化され、クライアントによってトンネルが付けられた各EAP応答は、TTLSサーバーによってAAA/HにアクセスのAAA/Hに復号化および転送されます-リクエスト。
This process continues until the AAA/H issues an Access-Accept or Access-Reject.
このプロセスは、AAA/Hがアクセスacceptまたはアクセス抵抗を発行するまで続きます。
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-Challenge [16オクテット] Chap Identifier [1 Octet]
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 CHAP Identifier, taken from the challenge material; and CHAP response, computed according to the CHAP algorithm.
クライアントは、TTLSサーバーにTunneling User-Name、Chap-Challenge、およびChap-Password AVPSによってCHAPを開始します。Chap-Challengeの価値は、チャレンジマテリアルから取得されます。チャップパスワードは、チャレンジマテリアルから取られた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-Challenge AVPの値とChap-Password AVPのChap Identifierの値がチャレンジ資料として生成された値に等しいことを確認する必要があります。いずれかのアイテムが正確に一致しない場合、TTLSサーバーはクライアントを拒否する必要があります。それ以外の場合は、AVPをACASE-REQUESTでAAA/Hに転送します。
The AAA/H will respond with an Access-Accept or Access-Reject.
AAA/Hは、アクセスacceptまたはアクセス抵抗で応答します。
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-challenge [8オクテット]識別[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サーバーにUser-Name、MS-Chap-Challenge、MS-Chap-Response AVPをトンネリングすることにより、MS-Chapを開始します。MS-Chap-Challenge値は、チャレンジマテリアルから取得されます。MS-Chap-Responseは、チャレンジ素材から取られた識別で構成されています。クライアントの設定に従って設定されたフラグ。MS-Chapアルゴリズムに従って計算されたLM応答とNT応答。
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-Challenge AVPの値とクライアントのMS-Chap-Response AVPのIDEの値がチャレンジ素材として生成された値に等しいことを確認する必要があります。いずれかのアイテムが正確に一致しない場合、TTLSサーバーはクライアントを拒否する必要があります。それ以外の場合は、AVPをACASE-REQUESTでAAA/Hに転送します。
The AAA/H will respond with an Access-Accept or Access-Reject.
AAA/Hは、アクセスacceptまたはアクセス抵抗で応答します。
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-challenge [16オクテット]識別[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-Challenge、およびMS-Chap2-Response AVPをトンネリングすることにより、MS-Chap-V2を開始します。MS-Chap-Challenge値は、チャレンジマテリアルから取得されます。MS-Chap2-responseは、チャレンジ素材から取られた識別で構成されています。フラグ、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-Challenge AVPの値とクライアントのMS-Chap2応答AVPの識別の値がチャレンジ素材として生成された値に等しいことを確認する必要があります。いずれかのアイテムが正確に一致しない場合、TTLSサーバーはクライアントを拒否する必要があります。それ以外の場合は、AVPをACASE-REQUESTでAAA/Hに転送します。
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-SUCCESS属性を含むアクセスアセプトで応答します。この属性には、ピアチャレンジに基づいて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-SUCSESS AVPを受信すると、クライアントはAAA/Hを認証できます。認証が成功した場合、クライアントはデータを含む（つまり、ゼロ長データフィールド）を含むEAP-TTLSパケットを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-Error属性を含むアクセスチャレンジで応答します。この属性には、新しい識別と、エラー理由や再試行が許可されるかなどの追加情報を含む文字列が含まれています。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.
クライアントがパスワードを変更したい場合は、MS-Chap-NT-enc-PW、MS-CHAP2-CPW、およびMS-Chap-Challenge AVPSをTTLSサーバーにトンネルします。MS-CHAP2-CPW AVPは、MS-Chap-Error AVPで受け取った新しい識別と課題から派生しています。MS-Chap-Challenge 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-Challenge AVPの値とクライアントのMS-Chap2-CPW AVPの識別の値がMS-Chapで送信された値と一致することを確認する必要があります。 - エラーAVP。いずれかのアイテムが正確に一致しない場合、TTLSサーバーはクライアントを拒否する必要があります。それ以外の場合は、AVPをACASE-REQUESTでAAA/Hに転送します。
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-SUCCESS属性を含むアクセスアセプトで応答します。この時点で、交渉は上記のように進行します。TTLSサーバーは、MS-CHAP2-SUCCESSをクライアントにトンネルし、クライアントはこのAVPに基づいてAAA/Hを認証します。次に、クライアントは失敗時に交渉を放棄するか、データを含むTTLSサーバーにEAP-TTLSパケットを送信します（つまり、長さのデータフィールドがゼロ）、TTLSサーバーはMS-CHAP-V2認証を検討します成功したこと。
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-Domain。TTLSサーバーは、MS-CHAP2-成功とともに、このような認証関連属性をトンネルする必要があります。
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.
ただし、EAP-TTLSクライアントは、そのような半径変数が利用できないため、パスワードをRADIUSで暗号化することはありません。とにかくパスワードはTLSを介して暗号化されるため、これはセキュリティの弱点ではありません。ただし、クライアントは、その長さを難読化するために、パスワードを16オクテットの倍数にnull-padする必要があります。
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に転送します。（Access-Requestでは、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は、アクセスacceptまたはアクセス抵抗ですぐに応答する場合があります。TTLSサーバーは、AAAキャリアプロトコルを使用してアクセスポイントにEAP-Successまたは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の挑戦からクライアントへのAVPSをトンネルします。これらのAVPを受け取ると、クライアントのトンネルユーザー名とユーザーパスワードが再び、ユーザーパスワードにチャレンジに応じて新しい情報を含みます。このプロセスは、AAA/Hがアクセスacceptまたはアクセス抵抗を発行するまで続きます。
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の少なくとも1つは、返信メッセージでなければなりません。通常、これはチャレンジの一部としてAAA/Hによって送信されます。ただし、AAA/Hが返信メッセージを送信していない場合、TTLSサーバーはNULL値で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がアクセスACCEPTまたはAccess-Rejectの一部として応答メッセージを含めている場合、TTLSサーバーはこのAVPをクライアントにトンネルしないことに注意してください。むしろ、ACACE-ACCEPTまたはACCESS-REJECTの一部としてAAA/Hによって送信されたこのAVPおよびその他すべての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-Challengeを実行するAAA/Hは、一般的なトークンカードを実行したいと考えています。最初にEAP-Request/MD5-Challengeを発行し、応答を受け取ります。応答が満足のいく場合、EAP-Request/Generic Tokenカードを発行して応答を受信します。その応答も満足のいくものであれば、ユーザーを受け入れます。
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シーケンスと見なされます。これは、次の各リクエストが、1つの認証が完了して別の認証が開始されている場合でも、前の要求とは異なる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タイプが変更されない場合に新しい認証が開始されるかを判断することができないため、同じEAPメソッドを2回連続で使用することは必ずしも実行可能ではないことに注意してください。EAP-TLSなどの特定のEAPメソッドは、スタートビットを使用して最初のリクエストを区別するため、そのタイプを使用して各新しい認証を以前と区別できるようにします。EAP-MS-Chap-V2などの他の方法は、明確に定義された方法で終了し、同じタイプの2番目の認証が明確に開始できるようにします。複数の認証に同じ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をトンネル認証方法として実装し、MD5-ChallengeをEAPタイプとして実装する必要があります。ただし、このような実装により、EAP、EAPタイプ、またはその他のトンネル認証方法を使用することができます。
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]に準拠して、Session-ID、Peer-ID、およびServer-IDがここで定義されています。
The Session-Id uniquely identifies an authentication exchange between the client and TTLS server. It is defined as follows:
Session-IDは、クライアントとTTLSサーバーの間の認証交換を一意に識別します。次のように定義されています。
Session-Id = 0x15 || client.random || server.random
session-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.
Peer-IDは、アクセス制御および会計目的で使用されるアイデンティティを表します。クライアントがTLSハンドシェイクの一部として証明書を提示すると、PEER-IDは[RFC5216]のセクション5.2で指定されているように、証明書の情報に基づいて決定されます。それ以外の場合、Peer-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.
Server-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 Plus Plus arbitraryary追加の追加認証（S）Ciphersuite交渉：はい相互認証：はい、推奨される実装整合性保護：はいリプレイ保護：はい機密性：はいキー派生：最大384ビット辞書辞書攻撃PROT。：はい高速再接続：はい暗号化バインディング：セッションの独立性：はい断片化：はいチャネルバインディング：いいえ
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のクライアントに認証され、クライアントはフェーズ2のAAA/Hサーバーに認証されます。TTLSサーバーのフェーズ1認証は通常、証明書によるものです。クライアントは、オプションで証明書によってTTLSサーバーに認証することもできます。AAA/Hサーバーへのクライアントのフェーズ2認証は、通常、EAPまたはサポートされている非EAP認証メカニズムを介したパスワードまたはセキュリティトークンによるものです。この認証メカニズムは、AAA/Hサーバーの認証をクライアントにも提供する場合があります（相互認証）。
Ciphersuite negotiation is inherited from TLS.
Ciphersuiteの交渉は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のクライアントに認証され、クライアントとAA/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マスターシークレットのサイズによって制限されます。交渉済みのDiffie-Helman（DH）グループ、証明書RSA/DSAグループなどの攻撃抵抗に応じて、効果的なキー強度は少ない場合があります。BITSの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メソッドとして、また反目的メソッドとして使用することを避けるように注意する必要があります。
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ハンドシェイクによって生成されるキーイング材料の暗号化結合を実行するために定義する必要があります。これにより、重要な内部の方法で使用される場合、中間の問題が回避されます。このような拡張メカニズムが提案されています[TTLS-Ext]。
TLS guarantees the session independence of its master secret, from which the EAP-TTLSv0 MSK/EMSK is derived.
TLSは、Master Secretのセッション独立性を保証し、そこから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応答/IDのCLEARでユーザー名を通知しません。この機能は、クライアントとTTLSサーバーの間のネットワークパスを盗聴する攻撃者からの匿名性とロケーションプライバシーをサポートするように設計されています。ただし、実装者は、EAP-TTLと他の場所の両方で他の要因がユーザーの身元を損なう可能性があることを認識する必要があります。たとえば、ユーザーがEAP-TTLSのフェーズ1で証明書で認証する場合、証明書の件名にユーザーの身元が明らかになる場合があります。EAP-TTLS以外では、クライアントの固定MACアドレス、またはワイヤレス接続の場合、クライアントのラジオ署名も情報を明らかにする場合があります。さらに、実装者は、ユーザーのIDがEAP-TTLSサーバーから隠されておらず、アクセスポイント、EAP-TTLSサーバー、およびAAA/Hサーバーの間のAAAメッセージに含まれる可能性があることに注意する必要があります。
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を発行して、2秒の暗号化された握手を開始し、その間にクライアントが証明書リストを送信します。この機能は、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ハンドシェイク中に伝えられるサーバー証明書を介して確立されます。クライアントには、どのサーバーIDが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拡張機能の欠如またはayextededKeyUsageの値は、証明書の目的に制約がないことを意味することに注意してください。
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 Key Exchangeは、前方の秘密を提供するアルゴリズムの例です。録音された認証またはデータセッションに対する攻撃が重大な脅威をもたらすと見なされる場合、将来の秘密アルゴリズムを考慮する必要があります。
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で提案されたプロトコルバージョンのTTLSサーバーの繰り返しである可能性があります。このようなAVPは、バージョン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は、巻き毛の装具（{}）に囲まれています。オプションのアイテムには、疑問符が付いています（？）。複数回表示される可能性のあるアイテムには、Plus Sign（）が付いています。
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-Challengeはトンネリングユーザー認証メカニズムとして使用されます。
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（小数）を割り当てました。新しい半径と直径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は半径または直径についてすでに定義されているにもかかわらず、各個々の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 AVP使用）の作成が必要です。これは、EAP-TTLS内で使用するために定義されている各非ベンダー固有の半径/直径AVPをリファレンスとともにリストします。そのセマンティクスを指定するRFCまたはその他のドキュメントに。AVPの最初のリストは、このドキュメントのセクション13にリストされているものとするものとします。このレジストリの目的は、異なる機能的コンテキストで同じAVPが利用されていることから生じる潜在的なあいまいさを回避することです。[RFC2865]および[RFC3588]で概説されているように、AVP番号は半径と直径の名前空間から割り当てられているため、このレジストリはAVPに番号を割り当てません。トップレベルのAVPのみ、つまりAVPがグループ化されたAVP内にカプセル化されていない - のみが登録されます。[RFC5226]で定義されているIETFレビューに基づいて、AVPをこのレジストリに追加する必要があります。
Thanks to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen Hanna, Ryan Hurst, Avi Lior, and Gabriel Montenegro for careful reviews and useful comments.
Bernard Aboba、Jari Arkko、Lakshminath Dondeti、Stephen Hanna、Ryan Hurst、Avi Lior、Gabriel Montenegroに慎重なレビューと有用なコメントをありがとう。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433] Zorn、G。およびS. Cobb、「Microsoft PPP Chap Extensions」、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] Zorn、G。、「Microsoft Vendor固有のRADIUS属性」、RFC 2548、1999年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759] Zorn、G。、「Microsoft PPP Chap Extensions、バージョン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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232] Reynolds、J.、ed。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、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.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Simon、D.、Aboba、B。、およびR. Hurst、「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.、Simon、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 Standard 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）仕様」、IEEEE標準802.11、2007。
[TTLS-EXT] Hanna, S. and P. Funk, "Key Agility Extensions for EAP-TTLSv0", Work in Progress, September 2007.
[TTLS-Ext] Hanna、S。およびP. Funk、「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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、and W. Polk、 "Internet 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] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、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] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、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.、Niemi、V。、およびNyberg、K。、「トンネル認証の中で中間者」、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
Paul Funk 43 Linnaean St. Cambridge、MA 02138メール：paulfunk@alum.mit.edu
Simon Blake-Wilson SafeNet Amstelveenseweg 88-90 1054XV, Amsterdam The Netherlands EMail: sblakewilson@nl.safenet-inc.com
Simon Blake-Wilson SafeNet AmstelveenseWeg 88-90 1054XV、AMSTERDAMオランダの電子メール：sblakewilson@nl.safenet-inc.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。