RFC5281 日本語訳
5281 Extensible Authentication Protocol Tunneled Transport LayerSecurity Authenticated Protocol Version 0 (EAP-TTLSv0). P. Funk, S.Blake-Wilson. August 2008. (Format: TXT=117059 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Funk
Request for Comments: 5281 Unaffiliated
Category: Informational S. Blake-Wilson
SafeNet
August 2008
コメントを求めるワーキンググループP.ファンク要求をネットワークでつないでください: 5281年の属しないカテゴリ: 情報のS.ブレーク-ウィルソンSafeNet2008年8月
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(輸送Layer Security)セッションをカプセル化するEAP(拡張認証プロトコル)メソッドです、握手フェーズとデータフェーズから成って。 aは暗号でトンネルを固定します。握手段階の間、サーバが標準のTLS手順を用いることでクライアント(クライアントとサーバは互いに認証される)に認証されて、材料を合わせるのが発生している、作成、順次データフェーズにおける情報交換のために。 データ段階の間、クライアントは、安全なトンネルの中でカプセル化された任意の認証機構を使用することでサーバ(クライアントとサーバは互いに認証される)に認証されます。 カプセル化された認証機構がそうするかもしれない、それ自体、EAPになりなさいか、またはそれはPAP、CHAP、さん-CHAP、またはCHAP-V2さんなどの別の認証プロトコルであるかもしれません。 したがって、EAP-TTLSは、盗聴、中央の人、および他の攻撃に対してこれらのレガシープロトコルのセキュリティを保護している間、レガシーのパスワードベースの認証プロトコルが既存の認証データベースに対して使用されるのを許容します。 また、データフェーズは追加していて、任意のデータ交換に使用されるかもしれません。
Funk & Blake-Wilson Informational [Page 1] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[1ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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
1. 序論…4 2. 動機…5 3. 要件言語…7 4. 用語…7 5. 建築モデル…9 5.1. キャリヤープロトコル…10 5.2. セキュリティ関係…10 5.3. メッセージング…11 5.4. 結果として起こるセキュリティ…12 6. モデルを層にして、議定書を作ってください…12 7. EAP-TTLS概要…13 7.1. フェーズ1: 握手…14 7.2. フェーズ2: トンネルを堀ってください…14 7.3. EAPアイデンティティ情報…15 7.4. 便乗します…15 7.5. セッション再開…16 7.6. フェーズ2に入るかどうか決定します…17 7.7. TLSバージョン…18 7.8. TLS PRFの使用…18 8. 材料を合わせながら、生成します。19 9. EAP-TTLSは議定書を作ります…20 9.1. パケット形式…20 9.2. EAP-TTLSはパケットを始めます…21 9.2.1. バージョン交渉…21 9.2.2. 断片化…22 9.2.3. 承認パケット…22 10. TLSの記録的な層の中のAVPsのカプセル化…23 10.1. AVP形式…23 10.2. AVP系列…25 10.3. AAAサーバとの最大の互換性のためのガイドライン…25 11. 認証にトンネルを堀ります…26 11.1. 暗黙の挑戦…26 11.2. 認証プロトコルにトンネルを堀ります…27 11.2.1. EAP…27 11.2.2. ひびが切れてください…29 11.2.3. さんと同じくらいひびが切れてください…30 11.2.4. やつV2さん…30 11.2.5. 乳首…32 11.3. 複数の認証を実行します…33 11.4. 義務的なトンネルを堀られた認証サポート…34 11.5. 追加提案されたトンネルを堀られた認証サポート…34 12. フレームワークを合わせます…35 12.1. セッションイド…35 12.2. 同輩イド…35 12.3. サーバイド…35 13. AVP概要…35
Funk & Blake-Wilson Informational [Page 2] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[2ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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
14. セキュリティ問題…36 14.1. セキュリティクレーム…36 14.1.1. 認証メカニズム…36 14.1.2. Ciphersuite交渉…37 14.1.3. 互いの認証…37 14.1.4. 保全保護…37 14.1.5. 保護を再演してください…37 14.1.6. 秘密性…37 14.1.7. キー派生…37 14.1.8. 主要な強さ…37 14.1.9. 辞書攻撃保護…38 14.1.10. 速く再接続してください…38 14.1.11. 暗号の結合…38 14.1.12. セッション独立…38 14.1.13. 断片化…38 14.1.14. 拘束力があった状態で、精神を集中してください…38 14.2. クライアント匿名…38 14.3. サーバ信頼…39 14.4. 合法化を証明してください…39 14.5. 感染を証明してください…40 14.6. 秘密保持を進めてください…40 14.7. 下に交渉は攻撃されます…40 15. メッセージ系列…41 15.1. Tunneled CHAPを通したうまくいっているAuthentication…41 15.2. Tunneled EAP/MD5-挑戦を通したうまくいっているAuthentication…43 15.3. うまくいっているセッション再開…46 16. IANA問題…47 17. 承認…48 18. 参照…48 18.1. 標準の参照…48 18.2. 有益な参照…49
Funk & Blake-Wilson Informational [Page 3] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[3ページ]情報のRFC5281EAP-TTLSv0 2008年8月
1. Introduction
1. 序論
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].
輸送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]、Diameter[RFC3588]、または他のAAAサーバによってアクセスされるかもしれない資格証明データベースの形にはこれらのプロトコルのサポートの大きいインストールされたベースがあります。 これらはPAP[RFC1661]、CHAP[RFC1661]、さん-CHAP[RFC2433]、またはCHAP-V2さん[RFC2759]などの非EAPプロトコルを含んでいます、MD5-挑戦[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-TTLSのユーザが彼らの展開でこれらを考えるよう強く奨励されます。
In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP-TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP- TTLS, the TLS authentication may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely deployed authentication infrastructures. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2.
EAP-TLSでは、TLS握手は、互いにクライアントとサーバを認証するのに使用されます。EAP-TTLSは、クライアントとサーバの間で追加情報を交換するためにTLS握手で確立された安全な接続を使用することによって、この認証交渉を広げています。EAP- TTLSでは、TLS認証は互いであるかもしれません。 または、唯一のサーバがどれであるかでクライアントに認証されて、それは一方向であるかもしれません。 そして、握手で確立された安全な接続は、サーバがクライアントを認証するのを既存の、そして、広く配布している認証インフラストラクチャを使用することで許容するのに使用されるかもしれません。 クライアントの認証がそうするかもしれない、それ自体、EAPになりなさいか、またはそれはPAP、CHAP、さん-CHAPまたはさん-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-TTLSは、盗聴、中央の人、および他の攻撃に対してこれらのレガシープロトコルのセキュリティを保護している間、レガシーのパスワードベースの認証プロトコルが既存の認証データベースに対して使用されるのを許容します。
Funk & Blake-Wilson Informational [Page 4] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[4ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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の中で暗号化された属性値組を使用することで交信します。 認証を超えた任意の機能と主要な交換はこの一般性でEAP交渉に加えます、AAAインフラストラクチャとのコンパチブル方法で。
The main limitation of EAP-TTLS is that its base version lacks support for cryptographic binding between the outer and inner authentication. Please refer to Section 14.1.11 for details and the conditions where this vulnerability exists. It should be noted that an extension for EAP-TTLS [TTLS-EXT] fixed this vulnerability. Users of EAP-TTLS are strongly encouraged to adopt this extension.
EAP-TTLSの主な限界は基本版が外側の、そして、内側の認証の間で暗号の結合のサポートを欠いているということです。 詳細と状態についてこの脆弱性が存在するところをセクション14.1.11を参照してください。 EAP-TTLS[TTLS-EXT]のための拡大がこの脆弱性を修理したことに注意されるべきです。 EAP-TTLSのユーザがこの拡大を採用するよう強く奨励されます。
2. Motivation
2. 動機
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、さん-CHAP、さん-CHAP-V2、EAP/MD5挑戦、および1EAP/回のPasswordについて説明します。
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.
そのようなアプローチの問題は挑戦と応答の両方を観測する立ち聞きする者が辞書攻撃を仕掛けることができるかもしれないということです。(そこでは、無作為のパスワードが1つを見つけるのを試みる知られている応答をもたらす知られている挑戦に対してテストされます)。 パスワードには低エントロピーが通常あるので、そのような攻撃は実際には容易に多くのパスワードを発見できます。
While this vulnerability has long been understood, it has not been of great concern in environments where eavesdropping attacks are unlikely in practice. For example, users with wired or dial-up connections to their service providers have not been concerned that such connections may be monitored. Users have also been willing to entrust their passwords to their service providers, or at least to allow their service providers to view challenges and hashed responses which are then forwarded to their home authentication servers using, for example, proxy RADIUS, without fear that the service provider will mount dictionary attacks on the observed credentials. Because a user typically has a relationship with a single service provider, such trust is entirely manageable.
この脆弱性は長い間理解されていますが、それは盗聴攻撃が実際にはありそうもないところの環境における大きな心配のものではありません。 例えば、彼らのサービスプロバイダーとのワイヤードであるかダイヤルアップ接続のユーザはそのような接続がモニターされるかもしれないことを心配していませんでした。 ユーザは、また、それらのサービスプロバイダーに彼らのパスワードを任せるか、またはそれらのサービスプロバイダーが挑戦を見るのを少なくとも許容することを望んで、次に例えばプロキシRADIUSを使用することでそれらのホーム認証サーバに送られる応答を論じ尽くしました、サービスプロバイダーが観測された資格証明書に辞書攻撃を仕掛けるという恐れなしで。 ユーザにはただ一つのサービスプロバイダーとの関係が通常あるので、そのような信頼は完全に処理しやすいです。
Funk & Blake-Wilson Informational [Page 5] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[5ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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.
- 既存の認証プロトコルは、明確でクライアントのユーザ名を交換することによって、しばしば始まります。 ワイヤレスのチャンネルを立ち聞きすることの文脈では、これは、クライアントの匿名とlocationalがプライバシーであると感染することができます。
- 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.
- ユーザのアイデンティティは、監視、マーケティング情報の望まれない獲得、および同様のものに対してユーザを保護するためにクライアントノードと信じられたサービスプロバイダーの間のコミュニケーションチャンネルで観察可能であるはずがありません。
Funk & Blake-Wilson Informational [Page 6] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[6ページ]情報のRFC5281EAP-TTLSv0 2008年8月
- 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.
- 認証機構はユーザが関係を全く持たないで、ルーティング認証要求のために能力を制限してしまうだろうアクセスドメインの中でローミングをサポートしなければなりません。
3. Requirements Language
3. 要件言語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
4. Terminology
4. 用語
AAA
AAA
Authentication, Authorization, and Accounting - functions that are
generally required to control access to a network and support
billing and auditing.
認証、Authorization、およびAccounting--一般に、機能がネットワークへのアクセスを制御して、支払いと監査をサポートするのが必要です。
AAA protocol
AAAプロトコル
A network protocol used to communicate with AAA servers; examples
include RADIUS and Diameter.
ネットワーク・プロトコルは以前はよくAAAサーバとコミュニケートしていました。 例はRADIUSとDiameterを含んでいます。
AAA server
AAAサーバ
A server which performs one or more AAA functions: authenticating
a user prior to granting network service, providing authorization
(policy) information governing the type of network service the
user is to be granted, and accumulating accounting information
about actual usage.
複数のAAA機能を実行するサーバ: ネットワーク・サービスを承諾する前にユーザを認証して、承認(方針)情報の治めるのにネットワーク・サービスのタイプを提供して、ユーザは、実際の用法に関して与えられて、課金情報を蓄積することになっています。
AAA/H
AAA/H
A AAA server in the user's home domain, where authentication and
authorization for that user are administered.
ユーザのホームドメインのAAAサーバ。そこでは、そのユーザのための認証と承認が管理されます。
access point
アクセスポイント
A network device providing users with a point of entry into the
network, and which may enforce access control and policy based on
information returned by a AAA server. Since the access point
terminates the server side of the EAP conversation, for the
aをユーザに提供するネットワークデバイスはネットワークにエントリーを指します、そして、どれがアクセスコントロールと情報に基づく方針を実施するかもしれないかはAAAサーバで戻りました。以来アクセスポイントはEAPの会話のサーバ側を終えます。
Funk & Blake-Wilson Informational [Page 7] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[7ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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].
したがってそれが「固有識別文字」で、EAP仕様[RFC3748]で使用されていた状態で相当しているこのドキュメントの目的。 アクセスポイントがクライアントとしてAAAサーバに機能するので、したがって、また、このドキュメントの目的のために、それも「ネットワークアクセス・サーバー(NAS)」に同等です、[RFC2865]などのAAA仕様で使用されるように。
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.
通常、ユーザと任意にユーザのホーム分野の名前から成るNetwork Access Identifier[RFC4282]。
proxy
プロキシ
A server that is able to route AAA transactions to the appropriate
AAA server, possibly in another domain, typically based on the
realm portion of an NAI.
適切なAAAサーバと、ことによると別のドメインでAAAトランザクションを発送できるサーバはNAIの分野の部分を通常基礎づけました。
realm
分野
The optional part of an NAI indicating the domain to which a AAA
transaction is to be routed, normally the user's home domain.
発送されるAAAトランザクションがことであるドメインを示すNAIの任意の部分、通常ユーザのホームドメイン。
Funk & Blake-Wilson Informational [Page 8] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[8ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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.
クライアントデバイスを操作している人。 系列がしばしばぼかされて、「ユーザ」がアイデンティティ(ユーザ名)、パスワード、または他の認証情報について所有されている人間について言及することを意図して、「クライアント」がネットワークアクセサリーを交渉するのにこの情報を利用するデバイスについて言及することを意図しますが また、クライアントが人間のオペレータなしでいるかもしれません。 この場合、「ユーザ」という用語は便利な抽象化です。
5. Architectural Model
5. 建築モデル
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 | | | | | | | | | +----------+ +----------+ +----------+ +----------+
+----------+ +----------+ +----------+ +----------+ | | | | | | | | | クライアント| <、-、-、--、>| アクセス| <、-、-、--、>| TTLS AAA| <、-、-、--、>| AAA/H| | | | ポイント| | サーバ| | サーバ| | | | | | | | | +----------+ +----------+ +----------+ +----------+
<---- 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
上に表現された実体は、論理的な実体であり、ネットワーク要素を切り離すために対応するかもしれません。 例えば、TTLSサーバとAAA/Hサーバは単一体であるかもしれません。 アクセスポイントとTTLSサーバは単一体であるかもしれません。 本当に、または、アクセスポイントの機能、TTLSサーバ、AAA/Hサーバは単一のフィジカル・デバイスに結合されるかもしれません。 上のダイヤグラムは、実体の中で一般的な方法で分業を例証して、aをどのようにに示しているか。
Funk & Blake-Wilson Informational [Page 9] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[9ページ]情報のRFC5281EAP-TTLSv0 2008年8月
distributed system might be constructed; however, actual systems might be realized more simply.
分散システムは構成されるかもしれません。 しかしながら、実際のシステムは、より単に実現されるかもしれません。
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サーバとAAA/Hサーバそのようなプロキシの間で通常アクセスポイントとTTLSサーバの間で配布されるかもしれないか、集合を実行するか、または分野ベースのメッセージルーティングに必要であることに注意してください。 しかしながら、そのようなサーバは、EAP-TTLSにおける直接的な役割を全くプレーしないで、またしたがって、示されません。
5.1. Carrier Protocols
5.1. キャリヤープロトコル
The entities shown above communicate with each other using carrier protocols capable of encapsulating EAP. The client and access point communicate typically using a link layer carrier protocol such as PPP or EAPOL (EAP over LAN). The access point, TTLS server, and AAA/H server communicate using a AAA carrier protocol such as RADIUS or Diameter.
上に示された実体は、EAPをカプセル化することができるキャリヤープロトコルを使用することで互いにコミュニケートします。 クライアントとアクセスポイントは、PPPかEAPOL(LANの上のEAP)などのリンクレイヤキャリヤープロトコルを通常使用することで交信します。 アクセスポイント、TTLSサーバ、およびAAA/Hサーバは、RADIUSかDiameterなどのAAAキャリヤープロトコルを使用することで交信します。
EAP, and therefore EAP-TTLS, must be initiated via the carrier protocol between client and access point. In PPP or EAPOL, for example, EAP is initiated when the access point sends an EAP- Request/Identity packet to the client.
クライアントとアクセスポイントの間のキャリヤープロトコルでEAP、およびしたがって、EAP-TTLSを開始しなければなりません。 アクセスポイントがEAPの要求/アイデンティティパケットをクライアントに送るとき、PPPかEAPOLでは、例えば、EAPは開始されます。
The keying material used to encrypt and authenticate the data connection between the client and access point is developed implicitly between the client and TTLS server as a result of the EAP-TTLS negotiation. This keying material must be communicated to the access point by the TTLS server using the AAA carrier protocol.
材料がクライアントとアクセスポイントとのデータ接続を暗号化して、認証するのに使用した合わせることはEAP-TTLS交渉の結果、クライアントとTTLSサーバの間でそれとなく開発されます。 AAAキャリヤープロトコルを使用することでこの合わせることの材料をアクセスポイントにTTLSサーバで伝えなければなりません。
5.2. Security Relationships
5.2. セキュリティ関係
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サーバで、ユーザが信じるカリフォルニア証明書でTTLSサーバの秘密鍵の所有物に基づいた一方向安全保障関係を保証させるか、または互いの安全保障関係は双方のための証明書に基づいているかもしれません。
Funk & Blake-Wilson Informational [Page 10] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[10ページ]情報のRFC5281EAP-TTLSv0 2008年8月
5.3. Messaging
5.3. メッセージング
The client and access point initiate an EAP conversation to negotiate the client's access to the network. Typically, the access point issues an EAP-Request/Identity to the client, which responds with an EAP-Response/Identity. Note that the client need not include the user's actual identity in this EAP-Response/Identity packet other than for routing purposes (e.g., realm information; see Section 7.3 and [RFC3748], Section 5.1); the user's actual identity need not be transmitted until an encrypted channel has been established.
クライアントとアクセスポイントは、ネットワークへのクライアントのアクセスを交渉するためにEAPの会話を開始します。 通常、アクセスポイントはクライアントへのEAP-要求/アイデンティティを発行します。(そのクライアントは、EAP-応答/アイデンティティで応じます)。 クライアントがルーティング目的以外のこのEAP-応答/アイデンティティパケットでユーザの実際のアイデンティティを入れる必要はないことに注意してください(例えば、分野情報; セクション7.3と[RFC3748]を見てください、セクション5.1)。 暗号化されたチャンネルが確立されるまで、ユーザの実際のアイデンティティは伝えられる必要はありません。
The access point now acts as a passthrough device, allowing the TTLS server to negotiate EAP-TTLS with the client directly.
TTLSサーバが直接クライアントとEAP-TTLSを交渉するのを許容して、アクセスポイントは現在、passthroughデバイスとして機能します。
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番目の段階の間、クライアントと安全なTLS記録的な層のチャンネルが情報交換するためにトンネルとTLS握手で書き立てたTTLSサーバ使用は認証(1つの方法の、または、互いの)などの追加機能を実行するために属性値組で要約されました、とクライアント保全の合法化と構成、情報の食糧を供給するのはデータの接続性などのために必要としました。
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).
クライアントとアクセスポイント(Session Key/拡張しているMaster Session Key(MSK/EMSK)をマスタリングしてください; セクション8を見る)との順次データ接続のための材料を合わせるのはTLS握手の間にクライアントとTTLSサーバの間で開発された秘密の情報に基づいて生成されます。うまくいっている認証の結論のときに、TTLSサーバは、それらのデバイス(例えば、RADIUS)の間の既存のセキュリティ協会に基づいて暗号化されたアクセスポイントに材料を合わせながら、これを伝えるかもしれません。
The client and access point now share keying material that they can use to encrypt data traffic between them.
クライアントとアクセスポイントは、現在、彼らがそれらの間のデータ通信量を暗号化するのに使用できる材料を合わせながら、共有されます。
Funk & Blake-Wilson Informational [Page 11] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[11ページ]情報のRFC5281EAP-TTLSv0 2008年8月
5.4. Resulting Security
5.4. 結果として起こるセキュリティ
As the diagram above indicates, EAP-TTLS allows user identity and password information to be securely transmitted between client and TTLS server, and generates keying material to allow network data subsequent to authentication to be securely transmitted between client and access point.
上のダイヤグラムが示すように、EAP-TTLSは、ユーザのアイデンティティとパスワード情報がしっかりとクライアントとTTLSサーバの間に伝えられるのを許容して、合わせるのが認証へのその後のネットワークデータがしっかりとクライアントとアクセスポイントの間に送られるのを許容する材料であると生成します。
6. Protocol Layering Model
6. プロトコルレイヤリングモデル
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をカプセル化します。(次に、属性値がユーザー認証か他の情報を運ぶかもしれない組(AVPs)であるとカプセル化するのにおいてTLSは使用されています)。 したがって、層にされたモデル(各層はそれの下で層によってカプセルに入れられる)を使用することでEAP-TTLSメッセージングについて説明できます。 以下のダイヤグラムはプロトコルの間の関係をはっきりさせます:
+-----------------------------------------------------------+ | AVPs, including authentication (PAP, CHAP, MS-CHAP, etc.) | +-----------------------------------------------------------+ | TLS | +-----------------------------------------------------------+ | EAP-TTLS | +-----------------------------------------------------------+ | EAP | +-----------------------------------------------------------+ | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | +-----------------------------------------------------------+
+-----------------------------------------------------------+ | 認証(PAP、CHAP、さん-CHAPなど)を含むAVPs | +-----------------------------------------------------------+ | TLS| +-----------------------------------------------------------+ | EAP-TTLS| +-----------------------------------------------------------+ | EAP| +-----------------------------------------------------------+ | キャリヤープロトコル(PPP、EAPOL、RADIUS、Diameterなど) | +-----------------------------------------------------------+
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.) | +-----------------------------------------------------------+
+-----------------------------------------------------------+ | EAP Method(MD-挑戦など) | +-----------------------------------------------------------+ | EAPを含むAVPs| +-----------------------------------------------------------+ | TLS| +-----------------------------------------------------------+ | EAP-TTLS| +-----------------------------------------------------------+ | EAP| +-----------------------------------------------------------+ | キャリヤープロトコル(PPP、EAPOL、RADIUS、Diameterなど) | +-----------------------------------------------------------+
Funk & Blake-Wilson Informational [Page 12] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[12ページ]情報のRFC5281EAP-TTLSv0 2008年8月
Methods for encapsulating EAP within carrier protocols are already defined. For example, PPP [RFC1661] or EAPOL [802.1X] may be used to transport EAP between client and access point; RADIUS [RFC2865] or Diameter [RFC3588] are used to transport EAP between access point and TTLS server.
キャリヤープロトコルの中でEAPをカプセル化するためのメソッドは既に定義されます。 例えば、PPP[RFC1661]かEAPOL[802.1X]がクライアントとアクセスポイントの間でEAPを輸送するのに使用されるかもしれません。 RADIUS[RFC2865]かDiameter[RFC3588]が、アクセスポイントとTTLSサーバの間でEAPを輸送するのに使用されます。
7. EAP-TTLS Overview
7. EAP-TTLS概要
A EAP-TTLS negotiation comprises two phases: the TLS handshake phase and the TLS tunnel phase.
EAP-TTLS交渉は二相を包括します: TLS握手フェーズとTLSはフェーズにトンネルを堀ります。
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サーバの間のトンネル情報に使用されます。 これらの力はユーザー認証、クライアント保全合法化、データ通信セキュリティ能力の交渉、主要な分配、課金情報に関するコミュニケーションなどを含んでいます。 RADIUSとDiameterとのコンパチブル属性値組(AVPs)を通してクライアントとTTLSサーバの間の情報を交換します。 したがって、そのようなAVPsを通して実装することができるどんなタイプの関数も容易に実行されるかもしれません。
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、さん-CHAP、またはさん-CHAP-V2などのレガシープロトコルであるかもしれません。 2ユーザー認証の位相を合わせてください。いつも必要であるかもしれないというわけではありません、ユーザがTLS握手プロトコルの互いの認証オプションで既に認証されたかもしれないので。
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の間、実行されるかもしれません。 このドキュメントはどんなそのような機能も定義しません。 しかしながら、どんな組織や標準化団体も自由に追加機能が適切なAVPsの使用でどう実行されるかもしれないかを指定できます。
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サーバはキャリヤープロトコルの上で合わせることの材料をアクセスポイントに伝えるでしょう。
Funk & Blake-Wilson Informational [Page 13] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[13ページ]情報のRFC5281EAP-TTLSv0 2008年8月
7.1. Phase 1: Handshake
7.1. フェーズ1: 握手
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/スタートパケットでEAP-TTLSメソッドに着手します、そして、S(始める)ビットはセットしました。(パケットはTypeとのEAP-要求=EAP-TTLSです)。 これは、ClientHelloメッセージを送ることによってTLS握手を始めるべきであるのをクライアントに示します。
EAP packets continue to be exchanged between client and TTLS server to complete the TLS handshake, as described in [RFC5216]. Phase 1 is completed when the client and TTLS server exchange ChangeCipherSpec and Finished messages. At this point, additional information may be securely tunneled.
EAPパケットは、[RFC5216]で説明されるようにTLS握手を終了するためにクライアントとTTLSサーバの間で交換され続けています。 クライアントとTTLSサーバがChangeCipherSpecとFinishedメッセージを交換すると、フェーズ1は完成します。 ここに、追加情報はしっかりとトンネルを堀られるかもしれません。
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サーバは信じられたカリフォルニアの証明書につながる証明書のチェーンに伴う証明書を送るでしょう。 クライアントは、認証を実行するために信じられたカリフォルニアの証明書によって構成される必要があるでしょう。
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.
クライアントの証明書ベースの認証が望まれているなら、クライアントは、証明書を発行したに違いなくて、その証明書に関連している秘密鍵を持たなければなりません。
7.2. Phase 2: Tunnel
7.2. フェーズ2: トンネル
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サーバの間の情報にトンネルを堀るのに使用されます。この情報は属性値組(AVPs)の系列でカプセル化されます。(使用と組の形式は後のセクションで説明されます)。
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を利用するアプリケーションがどんな情報を交換しなければならないか、そして、したがって、どのAVPsをサポートしなければならないかを指定すると予想されます。) クライアントは次々にのAVPsの符号化情報でフェーズ2交換を始めます、暗号化のためにTLSの記録的な層にこの系列を通過して、結果として起こるデータを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の記録的な層からクリアテキストのAVPsを取り戻します。 AVP系列が認証情報を含んでいるなら、それは、AAAキャリヤープロトコルを使用することでAAA/Hサーバにこの情報を転送します。 EAP-TTLSとAAA/Hサーバが全く同じであるかもしれないことに注意してください。 その場合、それは単に局所的に情報を処理します。
Funk & Blake-Wilson Informational [Page 14] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[14ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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サーバは、暗号化のためにTLSの記録的な層にAVP系列を通過して、結果として起こるデータをクライアントに送ります。 例えば、TTLSサーバはAAA/Hから受けられた認証挑戦を進めるかもしれません。
This process continues until the AAA/H either accepts or rejects the client, resulting in the TTLS server completing the EAP-TTLS negotiation and indicating success or failure to the encapsulating EAP protocol (which normally results in a final EAP-Success or EAP- Failure being sent to the client).
AAA/Hがクライアントを受け入れるか、または拒絶するまで、このプロセスは持続します、要約のEAPプロトコル(通常、クライアントに送られる最終的なEAP-成功かEAPの故障をもたらす)にEAP-TTLS交渉を終了して、成否を示すTTLSサーバをもたらして。
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キャリヤープロトコルメッセージのアクセスポイントに情報を合わせるデータ接続と他の承認情報を広げます。
7.3. EAP Identity Information
7.3. EAPアイデンティティ情報
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".
段階2の間、ユーザのアイデンティティを提供します。それは段階にTLSトンネルによって保護されます。 しかしながら、EAP- TTLS認証を始める前にクライアントはEAPプロトコルの一部としてEAPの応答/アイデンティティパケットを通常発行するでしょう、クリアテキストのユーザ名を含んでいて。 盗聴に対してユーザ匿名を保存するために、明確にこのパケットSHOULD NOTはユーザの実際の名前を含んでいます。 代わりにそれ、SHOULDは「匿名であること」のように空白かプレースホルダを費やします。 しかしながら、このプライバシー規制がルーティングに必要であるEAP-応答/アイデンティティの中でどんな情報にも適用することを意図しません。 したがって、EAP-応答/アイデンティティパケットはEAP-TTLSパケットが送られるべきである信じられたプロバイダーの分野の名前を含むかもしれません。 例えば、" anonymous@myisp.com "。
Note that at the time the initial EAP-Response/Identity packet is sent the EAP method is yet to be negotiated. If, in addition to EAP- TTLS, the client is willing to negotiate use of EAP methods that do not support user anonymity, then the client MAY include the name of the user in the EAP-Response/Identity to meet the requirements of the other candidate EAP methods.
初期のEAP-応答/アイデンティティパケットにEAPメソッドを送るときまだそれを交渉していないことに注意してください。 クライアントが、EAP- TTLSに加えてユーザに匿名をサポートしないEAPメソッドの使用を交渉しても構わないと思っているなら、クライアントは、他の候補EAPメソッドに関する必要条件を満たすためにEAP-応答/アイデンティティでユーザの名前を入れるかもしれません。
7.4. Piggybacking
7.4. 便乗します。
While it is convenient to describe EAP-TTLS messaging in terms of two phases, it is sometimes required that a single EAP-TTLS packet contain both phase 1 and phase 2 TLS messages.
二相に関してEAP-TTLSメッセージングについて説明するのが便利である間、時々単一のEAP-TTLSパケットがフェーズ1とフェーズ2TLSメッセージの両方を含むのが必要です。
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
また、握手を終了するパーティーが発信するAVPsを持っているとき、そのような「便乗」は起こります。 そして再開しているTLSセッションを交渉するとき、例えば、TTLSサーバがChangeCipherSpecを送る。
Funk & Blake-Wilson Informational [Page 15] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[15ページ]情報のRFC5281EAP-TTLSv0 2008年8月
Finished messages first, then the client sends its own ChangeCipherSpec and Finished messages to conclude the handshake. If the client has authentication or other AVPs to send to the TTLS server, it MUST tunnel those AVPs within the same EAP-TTLS packet immediately following its Finished message. If the client fails to do this, the TTLS server will incorrectly assume that the client has no AVPs to send, and the outcome of the negotiation could be affected.
次に、最初にクライアントがそれ自身のChangeCipherSpecを送るという終わっているメッセージと握手を結論づけるFinishedメッセージ。 クライアントがTTLSサーバに発信する認証か他のAVPsを持っているなら、すぐにFinishedメッセージに従って、それは同じEAP-TTLSパケットの中でそれらのAVPsにトンネルを堀らなければなりません。 クライアントがこれをしないと、TTLSサーバは、発信するためにクライアントがAVPsを全く持っていないと不当に仮定するでしょう、そして、交渉の結果は影響を受けるかもしれません。
7.5. Session Resumption
7.5. セッション再開
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-タイムアウト属性)から受け取られた情報を制限しながら、セッションがそれ自身の構成に基づいてセッションに基づいて聞き古したである考えるかもしれません。
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の間の少しもメッセージングなしで起こります。 例えば、オリジナルのセッションがRADIUS Session-タイムアウト属性を使用することで確立されるとき、AAA/Hへの周期的な再認証が望まれているなら、AAA/Hは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.
クライアントは、非認証機能を開始するためにセッション再開に関する第1段階2メッセージで他のAVPsを送るかもしれません。 そうしないなら、TTLSサーバは、非認証機能を開始するために任意にAVPsをクライアントに送るか、単にEAP-TTLS交渉を終了して、または要約のEAPプロトコルに成否を示すかもしれません。
Funk & Blake-Wilson Informational [Page 16] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[16ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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サーバは適切にSession-タイムアウトなどの時間的価値を変更するのに原因となります。
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.
そのセッションが段階2の間、ユーザのうまくいっている認証をもたらさなかったなら、TTLSサーバは、セッションが再開されることを許可してはいけません。 不当にセッション再開のこの局面を実装する結果は壊滅的でしょう。 どんな攻撃者も、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を実装するツールキットがしばしば自動的にresumable TLSセッションをキャッシュします。 ユーザが段階2の間、明確に認証されるまで、Implementersは、そのような無意識下での行動をくつがえすために注意して、セッションが可能な再開のためにキャッシュされるのを防がなければなりません。]
7.6. Determining Whether to Enter Phase 2
7.6. フェーズ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に入るか、またはどんなAVPsにもトンネルを堀らないでEAP-TTLS交渉を終了するのは可能です。
Scenarios in which phase 2 is never entered include:
フェーズ2が決して入れられないシナリオは:
- Successful session resumption, with no additional information
exchange required,
- 追加情報交換のないうまくいっているセッション再開が必要です。
- Authentication of the client via client certificate during phase
1, with no additional authentication or information exchange
required.
- 追加認証も情報交換のない段階1の間のクライアント証明書を通したクライアントの認証が必要です。
The client always has the first opportunity to initiate phase 2 upon completion of phase 1. If the client has no AVPs to send, it either sends an Acknowledgement (see Section 9.2.3) if the TTLS server sends the final phase 1 message, or simply does not piggyback a phase 2 message when it issues the final phase 1 message (as will occur during session resumption).
クライアントはいつもフェーズ2を開始する最初の機会をフェーズ1の完成に持っています。 1つのメッセージを最終段階に発行するとき(セッション再開の間起こるとき)、クライアントが発信するAVPsを全く持っていないなら、それは、TTLSサーバが1つのメッセージを最終段階に送るならAcknowledgement(セクション9.2.3を見る)を送るか、またはフェーズ2メッセージを絶対に背負いません。
Funk & Blake-Wilson Informational [Page 17] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[17ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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交渉を終了するか、またはクライアントにAVPsにトンネルを堀ることによって、フェーズ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サーバも、交換する追加情報がありません。 フェーズ2AVPsを背負わないで、クライアントはフェーズ1を完成します、そして、フェーズ2に入らないで、TTLSサーバは要約の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サーバは持っています。 フェーズ2AVPsを背負わないで、クライアントはフェーズ1を完成しますが、TTLSサーバは次のEAP-TTLSメッセージでトンネリングAVPsで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メッセージでフェーズ2AVPsを背負います、その結果、フェーズ2に交渉を広げています。
7.7. TLS Version
7.7. TLSバージョン
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実装SHOULDは、TLSがバージョン1.0であるとサポートします。
7.8. Use of TLS PRF
7.8. TLS PRFの使用
EAP-TTLSv0 utilizes a pseudo-random function (PRF) to generate keying material (Section 8) and to generate implicit challenge material for certain authentication methods (Section 11.1). The PRF used in these computations is the TLS PRF used in the TLS handshake negotiation that initiates the EAP-TTLS exchange.
EAP-TTLSv0は、合わせるのが材料(セクション8)であると生成して、ある認証方法(セクション11.1)のために暗黙の挑戦が材料であると生成するのに、擬似ランダム機能(PRF)を利用します。 これらの計算に使用されるPRFはEAP-TTLS交換を起こすTLS握手交渉に使用されるTLS PRFです。
TLS versions 1.0 [RFC2246] and 1.1 [RFC4346] define the same PRF function, and any EAP-TTLSv0 implementation based on these versions of TLS must use the PRF defined therein. It is expected that future versions of or extensions to the TLS protocol will permit alternative PRF functions to be negotiated. If an alternative PRF function is specified for the underlying TLS version or has been negotiated during the TLS handshake negotiation, then that alternative PRF function must be used in EAP-TTLSv0 computations instead of the TLS 1.0/1.1 PRF.
TLSバージョン1.0[RFC2246]と1.1[RFC4346]は同じPRF機能を定義します、そして、TLSのこれらのバージョンに基づくどんなEAP-TTLSv0実装もそこに定義されたPRFを使用しなければなりません。 TLSプロトコルへの将来のバージョンか拡大が、代替のPRF機能が交渉されることを許可すると予想されます。 代替のPRF機能が基本的なTLSバージョンに指定されるか、またはTLS握手交渉の間、交渉されているなら、TLS1.0/1.1PRFの代わりにEAP-TTLSv0計算にその代替のPRF機能を使用しなければなりません。
Funk & Blake-Wilson Informational [Page 18] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[18ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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)
ラベルはストリングです。(ヌルターミネータのない)
seed is a binary sequence.
種子は2進の系列です。
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.
TLS1.0/1.1PRFには、いくつの八重奏が発生しているかにかかわらず不変な出力があります。 しかしながら、代替のPRF機能がPRF機能に入力されるように出力系列のサイズを含んでいるのは、可能です。 これは、32の八重奏を生成することを意味します、そして、同じ入力パラメタから64の八重奏を生成するのはもう最初の32の同じである八重奏をもたらさないでしょう。 この理由として、発生している八重奏の数を示して、PRFはいつも"nn"で指定されます。
8. Generating Keying Material
8. 材料を合わせる生成すること
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の八重奏が64の八重奏がEMSKを構成する秒にMSKを構成します。
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マスター秘密、ASCIIによってコード化された一定のストリング「ttls合わせることの材料」、TLSクライアントから成っている入力でTLS PRF機能[RFC4346]とTLSサーバを使用するのは合わせることの材料に生成されます。 一定のストリングは終えられた状態でヌルではありません。
Keying Material = PRF-128(SecurityParameters.master_secret, "ttls
keying material", SecurityParameters.client_random +
SecurityParameters.server_random)
材料を合わせるのはPRF-128と等しいです。(「ttlsの合わせる物質的で」、_無作為の+SecurityParameters.server SecurityParameters.client_無作為のSecurityParameters.master_秘密)
MSK = Keying Material [0..63]
MSKは材料を合わせるのと等しいです。[0..63]
EMSK = Keying Material [64..127]
EMSKは材料を合わせるのと等しいです。[64..127]
Funk & Blake-Wilson Informational [Page 19] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[19ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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に、無作為の無作為、そして、サーバのクライアント_の注文がTLSプロトコル[RFC4346]のものから逆にされることに注意してください。 この注文はEAP-TLS[RFC5216]の主要な誘導法に従います。 randomsの注文を変更すると、EAP-TTLSのために定義された一定のストリングとTLSプロトコルのために定義されたものとの名前空間衝突は避けられます。
The TTLS server distributes this keying material to the access point via the AAA carrier protocol. When RADIUS is the AAA carrier protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes [RFC2548] may be used to distribute the first 32 octets and second 32 octets of the MSK, respectively.
TTLSサーバは、AAAキャリヤープロトコルで材料をアクセスポイントに合わせながら、これを分配します。 RADIUSがAAAキャリヤープロトコルであるときに、MPPE-Recv主要でMPPEがキーを送っている属性[RFC2548]は、それぞれMSKの最初の32の八重奏と2番目の32の八重奏を広げるのに使用されるかもしれません。
9. EAP-TTLS Protocol
9. EAP-TTLSプロトコル
9.1. Packet Format
9.1. パケット・フォーマット
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
Identifierがさばく識別子は、要求に応答に合うことにおいて1つの八重奏と援助です。 Identifier分野を各リクエスト・パケットのために変えなければならなくて、それぞれの応答パケットで反響しなければなりません。
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.
Lengthがさばく長さは、2つの八重奏であり、全体のEAPパケットの八重奏の数を示します、Code分野からData分野まで。
Type
21 (EAP-TTLS)
21をタイプしてください。(EAP-TTLS)
Funk & Blake-Wilson Informational [Page 20] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[20ページ]情報のRFC5281EAP-TTLSv0 2008年8月
Flags
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| L | M | S | R | R | V |
+---+---+---+---+---+---+---+---+
旗0 1 2 3 4 5 6 7の+---+---+---+---+---+---+---+---+ | L| M| S| R| R| V| +---+---+---+---+---+---+---+---+
L = Length included
M = More fragments
S = Start
R = Reserved
V = Version (000 for EAP-TTLSv0)
スタート長さの含まれているL=M=より多くの断片S=R=はV=バージョンを予約しました。(EAP-TTLSv0のための000)
The L bit is set to indicate the presence of the four-octet TLS
Message Length field. The M bit indicates that more fragments are
to come. The S bit indicates a Start message. The V field is set
to the version of EAP-TTLS, and is set to 000 for EAP-TTLSv0.
Lビットが4八重奏のTLS Message Length分野の存在を示すように設定されます。 ビットが来るために、より多くの断片がそうであることを示すM。 SビットはStartメッセージを示します。 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.
Length Message Lengthがさばくメッセージは、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.
データFor、Startパケット以外のすべてのパケット、Data分野はそれの生のTLSメッセージ系列か断片から成ります。 Startパケットに関しては、Data分野は任意にAVP系列を含むかもしれません。
9.2. EAP-TTLS Start Packet
9.2. EAP-TTLSはパケットを始めます。
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.
サーバによって送られた最初のパケットの上にEAP-TTLSプロトコルを開始するようにSビットを設定しなければなりません。 いかなる他のパケットの上にもそれを設定してはいけません。
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.
このパケットは役に立つヒントをクライアントに提供するかもしれないAVPsの形に追加情報を含むかもしれません。 例えば、サーバのアイデンティティは、セッション再開のために正しいTLSセッションにIDを選ぶのを許容するためにクライアントの役に立つかもしれません。 各AVPは4八重奏の境界で系列における最初のAVPに比例して始まらなければなりません。 AVPが4つの八重奏の倍数でないなら、ゼロで次の4八重奏の境界にそれを水増ししなければなりません。
9.2.1. Version Negotiation
9.2.1. バージョン交渉
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
EAP-TTLSのバージョンはサーバとクライアントの間の第一交換で交渉されます。 サーバはそれがStartメッセージのV分野でサポートするEAP-TTLSの最も大きいバージョン番号を設定します(EAP-TTLSv0の場合では、これは0です)。 応答における最初のEAPメッセージでは、クライアントは最も大きいバージョン番号にV分野を設定します。
Funk & Blake-Wilson Informational [Page 21] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[21ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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セッションを終えないEAP-ことを送ります。 さもなければ、クライアントによって送られたバージョンは使用しなければならないEAP-TTLSのバージョンです、そして、サーバとクライアントの両方がすべてのその後のEAPメッセージのそのバージョン番号にV分野を設定しなければなりません。
9.2.2. Fragmentation
9.2.2. 断片化
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ビットが断片化の前に全体の生のメッセージの長さを設定して、含んでいるのをさせなければなりません。 1番目以外の断片で、Lビットを設定してはいけません。 Unfragmentedメッセージは、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があるパケットを受け取り次第、ビットはセットして、受信機はAcknowledgementパケットを伝えなければなりません。 受信機は断片化しているパケットの再アセンブリに原因となります。
9.2.3. Acknowledgement Packets
9.2.3. 確認応答パケット
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.)
AcknowledgementパケットはFlags八重奏を超えたFlags八重奏のビットが0に設定するLと、Mと、Sがある追加データがなければEAP-TTLSパケットです。 (しかしながら、まだ適切なバージョン番号にV分野を設定しなければならないことに注意してください。)
An Acknowledgement packet is sent for the following purposes:
以下の目的のためにAcknowledgementパケットを送ります:
- A Fragment Acknowledgement is sent in response to an EAP packet
with the M bit set.
- 設定されて、噛み付かれたMがあるEAPパケットに対応してFragment Acknowledgementを送ります。
- 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).
- TTLSサーバでEAP-TTLS交渉の最終的なEAPパケットを送るとき、クライアントは、TTLSサーバがEAP-TTLS(通常、最終的なEAP-成功かEAP-失敗がクライアントに送られることを送るか、または引き起こすのによる)の完成のときにEAPプロトコルを続けるのを許容するためにAcknowledgementパケットで応じなければなりません。
Funk & Blake-Wilson Informational [Page 22] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[22ページ]情報のRFC5281EAP-TTLSv0 2008年8月
10. Encapsulation of AVPs within the TLS Record Layer
10. TLSの記録的な層の中のAVPsのカプセル化
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の記録的な層の中で暗号化された属性値組(AVPs)の使用で情報はクライアントとTTLSサーバの間でトンネルを堀られるかもしれません。
The AVP format chosen for EAP-TTLS is compatible with the Diameter AVP format. This does not represent a requirement that Diameter be supported by any of the devices or servers participating in an EAP- TTLS negotiation. Use of this format is merely a convenience. Diameter is a superset of RADIUS and includes the RADIUS attribute namespace by definition, though it does not limit the size of an AVP as does RADIUS; RADIUS, in turn, is a widely deployed AAA protocol and attribute definitions exist for all commonly used password authentication protocols, including EAP.
EAP-TTLSに選ばれたAVP形式はDiameter AVP形式と互換性があります。 これはDiameterがEAP- TTLS交渉に参加するデバイスかサーバのどれかによってサポートされるという要件を表しません。 この形式の使用は単に便利です。 直径は、RADIUSのスーパーセットであり、定義上RADIUS属性名前空間を含んでいます、RADIUSのようにAVPのサイズを制限しませんが。 RADIUSは順番に広く配布しているAAAプロトコルです、そして、属性定義はすべての一般的に使用されたパスワード認証プロトコルのために存在しています、EAPを含んでいて。
Thus, Diameter is not considered normative except as specified in this document. Specifically, the representation of the Data field of an AVP in EAP-TTLS is identical to that of Diameter.
したがって、Diameterは本書では指定される以外に、規範的であると考えられません。 明確に、EAP-TTLSのAVPのData分野の表現はDiameterのものと同じです。
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サーバはそれがクライアントに交信するのに使用するAVPsと広く配布される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.
彼らがDiameterと拡大によるRADIUSでするときEAP-TTLSで使用されるAVP CodesがEAP-TTLSでのおよそ同じ意味を運ぶと予想されます。 しかしながら、EAP-TTLSはDiameterとして同じAVP Codesと構文を使用しますが、意味論は異なるかもしれません、そして、ほとんどのDiameter AVPsはEAP-TTLSに少しの明確な意味論も持っていません。 別々の「EAP-TTLS AVP用法」登録はEAP-TTLSと彼らの意味論の中でこのような関係においては使用できるAVPsを記載します(詳細に関してセクション16を見てください)。 バックエンドでEAP-TTLS交換とDiameterかRADIUS交換の間のAVPsをコピーするTTLSサーバはそれがEAP-TTLSかバックエンドプロトコルのどちらかの用法を理解していないAVPsに関する仮定をしてはいけません。 したがって、AVPの意味論が理解されていて両方の文脈で定義されていない場合、TTLSサーバはEAP-TTLS交換とDiameterかRADIUS交換の間のAVPをコピーしてはいけません。
10.1. AVP Format
10.1. 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の書式は以下に示されます。 すべての項目がネットワーク、またはビッグエンディアンであって、注文してください。 すなわち、彼らには、最初に、最も重要な八重奏があります。
Funk & Blake-Wilson Informational [Page 23] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[23ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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 ...
+-+-+-+-+-+-+-+-+
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コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M r r r r r r| AVPの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーID(選びます)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+-+-+-+-+
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 Code AVP Codeは4つの八重奏であり、存在しているならVendor-ID分野に結合されて、唯一属性を特定します。 最初の256のAVP番号がRADIUS[RFC2865]で定義された属性を表します。 よりAVPより多くのNo.256はDiameter[RFC3588]で定義されます。
AVP Flags
AVP旗
The AVP Flags field is one octet and provides the receiver with
information necessary to interpret the AVP.
AVP Flags分野は、AVPを解釈するために1つの八重奏であり、必要情報を受信機に提供します。
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'(ベンダー特有)のビットは、任意のVendor-ID分野が存在しているかどうかを示します。 1に設定されると、Vendor-ID分野は存在しています、そして、Vendor-ID分野で示されたベンダーによって定義された名前空間に従って、AVP Codeは解釈されます。
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 Length分野は、3つの八重奏であり、AVP Code、AVP Length、AVP Flags、Vendor-ID(存在しているなら)、およびDataを含むこのAVPの長さを示します。
Funk & Blake-Wilson Informational [Page 24] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[24ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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 Flags分野に設定されるなら、Vendor-ID分野は存在しています。 それは、4つの八重奏であり、[RFC3232]が評価する「SMIネットワークマネージメント私企業コード」が割り当てられたベンダーのIANAを含んでいます。 それら自身のAVPsを定義するベンダーはそれらのAVPsの使用のためにRADIUS、Diameter、およびEAP-TTLSの中で一貫した名前空間を維持しなければなりません。
A Vendor-ID value of zero is equivalent to absence of the Vendor-
ID field altogether.
ゼロのVendor-ID値は全体でVendor 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(s)について0か1まで噛み付かれたMを設定することによって、機能を開始するパーティーは、相手による機能のサポートが任意であるか、または必要であることを示します。
10.2. AVP Sequences
10.2. AVP系列
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の記録的な層の中でカプセル化されたデータはゼロか、より多くのAVPsの系列から完全に成らなければなりません。 各AVPは4八重奏境界で系列における最初のAVPに比例して始まらなければなりません。 AVPが4つの八重奏の倍数でないなら、ゼロで次の4八重奏の境界にそれを水増ししなければなりません。
Note that the AVP Length does not include the padding.
AVP Lengthが詰め物を含んでいないことに注意してください。
10.3. Guidelines for Maximum Compatibility with AAA Servers
10.3. AAAサーバとの最大の互換性のためのガイドライン
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サーバで意図する非ベンダーの詳細AVPsはRADIUSのために定義された属性のセットから選択されるべきです。 すなわち、コード256がある属性。 これはRADIUSとDiameterの両方を互換性に提供します。
- 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サーバで意図するベンダー特有のAVPsはRADIUSに関して定義されるべきです。 ベンダー特有のRADIUS属性がDiameterに翻訳される、(したがってEAP-TTLS、)、自動的に。 逆は本当ではありません。 RADIUSのベンダー特有の属性は、RADIUS属性26を使用して、Vendor-ID、ベンダー特有の属性コード、および長さを含んでいます。 詳細に関して[RFC2865]を見てください。
Funk & Blake-Wilson Informational [Page 25] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[25ページ]情報のRFC5281EAP-TTLSv0 2008年8月
11. Tunneled Authentication
11. トンネルを堀られた認証
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握手の間、クライアントの証明書認証を実行するのは必要であるかもしれません。
11.1. Implicit Challenge
11.1. 暗黙の挑戦
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、さん-CHAP、およびさん-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かさん-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サーバの両方が生成する擬似ランダム機能を使用します:
Funk & Blake-Wilson Informational [Page 26] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[26ページ]情報のRFC5281EAP-TTLSv0 2008年8月
EAP-TTLS_challenge = PRF-nn(SecurityParameters.master_secret,
"ttls challenge",
SecurityParameters.client_random +
SecurityParameters.server_random);
EAP-TTLS_挑戦はPRF-nnと等しいです(秘密のSecurityParameters.master_「ttls挑戦」の、そして、_無作為の+SecurityParameters.server SecurityParameters.client_無作為の)。
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)の数は、認証方法によって、各認証方法のために内在している挑戦世代を必要としながら、以下で示されます。
11.2. Tunneled Authentication Protocols
11.2. トンネルを堀られた認証プロトコル
This section describes the methods for tunneling specific authentication protocols within EAP-TTLS.
このセクションはEAP-TTLSの中で特定の認証プロトコルにトンネルを堀るためのメソッドを説明します。
For the purpose of explication, it is assumed that the TTLS server and AAA/H use RADIUS as a AAA carrier protocol between them. However, this is not a requirement, and any AAA protocol capable of carrying the required information may be used.
解説の目的のために、TTLSサーバとAAA/Hが彼らの間のAAAキャリヤープロトコルとしてRADIUSを使用すると思われます。 しかしながら、これは要件ではありません、そして、必須情報を運ぶことができるどんなAAAプロトコルも使用されるかもしれません。
The client determines which authentication protocol will be used via the initial AVPs it sends to the server, as described in the following sections.
クライアントは、どの認証プロトコルがそれがサーバに送る初期のAVPsを通して使用されるかを決心しています、以下のセクションで説明されるように。
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のために定義されたベンダー特有のAVPsを利用します。 RADIUSとDiameterはベンダー特有のAVPsのコード化において異なります: RADIUSはベンダー特有の属性(コード26)を使用します、DiameterがVendor-IDの存在を示すのにVビットの設定を使用しますが。 Vビットがセットして、ベンダー特有の属性のRADIUSフォームはいつもDiameter AVPに変換可能です。 都合のよいDiameter Vビットメカニズムを使用して、以下で説明されたすべてのベンダー特有のAVPsをコード化しなければなりません。 EAP-TTLSの中でベンダーの特定のAVPsをコード化するのにすなわち、26のAVP Codeを使用してはいけません。
11.2.1. EAP
11.2.1. EAP
When EAP is the tunneled authentication protocol, each tunneled EAP packet between the client and TTLS server is encapsulated in an EAP- Message AVP, prior to tunneling via the TLS record layer.
EAPがトンネルを堀られた認証プロトコルであるときに、クライアントとTTLSサーバの間のそれぞれのトンネルを堀られたEAPパケットはEAPメッセージAVPでカプセルに入れられます、TLSの記録的な層でトンネルを堀る前に。
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.
Diameter AVPsがRADIUS属性のようにデータの253の八重奏に制限されないので253八重奏より長いEAPパケットを表す複数のEAP-メッセージ属性を連結するRADIUSメカニズムがEAP-TTLSで適切でないことに注意してください。 したがって、独身のEAP-メッセージAVPにただ一つのEAP-TTLSメッセージの中のトンネルを堀られたEAPパケットを含まなければなりません。
Funk & Blake-Wilson Informational [Page 27] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[27ページ]情報のRFC5281EAP-TTLSv0 2008年8月
The client initiates EAP by tunneling EAP-Response/Identity to the TTLS server. Depending on the requirements specified for the inner method, the client MAY now place the actual username in this packet; the privacy of the user's identity is now guaranteed by the TLS encryption. This username is typically a Network Access Identifier (NAI) [RFC4282]; that is, it is typically in the following format:
クライアントはTTLSサーバへのトンネリングEAP-応答/アイデンティティでEAPを開始します。内側のメソッドに指定された要件によって、クライアントは現在、実際のユーザ名をこのパケットに置くかもしれません。 ユーザのアイデンティティのプライバシーは現在、TLS暗号化で保証されます。 通常、このユーザ名はNetwork Access Identifier(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サーバが適切なAAA/HにEAPパケットを送るのを許容するのに使用されます。
Note that the client has two opportunities to specify realms. The first, in the initial, untunneled EAP-Response/Identity packet prior to starting EAP-TTLS, indicates the realm of the TTLS server. The second, occurring as part of the EAP exchange within the EAP-TTLS tunnel, indicates the realm of the client's home network. Thus, the access point need only know how to route to the realm of the TTLS server; the TTLS server is assumed to know how to route to the client's home realm. This serial routing architecture is anticipated to be useful in roaming environments, allowing access points or AAA proxies behind access points to be configured only with a small number of realms. (Refer to Section 7.3 for additional information distinguishing the untunneled and tunneled versions of the EAP- Response/Identity packets.)
始めのEAP-TTLSの前の初期のuntunneled EAP-応答/アイデンティティパケットでクライアントには分野1番目を指定する2つの機会があることに注意してください、とTTLSサーバの分野は示します。EAP交換の一部としてEAP-TTLSトンネルの中に起こって、2番目はクライアントのホームネットワークの分野を示します。 したがって、アクセスポイントはTTLSサーバの分野においてルートへのその方法を知るだけでよいです。 TTLSサーバがクライアントのホーム分野においてルートへのその方法を知ると思われます。 この連続のルーティングアーキテクチャはローミング環境で役に立つように予期されます、アクセスポイントの後ろのアクセスポイントかAAAプロキシが少ない数の分野だけによって構成されるのを許容して。(EAPの応答/アイデンティティパケットの「非-トンネル」の、そして、トンネルを堀られたバージョンを区別する追加情報についてセクション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.
初期のアイデンティティ交換のTTLS処理が明瞭なEAPと異なっていることに注意してください。 TTLSの州のマシンは異なっています。 しかしながら、サーバ側がクライアント開始に対応できると予想されます、通常のEAPプロトコル走行さえAAAの上でクライアントによって開始されているので。 クライアント側に、違いに対処するために、様々な実装のテクニックがあります。 TTLS気づかないEAPプロトコル走行さえ使用できました、TTLSがまるで実際にEAP-要求/アイデンティティメッセージを受け取るかのように見えるようにするなら。 これはクライアントとAAAサーバの間で作動するとき固有識別文字がすることと同様です。
Upon receipt of the tunneled EAP-Response/Identity, the TTLS server forwards it to the AAA/H in a RADIUS Access-Request.
トンネルを堀られたEAP-応答/アイデンティティを受け取り次第、TTLSサーバはRADIUS Access-要求における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はすぐに、Access-廃棄物で応じるかもしれません。 その場合、TTLSサーバは、EAPの故障をアクセスポイントに送ることによって、交渉を終了します。 EAPをサポートしないで、またAAA/Hがユーザのアイデンティティを認識しないなら、これは起こるかもしれません。
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
AAA/Hがユーザのアイデンティティを認識して、EAPをサポートするなら、TypeとType-データ・フィールドが用意ができていたEAPが議定書を作るEAP-要求を含んでいて、それはAccess-挑戦で応じます。
Funk & Blake-Wilson Informational [Page 28] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[28ページ]情報のRFC5281EAP-TTLSv0 2008年8月
which the AAA/H wishes to authenticate the client; for example MD5- Challenge, One-Time Password (OTP), or Generic Token Card.
AAA/Hがどれに願われているかがクライアントを認証します。 One-時間の例えば、MD5挑戦、Password(OTP)、またはGeneric Token Card。
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]で説明されるTTLSサーバがpassthroughデバイスとして機能するクライアントとAAA/H売り上げの間のEAP認証。 Access-挑戦におけるAAA/Hによって送られた各EAP-要求がTTLSサーバによってクライアントにトンネルを堀られて、TTLSサーバはクライアントによってトンネルを堀られた各EAP-応答を、Access-要求におけるAAA/Hに解読して、送ります。
This process continues until the AAA/H issues an Access-Accept or Access-Reject.
このプロセスがAAA/H問題まで持続する、Access受け入れるか、Access拒絶
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 Notificationパケットに課さないことに注意してください。 [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認証のための信頼できる輸送を提供するので、トンネル、およびSHOULDの中に静かに捨てられることに優先してそのようなものとして扱われた状態で起こると、おそらく、[RFC3748]に従って静かな破棄をもたらす誤りが実装誤りを表します。 本当に、トンネルの中で静かに有効にEAPメッセージを捨てると、停止が交換の進歩につけられて、即座の失敗をもたらすべきである場合における長いタイムアウトはもたらされるでしょう。
11.2.2. CHAP
11.2.2. やつ
The CHAP algorithm is described in [RFC1661]; RADIUS attribute formats are described in [RFC2865].
CHAPアルゴリズムは[RFC1661]で説明されます。 RADIUS属性形式は[RFC2865]で説明されます。
Both client and TTLS server generate 17 octets of challenge material, using the constant string "ttls challenge" as described above. These octets are used as follows:
上で説明されるように一定のストリング「ttls挑戦」を使用して、クライアントとTTLSサーバの両方が挑戦の材料の17の八重奏を生成します。 これらの八重奏は以下の通り使用されます:
CHAP-Challenge [16 octets]
CHAP Identifier [1 octet]
CHAP-挑戦[16の八重奏]CHAP Identifier[1つの八重奏]
The client initiates CHAP by tunneling User-Name, CHAP-Challenge, and CHAP-Password AVPs to the TTLS server. The CHAP-Challenge value is taken from the challenge material. The CHAP-Password consists of
クライアントはトンネリングUser-名、CHAP-挑戦、およびCHAP-パスワードAVPsでTTLSサーバにCHAPを開始します。挑戦の材料からCHAP-挑戦値を取ります。 CHAP-パスワードは成ります。
Funk & Blake-Wilson Informational [Page 29] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[29ページ]情報のRFC5281EAP-TTLSv0 2008年8月
CHAP Identifier, taken from the challenge material; and CHAP response, computed according to the CHAP algorithm.
CHAP Identifierであって、挑戦の材料から取られる。 そして、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.
クライアントからのこれらのAVPsを受け取り次第、TTLSサーバは、CHAP-挑戦AVPの値とCHAP-パスワードAVPのCHAP Identifierの値が挑戦の材料として生成された値と等しいことを確かめなければなりません。 どちらの項目もまさに合っていないなら、TTLSサーバはクライアントを拒絶しなければなりません。 さもなければ、それはAccess-要求におけるAAA/HにAVPsを送ります。
The AAA/H will respond with an Access-Accept or Access-Reject.
AAA/Hが応じる、Access受け入れるか、またはAccess拒絶します。
11.2.3. MS-CHAP
11.2.3. やつさん
The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute formats are described in [RFC2548].
さん-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]
CHAP Challenge Identさん[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.
クライアントは、User-名前、さん-CHAP挑戦、およびCHAP Response AVPsさんにTTLSサーバにトンネルを堀ることによって、さん-CHAPを開始します。挑戦の材料からCHAP-Challenge価値さんを取ります。 Response CHAP-さんは挑戦の材料から取られたIdentから成ります。 クライアント好み設定された旗。 そして、さん-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.
クライアントからのこれらのAVPsを受け取り次第、TTLSサーバは、CHAP Challenge AVPさんの値とクライアントのCHAP Response AVPさんのIdentの値が挑戦の材料として生成された値と等しいことを確かめなければなりません。 どちらの項目もまさに合っていないなら、TTLSサーバはクライアントを拒絶しなければなりません。 さもなければ、それはAccess-要求におけるAAA/HにAVPsを送ります。
The AAA/H will respond with an Access-Accept or Access-Reject.
AAA/Hが応じる、Access受け入れるか、またはAccess拒絶します。
11.2.4. MS-CHAP-V2
11.2.4. やつV2さん
The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute formats are described in [RFC2548].
さん-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の八重奏を生成します。 これらの八重奏は以下の通り使用されます:
Funk & Blake-Wilson Informational [Page 30] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[30ページ]情報のRFC5281EAP-TTLSv0 2008年8月
MS-CHAP-Challenge [16 octets]
Ident [1 octet]
CHAP Challenge Identさん[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.
クライアントはトンネリングUser-名、さん-CHAP挑戦、およびCHAP2Response AVPsさんでさん-CHAP-V2をTTLSサーバに開始します。挑戦の材料からCHAP-Challenge価値さんを取ります。 Response CHAP2-さんは挑戦の材料から取られたIdentから成ります。 0に設定された旗。 無作為の値に設定された同輩挑戦。 そして、さん-CHAP-V2アルゴリズムによると、計算されたResponse。
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.
クライアントからのこれらのAVPsを受け取り次第、TTLSサーバは、CHAP Challenge AVPさんの値とクライアントのCHAP2Response AVPさんのIdentの値が挑戦の材料として生成された値と等しいことを確かめなければなりません。 どちらの項目もまさに合っていないなら、TTLSサーバはクライアントを拒絶しなければなりません。 さもなければ、それはAccess-要求におけるAAA/HにAVPsを送ります。
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はAccess受け入れている含有によるCHAP2Success属性さんを反応させるでしょう。 この属性はPeer-挑戦に基づくクライアントに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.
CHAP2Success AVPさんを受け取り次第、クライアントはAAA/Hを認証できます。 認証が成功するなら、クライアントはデータ(すなわち、ゼロ・レングスData分野がある)を全く含まないTTLSサーバにEAP-TTLSパケットを送ります。 クライアントからの空のEAP- TTLSパケットを受け取り次第、TTLSサーバは、さん-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.
認証が失敗すると、Access挑戦がCHAP Error属性さんを含んでいて、AAA/Hは応じるでしょう。 この属性は誤り理由や再試行が許されているかどうかなどの追加情報がある新しいIdentとストリングを含んでいます。 TTLSサーバはこのAVPにクライアントにトンネルを堀ります。 誤り理由が満期のパスワードであり、再試行が許されているなら、クライアントはユーザのパスワードを変えるかもしれなくしかけます。 誤り理由が満期のパスワードでないクライアントがユーザのパスワードを変えたくないなら、それは単にEAP-TTLS交渉を捨てます。
If the client does wish to change the password, it tunnels MS-CHAP- NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS server. The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge received in the MS-CHAP-Error AVP. The MS-CHAP-Challenge AVP simply echoes the new Challenge.
クライアントがパスワードを変えたいなら、それはさん-CHAP- NT-Enc-PW、さん-CHAP2-CPW、およびCHAP Challenge AVPsさんにTTLSサーバにトンネルを堀ります。CHAP Error AVPさんで受け取られた新しいIdentとChallengeからさん-CHAP2-CPW AVPを得ます。 CHAP Challenge AVPさんは単に新しいChallengeを反響します。
Funk & Blake-Wilson Informational [Page 31] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[31ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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.
クライアントからのこれらのAVPsを受け取り次第、TTLSサーバは、CHAP Challenge AVPさんの値とクライアントのさん-CHAP2-CPW AVPのIdentの値がそれがCHAP Error AVPさんで送った値に合っていることを確かめなければなりません。 どちらの項目もまさに合っていないなら、TTLSサーバはクライアントを拒絶しなければなりません。 さもなければ、それはAccess-要求におけるAAA/HにAVPsを送ります。
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はAccess受け入れている含有によるCHAP2Success属性さんを反応させるでしょう。 ここに、交渉は上で説明されるように続きます。 TTLSサーバはCHAP2Successさんにクライアントにトンネルを堀ります、そして、クライアントはこのAVPに基づくAAA/Hを認証します。 次に、クライアントは、データ(すなわち、ゼロ・レングスData分野がある)を全く含まないTTLSサーバに、失敗の交渉を捨てるか、またはEAP-TTLSパケットを送ります、TTLSサーバが、さん-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.
さん-CHAP-V2に関連している追加AVPsがAAA/Hによって送られるかもしれないことに注意してください。 例えば、CHAP Domainさん。 TTLSサーバはさん-CHAP2成功に伴うそのような認証関連の属性にトンネルを堀らなければなりません。
11.2.5. PAP
11.2.5. 乳首
The client initiates PAP by tunneling User-Name and User-Password AVPs to the TTLS server.
クライアントはトンネリングUser-名とUser-パスワードAVPsでTTLSサーバに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.
通常、User-パスワードは、RADIUSでは、共有秘密キーと他のパケット情報を使用することでヌルで16の八重奏の倍数に水増しされて、次に、暗号化されます。
An EAP-TTLS client, however, does not RADIUS-encrypt the password since no such RADIUS variables are available; this is not a security weakness since the password will be encrypted via TLS anyway. The client SHOULD, however, null-pad the password to a multiple of 16 octets, to obfuscate its length.
しかしながら、そのようなどんなRADIUS変数も利用可能でないので、EAP-TTLSクライアントはパスワードをRADIUS暗号化しません。 パスワードがTLSを通してとにかく暗号化されるので、これはセキュリティ弱点ではありません。 しかしながら、クライアントSHOULDは、長さを困惑させるために16の八重奏の倍数へのパスワードをヌル水増しします。
Upon receipt of these AVPs from the client, the TTLS server forwards them to the AAA/H in a RADIUS Access-Request. (Note that in the Access-Request, the TTLS server must encrypt the User-Password attribute using the shared secret between the TTLS server and AAA/H.)
クライアントからのこれらのAVPsを受け取り次第、TTLSサーバはRADIUS Access-要求におけるAAA/Hに彼らを送ります。 (Access-要求では、TTLSサーバがTTLSサーバとAAA/H.の間の共有秘密キーを使用することでUser-パスワード属性を暗号化しなければならないというメモ)
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.
Access受け入れてください。AAA/Hがすぐに応じるかもしれない、または、Access廃棄物。 そして、TTLSサーバは、AAAキャリヤープロトコルを使用することでEAP-成功かEAP-失敗をアクセスポイントに送ることによって、交渉を終了します。
Funk & Blake-Wilson Informational [Page 32] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[32ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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はAccess-挑戦で応じるかもしれません。 そして、TTLSサーバはクライアントへのAAA/Hの挑戦からAVPsにトンネルを堀ります。 これらのAVPsを受け取り次第、クライアントは再びUser-名前とUserパスワードにトンネルを堀ります、新情報を挑戦に対応したUser-パスワードによる含有で。 このプロセスがAAA/H問題まで持続する、Access受け入れるか、Access拒絶
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.
少なくとも挑戦のときにクライアントにトンネルを堀られたAVPsの1つはReply-メッセージであるに違いありません。 通常、AAA/Hは挑戦の一部としてこれを送ります。 しかしながら、AAA/HがReply-メッセージを送らないなら、TTLSサーバはヌル値で1つを発行しなければなりません。 これで、クライアントは、チャレンジレスポンスが必要であると決心できます。
Note that if the AAA/H includes a Reply-Message as part of an Access-Accept or Access-Reject, the TTLS server does not tunnel this AVP to the client. Rather, this AVP and all other AVPs sent by the AAA/H as part of Access-Accept or Access-Reject are sent to the access point via the AAA carrier protocol.
Hが部分としてのReply-メッセージを含むAAA/であるならそれに注意してください、Access受け入れるか、Access拒絶、TTLSサーバはこのAVPにクライアントにトンネルを堀りません。 むしろ、AAAキャリヤープロトコルでこのAVPとAccess受け入れることの一部としてAAA/Hによって送られた他のすべてのAVPsかAccess-廃棄物をアクセスポイントに送ります。
11.3. Performing Multiple Authentications
11.3. 複数の認証を実行します。
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タイプでEAP-要求を一度出すことによって。前の認証は完成します。 それぞれの新しいEAPメソッドは交渉を受けることがあることに注意してください。 すなわち、クライアントはEAP-Nakと共に新しいEAPタイプを求めるEAP要求に応じるかもしれません、[RFC3748]で説明されるように。
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.
例えば、Generic Token Cardによって続かれたMD5-挑戦を実行したがっているAAA/Hは、最初に、MD5EAP-要求/挑戦を発行して、応答を受けるでしょう。 応答が満足できるなら、それは、次に、EAP-要求/ジェネリックToken Cardを発行して、応答を受けるでしょう。 また、その応答も満足できるなら、それはユーザを受け入れるでしょうに。
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系列であると考えられます、それぞれのその後の要求が前の要求からの異なったa EAP Identifierを含まなければならないので、認証が完成して、別のものが始めるものとしてさえ。
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-アイデンティティ交換を指定するアプリケーションプロフィール規格がないとき、SHOULD NOTは起こります。
Funk & Blake-Wilson Informational [Page 33] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[33ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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タイプが変化しないなら認証が始める新しさ。 EAP-TLSなどのあるEAPメソッドは最初の要求を区別するのにStartビットを使用します、その結果、そのタイプを使用するそれぞれの新しい認証が前と区別されるのを許容します。 EAP CHAP-V2さんなどの他のメソッドは明確な方法で終わります、同じタイプの2番目の認証が明白に始まるのを許容して。 同じEAPメソッドの複数の認証の使用が比較的ありそうもない間、implementersは問題を意識していて、あいまいさをもたらすケースを避けるはずです。
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メソッドの混合物が本書では定義されません、そして、そのようなアプローチが実装されたか否かに関係なく、それは知られません。
11.4. Mandatory Tunneled Authentication Support
11.4. 義務的なトンネルを堀られた認証サポート
To ensure interoperability, in the absence of an application profile standard specifying otherwise, an implementation compliant with this specification MUST implement EAP as a tunneled authentication method and MUST implement MD5-Challenge as an EAP type. However, such an implementation MAY allow the use of EAP, any EAP type, or any other tunneled authentication method to be enabled or disabled by administrative action on either client or TTLS server.
この仕様による対応することの実装は、別の方法で指定するアプリケーションプロフィール規格がないとき相互運用性を確実にするために、トンネルを堀られた認証方法としてEAPを実装しなければならなくて、EAPタイプとしてMD5-挑戦を実装しなければなりません。 しかしながら、そのような実装はEAPの使用、どんなEAPタイプ、またはいかなる他のクライアントかTTLSサーバのどちらかへの管理動作で可能にされるべきであるか、または無効にするべきトンネルを堀られた認証方法も許容するかもしれません。
In addition, in the absence of an application profile standard specifying otherwise, an implementation compliant with this specification MUST allow an administrator to configure the use of tunneled authentication without the M (Mandatory) bit set on any AVP.
さらに、別の方法で指定するアプリケーションプロフィール規格がないとき、管理者は、この仕様による対応することの実装でM(義務的な)ビットのないトンネルを堀られた認証の使用がどんなAVPにもセットしたのを構成できなければなりません。
11.5. Additional Suggested Tunneled Authentication Support
11.5. 追加提案されたトンネルを堀られた認証サポート
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の既存の実装があるこの仕様の作者と評論家の経験に基づく非標準の指導として以下の情報を提供します。
Funk & Blake-Wilson Informational [Page 34] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[34ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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)
- 乳首(パスワードとトークン認証のための両方)
- MS-CHAP-V2
- やつV2さん
- EAP-MS-CHAP-V2
- EAPやつV2さん
- EAP-GTC
- EAP-GTC
12. Keying Framework
12. フレームワークを合わせます。
In compliance with [RFC5247], Session-Id, Peer-Id, and Server-Id are here defined.
[RFC5247]に従って、定義されて、Session-イド、Peer-イド、およびServer-イドがここにあります。
12.1. Session-Id
12.1. セッションイド
The Session-Id uniquely identifies an authentication exchange between the client and TTLS server. It is defined as follows:
Session-イドは唯一クライアントとTTLSサーバの間の認証交換を特定します。それは以下の通り定義されます:
Session-Id = 0x15 || client.random || server.random
セッションイド=0x15|| client.random|| server.random
12.2. Peer-Id
12.2. 同輩イド
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-イドは、アクセスコントロールと会計目的に使用されるためにアイデンティティを表します。 クライアントがTLS握手の一部として証明書を提示するとき、Peer-イドは証明書の情報に基づいて決定しています、[RFC5216]のセクション5.2で指定されるように。 さもなければ、Peer-イドはヌルです。
12.3. Server-Id
12.3. サーバイド
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-イドはTTLSサーバを特定します。TTLSサーバがTLS握手の一部として証明書を提示するとき、Server-イドは証明書の情報に基づいて決定しています、[RFC5216]のセクション5.2で指定されるように。 さもなければ、Server-イドはヌルです。
13. AVP Summary
13. AVP概要
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がサーバからクライアント(「要求する」)までのパケットパケットでクライアントからサーバ(「応答」)まで見えるかもしれなくて、(「MI」)であるとAVPを実装しなければならないか否かに関係なく。
Funk & Blake-Wilson Informational [Page 35] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[35ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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
要求応答をMIと命名してください。--------------------------------------------------- ユーザ名XユーザパスワードXやつパスワードX応答メッセージXやつ挑戦X EAP-メッセージX X Xやつドメインさんさんやつ応答Xやつ誤りXやつ挑戦さんさんさんやつNT-Enc-PW X X X CHAP2応答さんX CHAP2成功Xさん-CHAP2-CPW Xさん
14. Security Considerations
14. セキュリティ問題
14.1. Security Claims
14.1. セキュリティクレーム
Pursuant to RFC 3748, security claims for EAP-TTLSv0 are as follows:
RFC3748によると、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と任意の追加保護された認証Ciphersuite交渉: はいMutual認証: はい、コネは実装Integrity保護を推薦しました: はいReplay保護: はい秘密性: はいKey派生: はいKeyの強さ: 最大384ビットのDictionaryがprotを攻撃する、: はいFastは再接続します: はいCryptographic結合: Session独立がありません: はい断片化: はいChannel結合: いいえ
14.1.1. Authentication Mechanism
14.1.1. 認証機構
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
EAP-TTLSv0は交渉された基本的な認証プロトコルを利用して、フェーズ1TLS握手とフェーズ2における両方はトンネルを堀られた認証です。 典型的な展開では、最小限で、サーバがフェーズ1、およびクライアントというクライアントに認証するTTLSはフェーズ2でAAA/Hにサーバを認証します。 クライアントへのTTLSサーバのフェーズ1認証が通常証明書であります。 クライアントは証明書で任意にTTLSにサーバを認証するかもしれません。
Funk & Blake-Wilson Informational [Page 36] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[36ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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を通して通常パスワードかセキュリティトークンであるか、または非EAPの認証機構であるとサポートされて、AAA/Hサーバにクライアントの2認証の位相を合わせてください。 この認証機構はまた、クライアント(互いの認証)にAAA/Hサーバの認証を提供するかもしれません。
14.1.2. Ciphersuite Negotiation
14.1.2. Ciphersuite交渉
Ciphersuite negotiation is inherited from TLS.
Ciphersuite交渉はTLSから引き継がれます。
14.1.3. Mutual Authentication
14.1.3. 互いの認証
In the recommended minimum configuration, the TTLS server is authenticated to the client in phase 1, and the client and AAA/H server mutually authenticate in phase 2.
お勧めの最小の構成では、TTLSサーバはフェーズ1でクライアントに認証されます、そして、クライアントとAAA/Hサーバはフェーズで互いに2を認証します。
14.1.4. Integrity Protection
14.1.4. 保全保護
Integrity protection is inherited from TLS.
保全保護はTLSから引き継がれます。
14.1.5. Replay Protection
14.1.5. 反復操作による保護
Replay protection is inherited from TLS.
反復操作による保護はTLSから引き継がれます。
14.1.6. Confidentiality
14.1.6. 秘密性
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パケットの暗号化への支給を全く含まないことに注意してください。
14.1.7. Key Derivation
14.1.7. 主要な派生
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の暗号の機敏さに依存します。
14.1.8. Key Strength
14.1.8. 主要な強さ
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].
主要な強さはTLSマスター秘密のサイズによって制限されます。(バージョン1.0と1.1のために、秘密は48の八重奏(384ビット)です)。 有効な主要な強さは、より少ないかもしれません、交渉されたディフィー-ヘルマン(DH)グループ、証明書RSA/DSAグループなどの攻撃抵抗によって BCP86[RFC3766](セクション5)はビットの必要なRSAかDHモジュールとDSAサブグループサイズでアドバイスします、ビットにおける、与えられたレベルの攻撃抵抗のために。 例えば、2048年のビットのRSAキーが128ビットの同等な主要な強さを提供することが勧められます。 また、StandardsとTechnology(NIST)のためのNational Instituteは[SP800-57]の適切な主要なサイズでアドバイスします。
Funk & Blake-Wilson Informational [Page 37] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[37ページ]情報のRFC5281EAP-TTLSv0 2008年8月
14.1.9. Dictionary Attack Protection
14.1.9. 辞書攻撃保護
Phase 2 password authentication is protected against eavesdropping and therefore against offline dictionary attack by TLS encryption.
フェーズ2パスワード認証は盗聴に対してしたがって、TLS暗号化によるオフライン辞書攻撃に対して保護されます。
14.1.10. Fast Reconnect
14.1.10. 速く再接続してください。
Fast reconnect is provided by TLS session resumption.
速く再接続してください。TLSセッション再開で、提供します。
14.1.11. Cryptographic Binding
14.1.11. 暗号の結合
[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]。
14.1.12. Session Independence
14.1.12. セッション独立
TLS guarantees the session independence of its master secret, from which the EAP-TTLSv0 MSK/EMSK is derived.
TLSはマスター秘密からのセッション独立を保証します。(EAP-TTLSv0 MSK/EMSKは秘密から引き出されます)。
14.1.13. Fragmentation
14.1.13. 断片化
Provision is made for fragmentation of lengthy EAP packets.
長いEAPパケットの断片化に備えます。
14.1.14. Channel Binding
14.1.14. チャンネル結合
Support for channel binding may be added as a future extension, using appropriate AVPs.
適切なAVPsを使用して、チャンネル結合のサポートは今後の拡大として加えられるかもしれません。
14.2. Client Anonymity
14.2. クライアント匿名
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
他のEAPメソッドと異なって、EAP-TTLSは初期のEAP-応答/アイデンティティにおける明確でユーザ名を伝えません。 この特徴は、クライアントとTTLSの間のネットワーク経路を盗み聞いている攻撃者から匿名と位置がプライバシーであるとサポートするように設計されています。
Funk & Blake-Wilson Informational [Page 38] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[38ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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.
サーバしかしながら、implementersは他の要素(ほかの場所のEAP-TTLSの中の両方)がユーザのアイデンティティに感染するかもしれないのを意識しているべきです。 例えば、ユーザが段階の間、証明書でEAP-TTLSの1つを認証するなら、証明書の対象の名前はユーザのアイデンティティを明らかにするかもしれません。 EAP-TTLSの外では、クライアントがMACにアドレスを固定したか、またはまた、無線接続、クライアントのラジオ署名の場合では、情報を明らかにするかもしれません。 さらに、implementersはユーザのアイデンティティが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.
証明書で認証するクライアントが立ち聞きする者から証明書に盾となって、したがって、アイデンティティに盾となりたいなら、クライアントがTLS握手の完成のときに1秒を始めるために空の証明書リスト、TTLSサーバ問題にServerHelloを送る.4セクション2.1[RFC5216](「プライバシー」)で説明されたテクニックを使用するかもしれないというメモは握手を暗号化しました。(クライアントはそれの間、証明書リストを送るでしょう)。 クライアントを働かせるこの特徴のためのそれが、あらかじめTTLSサーバがそれをサポートするのを知らなければならないことに注意してください。
14.3. Server Trust
14.3. サーバ信頼
Trust of the server by the client is established via a server certificate conveyed during the TLS handshake. The client should have a means of determining which server identities are authorized to act as a TTLS server and may be trusted, and should refuse to authenticate with servers it does not trust. The consequence of pursuing authentication with a hostile server is exposure of the inner authentication to attack; e.g., offline dictionary attack against the client password.
クライアントによるサーバの信頼はTLS握手の間に伝えられたサーバ証明書で確立されます。 クライアントには、それが信じないサーバで認証するどのサーバのアイデンティティがTTLSサーバとして機能するのが認可されて、信じられるかもしれなくて、拒否するべきであるかを決定する手段があるべきです。 敵対的なサーバで認証を追求する結果は攻撃する内側の認証の摘発です。 例えば、クライアントパスワードに対するオフライン辞書攻撃。
14.4. Certificate Validation
14.4. 証明書合法化
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
クライアントとサーバは、相手の証明書用法が証明書の目的に従うのを保証するためにそれが受け取る証明書のExtended Key Usage(EKU)拡張子[RFC5280]に関連する政策を実施するべきです。 クライアントEKU、通常現在のいつ
Funk & Blake-Wilson Informational [Page 39] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[39ページ]情報のRFC5281EAP-TTLSv0 2008年8月
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.
イド-kp-clientAuthを含んでいると予想されてください。 存在しているとき、サーバEKUがイド-kp-serverAuthを含んでいると予想されるでしょう。 EKU拡張子の欠如かanyExtendedKeyUsageの値が証明書の目的における規制の欠如を含意することに注意してください。
14.5. Certificate Compromise
14.5. 証明書感染
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].
クライアントには、認証の間、最新の取消しリストに対してサーバ証明書をチェックするのはいつも可能であるというわけではありません、それに認証の完成までネットワークアクセスがないとき。 TLS握手の間、Online Certificate Statusプロトコル(OCSP)[RFC2560]の使用でこの問題を軽減できます、[RFC4366]で説明されるように。
14.6. Forward Secrecy
14.6. 前進の秘密保持
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.
前進の秘密保持で、秘密の暴露は以前にその秘密に基づいて交渉されたセッションキーに感染しません。 TTLSサーバ証明書の秘密鍵が結局、盗まれるか、または解かれるならTLSの主要な交換アルゴリズムが前進の秘密保持を提供するとき、したがって、その証明書がもう使用中でない限り、トンネルを堀られたユーザパスワード情報は安全なままで残るでしょう。 ディフィー-ヘルマンの主要な交換は前進の秘密保持を提供するアルゴリズムに関する例です。 記録された認証かデータセッションに対する攻撃が多大なる脅威を引き起こすと考えられるなら、前進の秘密保持アルゴリズムは考えられるべきです。
14.7. Negotiating-Down Attacks
14.7. 下に交渉攻撃
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つはTTLSサーバのそれがトンネルの中のAVPで提案したプロトコルバージョンの繰り返しであるかもしれません、そのようなバージョン0が同意さえされるときはっきりと噛み付かれたMで挿入されるべきAVP。
Funk & Blake-Wilson Informational [Page 40] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[40ページ]情報のRFC5281EAP-TTLSv0 2008年8月
15. Message Sequences
15. メッセージ系列
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パケットは"passthrough"として示されます。 TLSの記録的な層の中でしっかりとトンネルを堀られるAVPsが巻き毛の支柱に同封される、() 任意の項目は疑問符(?)でsuffixedされます。 複数の回現れるかもしれない商品は、(+)をsuffixedされて、署名します。
15.1. Successful Authentication via Tunneled CHAP
15.1. Tunneled CHAPを通したうまくいっているAuthentication
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 ------ ------------ ----------- -----
クライアントアクセスポイントTTLSサーバAAA/H------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-要求/アイデンティティ<。--------------------
EAP-Response/Identity
-------------------->
EAP-応答/アイデンティティ-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
半径アクセス挑戦: TTLS EAP-要求/スタート<。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
EAP-応答/TTLS: ClientHello-------------------->。
Funk & Blake-Wilson Informational [Page 41] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[41ページ]情報のRFC5281EAP-TTLSv0 2008年8月
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
半径アクセス挑戦: EAP-要求/TTLS: ServerHello証明書ServerKeyExchange ServerHelloDone<。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
EAP-応答/TTLS: ClientKeyExchange ChangeCipherSpecは終わりました。-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
半径アクセス挑戦: EAP-要求/TTLS: ChangeCipherSpecは<を終えました。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
EAP-Response/TTLS:
{User-Name}
{CHAP-Challenge}
{CHAP-Password}
-------------------->
EAP-応答/TTLS: ユーザ名はやつパスワードにやつと同じくらい挑戦します。-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
Funk & Blake-Wilson Informational [Page 42] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[42ページ]情報のRFC5281EAP-TTLSv0 2008年8月
RADIUS Access-Request:
User-Name
CHAP-Challenge
CHAP-Password
-------------------->
半径アクセス要求: ユーザ名やつ挑戦やつパスワード-------------------->。
RADIUS Access-Accept
<--------------------
アクセスして受け入れている半径<。--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
半径はアクセスして受け入れます: EAP-成功<。--------------------
EAP-Success
<--------------------
EAP-成功<。--------------------
15.2. Successful Authentication via Tunneled EAP/MD5-Challenge
15.2. Tunneled EAP/MD5-挑戦を通したうまくいっているAuthentication
In this example, the client performs one-way TLS authentication of the TTLS server and EAP/MD5-Challenge is used as a tunneled user authentication mechanism.
この例では、クライアントはTTLSサーバの一方向TLS認証を実行します、そして、EAP/MD5-挑戦はトンネルを堀られたユーザー認証メカニズムとして使用されます。
client access point TTLS server AAA/H ------ ------------ ----------- -----
クライアントアクセスポイントTTLSサーバAAA/H------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-要求/アイデンティティ<。--------------------
EAP-Response/Identity
-------------------->
EAP-応答/アイデンティティ-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
半径アクセス挑戦: TTLS EAP-要求/スタート<。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
EAP-応答/TTLS: ClientHello-------------------->。
Funk & Blake-Wilson Informational [Page 43] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[43ページ]情報のRFC5281EAP-TTLSv0 2008年8月
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
半径アクセス挑戦: EAP-要求/TTLS: ServerHello証明書ServerKeyExchange ServerHelloDone<。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
EAP-応答/TTLS: ClientKeyExchange ChangeCipherSpecは終わりました。-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
半径アクセス挑戦: EAP-要求/TTLS: ChangeCipherSpecは<を終えました。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
EAP-Response/TTLS:
{EAP-Response/Identity}
-------------------->
EAP-応答/TTLS: EAP-応答/アイデンティティ-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Request:
EAP-Response/Identity
-------------------->
半径アクセス要求: EAP-応答/アイデンティティ-------------------->。
Funk & Blake-Wilson Informational [Page 44] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[44ページ]情報のRFC5281EAP-TTLSv0 2008年8月
RADIUS Access-Challenge
EAP-Request/
MD5-Challenge
<--------------------
MD5半径アクセス挑戦EAP-要求/挑戦<。--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
{EAP-Request/MD5-Challenge}
<--------------------
半径アクセス挑戦: EAP-要求/TTLS: MD5EAP-要求/挑戦<。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
EAP-Response/TTLS:
{EAP-Response/MD5-Challenge}
-------------------->
EAP-応答/TTLS: MD5EAP-応答/挑戦-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge
EAP-Response/
MD5-Challenge
-------------------->
MD5半径アクセス挑戦EAP-応答/挑戦-------------------->。
RADIUS Access-Accept
<--------------------
アクセスして受け入れている半径<。--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
半径はアクセスして受け入れます: EAP-成功<。--------------------
EAP-Success
<--------------------
EAP-成功<。--------------------
Funk & Blake-Wilson Informational [Page 45] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[45ページ]情報のRFC5281EAP-TTLSv0 2008年8月
15.3. Successful Session Resumption
15.3. うまくいっているセッション再開
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セッションを再開します。 ClientHelloの一部として再開するべきセッションのIDを送ります、そして、サーバはこのセッションのときにServerHelloの一部として同じセッションにIDを送ることによって再開するのに同意します。
client access point TTLS server AAA/H ------ ------------ ----------- -----
クライアントアクセスポイントTTLSサーバAAA/H------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-要求/アイデンティティ<。--------------------
EAP-Response/Identity
-------------------->
EAP-応答/アイデンティティ-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
半径アクセス挑戦: TTLS EAP-要求/スタート<。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
EAP-応答/TTLS: ClientHello-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
ChangeCipherSpec
Finished
<--------------------
半径アクセス挑戦: EAP-要求/TTLS: ServerHello ChangeCipherSpecは<を終えました。--------------------
EAP-Request passthrough
<--------------------
EAP-要求passthrough<。--------------------
Funk & Blake-Wilson Informational [Page 46] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[46ページ]情報のRFC5281EAP-TTLSv0 2008年8月
EAP-Response/TTLS:
ChangeCipherSpec
Finished
-------------------->
EAP-応答/TTLS: ChangeCipherSpecは終わりました。-------------------->。
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
半径アクセス要求: EAP-応答passthrough-------------------->。
RADIUS Access-Accept:
EAP-Success
<--------------------
半径はアクセスして受け入れます: EAP-成功<。--------------------
EAP-Success
<--------------------
EAP-成功<。--------------------
16. IANA Considerations
16. IANA問題
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.
EAP-TTLSのメソッドタイプが議定書を作るとき、IANAはNo.21(小数)を割り当てました。 新しいRADIUS、Diameter AVPs、および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によって確立された安全なトンネルの中でどう実行されるかもしれないかを指定します。 また、新しいメカニズムと他の機能はこのトンネルの中で実行されるかもしれません。 そのような拡大がベンダー特有でないAVPsを使用するところでは、新しいRFCsで彼らの意味論を指定しなければなりません。 すなわち、それぞれの個々のAVPの使用に関連するTTLS特有の処理規則があります、そのようなAVPsはRADIUSかDIAMETERのために既に定義されましたが。
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].
この仕様は、新しい登録(EAP- TTLS AVP Usage)の作成がIANAによって管理されるのを必要とします、それぞれを記載して非、-EAP-TTLSの中の使用のために定義されたベンダー特有のRADIUS/直径AVP、RFCか他のドキュメントの参照と共に、それが意味論を指定します。 AVPsの初期のリストはこのドキュメントのセクション13に記載されたものになるでしょう。 この登録の目的は異なった機能的な関係で利用される同じAVPから生じる潜在的あいまいさを避けることです。 この登録は数をAVPsに割り当てません、AVP番号が[RFC2865]と[RFC3588]に概説されているようにRADIUSとDiameter名前空間から割り当てられるとき。 トップレベルAVPs(すなわち、Grouped AVPsの中でカプセル化されなかったAVPs)だけが登録されるでしょう。 AVPsは[RFC5226]で定義されるようにIETF Reviewに基づくこの登録に加えられるべきです。
Funk & Blake-Wilson Informational [Page 47] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[47ページ]情報のRFC5281EAP-TTLSv0 2008年8月
17. Acknowledgements
17. 承認
Thanks to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen Hanna, Ryan Hurst, Avi Lior, and Gabriel Montenegro for careful reviews and useful comments.
慎重なレビューと役に立つコメントをバーナードAboba、ヤリArkko、Lakshminath Dondeti、スティーブン・ハンナ、ライアン・ハースト、アヴィLior、およびガブリエル・モンテネグロをありがとうございます。
18. References
18. 参照
18.1. Normative References
18.1. 引用規格
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、エド、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC2433] ゾルンとG.とS.コッブ、「マイクロソフトpppやつ拡大」、RFC2433、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問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2548] ゾルン、G.、「マイクロソフトのベンダー特有の半径属性」、RFC2548、1999年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
2759, January 2000.
[RFC2759] ゾルン、G.、「マイクロソフトpppやつ拡大、バージョン2インチ、RFC2759、2000年1月。」
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is
Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232] レイノルズ、J.、エド、「数は割り当てられました」。 「RFC1700はOn-系列DatabaseによるReplacedです」、RFC3232、2002年1月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、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.とカールソン、J.とH.Levkowetz、エド、「拡張認証プロトコル(EAP)」、RFC3748(2004年6月)
Funk & Blake-Wilson Informational [Page 48] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[48ページ]情報のRFC5281EAP-TTLSv0 2008年8月
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4282] AbobaとB.と用務員とM.とArkkoとJ.とP.Eronen、「ネットワークアクセス識別子」、RFC4282、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.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
2008年3月の[RFC5216]サイモンとD.とAboba、B.とR.ハースト、「EAP-TLS認証プロトコル」RFC5216。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC5247] Aboba、B.、サイモン、D.、およびP.Eronen、「拡張認証プロトコル(EAP)Key Managementフレームワーク」、RFC5247、2008年8月。
18.2. Informative References
18.2. 有益な参照
[802.1X] Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, December 2004.
[802.1X]米国電気電子技術者学会、「地方とメトロポリタンエリアネットワーク:」 「ポートベースのネットワークアクセスコントロール」、IEEEの標準の802.1X-2004、2004年12月。
[802.11] Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific Requirements Part
11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE Standard
802.11, 2007.
[802.11] 米国電気電子技術者学会、「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--特定のRequirements Part11:、」 「ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、IEEE規格802.11、2007。
[TTLS-EXT] Hanna, S. and P. Funk, "Key Agility Extensions for EAP-
TTLSv0", Work in Progress, September 2007.
[TTLS-EXT] ハンナとS.とP.ファンク、「EAP- TTLSv0"に、主要な機敏さ拡大、処理中の作業、2007年9月。」
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しは(CRL)プロフィールをリストアップします」、RFC5280、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.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、2004年4月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4366]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、2006年4月。
Funk & Blake-Wilson Informational [Page 49] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[49ページ]情報のRFC5281EAP-TTLSv0 2008年8月
[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.とニーベルグ、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]米国商務省標準技術局(「Key Managementのための推薦」、特別な公表800-57)は2006がそうするかもしれません。
Authors' Addresses
作者のアドレス
Paul Funk 43 Linnaean St. Cambridge, MA 02138 EMail: PaulFunk@alum.mit.edu
リンネの聖ケンブリッジ、MA 02138がメールするポールFunk43: PaulFunk@alum.mit.edu
Simon Blake-Wilson SafeNet Amstelveenseweg 88-90 1054XV, Amsterdam The Netherlands EMail: sblakewilson@nl.safenet-inc.com
XV、サイモンブレーク-ウィルソンSafeNet Amstelveenseweg88-90 1054アムステルダムオランダはメールされます: sblakewilson@nl.safenet-inc.com
Funk & Blake-Wilson Informational [Page 50] RFC 5281 EAP-TTLSv0 August 2008
ファンクとブレーク-ウィルソン[50ページ]情報のRFC5281EAP-TTLSv0 2008年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Funk & Blake-Wilson Informational [Page 51]
ファンクとブレーク-ウィルソンInformationalです。[51ページ]
一覧
スポンサーリンク
