RFC4851 日本語訳
4851 The Flexible Authentication via Secure Tunneling ExtensibleAuthentication Protocol Method (EAP-FAST). N. Cam-Winget, D. McGrew,J. Salowey, H. Zhou. May 2007. (Format: TXT=131460 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Cam-Winget
Request for Comments: 4851 D. McGrew
Category: Informational J. Salowey
H. Zhou
Cisco Systems
May 2007
カム-Wingetがコメントのために要求するワーキンググループN.をネットワークでつないでください: 4851年のD.マグリューカテゴリ: 情報のJ.Salowey H.周シスコシステムズ2007年5月
The Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol Method (EAP-FAST)
Secure Tunneling拡張認証プロトコルMethodを通したFlexible Authentication(速いEAP)
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server.
このドキュメントはSecure Tunneling(EAP-FAST)プロトコルで拡張認証プロトコルの(EAP)ベースのFlexible Authenticationを定義します。 EAP-FASTはTransport Layer Security(TLS)を使用するのによる同輩とサーバとの安全なコミュニケーションが互いに認証されたトンネルを確立するのを可能にするEAPメソッドです。 トンネルの中では、Type長さの価値(TLV)のオブジェクトは、同輩とEAPサーバの間に認証関連するデータを伝えるのに使用されます。
Cam-Winget, et al. Informational [Page 1] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [1ページ]情報のRFC4851速いEAP2007年5月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification Requirements . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Architectural Model . . . . . . . . . . . . . . . . . . . 6
2.2. Protocol Layering Model . . . . . . . . . . . . . . . . . 7
3. EAP-FAST Protocol . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 8
3.2. EAP-FAST Authentication Phase 1: Tunnel Establishment . . 9
3.2.1. TLS Session Resume Using Server State . . . . . . . . 10
3.2.2. TLS Session Resume Using a PAC . . . . . . . . . . . . 10
3.2.3. Transition between Abbreviated and Full TLS
Handshake . . . . . . . . . . . . . . . . . . . . . . 12
3.3. EAP-FAST Authentication Phase 2: Tunneled
Authentication . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. EAP Sequences . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Protected Termination and Acknowledged Result
Indication . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Determining Peer-Id and Server-Id . . . . . . . . . . . . 14
3.5. EAP-FAST Session Identifier . . . . . . . . . . . . . . . 15
3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1. TLS Layer Errors . . . . . . . . . . . . . . . . . . . 15
3.6.2. Phase 2 Errors . . . . . . . . . . . . . . . . . . . . 16
3.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 16
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. EAP-FAST Message Format . . . . . . . . . . . . . . . . . 18
4.1.1. Authority ID Data . . . . . . . . . . . . . . . . . . 20
4.2. EAP-FAST TLV Format and Support . . . . . . . . . . . . . 20
4.2.1. General TLV Format . . . . . . . . . . . . . . . . . . 21
4.2.2. Result TLV . . . . . . . . . . . . . . . . . . . . . . 22
4.2.3. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.4. Error TLV . . . . . . . . . . . . . . . . . . . . . . 24
4.2.5. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 25
4.2.6. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 26
4.2.7. Intermediate-Result TLV . . . . . . . . . . . . . . . 28
4.2.8. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 29
4.2.9. Request-Action TLV . . . . . . . . . . . . . . . . . . 31
4.3. Table of TLVs . . . . . . . . . . . . . . . . . . . . . . 32
5. Cryptographic Calculations . . . . . . . . . . . . . . . . . . 32
5.1. EAP-FAST Authentication Phase 1: Key Derivations . . . . . 32
5.2. Intermediate Compound Key Derivations . . . . . . . . . . 33
5.3. Computing the Compound MAC . . . . . . . . . . . . . . . . 34
5.4. EAP Master Session Key Generation . . . . . . . . . . . . 35
5.5. T-PRF . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 仕様書要求事項. . . . . . . . . . . . . . . . 5 1.2。 用語. . . . . . . . . . . . . . . . . . . . . . . 5 2。 概要. . . . . . . . . . . . . . . . . . . . . . 6 2.1について議定書の中で述べてください。 建築モデル. . . . . . . . . . . . . . . . . . . 6 2.2。 モデル. . . . . . . . . . . . . . . . . 7 3を層にして、議定書を作ってください。 速いEAPは.83.1について議定書の中で述べます。 バージョン交渉. . . . . . . . . . . . . . . . . . . 8 3.2。 速いEAP認証フェーズ1: 設立. . 9 3.2.1にトンネルを堀ってください。 サーバ州. . . . . . . . 10 3.2の.2を使用するTLSセッション履歴書。 PAC. . . . . . . . . . . . 10 3.2.3を使用するTLSセッション履歴書。 簡略化されて完全なTLS握手. . . . . . . . . . . . . . . . . . . . . . 12 3.3の間の変遷。 速いEAP認証フェーズ2: 認証. . . . . . . . . . . . . . . . . . . . . . 12 3.3.1にトンネルを堀りました。 EAP系列. . . . . . . . . . . . . . . . . . . . 13 3.3.2。 終了を保護して、結果指示. . . . . . . . . . . . . . . . . . . . . . 13 3.4を承諾しました。 同輩イドとサーバイド.143.5を決定します。 速いEAPセッション識別子. . . . . . . . . . . . . . . 15 3.6。 エラー処理. . . . . . . . . . . . . . . . . . . . . . 15 3.6.1。 TLSは誤り. . . . . . . . . . . . . . . . . . . 15 3.6.2を層にします。 2つの誤り. . . . . . . . . . . . . . . . . . . . 16 3.7の位相を合わせてください。 断片化. . . . . . . . . . . . . . . . . . . . . . 16 4。 メッセージ・フォーマット. . . . . . . . . . . . . . . . . . . . . . . 18 4.1。 速いEAPメッセージ・フォーマット. . . . . . . . . . . . . . . . . 18 4.1.1。 権威IDデータ. . . . . . . . . . . . . . . . . . 20 4.2。 速いEAP TLV形式とサポート. . . . . . . . . . . . . 20 4.2.1。 一般TLV形式. . . . . . . . . . . . . . . . . . 21 4.2.2。 結果TLV. . . . . . . . . . . . . . . . . . . . . . 22 4.2.3。 NAK TLV. . . . . . . . . . . . . . . . . . . . . . . 23 4.2.4。 誤りTLV. . . . . . . . . . . . . . . . . . . . . . 24 4.2.5。 ベンダー特有のTLV. . . . . . . . . . . . . . . . . 25 4.2.6。 EAP-有効搭載量TLV. . . . . . . . . . . . . . . . . . . 26 4.2.7。 中間結果TLV. . . . . . . . . . . . . . . 28 4.2.8。 暗号を拘束力があるTLV. . . . . . . . . . . . . . . . . . 29 4.2.9。 要求動作TLV. . . . . . . . . . . . . . . . . . 31 4.3。 TLVs. . . . . . . . . . . . . . . . . . . . . . 32 5のテーブル。 暗号の計算. . . . . . . . . . . . . . . . . . 32 5.1。 速いEAP認証フェーズ1: 主要な派生. . . . . 32 5.2。 中間的合成主要な派生. . . . . . . . . . 33 5.3。 MAC.345.4に化合物を計算します。 EAPはセッションキー生成. . . . . . . . . . . . 35 5.5を支配します。 T-PRF. . . . . . . . . . . . . . . . . . . . . . . . . . 35 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 36
Cam-Winget, et al. Informational [Page 2] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [2ページ]情報のRFC4851速いEAP2007年5月
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7.1. Mutual Authentication and Integrity Protection . . . . . . 37
7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . . 38
7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 38
7.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies . . . . . . . . . . . . . . . . . . . . . . . 39
7.4.1. User Identity Protection and Verification . . . . . . 39
7.4.2. Dictionary Attack Resistance . . . . . . . . . . . . . 40
7.4.3. Protection against Man-in-the-Middle Attacks . . . . . 40
7.4.4. PAC Binding to User Identity . . . . . . . . . . . . . 41
7.5. Protecting against Forged Clear Text EAP Packets . . . . . 41
7.6. Server Certificate Validation . . . . . . . . . . . . . . 42
7.7. Tunnel PAC Considerations . . . . . . . . . . . . . . . . 42
7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 43
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Successful Authentication . . . . . . . . . . . . . . . . 46
A.2. Failed Authentication . . . . . . . . . . . . . . . . . . 47
A.3. Full TLS Handshake using Certificate-based Ciphersuite . . 48
A.4. Client Authentication during Phase 1 with Identity
Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.5. Fragmentation and Reassembly . . . . . . . . . . . . . . . 52
A.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 53
A.7. Failed Crypto-Binding . . . . . . . . . . . . . . . . . . 56
A.8. Sequence of EAP Method with Vendor-Specific TLV
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 57
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 60
B.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 60
B.2. Crypto-Binding MIC . . . . . . . . . . . . . . . . . . . . 62
7. セキュリティ問題. . . . . . . . . . . . . . . . . . . 37 7.1。 互いの認証と保全保護. . . . . . 37 7.2。 メソッド交渉. . . . . . . . . . . . . . . . . . . . 38 7.3。 フェーズ1とフェーズ2サーバ. . . . . . . . 38 7.4の分離。 知られている脆弱性とプロトコル欠乏. . . . . . . . . . . . . . . . . . . . . . . 39 7.4.1の緩和。 ユーザアイデンティティ保護と検証. . . . . . 39 7.4.2。 辞書攻撃抵抗. . . . . . . . . . . . . 40 7.4.3。 介入者攻撃. . . . . 40 7.4.4に対する保護。 ユーザアイデンティティ. . . . . . . . . . . . . 41 7.5に付くPAC。 偽造クリアテキストEAPパケット. . . . . 41 7.6から守ります。 サーバ証明書合法化. . . . . . . . . . . . . . 42 7.7。 PAC問題. . . . . . . . . . . . . . . . 42 7.8にトンネルを堀ってください。 セキュリティは.438を要求します。 承認. . . . . . . . . . . . . . . . . . . . . . . 44 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 44 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 45付録A.の例. . . . . . . . . . . . . . . . . . . . . . 46のA.1。 うまくいっている認証. . . . . . . . . . . . . . . . 46A.2。 失敗した認証. . . . . . . . . . . . . . . . . . 47A.3。 証明書ベースのCiphersuite. . 48A.4を使用する完全なTLS握手。 アイデンティティプライバシー. . . . . . . . . . . . . . . . . . . . . . . . . 50A.5との段階1の間のクライアント認証。 断片化とReassembly. . . . . . . . . . . . . . . 52A.6。 EAPメソッド. . . . . . . . . . . . . . . . . 53A.7の系列。 失敗した暗号を拘束力がある.56A.8。 ベンダー特有のTLV交換. . . . . . . . . . . . . . . . . . . . . . . . . 57付録B.テストベクトル. . . . . . . . . . . . . . . . . . . . 60B.1があるEAPメソッドの系列。 主要な派生. . . . . . . . . . . . . . . . . . . . . . 60B.2。 暗号を拘束力があるMIC. . . . . . . . . . . . . . . . . . . . 62
Cam-Winget, et al. Informational [Page 3] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [3ページ]情報のRFC4851速いEAP2007年5月
1. Introduction
1. 序論
Network access solutions requiring user friendly and easily deployable secure authentication mechanisms highlight the need for strong mutual authentication protocols that enable the use of weaker user credentials. This document defines an Extensible Authentication Protocol (EAP), which consists of establishing a Transport Layer Security (TLS) tunnel using TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], or a successor version of TLS, using the latest version supported by both parties. Once the tunnel is established, the protocol further exchanges data in the form of type, length, and value objects (TLV) to perform further authentication. EAP-FAST supports the TLS extension defined in [RFC4507] to support fast re-establishment of the secure tunnel without having to maintain per-session state on the server. [EAP-PROV] defines EAP-FAST-based mechanisms to provision the credential for this extension which is called a Protected Access Credential (PAC).
ユーザフレンドリーで容易に配布可能な安全な認証機構を必要とするネットワークアクセスソリューションが、より弱いユーザ資格証明書の使用を可能にする強い互いの認証プロトコルの必要性を強調します。 このドキュメントは拡張認証プロトコル(EAP)を定義します、双方によってサポートされた最新版を使用して。(拡張認証プロトコルはTLS1.0[RFC2246]、TLS1.1[RFC4346]、またはTLSの後継者バージョンを使用することでTransport Layer Security(TLS)トンネルを確立するのから成ります)。 トンネルがいったん確立されると、プロトコルは、さらなる認証を実行するためにタイプ、長さ、および値のオブジェクト(TLV)の形でさらにデータを交換します。 EAP-FASTは、TLSがProtected Access Credential(PAC)と呼ばれるこの拡大のために安全なトンネルの. サーバ[EAP-PROV]の1セッションあたりの州がEAP-FASTベースのメカニズムを支給と定義すると主張する必要はなくて再建が資格証明書であると速くサポートするために[RFC4507]で定義された拡大であるとサポートします。
EAP-FAST's design motivations included:
EAP-FASTのデザイン動機は:だった
o Mutual authentication: an EAP server must be able to verify the
identity and authenticity of the peer, and the peer must be able
to verify the authenticity of the EAP server.
o 互いの認証: EAPサーバは同輩のアイデンティティと信憑性について確かめることができなければなりません、そして、同輩はEAPサーバの信憑性について確かめることができなければなりません。
o Immunity to passive dictionary attacks: many authentication
protocols require a password to be explicitly provided (either as
cleartext or hashed) by the peer to the EAP server; at minimum,
the communication of the weak credential (e.g., password) must be
immune from eavesdropping.
o 受け身の辞書への免疫は攻撃されます: 多くの認証プロトコルが、パスワードが同輩によって明らかにEAPサーバに提供されるのを(cleartextか論じ尽くされるとして)必要とします。 最小限では、弱い資格証明書(例えば、パスワード)のコミュニケーションは盗聴から免疫であるに違いありません。
o Immunity to man-in-the-middle (MitM) attacks: in establishing a
mutually authenticated protected tunnel, the protocol must prevent
adversaries from successfully interjecting information into the
conversation between the peer and the EAP server.
o 中央の男性(MitM)への免疫は攻撃されます: 互いに認証された保護されたトンネルを確立する際に、プロトコルによって、敵は首尾よく同輩とEAPサーバとの会話に情報を挿入できなくなければなりません。
o Flexibility to enable support for most password authentication
interfaces: as many different password interfaces (e.g., Microsoft
Challenge Handshake Authentication Protocol (MS-CHAP), Lightweight
Directory Access Protocol (LDAP), One-Time Password (OTP), etc.)
exist to authenticate a peer, the protocol must provide this
support seamlessly.
o ほとんどのパスワード認証のサポートを可能にする柔軟性は連結します: 多くの異なったパスワードインタフェース(例えば、マイクロソフトチャレンジハンドシェイク式認証プロトコル(さん-CHAP)、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)、One-時間Password(OTP)など)が同輩を認証するために存在するとき、プロトコルはシームレスにこのサポートを提供しなければなりません。
o Efficiency: specifically when using wireless media, peers will be
limited in computational and power resources. The protocol must
enable the network access communication to be computationally
lightweight.
o 効率: 特にワイヤレスのメディアを使用するとき、同輩はコンピュータとパワーリソースで制限されるでしょう。 プロトコルは、ネットワークアクセスコミュニケーションが計算上軽量であることを可能にしなければなりません。
Cam-Winget, et al. Informational [Page 4] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [4ページ]情報のRFC4851速いEAP2007年5月
With these motivational goals defined, further secondary design criteria are imposed:
これらの動機づけの目標が定義されている状態で、さらなるセカンダリ設計基準は課されます:
o Flexibility to extend the communications inside the tunnel: with
the growing complexity in network infrastructures, the need to
gain authentication, authorization, and accounting is also
evolving. For instance, there may be instances in which multiple
existing authentication protocols are required to achieve mutual
authentication. Similarly, different protected conversations may
be required to achieve the proper authorization once a peer has
successfully authenticated.
o トンネルの中でコミュニケーションを広げる柔軟性: また、ネットワークインフラにおける増加している複雑さによると、認証、承認、および会計を獲得する必要性は発展しています。 例えば、複数の既存の認証プロトコルが互いの認証を達成するのに必要であるインスタンスがあるかもしれません。 同様に、同輩がいったん首尾よく認証されていた状態で必要であると、異なった保護された会話が、適切な承認を達成するのに必要であるかもしれません。
o Minimize the authentication server's per user authentication state
requirements: with large deployments, it is typical to have many
servers acting as the authentication servers for many peers. It
is also highly desirable for a peer to use the same shared secret
to secure a tunnel much the same way it uses the username and
password to gain access to the network. The protocol must
facilitate the use of a single strong shared secret by the peer
while enabling the servers to minimize the per user and device
state it must cache and manage.
o サーバのユーザー認証州の要件あたりの認証ものを最小にしてください: 大きい展開で、多くの同輩のための認証サーバとして機能する多くのサーバを持っているのは典型的です。 また、同輩がトンネルに大体同じことを機密保護するのに同じ共有秘密キーを使用するのに、ずっと、ネットワークへの利得アクセスにユーザ名とパスワードを使用するのも、非常に望ましいです。 プロトコルが最小にするサーバを可能にしている間、同輩によるただ一つの強い分配している秘密の使用を容易にしなければならない、ユーザとデバイスに従って、キャッシュして、管理しなければならないと述べてください。
1.1. Specification Requirements
1.1. 仕様書要求事項
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]で説明されるように本書では解釈されることであるべきですか?
1.2. Terminology
1.2. 用語
Much of the terminology in this document comes from [RFC3748]. Additional terms are defined below:
用語の多くが[RFC3748]から本書では来ます。 追加用語は以下で定義されます:
Protected Access Credential (PAC)
保護されたアクセス資格証明書(PAC)
Credentials distributed to a peer for future optimized network
authentication. The PAC consists of, at most, three components: a
shared secret, an opaque element, and optionally other
information. The shared secret component contains the pre-shared
key between the peer and the authentication server. The opaque
part is provided to the peer and is presented to the
authentication server when the peer wishes to obtain access to
network resources. Finally, a PAC may optionally include other
information that may be useful to the peer. The opaque part of
the PAC is the same type of data as the ticket in [RFC4507] and
the shared secret is used to derive the TLS master secret.
未来の同輩に分配された資格証明書はネットワーク認証を最適化しました。 PACは大部分の3つのコンポーネントから成ります: 共有秘密キー、不明瞭な要素、および任意に他の情報。 共有秘密キーコンポーネントは同輩と認証サーバの間にあらかじめ共有されたキーを含んでいます。同輩がネットワーク資源へのアクセスを得たがっているとき、不透明な部分は、同輩に提供されて、認証サーバに示されます。 最終的に、PACは任意に同輩の役に立つかもしれない他の情報を含むかもしれません。 [RFC4507]のチケットと共有秘密キーがTLSマスター秘密を引き出すのに使用されるとき、PACの不透明な部分は同じタイプに関するデータです。
Cam-Winget, et al. Informational [Page 5] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [5ページ]情報のRFC4851速いEAP2007年5月
2. Protocol Overview
2. プロトコル概要
EAP-FAST is an authentication protocol similar to EAP-TLS [RFC2716] that enables mutual authentication and cryptographic context establishment by using the TLS handshake protocol. EAP-FAST allows for the established TLS tunnel to be used for further authentication exchanges. EAP-FAST makes use of TLVs to carry out the inner authentication exchanges. The tunnel is then used to protect weaker inner authentication methods, which may be based on passwords, and to communicate the results of the authentication.
EAP-FASTはTLS握手プロトコルを使用することによって互いの認証と暗号の文脈設立を可能にするEAP-TLS[RFC2716]と同様の認証プロトコルです。 EAP-FASTは、確立したTLSトンネルがさらなる認証交換に使用されるのを許容します。 EAP-FASTは、内側の認証交換を行うのにTLVsを利用します。 そして、トンネルは、パスワードに基づくかもしれないより弱い内側の認証方法を保護して、認証の結果を伝えるのに使用されます。
EAP-FAST makes use of the TLS enhancements in [RFC4507] to enable an optimized TLS tunnel session resume while minimizing server state. The secret key used in EAP-FAST is referred to as the Protected Access Credential key (or PAC-Key); the PAC-Key is used to mutually authenticate the peer and the server when securing a tunnel. The ticket is referred to as the Protected Access Credential opaque data (or PAC-Opaque). The secret key and ticket used to establish the tunnel may be provisioned through mechanisms that do not involve the TLS handshake. It is RECOMMENDED that implementations support the capability to distribute the ticket and secret key within the EAP- FAST tunnel as specified in [EAP-PROV].
EAP-FASTは、サーバ状態を最小にしている間、最適化されたTLSトンネルセッション履歴書を可能にするのに[RFC4507]でTLS増進を利用します。 EAP-FASTで使用される秘密鍵はProtected Access Credentialキー(または、PAC-キー)と呼ばれます。 PAC-キーは、トンネルを固定するとき、互いに同輩とサーバを認証するのに使用されます。 チケットはProtected Access Credentialの不明瞭なデータ(または、PAC-不透明なもの)と呼ばれます。 トンネルを証明するのに使用される秘密鍵とチケットはTLS握手にかかわらないメカニズムを通して食糧を供給されるかもしれません。 実装が[EAP-PROV]の指定されるとしてのEAP- FASTトンネルの中でチケットと秘密鍵を分配する能力をサポートするのは、RECOMMENDEDです。
The EAP-FAST conversation is used to establish or resume an existing session to typically establish network connectivity between a peer and the network. Upon successful execution of EAP-FAST, both EAP peer and EAP server derive strong session key material that can then be communicated to the network access server (NAS) for use in establishing a link layer security association.
EAP-FASTの会話は、同輩とネットワークの間のネットワークの接続性を通常証明するために既存のセッションを確立するか、または再開するのに使用されます。 EAP-FASTのうまくいっている実行のときに、EAP同輩とEAPサーバの両方が次にリンクレイヤセキュリティ協会を設立することにおける使用のためのネットワークアクセス・サーバー(NAS)に伝えることができる強いセッション主要な材料を誘導します。
2.1. Architectural Model
2.1. 建築モデル
The network architectural model for EAP-FAST usage is shown below:
EAP-FAST用法のための建築モデルが以下で見せられるネットワーク:
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| EAP-FAST |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
+----------+ +----------+ +----------+ +----------+ | | | | | | | 内側| | 同輩| <、-、-、--、>| Authen| <、-、-、--、>| 速いEAP| <、-、-、--、>| メソッド| | | | ticator| | サーバ| | サーバ| | | | | | | | | +----------+ +----------+ +----------+ +----------+
EAP-FAST Architectural Model
速いEAPの建築モデル
The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the EAP-FAST server and inner method server might be a single entity; the authenticator and EAP-FAST server might be a single entity; or the functions of the authenticator, EAP-FAST server, and inner method
上に表現された実体は、論理的な実体であり、ネットワーク要素を切り離すために対応するかもしれません。 例えば、EAP-FASTサーバと内側のメソッドサーバは単一体であるかもしれません。 固有識別文字とEAP-FASTサーバは単一体であるかもしれません。 または、固有識別文字、EAP-FASTサーバ、および内側のメソッドの機能
Cam-Winget, et al. Informational [Page 6] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [6ページ]情報のRFC4851速いEAP2007年5月
server might be combined into a single physical device. For example, typical 802.11 deployments place the Authenticator in an access point (AP) while a Radius server may provide the EAP-FAST and inner method server components. The above diagram illustrates the division of labor among entities in a general manner and shows how a distributed system might be constructed; however, actual systems might be realized more simply. The security considerations Section 7.3 provides an additional discussion of the implications of separating the EAP-FAST server from the inner method server.
サーバは単一のフィジカル・デバイスに結合されるかもしれません。 例えば、RadiusサーバがEAP-FASTと内側のメソッドサーバコンポーネントを提供しているかもしれない間、典型的な802.11の展開がアクセスポイント(AP)にAuthenticatorを置きます。 上のダイヤグラムは、実体の中で一般的な方法で分業を例証して、分散システムがどう構成されるかもしれないかを示しています。 しかしながら、実際のシステムは、より単に実現されるかもしれません。 セクション7.3が内側のメソッドサーバとEAP-FASTサーバを切り離す含意の追加議論を提供するセキュリティ問題。
2.2. Protocol Layering Model
2.2. プロトコルレイヤリングモデル
EAP-FAST packets are encapsulated within EAP; EAP in turn requires a carrier protocol for transport. EAP-FAST packets encapsulate TLS, which is then used to encapsulate user authentication information. Thus, EAP-FAST messaging can be described using a layered model, where each layer encapsulates the layer above it. The following diagram clarifies the relationship between protocols:
EAP-FASTパケットはEAPの中でカプセルに入れられます。 EAPは輸送のために順番にキャリヤープロトコルを必要とします。 EAP-FASTパケットはTLSをカプセル化します。(次に、TLSは、ユーザー認証情報をカプセル化するのに使用されます)。 したがって、層にされたモデル(各層はそれの上で層をカプセルに入れる)を使用することでEAP-FASTメッセージングについて説明できます。 以下のダイヤグラムはプロトコルの間の関係をはっきりさせます:
+---------------------------------------------------------------+
| Inner EAP Method | Other TLV information |
|---------------------------------------------------------------|
| TLV Encapsulation (TLVs) |
|---------------------------------------------------------------|
| TLS |
|---------------------------------------------------------------|
| EAP-FAST |
|---------------------------------------------------------------|
| EAP |
|---------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | 内側のEAPメソッド| 他のTLV情報| |---------------------------------------------------------------| | TLVカプセル化(TLVs)| |---------------------------------------------------------------| | TLS| |---------------------------------------------------------------| | 速いEAP| |---------------------------------------------------------------| | EAP| |---------------------------------------------------------------| | キャリヤープロトコル(ラン、RADIUS、Diameterなどの上のEAP) | +---------------------------------------------------------------+
Protocol Layering Model
プロトコルレイヤリングモデル
The TLV layer is a payload with Type-Length-Value (TLV) Objects defined in Section 4.2. The TLV objects are used to carry arbitrary parameters between an EAP peer and an EAP server. All conversations in the EAP-FAST protected tunnel must be encapsulated in a TLV layer.
TLV層はType長さの価値(TLV)のオブジェクトがセクション4.2で定義されているペイロードです。 TLVオブジェクトによる. EAP-FASTでのすべての会話が保護したEAP同輩とEAPサーバの間の任意のパラメタを運ぶのに使用されて、TLV層の中でトンネルをカプセル化しなければならないということです。
Methods for encapsulating EAP within carrier protocols are already defined. For example, IEEE 802.1X [IEEE.802-1X.2004] may be used to transport EAP between the peer and the authenticator; RADIUS [RFC3579] or Diameter [RFC4072] may be used to transport EAP between the authenticator and the EAP-FAST server.
キャリヤープロトコルの中でEAPをカプセル化するためのメソッドは既に定義されます。 例えば、IEEE 802.1X[IEEE.802-1×.2004]は同輩と固有識別文字の間でEAPを輸送するのに使用されるかもしれません。 RADIUS[RFC3579]かDiameter[RFC4072]が、固有識別文字とEAP-FASTサーバの間でEAPを輸送するのに使用されるかもしれません。
Cam-Winget, et al. Informational [Page 7] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [7ページ]情報のRFC4851速いEAP2007年5月
3. EAP-FAST Protocol
3. 速いEAPプロトコル
EAP-FAST authentication occurs in two phases. In the first phase, EAP-FAST employs the TLS handshake to provide an authenticated key exchange and to establish a protected tunnel. Once the tunnel is established the second phase begins with the peer and server engaging in further conversations to establish the required authentication and authorization policies. The operation of the protocol, including Phase 1 and Phase 2, are the topic of this section. The format of EAP-FAST messages is given in Section 4 and the cryptographic calculations are given in Section 5.
EAP-FAST認証は二相で起こります。 第1段階では、EAP-FASTは、認証された主要な交換を供給して、保護されたトンネルを証明するのにTLS握手を使います。 トンネルがいったん確立されると、同輩とサーバがさらなる会話に従事している状態で、2番目のフェーズは必要な認証と承認方針を確立し始めます。 Phase1とPhase2を含むプロトコルの操作はこのセクションの話題です。 セクション4でEAP-FASTメッセージの書式を与えます、そして、セクション5で暗号の計算を与えます。
3.1. Version Negotiation
3.1. バージョン交渉
EAP-FAST packets contain a 3-bit version field, following the TLS Flags field, which enables EAP-FAST implementations to be backward compatible with previous versions of the protocol. This specification documents the EAP-FAST version 1 protocol; implementations of this specification MUST use a version field set to 1.
EAP-FASTパケットは3ビットのバージョン分野を含んでいます、TLS Flags野原(EAP-FAST実装がプロトコルの旧バージョンと互換性があった状態で後方であることを可能にする)に続いて。 この仕様はEAP-FASTバージョン1プロトコルを記録します。 この仕様の実装はバージョン分野セットを1まで使用しなければなりません。
Version negotiation proceeds as follows:
バージョン交渉は以下の通り続きます:
In the first EAP-Request sent with EAP type=EAP-FAST, the EAP
server must set the version field to the highest supported version
number.
EAPタイプで送られた最初のEAP-要求=EAP-FASTでは、EAPサーバはバージョン番号であるとサポートされる中で最も高いものにバージョン分野を設定しなければなりません。
If the EAP peer supports this version of the protocol, it MUST
respond with an EAP-Response of EAP type=EAP-FAST, and the version
number proposed by the EAP-FAST server.
EAP同輩がプロトコルのこのバージョンをサポートするなら、EAPのEAP-応答でタイプ=EAP-FASTを反応させなければなりません、そして、バージョン番号はEAP-FASTサーバで提案しました。
If the EAP-FAST peer does not support this version, it responds
with an EAP-Response of EAP type=EAP-FAST and the highest
supported version number.
EAP-FAST同輩がこのバージョンをサポートしないなら、それはEAPのEAP-応答でタイプ=EAP-FASTとバージョン番号であるとサポートされる中で最も高いものを反応させます。
If the EAP-FAST server does not support the version number
proposed by the EAP-FAST peer, it terminates the conversation.
Otherwise the EAP-FAST conversation continues.
EAP-FASTサーバが、バージョンがEAP-FAST同輩によって提案された数であるとサポートしないなら、それは会話を終えます。 さもなければ、EAP-FASTの会話は続きます。
The version negotiation procedure guarantees that the EAP-FAST peer and server will agree to the latest version supported by both parties. If version negotiation fails, then use of EAP-FAST will not be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed.
バージョン交渉手順は、EAP-FAST同輩とサーバが双方によってサポートされた最新版に同意するのを保証します。 バージョン交渉が失敗すると、EAP-FASTの使用は可能にならないでしょう、そして、認証が続くつもりであると、別の互いに許容できるEAPメソッドは交渉される必要があるでしょう。
The EAP-FAST version is not protected by TLS; and hence can be modified in transit. In order to detect a modification of the EAP- FAST version, the peers MUST exchange the EAP-FAST version number
EAP-FASTバージョンはTLSによって保護されません。 そして、したがって、トランジットで変更できます。 EAP- FASTバージョンの変更を検出するために、同輩はEAP-FASTバージョン番号を交換しなければなりません。
Cam-Winget, et al. Informational [Page 8] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [8ページ]情報のRFC4851速いEAP2007年5月
received during version negotiation using the Crypto-Binding TLV described in Section 4.2.8. The receiver of the Crypto-Binding TLV MUST verify that the version received in the Crypto-Binding TLV matches the version sent by the receiver in the EAP-FAST version negotiation.
セクション4.2.8で説明されたCryptoを拘束力があるTLVを使用するバージョン交渉の間、受け取られています。 バージョンがCryptoを拘束力があるTLVで受けたTLV MUSTが確かめるCrypto-結合の受信機は受信機によってEAP-FASTバージョン交渉で送られたバージョンに合っています。
3.2. EAP-FAST Authentication Phase 1: Tunnel Establishment
3.2. 速いEAP認証フェーズ1: トンネル設立
EAP-FAST is based on the TLS handshake [RFC2246] to establish an authenticated and protected tunnel. The TLS version offered by the peer and server MUST be TLS v1.0 or later. This version of the EAP- FAST implementation MUST support the following TLS ciphersuites:
EAP-FASTは、認証されて保護されたトンネルを証明するためにTLS握手[RFC2246]に基づいています。 同輩とサーバによって提供されたTLSバージョンはTLS v1.0以降であるに違いありません。 EAP- FAST実装のこのバージョンは以下のTLS ciphersuitesをサポートしなければなりません:
TLS_RSA_WITH_RC4_128_SHA
_RC4_128_SHAとTLS_RSA_
TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268]
_AES_128_CBC_SHAとTLS_RSA_[RFC3268]
TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC3268]
_AES_128_CBC_SHAとTLS_DHE_RSA_[RFC3268]
Other ciphersuites MAY be supported. It is RECOMMENDED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in [EAP-PROV]. Care must be taken to address potential man-in-the-middle attacks when ciphersuites that do not provide authenticated tunnel establishment are used. During the EAP-FAST Phase 1 conversation the EAP-FAST endpoints MAY negotiate TLS compression.
他のciphersuitesはサポートされるかもしれません。 そんなに匿名のRECOMMENDEDが_やがてTLS_DHなどのようにciphersuitesするということである、_WITH_AES_128_CBC_SHA、[EAP-PROV]で説明された食糧を供給することの文脈で単に使用されてください。 認証されたトンネル設立を提供しないciphersuitesが使用されているとき、潜在的介入者攻撃を扱うために注意しなければなりません。 EAP-FAST Phase1の会話の間、EAP-FAST終点はTLS圧縮を交渉するかもしれません。
The EAP server initiates the EAP-FAST conversation with an EAP request containing an EAP-FAST/Start packet. This packet includes a set Start (S) bit, the EAP-FAST version as specified in Section 3.1, and an authority identity. The TLS payload in the initial packet is empty. The authority identity (A-ID) is used to provide the peer a hint of the server's identity that may be useful in helping the peer select the appropriate credential to use. Assuming that the peer supports EAP-FAST the conversation continues with the peer sending an EAP-Response packet with EAP type of EAP-FAST with the Start (S) bit clear and the version as specified in Section 3.1. This message encapsulates one or more TLS records containing the TLS handshake messages. If the EAP-FAST version negotiation is successful then the EAP-FAST conversation continues until the EAP server and EAP peer are ready to enter Phase 2. When the full TLS handshake is performed, then the first payload of EAP-FAST Phase 2 MAY be sent along with server-finished handshake message to reduce the number of round trips.
EAPサーバはEAP-FAST/スタートパケットを含んでいるEAP要求とのEAP-FASTの会話を開始します。 このパケットはセットStart(S)ビット、セクション3.1の指定されるとしてのEAP-FASTバージョン、および権威のアイデンティティを含んでいます。 初期のパケットのTLSペイロードは空です。 権威のアイデンティティ(A-ID)は、サーバの同輩が適切な資格証明書を選択するのを助ける際に使用の役に立つかもしれないアイデンティティのヒントを同輩に提供するのに使用されます。 同輩が、EAP-FASTが会話であるとサポートすると仮定するのがStart(S)ビットが明確であり、指定されるとしてのバージョンがセクション3.1にある状態でEAP-FASTのEAPタイプでEAP-応答パケットを送る同輩を続行します。 このメッセージは、1TLSがTLS握手メッセージを含む記録であるとカプセル化します。 EAP-FASTバージョン交渉がうまくいくなら、EAPサーバとEAP同輩がPhase2に入る準備ができるまで、EAP-FASTの会話は続きます。 完全なTLS握手を実行すると、周遊旅行の数を減少させるサーバで終わっている握手メッセージと共にEAP-FAST Phase2の最初のペイロードを送るかもしれません。
After the TLS session is established, another EAP exchange MAY occur within the tunnel to authenticate the EAP peer. EAP-FAST implementations MUST support client authentication during tunnel
TLSセッションが確立された後に、別のEAP交換は、EAP同輩を認証するためにトンネルの中に起こるかもしれません。 EAP-FAST実装はトンネルの間、クライアント認証をサポートしなければなりません。
Cam-Winget, et al. Informational [Page 9] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [9ページ]情報のRFC4851速いEAP2007年5月
establishment using the TLS ciphersuites specified in Section 3.2. EAP-FAST implementations SHOULD also support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current ciphersuite. This allows support for protection of the peer's identity. Note that the EAP peer does not need to authenticate as part of the TLS exchange, but can alternatively be authenticated through additional EAP exchanges carried out in Phase 2.
TLS ciphersuitesを使用する設立がセクション3.2で指定しました。 また、EAP-FAST実装SHOULDは、現在のciphersuiteの保護で新しい握手交換処理に着手するためにTLSセッションの即座の再交渉をサポートします。 これは同輩のアイデンティティの保護のサポートを許します。 TLS交換の一部として認証する必要はありませんが、あるいはまたEAP同輩を認証できる追加EAPが交換する注意はPhase2で運ばれました。
The EAP-FAST tunnel protects peer identity information from disclosure outside the tunnel. Implementations that wish to provide identity privacy for the peer identity must carefully consider what information is disclosed outside the tunnel.
EAP-FASTトンネルはトンネルの外での公開から同輩アイデンティティ情報を保護します。 アイデンティティプライバシーを同輩のアイデンティティに提供したがっている実装は、どんな情報がトンネルの外で明らかにされるかを慎重に考えなければなりません。
The following sections describe resuming a TLS session based on server-side or client-side state.
以下のセクションは、サーバ側かクライアントサイド州に基づくTLSセッションを再開すると説明します。
3.2.1. TLS Session Resume Using Server State
3.2.1. サーバ状態を使用するTLSセッション履歴書
EAP-FAST session resumption is achieved in the same manner TLS achieves session resume. To support session resumption, the server and peer must minimally cache the SessionID, master secret, and ciphersuite. The peer attempts to resume a session by including a valid SessionID from a previous handshake in its ClientHello message. If the server finds a match for the SessionID and is willing to establish a new connection using the specified session state, the server will respond with the same SessionID and proceed with the EAP- FAST Authentication Phase 1 tunnel establishment based on a TLS abbreviated handshake. After a successful conclusion of the EAP-FAST Authentication Phase 1 conversation, the conversation then continues on to Phase 2.
再開が同じ方法TLSで達成されるEAP-FASTセッションはセッション履歴書を実現します。 セッション再開、サーバ、および同輩をサポートするのはSessionID、マスター秘密、およびciphersuiteを最少量でキャッシュしなければなりません。 同輩は、ClientHelloメッセージにおける前の握手から有効なSessionIDを含んでいることによってセッションを再開するのを試みます。 サーバが、SessionIDに関してマッチを見つけて、指定されたセッション状態を使用することで新しい接続を確立しても構わないと思っていると、サーバは、簡略化された握手を同じSessionIDと共に反応して、EAP- FAST Authentication Phase1トンネル設立がTLSに基づいていて、続かせるでしょう。 そして、EAP-FAST Authentication Phase1の会話の成功裡の後に、会話はPhase2に続きます。
3.2.2. TLS Session Resume Using a PAC
3.2.2. PACを使用するTLSセッション履歴書
EAP-FAST supports the resumption of sessions based on client-side state using techniques described in [RFC4507]. This version of EAP- FAST does not support the provisioning of a ticket through the use of the SessionTicket handshake message. Instead it supports the provisioning of a ticket called a Protected Access Credential (PAC) as described in [EAP-PROV]. Implementations may provide additional ways to provision the PAC, such as manual configuration. Since the PAC mentioned here is used for establishing the TLS Tunnel, it is more specifically referred to as the Tunnel PAC. The Tunnel PAC is a security credential provided by the EAP server to a peer and comprised of:
EAP-FASTは[RFC4507]で説明されたテクニックを使用することでクライアントサイド州に基づくセッションの再開をサポートします。 EAP- FASTのこのバージョンはSessionTicket握手メッセージの使用によるチケットの食糧を供給することをサポートしません。 代わりに、それは[EAP-PROV]で説明されるようにProtected Access Credential(PAC)と呼ばれるチケットの食糧を供給することをサポートします。 実装は手動の構成などのPACを支給への追加道に提供するかもしれません。 ここに言及されたPACがTLS Tunnelを設立するのに使用されるので、それは、より明確にTunnel PACと呼ばれます。 Tunnel PACはEAPサーバによって同輩に提供されて、以下から成るセキュリティー証明書です。
Cam-Winget, et al. Informational [Page 10] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [10ページ]情報のRFC4851速いEAP2007年5月
1. PAC-Key: this is a 32-octet key used by the peer to establish the
EAP-FAST Phase 1 tunnel. This key is used to derive the TLS
premaster secret as described in Section 5.1. The PAC-Key is
randomly generated by the EAP server to produce a strong entropy
32-octet key. The PAC-Key is a secret and MUST be treated
accordingly. For example, as the PAC-Key is a separate component
provisioned by the server to establish a secure tunnel, the
server may deliver this component protected by a secure channel,
and it must be stored securely by the peer.
1. PAC-キー: これはEAP-FAST Phase1トンネルを証明するのに同輩によって使用された32八重奏のキーです。 このキーは、セクション5.1で説明されるようにTLS premaster秘密を引き出すのに使用されます。 PAC-キーはEAPサーバによって手当たりしだいに生成されて、強いエントロピー32八重奏のキーを生産します。 PAC-キーを秘密であり、それに従って、扱わなければなりません。 例えば、サーバはPAC-キーがサーバによって食糧を供給された、安全なトンネルを確立した別々のコンポーネントであるので、安全なチャンネルによって保護されたこのコンポーネントを提供するかもしれません、そして、同輩はしっかりとそれを保存しなければなりません。
2. PAC-Opaque: this is a variable length field that is sent to the
EAP server during the EAP-FAST Phase 1 tunnel establishment. The
PAC-Opaque can only be interpreted by the EAP server to recover
the required information for the server to validate the peer's
identity and authentication. For example, the PAC-Opaque
includes the PAC-Key and may contain the PAC's peer identity.
The PAC-Opaque format and contents are specific to the PAC
issuing server. The PAC-Opaque may be presented in the clear, so
an attacker MUST NOT be able to gain useful information from the
PAC-Opaque itself. The server issuing the PAC-Opaque must ensure
it is protected with strong cryptographic keys and algorithms.
2. PAC-不透明なもの: これはEAP-FAST Phase1トンネル設立の間にEAPサーバに送られる可変長フィールドです。 PAC-不透明なものはEAPサーバによって解釈されるだけであって、サーバが同輩のアイデンティティと認証を有効にするように、必須情報を回復できます。 例えば、PAC-不透明なものは、PAC-キーを含んで、PACの同輩のアイデンティティを含むかもしれません。 PAC不透明な形式とコンテンツはサーバを支給するPACに特定です。PAC-不透明なものは明確に提示されるかもしれません、したがって、攻撃者がPAC-不透明なもの自体から役に立つ情報を獲得できるはずがありません。 PAC-不透明なものを発行するサーバは、それが強い暗号化キーとアルゴリズムで保護されるのを確実にしなければなりません。
3. PAC-Info: this is a variable length field used to provide, at a
minimum, the authority identity of the PAC issuer. Other useful
but not mandatory information, such as the PAC-Key lifetime, may
also be conveyed by the PAC issuing server to the peer during PAC
provisioning or refreshment.
3. PAC-インフォメーション: これは最小限でPAC発行人の権威のアイデンティティを提供するのに使用される可変長フィールドです。 また、PAC主要な生涯などの他の役に立ちますが、義務的でない情報はPACの食糧を供給するか軽い飲食物の間にサーバを同輩に支給するPACによって伝えられるかもしれません。
The use of the PAC is based on the SessionTicket extension defined in [RFC4507]. The EAP server initiates the EAP-FAST conversation as normal. Upon receiving the A-ID from the server, the peer checks to see if it has an existing valid PAC-Key and PAC-Opaque for the server. If it does, then it obtains the PAC-Opaque and puts it in the SessionTicket extension in the ClientHello. It is RECOMMENDED in EAP-FAST that the peer include an empty Session ID in a ClientHello containing a PAC-Opaque. EAP-FAST does not currently support the SessionTicket Handshake message so an empty SessionTicket extension MUST NOT be included in the ClientHello. If the PAC-Opaque included in the SessionTicket extension is valid and the EAP server permits the abbreviated TLS handshake, it will select the ciphersuite allowed to be used from information within the PAC and finish with the abbreviated TLS handshake. If the server receives a Session ID and a PAC-Opaque in the SessionTicket extension in a ClientHello, it should place the same Session ID in the ServerHello if it is resuming a session based on the PAC-Opaque. The conversation then proceeds as described in [RFC4507] until the handshake completes or a fatal error occurs. After the abbreviated handshake completes, the peer and server are ready to commence Phase 2. Note that when a PAC is used,
PACの使用は[RFC4507]で定義されたSessionTicket拡張子に基づいています。 EAPサーバは通常のEAP-FASTの同じくらい会話を開始します。 サーバからA-IDを受けると、同輩は、サーバに関してそれが既存の有効なPAC-キーとPAC-不透明なものを持っているかどうか確認するためにチェックします。そうするなら、次に、それは、PAC-不透明なものを得て、ClientHelloのSessionTicket拡張子にそれを入れます。 それはEAP-FASTのRECOMMENDEDです。同輩はPAC-不透明なものを含むClientHelloで人影のないSession IDを入れます。 EAP-FASTが現在SessionTicket Handshakeメッセージをサポートしないので、ClientHelloに空のSessionTicket拡張子を含んではいけません。 SessionTicket拡張子でPAC-不透明なものを含んでいるのが有効であり、EAPサーバが簡略化されたTLS握手を可能にすると、それは、PACの中の情報から使用できたciphersuiteを選択して、簡略化されたTLS握手で終わるでしょう。 サーバがClientHelloのSessionTicket拡張子でSession IDとPAC-不透明なものを受けるなら、PAC-不透明なものに基づいているセッションを再開しているなら、それは同じSession IDをServerHelloに置くべきです。 握手までの[RFC4507]が完成する説明されたコネとしての会話の当時の売り上げか致命的な誤りが発生します。 握手が完成する簡略化の後に、同輩とサーバはPhase2を始める準備ができています。 PACが使用されているときにはそれに注意してください。
Cam-Winget, et al. Informational [Page 11] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [11ページ]情報のRFC4851速いEAP2007年5月
the TLS master secret is calculated from the PAC-Key, client random, and server random as described in Section 5.1.
TLSマスター秘密は、セクション5.1で説明されるようにクライアント無作為のPAC-キーから計算されていてサーバ無作為です。
Specific details for the Tunnel PAC format, provisioning and security considerations are best described in [EAP-PROV]
Tunnel PAC形式、食糧を供給することおよび問題について説明するのが最も良いセキュリティのための特定の詳細[EAP-PROV]
3.2.3. Transition between Abbreviated and Full TLS Handshake
3.2.3. 簡略化されて完全なTLS握手の間の変遷
If session resumption based on server-side or client-side state fails, the server can gracefully fall back to a full TLS handshake. If the ServerHello received by the peer contains a empty Session ID or a Session ID that is different than in the ClientHello, the server may be falling back to a full handshake. The peer can distinguish the server's intent of negotiating full or abbreviated TLS handshake by checking the next TLS handshake messages in the server response to the ClientHello. If ChangeCipherSpec follows the ServerHello in response to the ClientHello, then the server has accepted the session resumption and intends to negotiate the abbreviated handshake. Otherwise, the server intends to negotiate the full TLS handshake. A peer can request for a new PAC to be provisioned after the full TLS handshake and mutual authentication of the peer and the server. In order to facilitate the fallback to a full handshake, the peer SHOULD include ciphersuites that allow for a full handshake and possibly PAC provisioning so the server can select one of these in case session resumption fails. An example of the transition is shown in Appendix A.
サーバ側かクライアントサイド州に基づくセッション再開が失敗するなら、サーバは優雅に完全なTLS握手へ後ろへ下がることができます。 同輩によって受け取られたServerHelloがClientHelloより異なった人影のないSession IDかSession IDを含んでいるなら、サーバは完全な握手へ後ろへ下がっているかもしれません。 同輩はサーバのClientHelloへのサーバ応答における次のTLS握手メッセージをチェックすることによって完全であるか簡略化されたTLS握手を交渉する意図を区別できます。 ChangeCipherSpecがClientHelloに対応してServerHelloに続くなら、サーバは、セッション再開を受け入れて、簡略化された握手を交渉するつもりです。 さもなければ、サーバは完全なTLS握手を交渉するつもりです。 同輩は後退を容易にするために新しいPACが同輩の完全なTLS握手と互いの認証の後に食糧を供給されるという要求とサーバを含めることができて、完全な握手に、同輩SHOULDはセッション再開が失敗するといけないのでサーバがこれらの1つを選択できるように完全な握手とことによるとPACの食糧を供給することを考慮するciphersuitesを含めます。 変遷に関する例はAppendix Aに示されます。
3.3. EAP-FAST Authentication Phase 2: Tunneled Authentication
3.3. 速いEAP認証フェーズ2: トンネルを堀られた認証
The second portion of the EAP-FAST Authentication occurs immediately after successful completion of Phase 1. Phase 2 occurs even if both peer and authenticator are authenticated in the Phase 1 TLS negotiation. Phase 2 MUST NOT occur if the Phase 1 TLS handshake fails. Phase 2 consists of a series of requests and responses encapsulated in TLV objects defined in Section 4.2. Phase 2 MUST always end with a protected termination exchange described in Section 3.3.2. The TLV exchange may include the execution of zero or more EAP methods within the protected tunnel as described in Section 3.3.1. A server MAY proceed directly to the protected termination exchange if it does not wish to request further authentication from the peer. However, the peer and server must not assume that either will skip inner EAP methods or other TLV exchanges. The peer may have roamed to a network that requires conformance with a different authentication policy or the peer may request the server take additional action through the use of the Request-Action TLV.
EAP-FAST Authenticationの2番目の一部がPhase1の無事終了直後起こります。 同輩と固有識別文字の両方がPhase1TLS交渉で認証されても、フェーズ2は起こります。 Phase1TLS握手が失敗するなら、フェーズ2は起こってはいけません。 フェーズ2はセクション4.2で定義されたTLVオブジェクトでカプセル化された一連の要求と応答から成ります。 保護された終了交換がセクション3.3.2で説明されている状態で、フェーズ2はいつも終わらなければなりません。 TLV交換がゼロの実行を含むかもしれませんか、または保護の中の、より多くのEAPメソッドがセクション3.3.1で説明されるようにトンネルを堀ります。 同輩からさらなる認証を要求したくないなら、サーバは直接保護された終了交換に続くかもしれません。 しかしながら、同輩とサーバは、どちらかが内側のEAPメソッドか他のTLV交換をサボると仮定してはいけません。 同輩が異なった認証方針がある順応を必要とするネットワークに歩き回ったかもしれませんか、または同輩は、サーバがRequest-動作TLVの使用で追加措置を取るよう要求するかもしれません。
Cam-Winget, et al. Informational [Page 12] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [12ページ]情報のRFC4851速いEAP2007年5月
3.3.1. EAP Sequences
3.3.1. EAP系列
EAP [RFC3748] prohibits use of multiple authentication methods within a single EAP conversation in order to limit vulnerabilities to man- in-the-middle attacks. EAP-FAST addresses man-in-the-middle attacks through support for cryptographic protection of the inner EAP exchange and cryptographic binding of the inner authentication method(s) to the protected tunnel. EAP methods are executed serially in a sequence. This version of EAP-FAST does not support initiating multiple EAP methods simultaneously in parallel. The methods need not be distinct. For example, EAP-TLS could be run twice as an inner method, first using machine credentials followed by a second instance using user credentials.
EAP[RFC3748]は、脆弱性を中央での男性攻撃に制限するためにただ一つのEAPの会話の中で複数の認証方法の使用を禁止します。 EAP-FASTは内側のEAP交換の暗号の保護と内側の認証方法の暗号の結合のサポートで保護されたトンネルに介入者攻撃を扱います。 EAPメソッドは次々に順次、実行されます。 EAP-FASTのこのバージョンは、開始が同時に平行な複数のEAPメソッドであるとサポートしません。 メソッドは異なっている必要はありません。 例えば、内側のメソッドとして二度EAP-TLSを実行できました、最初に2番目のインスタンスがユーザ資格証明書を使用することであとに続いたマシン資格証明書を使用して。
EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.6. If more than one method is going to be executed in the tunnel then, upon completion of a method, a server MUST send an Intermediate-Result TLV indicating the result. The peer MUST respond to the Intermediate-Result TLV indicating its result. If the result indicates success, the Intermediate-Result TLV MUST be accompanied by a Crypto-Binding TLV. The Crypto-Binding TLV is further discussed in Section 4.2.8 and Section 5.3. The Intermediate-Result TLVs can be included with other TLVs such as EAP-Payload TLVs starting a new EAP conversation or with the Result TLV used in the protected termination exchange. In the case where only one EAP method is executed in the tunnel, the Intermediate-Result TLV MUST NOT be sent with the Result TLV. In this case, the status of the inner EAP method is represented by the final Result TLV, which also represents the result of the whole EAP-FAST conversation. This is to maintain backward compatibility with existing implementations.
EAPメソッドメッセージはセクション4.2.6で定義されたEAP-有効搭載量TLVsの中で伝えられます。 1つ以上のメソッドがメソッドの完成のときにその時トンネルで実行されるなら、サーバで、Intermediate-結果TLVは結果を示さなければなりません。 同輩は結果を示すIntermediate-結果TLVに応じなければなりません。 結果が、成功、Intermediate-結果TLV MUSTがCryptoを拘束力があるTLVによって同伴されるのを示すなら。 セクション4.2.8とセクション5.3でさらにCryptoを拘束力があるTLVについて議論します。 EAP-有効搭載量TLVsなどの他のTLVsが新しいEAPの会話を始めているか、またはResult TLVが保護された終了交換に使用されている状態で、Intermediate-結果TLVsを含むことができます。 場合では、1つのEAPメソッドがトンネルで唯一で実行されます、Intermediate-結果TLV MUST NOT。Result TLVと共に送ります。 この場合、内側のEAPメソッドの状態は最終的なResult TLVによって表されます。(また、Result TLVは全体のEAP-FASTの会話の結果を表します)。 これは、既存の実装との後方の互換性を維持するためのものです。
If both peer and server indicate success, then the method is considered complete. If either indicates failure. then the method is considered failed. The result of failure of an EAP method does not always imply a failure of the overall authentication. If one authentication method fails, the server may attempt to authenticate the peer with a different method.
同輩とサーバの両方が成功を示すなら、メソッドは完全であると考えられます。 どちらかが失敗その時を示すなら、メソッドは失敗されていると考えられます。 EAPメソッドの失敗の結果はいつも総合的な認証の失敗を含意するというわけではありません。 1つの認証方法が失敗するなら、サーバは、異なったメソッドをもっている同輩を認証するのを試みるかもしれません。
3.3.2. Protected Termination and Acknowledged Result Indication
3.3.2. 保護された終了と承認された結果指示
A successful EAP-FAST Phase 2 conversation MUST always end in a successful Result TLV exchange. An EAP-FAST server may initiate the Result TLV exchange without initiating any EAP conversation in EAP- FAST Phase 2. After the final Result TLV exchange, the TLS tunnel is terminated and a clear text EAP-Success or EAP-Failure is sent by the server. The format of the Result TLV is described in Section 4.2.2.
うまくいっているEAP-FAST Phase2の会話はいつもうまくいっているResult TLV交換に終わらなければなりません。 EAP- FAST Phase2でのどんなEAPの会話も開始しないで、EAP-FASTサーバはResult TLV交換を起こすかもしれません。 最終的なResult TLV交換の後に、TLSトンネルは終えます、そして、サーバはクリアテキストEAP-成功かEAP-失敗を送ります。セクション4.2.2でResult TLVの形式について説明します。
Cam-Winget, et al. Informational [Page 13] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [13ページ]情報のRFC4851速いEAP2007年5月
A server initiates a successful protected termination exchange by sending a Result TLV indicating success. The server may send the Result TLV along with an Intermediate-Result TLV and a Crypto-Binding TLV. If the peer requires nothing more from the server it will respond with a Result TLV indicating success accompanied by an Intermediate-Result TLV and Crypto-Binding TLV if necessary. The server then tears down the tunnel and sends a clear text EAP-Success.
Result TLVに成功を示させることによって、サーバはうまくいっている保護された終了交換を起こします。 サーバはIntermediate-結果TLVとCryptoを拘束力があるTLVに伴うResult TLVを送るかもしれません。 同輩がサーバからそれ以上何もを必要とすると、Result TLVが必要なら、Intermediate-結果TLVとCryptoを拘束力があるTLVによって伴われた成功を示していて、それは応じるでしょう。 サーバは、次に、トンネルを取りこわして、クリアテキストEAP-成功を送ります。
If the peer receives a Result TLV indicating success from the server, but its authentication policies are not satisfied (for example it requires a particular authentication mechanism be run or it wants to request a PAC), it may request further action from the server using the Request-Action TLV. The Request-Action TLV is sent along with the Result TLV indicating what EAP Success/Failure result the peer would expect if the requested action is not granted. The value of the Request-Action TLV indicates what the peer would like to do next. The format and values for the Request-Action TLV are defined in Section 4.2.9.
同輩がサーバから成功を示すResult TLVを受け取りますが、認証方針が満たされていないなら(例えば、それは走行かそれがPACを要求する必需品であったなら特定の認証機構を必要とします)、それは、サーバからRequest-動作TLVを使用することでさらなる動作を要求するかもしれません。 要求された動作が承諾されないなら同輩がどんなEAP Success/失敗結果を予想するかを示すResult TLVと共にRequest-動作TLVを送ります。 Request-動作TLVの値は同輩が次にしたがっていることを示します。 Request-動作TLVのための書式と値はセクション4.2.9で定義されます。
Upon receiving the Request-Action TLV the server may process the request or ignore it, based on its policy. If the server ignores the request, it proceeds with termination of the tunnel and send the clear text EAP Success or Failure message based on the value of the peer's result TLV. If the server honors and processes the request, it continues with the requested action. The conversation completes with a Result TLV exchange. The Result TLV may be included with the TLV that completes the requested action.
Request-動作TLVを受けると、サーバは、方針に基づいて要求を処理するか、またはそれを無視するかもしれません。 サーバが要求を無視するなら、それはトンネルの終了を続けます、そして、同輩の結果TLVの値に基づくEAP SuccessかFailureメッセージをクリアテキストに送ってください。 サーバが要求を光栄に思って、処理するなら、それは要求された動作を続行します。 会話はResult TLVと共に交換を終了します。 Result TLVは要求された操作を完了するTLVと共に含まれるかもしれません。
Error handling for Phase 2 is discussed in Section 3.6.2.
セクション3.6.2でPhase2のためのエラー処理について議論します。
3.4. Determining Peer-Id and Server-Id
3.4. 同輩イドとサーバイドを決定します。
The Peer-Id and Server-Id may be determined based on the types of credentials used during either the EAP-FAST tunnel creation or authentication.
Peer-イドとServer-イドはEAP-FASTトンネル作成か認証の間に使用される資格証明書のタイプに基づいて決定しているかもしれません。
When X.509 certificates are used for peer authentication, the Peer-Id is determined by the subject or subjectAltName fields in the peer certificate. As noted in [RFC3280] (updated by [RFC4630]):
X.509証明書が同輩認証に使用されるとき、Peer-イドは同輩証明書の対象かsubjectAltName分野のそばで決定しています。 [RFC3280]([RFC4630]によってアップデートされる)に述べられるように:
The subject field identifies the entity associated with the public
key stored in the subject public key field. The subject name MAY
be carried in the subject field and/or the subjectAltName
extension.... If subject naming information is present only in
the subjectAltName extension (e.g., a key bound only to an email
address or URI), then the subject name MUST be an empty sequence
and the subjectAltName extension MUST be critical.
対象の分野は対象の公開鍵分野に保存される公開鍵に関連している実体を特定します。 対象の名前は対象の分野、そして/または、subjectAltName拡張子で運ばれるかもしれません… 対象の命名情報がsubjectAltName拡張子だけで存在しているなら(例えばキーはEメールアドレスかURIだけに固まりました)、対象の名前は空の系列であるに違いありません、そして、subjectAltName拡張子は重要であるに違いありません。
Cam-Winget, et al. Informational [Page 14] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [14ページ]情報のRFC4851速いEAP2007年5月
Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN).
それが非空であるところでは、対象の分野はX.500分類名(DN)を含まなければなりません。
If an inner EAP method is run, then the Peer-Id is obtained from the inner method.
内側のEAPメソッドを実行するなら、内側のメソッドからPeer-イドを得ます。
When the server uses an X.509 certificate to establish the TLS tunnel, the Server-Id is determined in a similar fashion as stated above for the Peer-Id; e.g., the subject or subjectAltName field in the server certificate defines the Server-Id.
サーバがTLSトンネルを証明するのにX.509証明書を使用すると、Server-イドはPeer-イドのための上で述べられるとしての同様のファッションで決定します。 例えば、サーバ証明書の対象かsubjectAltName分野がServer-アイダホ州を定義します。
3.5. EAP-FAST Session Identifier
3.5. 速いEAPセッション識別子
The EAP session identifier is constructed using the random values provided by the peer and server during the TLS tunnel establishment. The Session-Id is defined as follows:
EAPセッション識別子は、TLSトンネル設立の間に同輩とサーバによって提供された無作為の値を使用することで構成されます。 Session-イドは以下の通り定義されます:
Session-Id = 0x2B || client_random || server_random)
client_random = 32 byte nonce generated by the peer
server_random = 32 byte nonce generated by the server
セッションイド=0x2B|| クライアント_無作為です。|| サーバ_無作為である、)、無作為の状態で同輩サーバ_によって生成されたクライアントの_の=の32バイトの無作為の一回だけはサーバによって生成された32バイトの一回だけと等しいです。
3.6. Error Handling
3.6. エラー処理
EAP-FAST uses the following error handling rules summarized below:
EAP-FASTは以下へまとめられた以下のエラー処理規則を使用します:
1. Errors in the TLS layer are communicated via TLS alert messages
in all phases of EAP-FAST.
1. TLS層における誤りはEAP-FASTのすべてのフェーズにおけるTLS警告メッセージで伝えられます。
2. The Intermediate-Result TLVs carry success or failure indications
of the individual EAP methods in EAP-FAST Phase 2. Errors within
the EAP conversation in Phase 2 are expected to be handled by
individual EAP methods.
2. Intermediate-結果TLVsはEAP-FAST Phase2の独特のEAPメソッドの成否しるしを運びます。 独特のEAPメソッドでPhase2でのEAPの会話の中の誤りが扱われると予想されます。
3. Violations of the TLV rules are handled using Result TLVs
together with Error TLVs.
3. TLV規則の違反は、Error TLVsと共にResult TLVsを使用することで扱われます。
4. Tunnel compromised errors (errors caused by Crypto-Binding failed
or missing) are handled using Result TLVs and Error TLVs.
4. 誤り(失敗されたCrypto-結合で引き起こされた誤りか取り逃がす)であると感染されるトンネルは、Result TLVsとError TLVsを使用することで扱われます。
3.6.1. TLS Layer Errors
3.6.1. TLS層の誤り
If the EAP-FAST server detects an error at any point in the TLS Handshake or the TLS layer, the server SHOULD send an EAP-FAST request encapsulating a TLS record containing the appropriate TLS alert message rather than immediately terminating the conversation so as to allow the peer to inform the user of the cause of the failure and possibly allow for a restart of the conversation. The peer MUST send an EAP-FAST response to an alert message. The EAP-Response
EAP-FASTサーバがTLS Handshakeの任意な点かTLS層に誤りを検出するなら、サーバSHOULDはEAP-FAST要求にすぐに同輩が失敗の原因についてユーザに知らせて、ことによると会話の再開を考慮するのを許容するために会話を終えるよりむしろ適切なTLS警告メッセージを含むTLS記録をカプセル化させます。 同輩はEAP-FAST応答を警告メッセージに送らなければなりません。 EAP-応答
Cam-Winget, et al. Informational [Page 15] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [15ページ]情報のRFC4851速いEAP2007年5月
packet sent by the peer may encapsulate a TLS ClientHello handshake message, in which case the EAP-FAST server MAY allow the EAP-FAST conversation to be restarted, or it MAY contain an EAP-FAST response with a zero-length message, in which case the server MUST terminate the conversation with an EAP-Failure packet. It is up to the EAP- FAST server whether to allow restarts, and if so, how many times the conversation can be restarted. An EAP-FAST Server implementing restart capability SHOULD impose a limit on the number of restarts, so as to protect against denial-of-service attacks.
ゼロ・レングスメッセージがあるEAP-FAST応答を含むかもしれません、そして、サーバは同輩によって送られたパケットがTLS ClientHello握手メッセージをカプセル化しなければならないかもしれませんか、その場合、EAP-FASTの会話がEAP-FASTサーバで再開しなければならないかもしれませんか、またはその場合、EAP-失敗パケットとの会話を終えなければなりません。 EAP- FASTサーバまでそれはそうです。再開を許すかどうかと、そうだとすれば、何回、会話は再開できますか? SHOULDが数で指し値する再開能力を実装するEAP-FAST Serverは再開します、サービス不能攻撃から守るために。
If the EAP-FAST peer detects an error at any point in the TLS layer, the EAP-FAST peer should send an EAP-FAST response encapsulating a TLS record containing the appropriate TLS alert message. The server may restart the conversation by sending an EAP-FAST request packet encapsulating the TLS HelloRequest handshake message. The peer may allow the EAP-FAST conversation to be restarted or it may terminate the conversation by sending an EAP-FAST response with an zero-length message.
EAP-FAST同輩がTLS層の任意な点に誤りを検出するなら、EAP-FAST同輩はEAP-FAST応答に適切なTLS警告メッセージを含むTLS記録をカプセル化させるべきです。 EAP-FASTリクエスト・パケットにTLS HelloRequest握手メッセージをカプセル化させることによって、サーバは会話を再開するかもしれません。 同輩がEAP-FASTの会話を再開させるかもしれませんか、またはそれは、ゼロ・レングスメッセージでEAP-FAST応答を送ることによって、会話を終えるかもしれません。
3.6.2. Phase 2 Errors
3.6.2. フェーズ2誤り
Any time the peer or the server finds a fatal error outside of the TLS layer during Phase 2 TLV processing, it MUST send a Result TLV of failure and an Error TLV with the appropriate error code. For errors involving the processing of the sequence of exchanges, such as a violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error code is Unexpected_TLVs_Exchanged. For errors involving a tunnel compromise, the error-code is Tunnel_Compromise_Error. Upon sending a Result TLV with a fatal Error TLV the sender terminates the TLS tunnel. Note that a server will still wait for a message from the peer after it sends a failure, however the server does not need to process the contents of the response message.
いつでも、同輩かサーバが適切なエラーコードでPhase2TLV処理の間のTLS層の外に、それが送らなければならない致命的な誤りに失敗のResult TLVとError TLVを見つけます。 TLV規則(例えば、倍数EAP-有効搭載量TLVs)の違反などの交換の系列の処理にかかわる誤りのために、エラーコードはUnexpected_TLVs_Exchangedです。 トンネル感染にかかわる誤りのために、エラーコードはTunnel_Compromise_Errorです。 致命的なError TLVとResult TLVを送ると、送付者はTLSトンネルを終えます。 しかしながら、それでも、失敗を送った後にサーバが同輩からのメッセージを待っていて、サーバが応答メッセージのコンテンツを処理する必要はないことに注意してください。
If a server receives a Result TLV of failure with a fatal Error TLV, it SHOULD send a clear text EAP-Failure. If a peer receives a Result TLV of failure, it MUST respond with a Result TLV indicating failure. If the server has sent a Result TLV of failure, it ignores the peer response, and it SHOULD send a clear text EAP-Failure.
サーバはaであるなら致命的なError TLVと共に失敗のResult TLVを受けます、それ。SHOULDはクリアテキストEAP-失敗を送ります。 同輩が失敗のResult TLVを受け取るなら、Result TLVが失敗を示していて、それは応じなければなりません。 サーバが失敗のResult TLVを送ったなら、それは同輩応答、およびそれを無視します。SHOULDはクリアテキストEAP-失敗を送ります。
3.7. Fragmentation
3.7. 断片化
A single TLS record may be up to 16384 octets in length, but a TLS message may span multiple TLS records, and a TLS certificate message may in principle be as long as 16 MB. This is larger than the maximum size for a message on most media types, therefore it is desirable to support fragmentation. Note that in order to protect against reassembly lockup and denial-of-service attacks, it may be desirable for an implementation to set a maximum size for one such
ただ一つのTLS記録が長さが最大16384の八重奏であるかもしれませんが、TLSメッセージが複数のTLS記録にかかるかもしれなくて、TLS証明書メッセージは原則として16MBと同じくらい長いかもしれません。 ほとんどのメディアタイプに関するメッセージには、これが最大サイズより大きい、したがって、断片化をサポートするのは望ましいです。 実装が1のための最大のサイズにそのようなものを設定するのが、再アセンブリ留置所とサービス不能攻撃から守るために望ましいかもしれないことに注意してください。
Cam-Winget, et al. Informational [Page 16] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [16ページ]情報のRFC4851速いEAP2007年5月
group of TLS messages. Since a typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB. This is still a fairly large message packet size so an EAP-FAST implementation MUST provide its own support for fragmentation and reassembly.
TLSメッセージのグループ。 典型的な証明書チェーンが数1,000の八重奏ほどめったに長くなく、また他のどんな分野もいくらか同じくらい長い傾向がないので、最大の許容できるメッセージ長の正当な選択は64KBであるかもしれません。 それでも、これがかなり大きいメッセージパケットサイズであり、EAP-FAST実装は、それ自身の断片化のサポートを提供するので、再アセンブリされなければなりません。
Since EAP is an lock-step protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field.
EAPが堅苦しいプロトコルであるので、簡単な方法で断片化サポートを加えることができます。 EAP、再送されて、以来情報を配列するトランジットでなくされているか、または破損する断片では、断片オフセットの必要は全くEAPのIdentifier分野のそばになければ、分野があります。
EAP-FAST fragmentation support is provided through the addition of flag bits within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets. Flags include the Length included (L), More fragments (M), and EAP-FAST Start (S) bits. The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M flag is set on all but the last fragment. The S flag is set only within the EAP-FAST start message sent from the EAP server to the peer. The TLS Message Length field is four octets, and provides the total length of the TLS message or set of messages that is being fragmented; this simplifies buffer allocation.
EAP-応答とEAP-リクエスト・パケットの中でフラグビットの追加を通してEAP-FAST断片化サポートを提供します、4つの八重奏のTLS Message Length分野と同様に。 旗は、Lengthを含んでいるのを含んでいます。(L)、More断片(M)、およびEAP-FAST Start(S)ビット。 L旗を4八重奏のTLS Message Length分野の存在を示すように設定されて、断片化しているTLSメッセージか1セットのメッセージの最初の断片に設定しなければなりません。 M旗は最後の断片以外のすべてに設定されます。 S旗はEAPサーバから同輩に送られたEAP-FAST開始メッセージだけの中に設定されます。 TLS Message Length分野は、4つの八重奏であり、断片化されているメッセージのTLSメッセージかセットの全長を提供します。 これはバッファ配分を簡素化します。
When an EAP-FAST peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type of EAP-FAST and no data. This serves as a fragment ACK. The EAP server must wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer must include this Identifier value in the fragment ACK contained within the EAP- Response. Retransmitted fragments will contain the same Identifier value.
EAP-FAST同輩がMがあるEAP-リクエスト・パケットの噛み付いているセットを受け取るとき、それはEAP-FASTにもかかわらず、データがないEAP-タイプとのEAP-応答で応じなければなりません。 これは断片ACKとして機能します。 別の断片を送る前にEAP-応答を受けるまで、EAPサーバは待たなければなりません。 断片の処理における誤りを防いで、EAPサーバはEAP-要求の中に含まれた各断片のためにIdentifier分野を増加しなければなりません、そして、同輩はEAP応答の中に含まれた断片ACKでこのIdentifier値を入れなければなりません。 再送された断片は同じIdentifier値を含むでしょう。
Similarly, when the EAP-FAST server receives an EAP-Response with the M bit set, it must respond with an EAP-Request with EAP-Type of EAP- FAST and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP- Response.
EAP-FASTサーバがMとのEAP-応答の噛み付いているセットを受けるとき、同様に、それはEAP- FASTにもかかわらず、データがないEAP-タイプとのEAP-要求で応じなければなりません。 これは断片ACKとして機能します。 別の断片を送る前にEAP-要求を受け取るまで、EAP同輩は待たなければなりません。 断片の処理における誤りを防いで、EAPサーバはEAP-要求の中に含まれたそれぞれの断片ACKのためにIdentifier値を増加しなければなりません、そして、同輩はEAP応答の中に含まれたその後の断片でこのIdentifier値を入れなければなりません。
Cam-Winget, et al. Informational [Page 17] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [17ページ]情報のRFC4851速いEAP2007年5月
4. Message Formats
4. メッセージ・フォーマット
The following sections describe the message formats used in EAP-FAST. The fields are transmitted from left to right in network byte order.
以下のセクションはEAP-FASTで使用されるメッセージ・フォーマットについて説明します。野原はネットワークバイトオーダーで左から右まで伝えられます。
4.1. EAP-FAST Message Format
4.1. 速いEAPメッセージ・フォーマット
A summary of the EAP-FAST Request/Response packet format is shown below.
EAP-FAST Request/応答パケット・フォーマットの概要は以下に示されます。
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 | Ver | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 旗| Ver| メッセージ長: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : メッセージ長| データ… + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
The code field is one octet in length defined as follows:
コード分野は以下の通り定義された長さが1つの八重奏です:
1 Request
1つの要求
2 Response
2 応答
Identifier
識別子
The Identifier field is one octet and aids in matching
responses with requests. The Identifier field MUST be changed
on each Request packet. The Identifier field in the Response
packet MUST match the Identifier field from the corresponding
request.
Identifier分野は、要求に応答に合うことにおいて1つの八重奏と援助です。 それぞれのRequestパケットでIdentifier分野を変えなければなりません。 ResponseパケットのIdentifier分野は対応する要求からIdentifier分野に合わなければなりません。
Length
長さ
The Length field is two octets and indicates the length of the
EAP packet including the Code, Identifier, Length, Type, Flags,
Ver, Message Length, and Data fields. Octets outside the range
of the Length field should be treated as Data Link Layer
padding and should be ignored on reception.
Length分野は、2つの八重奏であり、Code、Identifier、Length、Type、Flags、Ver、Message Length、およびData分野を含むEAPパケットの長さを示します。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、Length分野の範囲の外での八重奏は扱われるべきです。
Type
タイプ
43 for EAP-FAST
43 速いEAPのために
Cam-Winget, et al. Informational [Page 18] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [18ページ]情報のRFC4851速いEAP2007年5月
Flags
旗
0 1 2 3 4
+-+-+-+-+-+
|L M S R R|
+-+-+-+-+-+
0 1 2 3 4 +-+-+-+-+-+ |L M S R R| +-+-+-+-+-+
L Length included; set to indicate the presence of the four-
octet Message Length field
Lの長さを含んでいます。 4八重奏Message Length分野の存在を示すために、セットします。
M More fragments; set on all but the last fragment
Mより多くの断片。 最後の断片以外のすべてでは、セットします。
S EAP-FAST start; set in an EAP-FAST Start message
S EAP-FASTは始まります。 EAP-FAST Startメッセージでは、セットします。
R Reserved (must be zero)
予約されたR(ゼロでなければなりません)
Ver
Ver
This field contains the version of the protocol. This document
describes version 1 (001 in binary) of EAP-FAST.
この分野はプロトコルのバージョンを含んでいます。 このドキュメントはEAP-FASTのバージョン1(バイナリーの001)について説明します。
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
message that may be fragmented over the data fields of multiple
packets.
Message Length分野は、4つの八重奏であり、Lビットが設定される場合にだけ、存在しています。 この分野は複数のパケットのデータ・フィールドにわたって断片化されるかもしれないメッセージの全長を提供します。
Data
データ
In the case of an EAP-FAST Start request (i.e., when the S bit
is set) the Data field consists of the A-ID described in
Section 4.1.1. In other cases, when the Data field is present,
it consists of an encapsulated TLS packet in TLS record format.
An EAP-FAST packet with Flags and Version fields, but with zero
length data field, is used to indicate EAP-FAST acknowledgement
for either a fragmented message, a TLS Alert message or a TLS
Finished message.
EAP-FAST Startの場合では、Data分野がセクション4.1.1で説明されたA-IDから成るよう要求してください(すなわち、Sビットが設定されるとき)。 他の場合では、Data分野が存在しているとき、それはTLSレコード形式でカプセル化されたTLSパケットから成ります。 Flagsとバージョン分野にもかかわらず、ゼロ・レングスデータ・フィールドがあるEAP-FASTパケットは、断片化しているメッセージ、TLS AlertメッセージかTLS FinishedメッセージのどちらかのためのEAP-FAST承認を示すのに使用されます。
Cam-Winget, et al. Informational [Page 19] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [19ページ]情報のRFC4851速いEAP2007年5月
4.1.1. Authority ID Data
4.1.1. 権威IDデータ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x04) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ(0×04)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID+++++++++++++++++++++++++++++++++
Type
タイプ
The Type field is two octets. It is set to 0x0004 for
Authority ID
Type分野は2つの八重奏です。 それはAuthority IDのために0×0004に設定されます。
Length
長さ
The Length filed is two octets, which contains the length of
the ID field in octets.
ファイルされたLengthは2つの八重奏です(八重奏における、ID分野の長さを含んでいます)。
ID
ID
Hint of the identity of the server. It should be unique across
the deployment.
ヒント、サーバのアイデンティティでは. それは展開の向こう側にユニークであるべきです。
4.2. EAP-FAST TLV Format and Support
4.2. 速いEAP TLV形式とサポート
The TLVs defined here are standard Type-Length-Value (TLV) objects. The TLV objects could be used to carry arbitrary parameters between EAP peer and EAP server within the protected TLS tunnel.
ここで定義されたTLVsは標準のType長さの価値(TLV)のオブジェクトです。 保護されたTLSトンネルの中でEAP同輩とEAPサーバの間の任意のパラメタを運ぶのにTLVオブジェクトを使用できました。
The EAP peer may not necessarily implement all the TLVs supported by the EAP server. To allow for interoperability, TLVs are designed to allow an EAP server to discover if a TLV is supported by the EAP peer, using the NAK TLV. The mandatory bit in a TLV indicates whether support of the TLV is required. If the peer or server does not support a TLV marked mandatory, then it MUST send a NAK TLV in the response, and all the other TLVs in the message MUST be ignored. If an EAP peer or server finds an unsupported TLV that is marked as optional, it can ignore the unsupported TLV. It MUST NOT send an NAK TLV for a TLV that is not marked mandatory.
EAP同輩は必ずEAPサーバによってサポートされたすべてのTLVsを実装するかもしれないというわけではありません。相互運用性を考慮するなら、TLVsはEAPサーバが、TLVがEAP同輩によってサポートされるかどうか発見するのを許容するように設計されます、NAK TLVを使用して。 TLVの義務的なビットは、TLVのサポートが必要であるかどうかを示します。 同輩かサーバが義務的であるとマークされたTLVをサポートしないなら、応答でNAK TLVを送らなければなりません、そして、メッセージの他のすべてのTLVsを無視しなければなりません。 EAP同輩かサーバが任意であるとしてマークされるサポートされないTLVを見つけるなら、それはサポートされないTLVを無視できます。 それは義務的であることはマークされないTLVのためにNAK TLVを送ってはいけません。
Note that a peer or server may support a TLV with the mandatory bit set, but may not understand the contents. The appropriate response to a supported TLV with content that is not understood is defined by the individual TLV specification.
同輩かサーバが義務的な噛み付いているセットでTLVをサポートしますが、コンテンツを理解しないかもしれないことに注意してください。 理解されていない内容があるサポートしているTLVへの適切な応答は独特のTLV仕様で定義されます。
Cam-Winget, et al. Informational [Page 20] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [20ページ]情報のRFC4851速いEAP2007年5月
EAP implementations compliant with this specification MUST support TLV exchanges, as well as the processing of mandatory/optional settings on the TLV. Implementations conforming to this specification MUST support the following TLVs:
この仕様による対応することのEAP実装はTLVに交換をサポートしなければなりません、TLVにおける義務的であるか任意の設定の処理と同様に。 この仕様に従う実装は以下のTLVsをサポートしなければなりません:
Result TLV
NAK TLV
Error TLV
EAP-Payload TLV
Intermediate-Result TLV
Crypto-Binding TLV
Request-Action TLV
結果TLV NAK TLV誤りTLV EAP-有効搭載量の中間結果のTLVの暗号を拘束力があるTLV要求動作TLV TLV
4.2.1. General TLV Format
4.2.1. 一般TLV形式
TLVs are defined as described below. The fields are transmitted from left to right.
TLVsは以下で説明されると定義されます。 野原は左から右まで伝えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 Optional TLV
0 任意のTLV
1 Mandatory TLV
1 義務的なTLV
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
TLV Type
TLVはタイプします。
A 14-bit field, denoting the TLV type. Allocated Types
include:
TLVタイプを指示する14ビットの分野。 割り当てられたTypesは:
Cam-Winget, et al. Informational [Page 21] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [21ページ]情報のRFC4851速いEAP2007年5月
0 Reserved
1 Reserved
2 Reserved
3 Result TLV (Section 4.2.2)
4 NAK TLV (Section 4.2.3)
5 Error TLV (Section 4.2.4)
7 Vendor-Specific TLV (Section 4.2.5)
9 EAP-Payload TLV (Section 4.2.6)
10 Intermediate-Result TLV (Section 4.2.7)
11 PAC TLV [EAP-PROV]
12 Crypto-Binding TLV (Section 4.2.8)
18 Server-Trusted-Root TLV [EAP-PROV]
19 Request-Action TLV (Section 4.2.9)
20 PKCS#7 TLV [EAP-PROV]
0 1予約された予約された2予約された3結果TLV(セクション4.2.2)4NAK TLV(セクション4.2.3)5誤りTLV(セクション4.2.4)の7のベンダー特有のTLV(セクション4.2.5)9EAP-有効搭載量TLV(セクション4.2.6)10中間結果TLV(セクション4.2.7)11PAC TLV[EAP-PROV]12暗号を拘束力があるTLV(セクション4.2.8)18のサーバの信じられた根のTLV[EAP-PROV]19要求動作TLV(セクション4.2.9)20PKCS#7TLV[EAP-PROV]
Length
長さ
The length of the Value field in octets.
八重奏における、Value分野の長さ。
Value
値
The value of the TLV.
TLVの値。
4.2.2. Result TLV
4.2.2. 結果TLV
The Result TLV provides support for acknowledged success and failure messages for protected termination within EAP-FAST. If the Status field does not contain one of the known values, then the peer or EAP server MUST treat this as a fatal error of Unexpected_TLVs_Exchanged. The behavior of the Result TLV is further discussed in Section 3.3.2 and Section 3.6.2. A Result TLV indicating failure MUST NOT be accompanied by the following TLVs: NAK, EAP-Payload TLV, or Crypto- Binding TLV. The Result TLV is defined as follows:
Result TLVはEAP-FASTの中の保護された終了への承認された成功と失敗メッセージのサポートを提供します。Status分野が知られている値の1つを含んでいないなら、同輩かEAPサーバがUnexpected_TLVs_Exchangedの致命的な誤りとしてこれを扱わなければなりません。 セクション3.3.2とセクション3.6.2でResult TLVの動きについてさらに議論します。 失敗を示すResult TLVは以下のTLVsによって同伴されてはいけません: NAK、EAP-有効搭載量TLV、または暗号TLVを縛ります。 Result TLVは以下の通り定義されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
義務的であることで、1つにセットしてください。(1)
Cam-Winget, et al. Informational [Page 22] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [22ページ]情報のRFC4851速いEAP2007年5月
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
TLV Type
TLVはタイプします。
3 for Result TLV
3 結果TLVのために
Length
長さ
2
2
Status
状態
The Status field is two octets. Values include:
Status分野は2つの八重奏です。 値は:
1 Success
1 成功
2 Failure
2 失敗
4.2.3. NAK TLV
4.2.3. NAK TLV
The NAK TLV allows a peer to detect TLVs that are not supported by the other peer. An EAP-FAST packet can contain 0 or more NAK TLVs. A NAK TLV should not be accompanied by other TLVs. A NAK TLV MUST NOT be sent in response to a message containing a Result TLV, instead a Result TLV of failure should be sent indicating failure and an Error TLV of Unexpected_TLVs_Exchanged. The NAK TLV is defined as follows:
NAK TLVは同輩にもう片方の同輩によってサポートされないTLVsを検出させます。 EAP-FASTパケットは0NAK TLVsを含むことができます。 他のTLVsはNAK TLVに同伴するはずがありません。 Result TLVを含むメッセージに対応してNAK TLV MUST NOTを送って、代わりに、失敗のResult TLVにUnexpected_TLVs_Exchangedの失敗とError TLVを示させるべきです。 NAK TLVは以下の通り定義されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーイド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAK-タイプ| TLVs… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
義務的であることで、1つにセットしてください。(1)
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
Cam-Winget, et al. Informational [Page 23] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [23ページ]情報のRFC4851速いEAP2007年5月
TLV Type
TLVはタイプします。
4 for NAK TLV
4 NAK TLVのために
Length
長さ
>=6
>=6
Vendor-Id
ベンダーイド
The Vendor-Id field is four octets, and contains the Vendor-Id
of the TLV that was not supported. The high-order octet is 0
and the low-order three octets are the Structure of Management
Information (SMI) Network Management Private Enterprise Code of
the Vendor in network byte order. The Vendor-Id field MUST be
zero for TLVs that are not Vendor-Specific TLVs.
Vendor-イド分野は、4つの八重奏であり、サポートされなかったTLVのVendor-イドを含んでいます。 高位八重奏は0です、そして、下位の3つの八重奏がネットワークバイトオーダーにおけるVendorのManagement情報(SMI)ネットワークManagement兵士のエンタープライズCodeのStructureです。 Vendor-イド分野はVendor特有のTLVsでないTLVsのためのゼロでなければなりません。
NAK-Type
NAK-タイプ
The NAK-Type field is two octets. The field contains the Type
of the TLV that was not supported. A TLV of this Type MUST
have been included in the previous packet.
NAK-タイプ分野は2つの八重奏です。 分野はサポートされなかったTLVのTypeを含んでいます。 このTypeのTLVは前のパケットに含まれていたに違いありません。
TLVs
TLVs
This field contains a list of zero or more TLVs, each of which
MUST NOT have the mandatory bit set. These optional TLVs are
for future extensibility to communicate why the offending TLV
was determined to be unsupported.
この分野はゼロのリストか、より多くのTLVsを含んでいます。それはそれぞれ義務的な噛み付いているセットを持ってはいけません。 怒っているTLVがサポートされないと決心していたこれらの任意のTLVsは将来の伸展性を交信させることになっています。
4.2.4. Error TLV
4.2.4. 誤りTLV
The Error TLV allows an EAP peer or server to indicate errors to the other party. An EAP-FAST packet can contain 0 or more Error TLVs. The Error-Code field describes the type of error. Error Codes 1-999 represent successful outcomes (informative messages), 1000-1999 represent warnings, and codes 2000-2999 represent fatal errors. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure and the conversation must be terminated as described in Section 3.6.2. The Error TLV is defined as follows:
Error TLVはEAP同輩かサーバに誤りを相手に示させます。 EAP-FASTパケットは0Error TLVsを含むことができます。 Error-コード分野は誤りのタイプについて説明します。 1000-1999 警告を表して、誤りCodes1-999はうまくいっている結果(通知メッセージ)を表します、そして、コード2000-2999は致命的な誤りを表します。 失敗を示すResult TLVは致命的なError TLVに同伴しなければなりません、そして、セクション3.6.2で説明されるように会話を終えなければなりません。 Error TLVは以下の通り定義されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cam-Winget, et al. Informational [Page 24] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [24ページ]情報のRFC4851速いEAP2007年5月
M
M
Mandatory, set to one (1)
義務的であることで、1つにセットしてください。(1)
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
TLV Type
TLVはタイプします。
5 for Error TLV
5 誤りTLVのために
Length
長さ
4
4
Error-Code
エラーコード
The Error-Code field is four octets. Currently defined values
for Error-Code include:
Error-コード分野は4つの八重奏です。 Error-コードのための現在定義された値は:
2001 Tunnel_Compromise_Error
2001年のトンネル_感染_誤り
2002 Unexpected_TLVs_Exchanged
TLVs_が交換した2002の予期していなかった_
4.2.5. Vendor-Specific TLV
4.2.5. ベンダー特有のTLV
The Vendor-Specific TLV is available to allow vendors to support their own extended attributes not suitable for general usage. A Vendor-Specific TLV attribute can contain one or more TLVs, referred to as Vendor TLVs. The TLV-type of a Vendor-TLV is defined by the vendor. All the Vendor TLVs inside a single Vendor-Specific TLV belong to the same vendor. There can be multiple Vendor-Specific TLVs from different vendors in the same message.
Vendor特有のTLVは、ベンダーがそれら自身の一般的な用法に適していない拡張属性をサポートするのを許容するために利用可能です。 Vendor特有のTLV属性はVendor TLVsと呼ばれた1TLVsを含むことができます。 Vendor-TLVのTLV-タイプはベンダーによって定義されます。 独身のVendor特有のTLVの中のすべてのVendor TLVsが同じベンダーのものです。 同じメッセージには異なったベンダーからの複数のVendor特有のTLVsがあることができます。
Vendor TLVs may be optional or mandatory. Vendor TLVs sent with Result TLVs MUST be marked as optional.
ベンダーTLVsは任意であるか、または義務的であるかもしれません。 任意であるとしてResult TLVsと共に送られたベンダーTLVsをマークしなければなりません。
Cam-Winget, et al. Informational [Page 25] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [25ページ]情報のRFC4851速いEAP2007年5月
The Vendor-Specific TLV is defined as follows:
Vendor特有のTLVは以下の通り定義されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーイド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーTLVs… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 or 1
0か1
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
TLV Type
TLVはタイプします。
7 for Vendor Specific TLV
7 ベンダーの特定のTLVのために
Length
長さ
4 + cumulative length of all included Vendor TLVs
4 + すべての含まれているVendor TLVsの累積している長さ
Vendor-Id
ベンダーイド
The Vendor-Id field is four octets, and contains the Vendor-Id
of the TLV. The high-order octet is 0 and the low-order 3
octets are the SMI Network Management Private Enterprise Code
of the Vendor in network byte order.
Vendor-イド分野は、4つの八重奏であり、TLVのVendor-イドを含んでいます。 高位八重奏は0です、そして、下位の3つの八重奏がネットワークバイトオーダーにおけるVendorのSMI Network Management兵士のエンタープライズCodeです。
Vendor TLVs
ベンダーTLVs
This field is of indefinite length. It contains vendor-
specific TLVs, in a format defined by the vendor.
この分野は無期長さのものです。 それはベンダーによって定義された書式にベンダーの特定のTLVsを含んでいます。
4.2.6. EAP-Payload TLV
4.2.6. EAP-有効搭載量TLV
To allow piggybacking an EAP request or response with other TLVs, the EAP-Payload TLV is defined, which includes an encapsulated EAP packet and a list of optional TLVs. The optional TLVs are provided for future extensibility to provide hints about the current EAP authentication. Only one EAP-Payload TLV is allowed in a message. The EAP-Payload TLV is defined as follows:
他のTLVsとのEAP要求か応答を背負うのを許容するために、EAP-有効搭載量TLV(カプセル化されたEAPパケットと任意のTLVsのリストを含んでいる)は定義されます。 将来の伸展性が現在のEAP認証に関してヒントを提供するように、任意のTLVsを提供します。 1EAP-有効搭載量TLVだけがメッセージに許容されています。 EAP-有効搭載量TLVは以下の通り定義されます:
Cam-Winget, et al. Informational [Page 26] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [26ページ]情報のRFC4851速いEAP2007年5月
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP packet... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPパケット… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to (1)
義務的であって、設定しています。(1)
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
TLV Type
TLVはタイプします。
9 for EAP-Payload TLV
9 EAP-有効搭載量TLVのために
Length
長さ
length of embedded EAP packet + cumulative length of additional
TLVs
追加TLVsの埋め込まれたEAPパケット+累積している長さの長さ
EAP packet
EAPパケット
This field contains a complete EAP packet, including the EAP
header (Code, Identifier, Length, Type) fields. The length of
this field is determined by the Length field of the
encapsulated EAP packet.
この分野はEAPヘッダー(コード、Identifier、Length、Type)分野を含む完全なEAPパケットを含んでいます。 この分野の長さはカプセル化されたEAPパケットのLength分野のそばで決定しています。
TLVs
TLVs
This field contains a list of zero or more TLVs associated with
the EAP packet field. The TLVs MUST NOT have the mandatory bit
set. The total length of this field is equal to the Length
field of the EAP-Payload TLV, minus the Length field in the EAP
header of the EAP packet field.
この分野はEAPパケットに関連しているTLVsがさばくゼロか以上のリストを含んでいます。 TLVsは義務的なビットを設定させてはいけません。 この分野の全長はEAP-有効搭載量TLVのLength分野と等しいです、EAPパケット分野のEAPヘッダーのLength分野を引いて。
Cam-Winget, et al. Informational [Page 27] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [27ページ]情報のRFC4851速いEAP2007年5月
4.2.7. Intermediate-Result TLV
4.2.7. 中間結果TLV
The Intermediate-Result TLV provides support for acknowledged intermediate Success and Failure messages between multiple inner EAP methods within EAP. An Intermediate-Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV. The optional TLVs associated with this TLV are provided for future extensibility to provide hints about the current result. The Intermediate-Result TLV is defined as follows:
Intermediate-結果TLVはEAPの中の複数の内側のEAPメソッドの間に承認された中間的SuccessとFailureメッセージのサポートを提供します。 Cryptoを拘束力があるTLVは成功を示すIntermediate-結果TLVに同伴しなければなりません。 将来の伸展性が現在の結果に関してヒントを提供するように、このTLVに関連している任意のTLVsを提供します。 Intermediate-結果TLVは以下の通り定義されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| TLVs… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to (1)
義務的であって、設定しています。(1)
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
TLV Type
TLVはタイプします。
10 for Intermediate-Result TLV
10 中間結果TLVのために
Length
長さ
2 + cumulative length of the embedded associated TLVs
2 + 埋め込まれた関連TLVsの累積している長さ
Status
状態
The Status field is two octets. Values include:
Status分野は2つの八重奏です。 値は:
1 Success
1 成功
2 Failure
2 失敗
TLVs
TLVs
This field is of indeterminate length, and contains zero or
more of the TLVs associated with the Intermediate Result TLV.
The TLVs in this field MUST NOT have the mandatory bit set.
この分野は、不確定の長さがあって、Intermediate Result TLVに関連しているTLVsのゼロか以上を含んでいます。 この分野のTLVsは義務的なビットを設定させてはいけません。
Cam-Winget, et al. Informational [Page 28] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [28ページ]情報のRFC4851速いEAP2007年5月
4.2.8. Crypto-Binding TLV
4.2.8. 暗号を拘束力があるTLV
The Crypto-Binding TLV is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the EAP-FAST version negotiated before TLS tunnel establishment, see Section 3.1.
Cryptoを拘束力があるTLVは、同輩とサーバの両方が認証のトンネル設立と系列に参加したと立証するのに使用されます。 セクション3.1は、また、それがTLSが設立にトンネルを堀る前に交渉されたEAP-FASTバージョンの検証を提供するのを見ます。
The Crypto-Binding TLV MUST be included with the Intermediate-Result TLV to perform Cryptographic Binding after each successful EAP method in a sequence of EAP methods. The Crypto-Binding TLV can be issued at other times as well.
次々にのEAPメソッドの働くIntermediate-結果TLV Cryptographic Bindingによって、後それぞれうまくいった状態で含まれていて、TLV MUSTをCrypto縛りEAPメソッド。 また、他の時にCryptoを拘束力があるTLVを発行できます。
The Crypto-Binding TLV is valid only if the following checks pass:
以下のチェックが終わる場合にだけ、Cryptoを拘束力があるTLVは有効です:
o The Crypto-Binding TLV version is supported
o Cryptoを拘束力があるTLVバージョンはサポートされます。
o The MAC verifies correctly
o MACは正しく確かめます。
o The received version in the Crypto-Binding TLV matches the version
sent by the receiver during the EAP version negotiation
o バージョンがEAPバージョン交渉の間に受信機で送ったCryptoを拘束力があるTLVマッチの容認されたバージョン
o The subtype is set to the correct value
o 「副-タイプ」は正しい値に用意ができています。
If any of the above checks fail, then the TLV is invalid. An invalid Crypto-Binding TLV is a fatal error and is handled as described in Section 3.6.2.
上のチェックのどれかが失敗するなら、TLVは無効です。 無効のCryptoを拘束力があるTLVは致命的な誤りであり、セクション3.6.2で説明されるように扱われます。
The Crypto-Binding TLV is defined as follows:
Cryptoを拘束力があるTLVは以下の通り定義されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version | Received Ver. | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| バージョン| 容認されたVer。| サブタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 一回だけ~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 合成MAC~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to (1)
義務的であって、設定しています。(1)
Cam-Winget, et al. Informational [Page 29] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [29ページ]情報のRFC4851速いEAP2007年5月
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
TLV Type
TLVはタイプします。
12 for Crypto-Binding TLV
12 暗号を拘束力があるTLVのために
Length
長さ
56
56
Reserved
予約されます。
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
Version
バージョン
The Version field is a single octet, which is set to the
version of Crypto-Binding TLV the EAP method is using. For an
implementation compliant with this version of EAP-FAST, the
version number MUST be set to 1.
バージョン分野がただ一つの八重奏である、どれがCrypto-結合TLVのバージョンにEAPメソッドを設定することであるかは使用されています。 EAP-FASTのこのバージョンによる対応することの実装において、バージョン番号を1に設定しなければなりません。
Received Version
容認されたバージョン
The Received Version field is a single octet and MUST be set to
the EAP version number received during version negotiation.
Note that this field only provides protection against downgrade
attacks, where a version of EAP requiring support for this TLV
is required on both sides.
Receivedバージョン分野をただ一つの八重奏であり、バージョン交渉の間に受け取られたEAPバージョン番号に設定しなければなりません。 この分野がダウングレード攻撃に対する保護を提供するだけであることに注意してください、EAPがこのTLVに支持を要するバージョンが両側で必要であるところで。
Sub-Type
サブタイプ
The Sub-Type field is one octet. Defined values include:
Sub-タイプ分野は1つの八重奏です。 定義された値は:
0 Binding Request
0の拘束力がある要求
1 Binding Response
1 拘束力がある応答
Nonce
一回だけ
The Nonce field is 32 octets. It contains a 256-bit nonce that
is temporally unique, used for compound MAC key derivation at
each end. The nonce in a request MUST have its least
significant bit set to 0 and the nonce in a response MUST have
the same value as the request nonce except the least
significant bit MUST be set to 1.
Nonce分野は32の八重奏です。 それは各端のときに合成MACキー派生において、時間的にユニークで、使用された256ビットの一回だけを含みます。 要求における一回だけで0に最下位ビットを設定しなければなりません、そして、応答における一回だけには、最下位ビット以外の一回だけを1に設定しなければならないという要求と同じ値がなければなりません。
Cam-Winget, et al. Informational [Page 30] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [30ページ]情報のRFC4851速いEAP2007年5月
Compound MAC
合成MAC
The Compound MAC field is 20 octets. This can be the Server
MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of
the MAC is described in Section 5.3.
Compound MAC分野は20の八重奏です。 これは、Server MAC(B1_MAC)かClient MACであるかもしれません(B2_MAC)。 MACの計算はセクション5.3で説明されます。
4.2.9. Request-Action TLV
4.2.9. 要求動作TLV
The Request-Action TLV MAY be sent by the peer along with a Result TLV in response to a server's successful Result TLV. It allows the peer to request the EAP server to negotiate additional EAP methods or process TLVs specified in the response packet. The server MAY ignore this TLV.
Request-動作TLV MAY、サーバのうまくいっているResult TLVに対応してResult TLVに伴う同輩によって送られてください。 それで、同輩は、応答パケットで指定された追加EAPメソッドかプロセスTLVsを交渉するようEAPサーバに要求できます。 サーバはこのTLVを無視するかもしれません。
The Request-Action TLV is defined as follows:
Request-動作TLVは以下の通り定義されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLVはタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 動作| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory set to one (1)
1つへの義務的なセット(1)
R
R
Reserved, set to zero (0)
予約されていて、ゼロにセットしてください。(0)
TLV Type
TLVはタイプします。
19 for Request-Action TLV
19 要求動作TLVのために
Length
長さ
2
2
Action
動作
The Action field is two octets. Values include:
Action分野は2つの八重奏です。 値は:
Process-TLV
プロセス-TLV
Negotiate-EAP
EAPを交渉します。
Cam-Winget, et al. Informational [Page 31] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [31ページ]情報のRFC4851速いEAP2007年5月
4.3. Table of TLVs
4.3. TLVsのテーブル
The following table provides a guide to which TLVs may be found in which kinds of messages, and in what quantity. The messages are as follows: Request is an EAP-FAST Request, Response is an EAP-FAST Response, Success is a message containing a successful Result TLV, and Failure is a message containing a failed Result TLV.
以下のテーブルはTLVsがどの種類に関するメッセージ、およびどんな量に見つけられるかもしれないガイドを提供します。 メッセージは以下の通りです: 要求はEAP-FAST Requestです、そして、ResponseはEAP-FAST Responseです、そして、SuccessはうまくいっているResult TLVを含むメッセージです、そして、Failureは失敗したResult TLVを含むメッセージです。
Request Response Success Failure TLVs 0-1 0-1 0-1 0-1 Intermediate-Result 0-1 0-1 0 0 EAP-Payload 0-1 0-1 1 1 Result 0-1 0-1 0-1 0-1 Crypto-Binding 0+ 0+ 0+ 0+ Error 0+ 0+ 0 0 NAK 0+ 0+ 0+ 0+ Vendor-Specific [NOTE1] 0 0-1 0-1 0-1 Request-Action
ベンダー応答成功失敗TLVs0-1 0-1 0-1 0-1中間結果0-1 0-1 0 0EAP-有効搭載量0-1 0-1 1 1結果0-1 0-1 0-1 0-1暗号を拘束力がある0+0+0+0+誤り0+0+0 0NAK0+0+0+0+特有の[NOTE1]0 0-1 0-1 0-1要求動作を要求してください。
[NOTE1] Vendor TLVs (included in Vendor-Specific TLVs) sent with a Result TLV MUST be marked as optional.
任意であるとしてResult TLVと共に送られた[NOTE1]ベンダーTLVs(Vendor特有のTLVsでは、含まれている)をマークしなければなりません。
The following table defines the meaning of the table entries in the sections below:
以下のテーブルは下のセクションでテーブル項目の意味を定義します:
0 This TLV MUST NOT be present in the message.
0、このTLV MUST NOT、メッセージに存在してください。
0+ Zero or more instances of this TLV MAY be present in the message.
0 ゼロか以上が現在のコネがメッセージであったならこのTLV MAYについて例証する+。
0-1 Zero or one instance of this TLV MAY be present in the message.
0-1ゼロか1 現在のコネがメッセージであったならこのTLV MAYについて例証します。
1 Exactly one instance of this TLV MUST be present in the message.
ちょうどものが現在のコネがメッセージであったならこのTLV MUSTについて例証する1。
5. Cryptographic Calculations
5. 暗号の計算
5.1. EAP-FAST Authentication Phase 1: Key Derivations
5.1. 速いEAP認証フェーズ1: 主要な派生
The EAP-FAST Authentication tunnel key is calculated similarly to the TLS key calculation with an additional 40 octets (referred to as the session_key_seed) generated. The additional session_key_seed is used in the Session Key calculation in the EAP-FAST Tunneled Authentication conversation.
EAP-FAST Authenticationトンネルキーは同様に追加40の八重奏(セッションの_の主要な_種子と呼ばれる)が生成されているTLSの主要な計算に計算されます。 追加セッション_主要な_種子はEAP-FAST Tunneled Authenticationの会話におけるSession Key計算に使用されます。
Cam-Winget, et al. Informational [Page 32] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [32ページ]情報のRFC4851速いEAP2007年5月
To generate the key material required for the EAP-FAST Authentication tunnel, the following construction from [RFC4346] is used:
EAP-FAST Authenticationトンネルに必要である主要な材料を生成するために、[RFC4346]からの以下の建築は使用されています:
key_block = PRF(master_secret, "key expansion",
server_random + client_random)
主要な_ブロック=PRF(_が秘密の「キー拡張」、サーバ_無作為の+クライアント_であると無作為の状態でマスタリングします)
where '+' denotes concatenation.
'+'が連結を指示するところ。
The PRF function used to generate keying material is defined by [RFC4346].
材料を合わせる生成するのにおいて中古のPRF機能は[RFC4346]によって定義されます。
For example, if the EAP-FAST Authentication employs 128-bit RC4 and SHA1, the key_block is 112 octets long and is partitioned as follows:
例えば、EAP-FAST Authenticationが128ビットのRC4とSHA1を使うなら、主要な_ブロックは、長い間の112の八重奏であり、以下の通り仕切られます:
client_write_MAC_secret[20]
server_write_MAC_secret[20]
client_write_key[16]
server_write_key[16]
client_write_IV[0]
server_write_IV[0]
session_key_seed[40]
_が_IV[0]セッションの_の主要な_種子を書くと__秘密の[20]サーバ_が_IV[0]サーバ_に書くと__秘密の[20]クライアント_が_主要な[16]クライアント_に書くと_主要な[16]サーバ_に書くMACに書くMACに書くクライアント[40]
The session_key_seed is used by the EAP-FAST Authentication Phase 2 conversation to both cryptographically bind the inner method(s) to the tunnel as well as generate the resulting EAP-FAST session keys. The other quantities are used as they are defined in [RFC4346].
セッションの_の主要な_種子は、暗号で内側のメソッドをトンネルに縛って、結果として起こるEAP-FASTセッションキーを生成するのにEAP-FAST Authentication Phase2の会話で使用されます。 それらが[RFC4346]で定義されるとき、他の量は使用されています。
The master_secret is generated as specified in TLS unless a PAC is used to establish the TLS tunnel. When a PAC is used to establish the TLS tunnel, the master_secret is calculated from the specified client_random, server_random, and PAC-Key as follows:
マスター_秘密はPACがTLSトンネルを証明するのに使用されない場合TLSで指定されるように発生しています。 PACがTLSトンネルを証明するのに使用されるとき、マスター_秘密は、以下の通り指定されたクライアント_無作為で、サーバ_無作為から計算されていて、PAC主要です:
master_secret = T-PRF(PAC-Key, "PAC to master secret label hash",
server_random + client_random, 48)
マスター_秘密=T-PRF(PAC主要で、「秘密をマスタリングするPACはハッシュをラベルしてい」て、_無作為の+クライアントサーバ_無作為の48)
where T-PRF is described in Section 5.5.
T-PRFがセクション5.5で説明されるところ。
5.2. Intermediate Compound Key Derivations
5.2. 中間的合成主要な派生
The session_key_seed derived as part of EAP-FAST Phase 2 is used in EAP-FAST Phase 2 to generate an Intermediate Compound Key (IMCK) used to verify the integrity of the TLS tunnel after each successful inner authentication and in the generation of Master Session Key (MSK) and Extended Master Session Key (EMSK) defined in [RFC3748]. Note that the IMCK must be recalculated after each successful inner EAP method.
EAP-FAST Phase2の一部がIntermediate Compound Key(IMCK)を生成するのにEAP-FAST Phase2で使用されるので引き出されたセッションの_の主要な_種子は以前はそれぞれのうまくいっている内側の認証の後と[RFC3748]で定義されたMaster Session Key(MSK)とExtended Master Session Key(EMSK)の世代でTLSトンネルの保全についてよく確かめていました。 それぞれのうまくいっている内側のEAPメソッドの後にIMCKについて再計算しなければならないことに注意してください。
Cam-Winget, et al. Informational [Page 33] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [33ページ]情報のRFC4851速いEAP2007年5月
The first step in these calculations is the generation of the base compound key, IMCK[n] from the session_key_seed and any session keys derived from the successful execution of n inner EAP methods. The inner EAP method(s) may provide Master Session Keys, MSK1..MSKn, corresponding to inner methods 1 through n. The MSK is truncated at 32 octets if it is longer than 32 octets or padded to a length of 32 octets with zeros if it is less than 32 octets. If the ith inner method does not generate an MSK, then MSKi is set to zero (e.g., MSKi = 32 octets of 0x00s). If an inner method fails, then it is not included in this calculation. The derivations of S-IMCK is as follows:
これらの計算における第一歩はベース合成キー、セッションの_の主要な_種子からのIMCK[n]、およびn内側のEAPメソッドのうまくいっている実行から得られたどんなセッションキーの世代です。 内側のEAPメソッドはMaster Sessionキーズ、MSK1を提供するかもしれません。1〜nに内側のメソッドに対応するMSKn。 それが32未満の八重奏であるなら32の八重奏より長く、ゼロで32の八重奏の長さに水増しされるなら、MSKは32の八重奏のときに先端を切られます。 ithの内側のメソッドがMSKを生成しないなら、MSKiは(0x00sの32の例えば、MSKi=八重奏)のゼロを合わせるように用意ができています。 内側のメソッドが失敗するなら、それはこの計算に含まれていません。 S-IMCKの派生は以下の通りです:
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = T-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
MSK[j], 60)
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
n-1への主要なセッションの_種子For j_S-IMCK[0]==1はIMCKの最後の20のIMCK[j] CMK[j]の最初の40の(S-IMCK[j-1]、「内側のメソッドはキーを合成する」MSK[j]、60)S-IMCK[j]=八重奏=八重奏をIMCK[j]=T-PRFにします。[j]
where T-PRF is described in Section 5.5.
T-PRFがセクション5.5で説明されるところ。
5.3. Computing the Compound MAC
5.3. 合成MACを計算します。
For authentication methods that generate keying material, further protection against man-in-the-middle attacks is provided through cryptographically binding keying material established by both EAP- FAST Phase 1 and EAP-FAST Phase 2 conversations. After each successful inner EAP authentication, EAP MSKs are cryptographically combined with key material from EAP-FAST Phase 1 to generate a compound session key, CMK. The CMK is used to calculate the Compound MAC as part of the Crypto-Binding TLV described in Section 4.2.8, which helps provide assurance that the same entities are involved in all communications in EAP-FAST. During the calculation of the Compound-MAC the MAC field is filled with zeros.
合わせるのが材料であると生成する認証方法において、EAP- FAST Phase1とEAP-FAST Phase両方の2つの会話で確立された材料を合わせながら暗号で付くことで介入者攻撃に対するさらなる保護を提供します。 それぞれのうまくいっている内側のEAP認証の後に、EAP MSKsは、合成セッションキー(CMK)を生成するために暗号でEAP-FAST Phase1からの主要な材料に合成されます。 CMKは、セクション4.2.8で説明されたCryptoを拘束力があるTLVの一部としてCompound MACについて計算するのに使用されます。TLVは同じ実体がEAP-FASTのすべてのコミュニケーションにかかわるという保証を提供するのを助けます。Compound-MACの計算の間、MAC分野はゼロでいっぱいにされます。
The Compound MAC computation is as follows:
Compound MAC計算は以下の通りです:
CMK = CMK[j]
Compound-MAC = HMAC-SHA1( CMK, Crypto-Binding TLV )
CMK[j]合成CMK=MacはHMAC-SHA1と等しいです。(TLVを暗号で縛るCMK
where j is the number of the last successfully executed inner EAP method.
jが最後に首尾よく実行された内側のEAPメソッドの数であるところ。
Cam-Winget, et al. Informational [Page 34] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [34ページ]情報のRFC4851速いEAP2007年5月
5.4. EAP Master Session Key Generation
5.4. EAPマスターセッションキー生成
EAP-FAST Authentication assures the master session key (MSK) and Extended Master Session Key (EMSK) output from the EAP method are the result of all authentication conversations by generating an Intermediate Compound Key (IMCK). The IMCK is mutually derived by the peer and the server as described in Section 5.2 by combining the MSKs from inner EAP methods with key material from EAP-FAST Phase 1. The resulting MSK and EMSK are generated as part of the IMCKn key hierarchy as follows:
EAP-FAST Authenticationは、EAPメソッドからの(MSK)とExtended Master Session Key(EMSK)出力がIntermediate Compound Key(IMCK)を生成するのによるすべての認証の会話の結果であることをマスターセッションキーに保証します。 IMCKはセクション5.2でMSKsを内側のEAPメソッドからEAP-FAST Phase1からの主要な材料に合成することによって説明されるように同輩とサーバによって互いに引き出されます。 結果として起こるMSKとEMSKは以下のIMCKnの主要な階層構造の一部として生成されます:
MSK = T-PRF(S-IMCK[j], "Session Key Generating Function", 64)
EMSK = T-PRF(S-IMCK[j],
"Extended Session Key Generating Function", 64)
MSKはT-PRF(S-IMCK[j]、「セッションの主要な母関数」、64)EMSK=T-PRFと等しいです。(S-IMCK[j]、「拡張セッション主要な母関数」、64)
where j is the number of the last successfully executed inner EAP method.
jが最後に首尾よく実行された内側のEAPメソッドの数であるところ。
The EMSK is typically only known to the EAP-FAST peer and server and is not provided to a third party. The derivation of additional keys and transportation of these keys to a third party is outside the scope of this document.
EMSKはEAP-FAST同輩とサーバに通常知られているだけであり、第三者に提供されません。 このドキュメントの範囲の外に追加キーの派生と第三者のこれらのキーの輸送があります。
If no EAP methods have been negotiated inside the tunnel or no EAP methods have been successfully completed inside the tunnel, the MSK and EMSK will be generated directly from the session_key_seed meaning S-IMCK = session_key_seed.
EAPメソッドが全くトンネルの中で交渉されていないか、またはEAPメソッドが全くトンネルの中で首尾よく完成されていないと、MSKとEMSKは直接主要なセッション意味S-IMCK=セッション_キー___種子種子から生成されるでしょう。
5.5. T-PRF
5.5. T-PRF
EAP-FAST employs the following PRF prototype and definition:
EAP-FASTは以下のPRFプロトタイプと定義を使います:
T-PRF = F(key, label, seed, outputlength)
T-PRFはFと等しいです。(キー、ラベル、種子、outputlength)
Where label is intended to be a unique label for each different use of the T-PRF. The outputlength parameter is a two-octet value that is represented in big endian order. Also note that the seed value may be optional and may be omitted as in the case of the MSK derivation described in Section 5.4.
ラベルがT-PRFのそれぞれの異なった使用のためのユニークなラベルであることを意図するところ。 outputlengthパラメタはビッグエンディアンオーダーに表される2八重奏の値です。 また、種子値がセクション5.4で説明されたMSK派生に関するケースのように任意であるかもしれなく、省略されるかもしれないことに注意してください。
Cam-Winget, et al. Informational [Page 35] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [35ページ]情報のRFC4851速いEAP2007年5月
To generate the desired outputlength octets of key material, the T-PRF is calculated as follows:
主要な材料、T-PRFの八重奏を必要なoutputlengthに生成するのは以下の通り計算されています:
S = label + 0x00 + seed
T-PRF output = T1 + T2 + T3 + ... + Tn
T1 = HMAC-SHA1 (key, S + outputlength + 0x01)
T2 = HMAC-SHA1 (key, T1 + S + outputlength + 0x02)
T3 = HMAC-SHA1 (key, T2 + S + outputlength + 0x03)
Tn = HMAC-SHA1 (key, Tn-1 + S + outputlength + 0xnn)
ラベル+0×00+種子T-PRF S=出力はT1+T2+T3+と等しいです… HMAC-SHA1(キー、T2+S+outputlength+0×03)HMAC-SHA1(キー、T1+S+outputlength+0×02)HMAC-SHA1(キー、S+outputlength+0×01)+ Tn T1=T2=T3=TnはHMAC-SHA1と等しいです。(キー、Tn-1+S+outputlength+0xnn)
where '+' indicates concatenation. Each Ti generates 20-octets of keying material. The last Tn may be truncated to accommodate the desired length specified by outputlength.
'+'が連結を示すところ。 各Tiは合わせることの材料の20八重奏を生成します。 最後のTnは、outputlengthによって指定された必要な長さを収容するために先端を切られるかもしれません。
6. IANA Considerations
6. IANA問題
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the EAP- FAST protocol, in accordance with BCP 26, [RFC2434].
このセクションはEAP- FASTプロトコルに関連する値の登録に関してインターネットAssigned民数記Authority(IANA)に指導を供給します、BCP26によると、[RFC2434。]
EAP-FAST has already been assigned the EAP Method Type number 43.
既にEAP Method Type No.43をEAP-FASTに割り当ててあります。
The document defines a registry for EAP-FAST TLV types, which may be assigned by Specification Required as defined in [RFC2434]. Section 4.2 defines the TLV types that initially populate the registry. A summary of the EAP-FAST TLV types is given below:
ドキュメントはEAP-FAST TLVタイプのために登録を定義します。(タイプは[RFC2434]で定義されるようにSpecification Requiredによって選任されるかもしれません)。 セクション4.2は初めは登録に居住するTLVタイプを定義します。 EAP-FAST TLVタイプの概要を以下にします:
0 Reserved 1 Reserved 2 Reserved 3 Result TLV 4 NAK TLV 5 Error TLV 7 Vendor-Specific TLV 9 EAP-Payload TLV 10 Intermediate-Result TLV 11 PAC TLV [EAP-PROV] 12 Crypto-Binding TLV 18 Server-Trusted-Root TLV [EAP-PROV] 19 Request-Action TLV 20 PKCS#7 TLV [EAP-PROV]
0 予約された1は2の予約された3結果TLV4NAK TLV5誤りTLV7のベンダー特有のTLV9EAP-有効搭載量TLV10中間結果TLV11PAC TLV[EAP-PROV]12暗号を拘束力があるTLV18サーバの信じられた根のTLV[EAP-PROV]19要求動作TLV20PKCS#7TLVを予約しました。[EAP-PROV]
The Error-TLV defined in Section 4.2.4 requires an error-code. EAP- FAST Error-TLV error-codes are assigned based on specifications required as defined in [RFC2434]. The initial list of error codes is as follows:
セクション4.2.4で定義されたError-TLVはエラーコードを必要とします。 EAP- FAST Error-TLVエラーコードは[RFC2434]の定義されるとして必要な仕様に基づいて割り当てられます。 エラーコードの初期のリストは以下の通りです:
Cam-Winget, et al. Informational [Page 36] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [36ページ]情報のRFC4851速いEAP2007年5月
2001 Tunnel_Compromise_Error
2001年のトンネル_感染_誤り
2002 Unexpected_TLVs_Exchanged
TLVs_が交換した2002の予期していなかった_
The Request-Action TLV defined in Section 4.2.9 contains an action code which is assigned on a specification required basis as defined in [RFC2434]. The initial actions defined are:
セクション4.2.9で定義されたRequest-動作TLVは[RFC2434]で定義されるように仕様必要なベースで割り当てられるアクション・コードを含んでいます。 定義された初期の動きは以下の通りです。
1 Process-TLV
1 プロセス-TLV
2 Negotiate-EAP
2、EAPを交渉します。
The various values under Vendor-Specific TLV are assigned by Private Use and do not need to be assigned by IANA.
Vendor特有のTLVの下の様々な値によって兵士のUseによって割り当てられて、IANAによって割り当てられる必要はありません。
7. Security Considerations
7. セキュリティ問題
EAP-FAST is designed with a focus on wireless media, where the medium itself is inherent to eavesdropping. Whereas in wired media, an attacker would have to gain physical access to the wired medium; wireless media enables anyone to capture information as it is transmitted over the air, enabling passive attacks. Thus, physical security can not be assumed and security vulnerabilities are far greater. The threat model used for the security evaluation of EAP- FAST is defined in the EAP [RFC3748].
焦点がワイヤレスのメディアにある状態で、EAP-FASTは設計されています。(そこでは、媒体自体が盗聴に固有です)。 ワイヤードなメディアでは、攻撃者はワイヤードな媒体への物理的なアクセスを得なければならないでしょうが。 ワイヤレスのメディアは、受け身の攻撃を可能にして、それが空気の上に伝えられるようにだれでも情報を得るのを可能にします。 したがって、物理的なセキュリティを想定できません、そして、セキュリティの脆弱性ははるかにすばらしいです。 EAP- FASTの機密保護評価に使用される脅威モデルはEAP[RFC3748]で定義されます。
7.1. Mutual Authentication and Integrity Protection
7.1. 互いの認証と保全保護
EAP-FAST as a whole, provides message and integrity protection by establishing a secure tunnel for protecting the authentication method(s). The confidentiality and integrity protection is defined by TLS and provides the same security strengths afforded by TLS employing a strong entropy shared master secret. The integrity of the key generating authentication methods executed within the EAP- FAST tunnel is verified through the calculation of the Crypto-Binding TLV. This ensures that the tunnel endpoints are the same as the inner method endpoints.
全体でEAP-FAST、認証方法を保護するために安全なトンネルを確立することによって、メッセージと保全保護を提供します。 秘密性と保全保護は、TLSによって定義されて、強いエントロピー共有されたマスター秘密を使うTLSによって提供された同じセキュリティの強さを提供します。 認証がEAP- FASTトンネルの中で実行されたメソッドであると生成するキーの保全はCryptoを拘束力があるTLVの計算で確かめられます。 これは、トンネル終点が内側のメソッド終点と同じであることを確実にします。
The Result TLV is protected and conveys the true Success or Failure of EAP-FAST, and should be used as the indicator of its success or failure respectively. However, as EAP must terminate with a clear text EAP Success or Failure, a peer will also receive a clear text EAP Success or Failure. The received clear text EAP success or failure must match that received in the Result TLV; the peer SHOULD silently discard those clear text EAP Success or Failure messages that do not coincide with the status sent in the protected Result TLV.
Result TLVは保護されて、EAP-FASTの本当のSuccessかFailureを運んで、成否のインディケータとしてそれぞれ使用されるべきです。 しかしながら、EAPがまたEAP SuccessかFailure、同輩がそうするクリアテキストで終わらなければならないように、クリアテキストのEAP SuccessかFailureを受けてください。 容認されたクリアテキストEAP成否はResult TLVに受け取られたそれに合わなければなりません。 同輩SHOULDは静かに状態と一致していないテキストEAP SuccessかFailureメッセージが保護されたResult TLVを送ったのが明確なそれらを捨てます。
Cam-Winget, et al. Informational [Page 37] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [37ページ]情報のRFC4851速いEAP2007年5月
7.2. Method Negotiation
7.2. メソッド交渉
As is true for any negotiated EAP protocol, NAK packets used to suggest an alternate authentication method are sent unprotected and as such, are subject to spoofing. During unprotected EAP method negotiation, NAK packets may be interjected as active attacks to negotiate down to a weaker form of authentication, such as EAP-MD5 (which only provides one-way authentication and does not derive a key). Both the peer and server should have a method selection policy that prevents them from negotiating down to weaker methods. Inner method negotiation resists attacks because it is protected by the mutually authenticated TLS tunnel established. Selection of EAP-FAST as an authentication method does not limit the potential inner authentication methods, so EAP-FAST should be selected when available.
本当であるように、どんな交渉されたEAPプロトコルにおいても、代替の認証方法を示すのに使用されるNAKパケットは、保護がなくあれほど状態で送られて、スプーフィングを受けることがあります。 保護のないEAPメソッド交渉の間、交渉する活発な攻撃が、より弱い形式の認証にダウンするとき、NAKパケットを挿入するかもしれません、EAP-MD5(一方向認証を提供するだけであり、キーを引き出さない)などのように。 ともに、同輩とサーバには、それらを交渉から、より弱いメソッドまで防ぐメソッド選択方針があるべきです。 それがトンネルが設立した互いに認証されたTLSによって保護されるので、内側のメソッド交渉は攻撃に抵抗します。 認証方法としてのEAP-FASTの選択が潜在的内側の認証方法を制限しないので、利用可能であるときに、EAP-FASTは選択されるべきです。
An attacker cannot readily determine the inner EAP method used, except perhaps by traffic analysis. It is also important that peer implementations limit the use of credentials with an unauthenticated or unauthorized server.
攻撃者は容易に恐らくトラヒック分析以外に、使用される内側のEAPメソッドを決定できません。 また、同輩実装が非認証されたか権限のないサーバによる資格証明書の使用を制限するのも、重要です。
7.3. Separation of Phase 1 and Phase 2 Servers
7.3. フェーズ1とフェーズ2サーバの分離
Separation of the EAP-FAST Phase 1 from the Phase 2 conversation is not recommended. Allowing the Phase 1 conversation to be terminated at a different server than the Phase 2 conversation can introduce vulnerabilities if there is not a proper trust relationship and protection for the protocol between the two servers. Some vulnerabilities include:
Phase2の会話からのEAP-FAST Phase1の分離は推薦されません。 異なったサーバでは、終えられてください。1つの会話をPhaseに許す、2つのサーバの間には、プロトコルのための適切な信頼関係と保護がなければPhase2の会話が脆弱性を導入できるより。 いくつかの脆弱性は:
o Loss of identity protection o Offline dictionary attacks o Lack of policy enforcement
o 方針実施のアイデンティティ保護o Offline辞書攻撃o Lackの損失
There may be cases where a trust relationship exists between the Phase 1 and Phase 2 servers, such as on a campus or between two offices within the same company, where there is no danger in revealing the inner identity and credentials of the peer to entities between the two servers. In these cases, using a proxy solution without end-to-end protection of EAP-FAST MAY be used. The EAP-FAST encrypting/decrypting gateway SHOULD, at a minimum, provide support for IPsec or similar protection in order to provide confidentiality for the portion of the conversation between the gateway and the EAP server.
ケースが信頼関係が2つのサーバの間には、同輩の内側のアイデンティティと資格証明書を実体に明らかにするのにおいて危険が全くないのと同じ会社の中にキャンパスなどのPhase1とPhase2つのサーバの間、または、2つのオフィスの間に存在するところにあるかもしれません。 これらの場合では、終わりから終わりへのEAP-FAST MAYの保護なしでプロキシソリューションを使用して、使用されてください。 最小限でゲートウェイがSHOULDであると暗号化するか、または解読するEAP-FASTは、ゲートウェイとEAPサーバとの会話の部分に秘密性を提供するためにIPsecのサポートか同様の保護を提供します。
Cam-Winget, et al. Informational [Page 38] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [38ページ]情報のRFC4851速いEAP2007年5月
7.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies
7.4. 知られている脆弱性とプロトコル欠乏の緩和
EAP-FAST addresses the known deficiencies and weaknesses in the EAP method. By employing a shared secret between the peer and server to establish a secured tunnel, EAP-FAST enables:
EAP-FASTはEAPメソッドで知られている欠乏と弱点を扱います。 機密保護しているトンネルを証明するのに同輩とサーバの間の共有秘密キーを使うことによって、EAP-FASTは以下を可能にします。
o Per packet confidentiality and integrity protection o User identity protection o Better support for notification messages o Protected EAP inner method negotiation o Sequencing of EAP methods o Strong mutually derived master session keys o Acknowledged success/failure indication o Faster re-authentications through session resumption o Mitigation of dictionary attacks o Mitigation of man-in-the-middle attacks o Mitigation of some denial-of-service attacks
o パケットに従って、秘密性と保全保護o Userアイデンティティ保護o Betterは、通知メッセージoのためにProtected EAPの内側のメソッド交渉oがEAPメソッドo Strong互いに派生しているマスターセッションキーo Acknowledgedの成功/故障指示o Faster再認証のSequencingであるといくつかのサービス不能攻撃の介入者攻撃o Mitigationの辞書攻撃o Mitigationのセッション再開o Mitigationでサポートします。
It should be noted that with EAP-FAST, as in many other authentication protocols, a denial-of-service attack can be mounted by adversaries sending erroneous traffic to disrupt the protocol. This is a problem in many authentication or key agreement protocols and is therefore noted for EAP-FAST as well.
EAP-FASTと共に、プロトコルを混乱させるために誤ったトラフィックを送る敵が他の多くの認証プロトコルのようにサービス不能攻撃を仕掛けることができることに注意されるべきです。 これは、多くの認証か主要な協定プロトコルの問題であり、したがって、また、EAP-FASTによって述べられます。
EAP-FAST was designed with a focus on protected authentication methods that typically rely on weak credentials, such as password- based secrets. To that extent, the EAP-FAST Authentication mitigates several vulnerabilities, such as dictionary attacks, by protecting the weak credential-based authentication method. The protection is based on strong cryptographic algorithms in TLS to provide message confidentiality and integrity. The keys derived for the protection relies on strong random challenges provided by both peer and server as well as an established key with strong entropy. Implementations should follow the recommendation in [RFC4086] when generating random numbers.
焦点が弱い資格証明書を通常当てにする保護された認証方法にある状態で、EAP-FASTは設計されました、パスワードベースの秘密などのように。 その程度まで、EAP-FAST Authenticationは弱い資格証明書ベースの認証方法を保護するのによる辞書攻撃などのいくつかの脆弱性を緩和します。 保護は、メッセージ秘密性と保全を提供するためにTLSの強い暗号アルゴリズムに基づいています。 保護のために引き出されたキーは同輩とサーバと確立したキーの両方によって強いエントロピーに提供された強い無作為の挑戦に依存します。 乱数を生成するとき、実装は[RFC4086]で推薦に続くべきです。
7.4.1. User Identity Protection and Verification
7.4.1. ユーザアイデンティティ保護と検証
The initial identity request response exchange is sent in cleartext outside the protection of EAP-FAST. Typically the Network Access Identifier (NAI) [RFC4282] in the identity response is useful only for the realm information that is used to route the authentication requests to the right EAP server. This means that the identity response may contain an anonymous identity and just contain realm information. In other cases, the identity exchange may be eliminated altogether if there are other means for establishing the destination realm of the request. In no case should an intermediary place any trust in the identity information in the identity response since it
cleartextでEAP-FASTの保護の外で初期のアイデンティティ要求応答交換を送ります。アイデンティティ応答におけるNetwork Access Identifier(NAI)[RFC4282]は通常、正しいEAPサーバに認証要求を発送するのに使用される分野情報だけの役に立ちます。これは、アイデンティティ応答が匿名のアイデンティティを含んでいて、ただ分野情報を含むかもしれないことを意味します。 他の場合では、要求の目的地分野を確立するための他の手段があれば、アイデンティティ交換は全体で排除されるかもしれません。 仲介者はそれ以来のアイデンティティ応答で少しの信頼もアイデンティティ情報に決して、置くべきではありません。
Cam-Winget, et al. Informational [Page 39] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [39ページ]情報のRFC4851速いEAP2007年5月
is unauthenticated an may not have any relevance to the authenticated identity. EAP-FAST implementations should not attempt to compare any identity disclosed in the initial cleartext EAP Identity response packet with those Identities authenticated in Phase 2
非認証される、認証されたアイデンティティに少しの関連性も持っていないかもしれません。 EAP-FAST実装は、それらのIdentitiesがPhase2で認証されている状態で初期のcleartext EAP Identity応答パケットで明らかにされたどんなアイデンティティも比較するのを試みるべきではありません。
Identity request-response exchanges sent after the EAP-FAST tunnel is established are protected from modification and eavesdropping by attackers.
EAP-FASTトンネルが変更から保護されて、攻撃者で盗み聞きながら確立された後にアイデンティティ要求応答交換は発信しました。
Note that since TLS client certificates are sent in the clear, if identity protection is required, then it is possible for the TLS authentication to be re-negotiated after the first server authentication. To accomplish this, the server will typically not request a certificate in the server_hello, then after the server_finished message is sent, and before EAP-FAST Phase 2, the server MAY send a TLS hello_request. This allows the client to perform client authentication by sending a client_hello if it wants to, or send a no_renegotiation alert to the server indicating that it wants to continue with EAP-FAST Phase 2 instead. Assuming that the client permits renegotiation by sending a client_hello, then the server will respond with server_hello, a certificate and certificate_request messages. The client replies with certificate, client_key_exchange and certificate_verify messages. Since this re- negotiation occurs within the encrypted TLS channel, it does not reveal client certificate details. It is possible to perform certificate authentication using an EAP method (for example: EAP-TLS) within the TLS session in EAP-FAST Phase 2 instead of using TLS handshake renegotiation.
アイデンティティ保護が必要であるならTLS認証が最初のサーバ証明の後に再交渉されるのが、明確でTLSクライアント証明書を送るので可能であることに注意してください。 これを達成するために、サーバは、aが、こんにちはと次に、_の終わっているサーバメッセージを送った後、およびEAP-FAST Phase2の前でこんにちは、サーバがTLSを送るかもしれないサーバ_で証明するよう通常要求しないでしょう。_は要求します。 クライアントがこれでクライアント_を送ることによってクライアント認証を実行できる、こんにちは、いいえ_再交渉警戒をそれを示すサーバに欲しい、または送るなら、それは代わりにEAP-FAST Phase2を続行したがっています。 こんにちは、クライアントがクライアント_を送ることによって再交渉を可能にすると仮定すると、次に、サーバはサーバで_こんにちは、証明書を反応させて、_要求メッセージを証明するでしょう。 証明書、クライアントの_の主要な_交換、および証明書_とのクライアント回答はメッセージについて確かめます。 この再交渉が暗号化されたTLSチャンネルの中に起こるので、それはクライアント証明書の詳細を明らかにしません。 証明書認証を実行するのは、TLSセッション中にTLS握手再交渉を使用することの代わりにEAP-FAST Phase2でEAPメソッド(: 例えば、EAP-TLS)を使用することで可能です。
7.4.2. Dictionary Attack Resistance
7.4.2. 辞書攻撃抵抗
EAP-FAST was designed with a focus on protected authentication methods that typically rely on weak credentials, such as password- based secrets. EAP-FAST mitigates dictionary attacks by allowing the establishment of a mutually authenticated encrypted TLS tunnel providing confidentiality and integrity to protect the weak credential based authentication method.
焦点が弱い資格証明書を通常当てにする保護された認証方法にある状態で、EAP-FASTは設計されました、パスワードベースの秘密などのように。 秘密性と保全を提供する互いに認証された暗号化されたTLSトンネルの設立が弱い資格証明ベースの認証方法を保護するのを許容することによって、EAP-FASTは辞書攻撃を緩和します。
7.4.3. Protection against Man-in-the-Middle Attacks
7.4.3. 介入者攻撃に対する保護
Allowing methods to be executed both with and without the protection of a secure tunnel opens up a possibility of a man-in-the-middle attack. To avoid man-in-the-middle attacks it is recommended to always deploy authentication methods with protection of EAP-FAST. EAP-FAST provides protection from man-in-the-middle attacks even if a deployment chooses to execute inner EAP methods both with and without EAP-FAST protection, EAP-FAST prevents this attack in two ways:
保護と安全なトンネルの保護なしで実行されるべきメソッドを許容すると、介入者攻撃の可能性は開きます。 展開が、保護とEAP-FAST保護なしで内側のEAPメソッドを実行するのを選んでも、EAP-FAST. EAP-FASTの保護でいつも認証方法を配布するのがお勧めである介入者攻撃を避けるのは介入者攻撃から保護を提供して、EAP-FASTは2つの方法でこの攻撃を防ぎます:
Cam-Winget, et al. Informational [Page 40] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [40ページ]情報のRFC4851速いEAP2007年5月
1. By using the PAC-Key to mutually authenticate the peer and server
during EAP-FAST Authentication Phase 1 establishment of a secure
tunnel.
1. 安全なトンネルのEAP-FAST Authentication Phaseの間、互いに同輩とサーバを認証するためにPAC主要な1つの設立を使用することによって。
2. By using the keys generated by the inner authentication method
(if the inner methods are key generating) in the crypto-binding
exchange and in the generation of the key material exported by
the EAP method described in Section 5.
2. 内側の認証で生成されたキーを使用することによって、暗号を拘束力がある交換と主要な材料の世代におけるメソッド(内側のメソッドが生成することであるなら主要な)はセクション5で説明されたEAPメソッドでエクスポートしました。
7.4.4. PAC Binding to User Identity
7.4.4. ユーザのアイデンティティに付くPAC
A PAC may be bound to a user identity. A compliant implementation of EAP-FAST MUST validate that an identity obtained in the PAC-Opaque field matches at minimum one of the identities provided in the EAP- FAST Phase 2 authentication method. This validation provides another binding to ensure that the intended peer (based on identity) has successfully completed the EAP-FAST Phase 1 and proved identity in the Phase 2 conversations.
PACはユーザアイデンティティに縛られるかもしれません。 EAP-FAST MUSTの対応する実装はそれを有効にします。PAC不透明な分野マッチでアイデンティティの最小の1つで得られたアイデンティティはEAP- FAST Phase2認証方法に提供されました。 この合法化は、意図している同輩(アイデンティティに基づいている)が首尾よくEAP-FAST Phase1を完成して、Phase2の会話におけるアイデンティティを立証したのを保証するために別の結合を提供します。
7.5. Protecting against Forged Clear Text EAP Packets
7.5. 偽造クリアテキストEAPパケットから守ります。
EAP Success and EAP Failure packets are, in general, sent in clear text and may be forged by an attacker without detection. Forged EAP Failure packets can be used to attempt to convince an EAP peer to disconnect. Forged EAP Success packets may be used to attempt to convince a peer that authentication has succeeded, even though the authenticator has not authenticated itself to the peer.
EAP SuccessとEAP Failureパケットは、一般に、クリアテキストで送られて、検出なしで攻撃者によって鍛造されるかもしれません。 切断するようにEAP同輩を説得するのを試みるのに偽造EAP Failureパケットを使用できます。 偽造EAP Successパケットは認証が成功したと同輩に納得させるのを試みるのに使用されるかもしれません、固有識別文字が同輩にそれ自体を認証していませんが。
By providing message confidentiality and integrity, EAP-FAST provides protection against these attacks. Once the peer and AS initiate the EAP-FAST Authentication Phase 2, compliant EAP-FAST implementations must silently discard all clear text EAP messages, unless both the EAP-FAST peer and server have indicated success or failure using a protected mechanism. Protected mechanisms include TLS alert mechanism and the protected termination mechanism described in Section 3.3.2.
メッセージ秘密性と保全を提供することによって、EAP-FASTはこれらの攻撃に対する保護を提供します。 同輩とASがいったんEAP-FAST Authentication Phase2を開始すると、対応するEAP-FAST実装は静かに警報解除テキストEAPメッセージを捨てなければなりません、EAP-FAST同輩とサーバの両方が保護されたメカニズムを使用することで成否を示していないなら。 保護されたメカニズムはセクション3.3.2で説明されたTLSの警告メカニズムと保護された終了メカニズムを含んでいます。
The success/failure decisions within the EAP-FAST tunnel indicate the final decision of the EAP-FAST authentication conversation. After a success/failure result has been indicated by a protected mechanism, the EAP-FAST peer can process unprotected EAP success and EAP failure messages; however the peer MUST ignore any unprotected EAP success or failure messages where the result does not match the result of the protected mechanism.
EAP-FASTトンネルの中の成功/失敗決定はEAP-FAST認証の会話の最終決定を示します。 成功/失敗結果が保護されたメカニズムによって示された後に、EAP-FAST同輩は保護のないEAP成功とEAP失敗メッセージを処理できます。 しかしながら、同輩は結果が保護されたメカニズムの結果に合っていないどんな保護のないEAP成否メッセージも無視しなければなりません。
To abide by [RFC3748], the server must send a clear text EAP Success or EAP Failure packet to terminate the EAP conversation. However, since EAP Success and EAP Failure packets are not retransmitted, the
[RFC3748]を守るなら、サーバは、EAPの会話を終えるためにEAP SuccessかEAP Failureパケットをクリアテキストに送らなければなりません。 しかしながら、EAP SuccessとEAP Failure以来、パケットは再送されません。
Cam-Winget, et al. Informational [Page 41] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [41ページ]情報のRFC4851速いEAP2007年5月
final packet may be lost. While an EAP-FAST protected EAP Success or EAP Failure packet should not be a final packet in an EAP-FAST conversation, it may occur based on the conditions stated above, so an EAP peer should not rely upon the unprotected EAP success and failure messages.
最終的なパケットは失われるかもしれません。 EAP-FASTがEAP Successを保護したか、EAP FailureパケットがEAP-FASTの会話では最終的なパケットであるべきではありませんが、上に述べられた状態に基づいて起こるかもしれないので、EAP同輩は保護のないEAP成功と失敗メッセージを当てにするべきではありません。
7.6. Server Certificate Validation
7.6. サーバ証明書合法化
As part of the TLS negotiation, the server presents a certificate to the peer. The peer MUST verify the validity of the EAP server certificate, and SHOULD also examine the EAP server name presented in the certificate, in order to determine whether the EAP server can be trusted. Please note that in the case where the EAP authentication is remote, the EAP server will not reside on the same machine as the authenticator, and therefore the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a CA controlling the intended domain and whether the authenticator can be authorized by a server in that domain.
TLS交渉の一部として、サーバは同輩に証明書を提示します。 同輩はEAPサーバ証明書の正当性について確かめなければなりません、そして、また、SHOULDは証明書に提示されたEAPサーバー名を調べます、EAPサーバを信じることができるかどうか決定するために。 EAP認証がリモートである場合では、EAPサーバは固有識別文字と同じマシンの上にないでしょう、そして、したがって、EAPサーバの証明書の名前が意図している目的地のものに合っていることを期待できません。 この場合、より適切なテストは意図しているドメインを制御するカリフォルニアがEAPサーバの証明書に署名するかどうかと、そのドメインでサーバで固有識別文字を認可できるかどうかということであるかもしれません。
7.7. Tunnel PAC Considerations
7.7. トンネルPAC問題
Since the Tunnel PAC is stored by the peer, special care should be given to the overall security of the peer. The Tunnel PAC must be securely stored by the peer to prevent theft or forgery of any of the Tunnel PAC components.
Tunnel PACが同輩によって保存されるので、同輩の総合的なセキュリティに特別な注意を与えるべきです。 同輩は、Tunnel PACの部品のどれかの窃盗か偽造を防ぐためにしっかりとTunnel PACを保存しなければなりません。
In particular, the peer must securely store the PAC-Key and protect it from disclosure or modification. Disclosure of the PAC-Key enables an attacker to establish the EAP-FAST tunnel; however, disclosure of the PAC-Key does not reveal the peer or server identity or compromise any other peer's PAC credentials. Modification of the PAC-Key or PAC-Opaque components of the Tunnel PAC may also lead to denial of service as the tunnel establishment will fail.
同輩は、特に、しっかりとPAC-キーを保存して、公開か変更からそれを保護しなければなりません。 PAC-キーの公開は、攻撃者がEAP-FASTトンネルを確立するのを可能にします。 しかしながら、PAC-キーの公開は、同輩かサーバのアイデンティティを明らかにもしませんし、いかなる他の同輩のPAC資格証明書にも感染もしません。 また、トンネル設立が行き詰まるとき、Tunnel PACのPAC主要であるかPAC不透明な部品の変更はサービスの否定につながるかもしれません。
The PAC-Opaque component is the effective TLS ticket extension used to establish the tunnel using the techniques of [RFC4507]. Thus, the security considerations defined by [RFC4507] also apply to the PAC- Opaque.
PAC不透明なコンポーネントは[RFC4507]のテクニックを使用することでトンネルを証明するのに使用される有効なTLSチケット拡張子です。 したがって、また、[RFC4507]によって定義されたセキュリティ問題はPAC不透明なものに適用されます。
The PAC-Info may contain information about the Tunnel PAC such as the identity of the PAC issuer and the Tunnel PAC lifetime for use in the management of the Tunnel PAC. The PAC-Info should be securely stored by the peer to protect it from disclosure and modification.
PAC-インフォメーションはPAC発行人のアイデンティティなどのTunnel PACとTunnel PAC生涯頃にTunnel PACの管理における使用のために情報を含むかもしれません。 PAC-インフォメーションは、公開と変更からそれを保護するために同輩によってしっかりと保存されるべきです。
Cam-Winget, et al. Informational [Page 42] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [42ページ]情報のRFC4851速いEAP2007年5月
7.8. Security Claims
7.8. セキュリティクレーム
This section provides the needed security claim requirement for EAP [RFC3748].
このセクションはEAP[RFC3748]のための必要なセキュリティクレーム要件を提供します。
Auth. mechanism: Certificate based, shared secret based and
various tunneled authentication mechanisms.
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes, Any method executed within the EAP-FAST
tunnel is integrity protected. The
cleartext EAP headers outside the tunnel are
not integrity protected.
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes
Key strength: See Note 1 below.
Dictionary attack prot.: Yes
Fast reconnect: Yes
Cryptographic binding: Yes
Session independence: Yes
Fragmentation: Yes
Key Hierarchy: Yes
Channel binding: No, but TLVs could be defined for this.
Authメカニズム: ベースの、そして、共有された秘密のベースの、そして、様々なトンネルを堀られた認証機構Ciphersuite交渉を証明してください: はいMutual認証: はいIntegrity保護: はい、EAP-FASTトンネルの中で実行されたAnyメソッドは保護された保全です。 トンネルの外のcleartext EAPヘッダーは保護された保全ではありません。 保護を再演してください: はい秘密性: はいKey派生: はいKeyの強さ: 以下のNote1を見てください。 辞書攻撃prot、: はいFastは再接続します: はいCryptographic結合: はいSession独立: はい断片化: はいの主要な階層構造: はいChannel結合: いいえ、これのためにTLVsを定義できました。
Notes
注意
1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The
National Institute for Standards and Technology (NIST) also
offers advice on appropriate key sizes in [NIST.SP800-57].
[RFC3766] Section 5 advises use of the following required RSA or
DH module and DSA subgroup size in bits, for a given level of
attack resistance in bits. Based on the table below, a 2048-bit
RSA key is required to provide 128-bit equivalent key strength:
1. BCP86[RFC3766]は適切な主要なサイズでアドバイスします。 また、StandardsとTechnology(NIST)のためのNational Instituteは[NIST.SP800-57]の適切な主要なサイズでアドバイスします。 [RFC3766]セクション5はビットの以下の必要なRSAかDHモジュールとDSAサブグループサイズを使用に知らせます、ビットにおける、与えられたレベルの攻撃抵抗のために。 以下のテーブルに基づいて、2048年のビットのRSAキーが128ビットの同等な主要な強さを提供するのに必要です:
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 129
80 1228 148
90 1553 167
100 1926 186
150 4575 284
200 8719 383
250 14596 482
攻撃Resistance RSAかDH Modulus DSAサブグループ(ビット)サイズ(ビット)サイズ(ビット)----------------- ----------------- ------------ 70 947 129 80 1228 148 90 1553 167 100 1926 186 150 4575 284 200 8719 383 250 14596 482
Cam-Winget, et al. Informational [Page 43] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [43ページ]情報のRFC4851速いEAP2007年5月
8. Acknowledgements
8. 承認
The EAP-FAST design and protocol specification is based on the ideas and hard efforts of Pad Jakkahalli, Mark Krischer, Doug Smith, and Glen Zorn of Cisco Systems, Inc.
EAP-FASTデザインとプロトコル仕様はシスコシステムズInc.のPad Jakkahalliの考えと困難な取り組み、マークKrischer、ダグ・スミス、およびGlenゾルンに基づいています。
The TLV processing was inspired from work on the Protected Extensible Authentication Protocol version 2 (PEAPv2) with Ashwin Palekar, Dan Smith, and Simon Josefsson. Helpful review comments were provided by Russ Housley, Jari Arkko, Bernard Aboba, Ilan Frenkel, and Jeremy Steiglitz.
TLV処理はAshwin Palekar、ダン・スミス、およびサイモンJosefssonと共にProtected拡張認証プロトコルバージョン2(PEAPv2)に対する仕事から奮い立たせられました。 役立っているレビューコメントはバーナードAboba、宜蘭のラスHousley、ヤリArkko、フレンケリ、およびジェレミーSteiglitzによって提供されました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[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について議定書の中で述べます」。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002.
[RFC3268]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson,
J., and H. Levkowetz, "Extensible Authentication
Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[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について議定書の中で述べます」。
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H.
Tschofenig, "Transport Layer Security (TLS)
Session Resumption without Server-Side State",
RFC 4507, May 2006.
[RFC4507]Salowey(J.、周、H.、Eronen、P.、およびH.Tschofenig)は「サーバサイド州なしで層のセキュリティ(TLS)セッション再開を輸送します」、RFC4507、2006年5月。
Cam-Winget, et al. Informational [Page 44] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [44ページ]情報のRFC4851速いEAP2007年5月
9.2. Informative References
9.2. 有益な参照
[EAP-PROV] Cam-Winget, N., "Dynamic Provisioning using EAP-
FAST", Work in Progress, January 2007.
[EAP-PROV]カム-Winget、N.、「速くEAPを使用するダイナミックな食糧を供給すること」は進歩、2007年1月に働いています。
[IEEE.802-1X.2004] "Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X,
December 2004.
[IEEE.802-1×.2004]、「地方とメトロポリタンエリアネットワーク:」 「ポートベースのネットワークアクセス管理」、IEEEの標準の802.1X、2004年12月。
[NIST.SP800-57] National Institute of Standards and Technology,
"Recommendation for Key Management", Special
Publication 800-57, May 2006.
[NIST.SP800-57]米国商務省標準技術局(「Key Managementのための推薦」、特別な公表800-57)は2006がそうするかもしれません。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS
Authentication Protocol", RFC 2716, October 1999.
[RFC2716] AbobaとB.とD.サイモン、「ppp EAP TLS認証プロトコル」、RFC2716、1999年10月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)",
RFC 3579, September 2003.
[RFC3579]Aboba、B.とP.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
[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月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP)
Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、ヒラー、T.、およびG.ゾルン、「直径拡張認証プロトコル(EAP)アプリケーション」、RFC4072、2005年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[RFC4086]イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
"The Network Access Identifier", RFC 4282,
December 2005.
2005年12月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[RFC4630] Housley, R. and S. Santesson, "Update to
DirectoryString Processing in the Internet X.509
Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile",
RFC 4630, August 2006.
[RFC4630]Housley(R.とS.Santesson)は「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィールで処理をDirectoryStringにアップデートします」、RFC4630、2006年8月。
Cam-Winget, et al. Informational [Page 45] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [45ページ]情報のRFC4851速いEAP2007年5月
Appendix A. Examples
付録A.の例
In the following examples the version field in EAP Fast is always assumed to be 1. The S, M, and L bits are assumed to be 0 unless otherwise specified.
以下の例では、EAP Fastのバージョン分野は1であるといつも思われます。 別の方法で指定されない場合、S、M、およびLビットは0であると思われます。
A.1. Successful Authentication
A.1。 うまくいっている認証
The following exchanges show a successful EAP-FAST authentication with optional PAC refreshment; the conversation will appear as follows:
以下の交換は任意のPAC軽い飲食物によるうまくいっているEAP-FAST認証を示しています。 会話は以下の通りに見えるでしょう:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
同輩固有識別文字を認証します。------------------- ------------- <。 EAP-要求/アイデンティティEAP-応答/アイデンティティ(MyID1)->。
<- EAP-Request/EAP-FAST
(S=1, A-ID)
速い<EAP-要求/EAP(S=1、A-ID)
EAP-Response/EAP-FAST
(TLS client_hello with
PAC-Opaque in SessionTicket extension)->
EAP-応答/EAP-FAST、(_拡大) こんにちは、PAC-不透明なものがSessionTicketにある状態でTLSクライアント->。
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
速い<EAP-要求/EAP(TLSサーバ_、こんにちは、TLS変化_暗号_仕様、終わっているTLS)
EAP-Response/EAP-FAST
(TLS change_cipher_spec,
TLS finished) ->
EAP-応答/EAP-FAST(TLSは_暗号_仕様を変えて、TLSは終わった)->。
TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
チャンネルが設立したTLS(TLSチャンネルの中に送られたその後のメッセージEAP-FASTの中で要約されて、
<- EAP Payload TLV
(EAP-Request/EAP-GTC(Challenge))
<EAP有効搭載量TLV(EAP-要求/EAP-GTC(挑戦))
EAP Payload TLV (EAP-Response/
EAP-GTC(Response with both
user name and password)) ->
EAP有効搭載量TLV(EAP-応答/EAP-GTC(ユーザ名とパスワードの両方がある応答))->。
optional additional exchanges (new pin mode,
password change etc.) ...
任意の追加交換(新しいパスワードピン変化モードなど) ...
Cam-Winget, et al. Informational [Page 46] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [46ページ]情報のRFC4851速いEAP2007年5月
<- Intermediate-Result TLV (Success)
Crypto-Binding TLV (Request)
<中間結果TLV(成功)の暗号を拘束力があるTLV(要求)
Intermediate-Result TLV (Success)
Crypto-Binding TLV(Response) ->
中間結果TLV(成功)暗号を拘束力があるTLV(応答)->。
<- Result TLV (Success)
[Optional PAC TLV]
<結果TLV(成功)[任意のPAC TLV]
Result TLV (Success)
[PAC TLV Acknowledgment] ->
結果TLV(成功)[PAC TLV承認]->。
TLS channel torn down
(messages sent in clear text)
取りこわされたTLSチャンネル(クリアテキストで送られたメッセージ)
<- EAP-Success
<EAP-成功
A.2. Failed Authentication
A.2。 失敗した認証
The following exchanges show a failed EAP-FAST authentication due to wrong user credentials; the conversation will appear as follows:
以下の交換は間違ったユーザ信任状による失敗したEAP-FAST認証を示しています。 会話は以下の通りに見えるでしょう:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
同輩固有識別文字を認証します。------------------- ------------- <。 EAP-要求/アイデンティティ
EAP-Response/
Identity (MyID1) ->
EAP-応答/アイデンティティ(MyID1)->。
<- EAP-Request/EAP-FAST
(S=1, A-ID)
速い<EAP-要求/EAP(S=1、A-ID)
EAP-Response/EAP-FAST
(TLS client_hello with
PAC-Opaque in SessionTicket extension)->
EAP-応答/EAP-FAST、(_拡大) こんにちは、PAC-不透明なものがSessionTicketにある状態でTLSクライアント->。
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
速い<EAP-要求/EAP(TLSサーバ_、こんにちは、TLS変化_暗号_仕様、終わっているTLS)
EAP-Response/EAP-FAST
(TLS change_cipher_spec,
TLS finished) ->
EAP-応答/EAP-FAST(TLSは_暗号_仕様を変えて、TLSは終わった)->。
Cam-Winget, et al. Informational [Page 47] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [47ページ]情報のRFC4851速いEAP2007年5月
TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
チャンネルが設立したTLS(TLSチャンネルの中に送られたその後のメッセージEAP-FASTの中で要約されて、
<- EAP Payload TLV (EAP-Request/
EAP-GTC (Challenge))
<EAP有効搭載量TLV(EAP-要求/EAP-GTC(挑戦))
EAP Payload TLV (EAP-Response/
EAP-GTC (Response with both
user name and password)) ->
EAP有効搭載量TLV(EAP-応答/EAP-GTC(ユーザ名とパスワードの両方がある応答))->。
<- EAP Payload TLV (EAP-Request/
EAP-GTC (error message))
<EAP有効搭載量TLV(EAP-要求/EAP-GTC(エラーメッセージ))
EAP Payload TLV (EAP-Response/
EAP-GTC (empty data packet to
acknowledge unrecoverable error)) ->
EAP有効搭載量TLV(EAP-応答/EAP-GTC(回復不能エラーを承認する空のデータ・パケット))->。
<- Result TLV (Failure)
<結果TLV(失敗)
Result TLV (Failure) ->
結果TLV(失敗)->。
TLS channel torn down
(messages sent in clear text)
取りこわされたTLSチャンネル(クリアテキストで送られたメッセージ)
<- EAP-Failure
<のEAP-故障
A.3. Full TLS Handshake using Certificate-based Ciphersuite
A.3。 証明書ベースのCiphersuiteを使用する完全なTLS握手
In the case where an abbreviated TLS handshake is tried and failed, and a fallback to certificate-based full TLS handshake occurs within EAP-FAST Phase 1, the conversation will appear as follows:
簡略化されたTLS握手が試みられて、失敗されて、証明書ベースの完全なTLS握手への後退がEAP-FAST Phase1の中に起こる場合では、会話は以下の通りに見えるでしょう:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
同輩固有識別文字を認証します。------------------- ------------- <。 EAP-要求/アイデンティティEAP-応答/アイデンティティ(MyID1)->。
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
//アイデンティティは明確を送りました。 完全なユーザアイデンティティの代わりにEAPサーバに認証要求を発送するのを助けるためにはヒントであるかもしれません。
<- EAP-Request/EAP-FAST
(S=1, A-ID)
速い<EAP-要求/EAP(S=1、A-ID)
Cam-Winget, et al. Informational [Page 48] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [48ページ]情報のRFC4851速いEAP2007年5月
EAP-Response/EAP-FAST
(TLS client_hello
with PAC-Opaque extension)->
EAP-応答/EAP-FAST、(TLSクライアント_、PAC不透明な拡大) ->でこんにちは。
// Peer sends PAC-Opaque of Tunnel PAC along with a list of
ciphersuites supported. If the server rejects the PAC-
Opaque, it falls through to the full TLS handshake
//同輩は支持されたciphersuitesのリストに伴うTunnel PACのPAC-不透明なものを送ります。 サーバがPAC不透明なものを拒絶するなら、それは完全なTLS握手に通り抜けて落ちます。
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
<EAP-要求/EAP-FAST、(TLSサーバ_、こんにちは、_行われた_) こんにちは、TLS証明書、[TLSのサーバの_の主要な_交換][TLSは_要求を証明します]TLSサーバEAP-応答/EAP-FAST([TLS証明書]TLSのクライアントの_の主要な_交換、[証明書_が確かめるTLS]TLS変化_暗号_仕様、TLSは終わった)-><EAP-要求/EAP-FAST(TLS変化_暗号_仕様、終わっているTLS、EAP有効搭載量TLV(EAP-要求/アイデンティティ))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
チャンネルが設立した//TLS(TLSチャンネルの中に送られたその後のメッセージEAP-FASTの中で要約されて、
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
//最初のEAP有効搭載量TLVはApplication DataとしてTLS Finishedに背負われて、TLSトンネルによって保護されます。
EAP-Payload-TLV
(EAP-Response/Identity (MyID2))->
EAP有効搭載量TLV(EAP-応答/アイデンティティ(MyID2))->。
// identity protected by TLS.
//アイデンティティはTLSによって保護されました。
<- EAP-Payload-TLV
(EAP-Request/Method X)
<EAP有効搭載量TLV(EAP-要求/方法X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
EAP有効搭載量TLV(EAP-応答/方法X)->。
Cam-Winget, et al. Informational [Page 49] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [49ページ]情報のRFC4851速いEAP2007年5月
// Method X exchanges followed by Protected Termination
Protected Terminationによって続かれた//方法X交換
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
<の暗号を拘束力があるTLV(CompoundMAC、バージョンは1、速いEAPバージョン=1、一回だけと等しい)、結果TLV(成功)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
暗号を拘束力があるTLV(CompoundMAC、バージョンは1、速いEAPバージョン=1、一回だけと等しい)、結果-TLV(成功)->。
// TLS channel torn down
(messages sent in clear text)
取りこわされた//TLSチャンネル(クリアテキストで送られたメッセージ)
<- EAP-Success
<EAP-成功
A.4. Client Authentication during Phase 1 with Identity Privacy
A.4。 アイデンティティプライバシーとの段階1の間のクライアント認証
In the case where a certificate-based TLS handshake occurs within EAP-FAST Phase 1, and client certificate authentication and identity privacy is desired, the conversation will appear as follows:
証明書ベースのTLS握手がEAP-FAST Phase1の中に起こって、クライアント証明書認証とアイデンティティプライバシーが望まれている場合では、会話は以下の通りに見えるでしょう:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
同輩固有識別文字を認証します。------------------- ------------- <。 EAP-要求/アイデンティティEAP-応答/アイデンティティ(MyID1)->。
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
//アイデンティティは明確を送りました。 完全なユーザアイデンティティの代わりにEAPサーバに認証要求を発送するのを助けるためにはヒントであるかもしれません。
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
(TLS client_key_exchange,
TLS change_cipher_spec,
TLS finished) ->
<EAP-要求/EAP-FAST(S=1、A-ID)EAP-応答/EAP-FAST、(TLSクライアント_、こんにちは、)、-><EAP-要求/EAP-FAST、(TLSサーバ_、こんにちは、_行われた_) こんにちは、TLS証明書、[TLSのサーバの_の主要な_交換][TLSは_要求を証明します]TLSサーバEAP-応答/EAP-FAST(TLSのクライアントの_の主要な_交換、TLS変化_暗号_仕様、TLSは終わった)->。
Cam-Winget, et al. Informational [Page 50] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [50ページ]情報のRFC4851速いEAP2007年5月
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,TLS Hello-Request)
速い<EAP-要求/EAP(TLS変化_暗号_仕様、終わっているTLS、TLS Hello-要求)
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
チャンネルが設立した//TLS(TLSチャンネルの中に送られたその後のメッセージEAP-FASTの中で要約されて、
// TLS Hello-Request is piggybacked to the TLS Finished as
Handshake Data and protected by the TLS tunnel
TLS Hello//要求は、Handshake DataとしてTLS Finishedに背負われて、TLSトンネルによって保護されます。
// Subsequent messages are protected by the TLS Tunnel
//その後のメッセージはTLS Tunnelによって保護されます。
EAP-Response/EAP-FAST
(TLS client_hello) ->
EAP-応答/EAP-FAST、(TLSクライアント_、こんにちは、)、->。
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<EAP-要求/EAP-FAST、(TLSサーバ_、こんにちは、_行われた_) こんにちは、TLS証明書、[TLSのサーバの_の主要な_交換][TLSは_要求を証明します]TLSサーバEAP-応答/EAP-FAST([TLS証明書]TLSのクライアントの_の主要な_交換、[証明書_が確かめるTLS]TLS変化_暗号_仕様、TLSは終わった)->。
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
Result TLV (Success))
速い<EAP-要求/EAP(TLS変化_暗号_仕様、終わっているTLS、Result TLV(成功))
EAP-Response/EAP-FAST
(Result-TLV (Success)) ->
速いEAP-応答/EAP(結果-TLV(成功))->。
//TLS channel torn down
(messages sent in clear text)
取りこわされた//TLSチャンネル(クリアテキストで送られたメッセージ)
<- EAP-Success
<EAP-成功
Cam-Winget, et al. Informational [Page 51] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [51ページ]情報のRFC4851速いEAP2007年5月
A.5. Fragmentation and Reassembly
A.5。 断片化とReassembly
In the case where EAP-FAST fragmentation is required, the conversation will appear as follows:
EAP-FAST断片化が必要である場合では、会話は以下の通りに見えるでしょう:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
同輩固有識別文字を認証します。------------------- ------------- <。 速いアイデンティティEAP-応答/アイデンティティ(MyID)->EAP-要求/<EAP-要求/EAP(S=1、A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(L=1,M=1, TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,])
EAP-応答/EAP-FAST、(TLSクライアント_、こんにちは、)、-><EAP-要求/EAP-FAST(L=1、Mが1と等しく、TLSサーバが_である、こんにちは、TLS証明書、[TLSのサーバの_の主要な_交換] [TLSは_要求を証明します)
EAP-Response/EAP-FAST ->
速いEAP-応答/EAP->。
<- EAP-Request/EAP-FAST
(M=1,
[TLS certificate_request(con't),])
EAP-Response/EAP-FAST ->
<- EAP-Request/EAP-FAST
([TLS certificate_request(con't),]
TLS server_hello_done)
EAP-Response/EAP-FAST,
(L=1,M=1,[TLS certificate,])->
<は/EAP-FASTをEAP要求します。(Mが1と等しい、[TLS証明書_要求、(まやかし、)、)、EAP-FAST->EAP-応答/<EAP-要求/EAP-FAST、[TLS証明書_要求、(まやかし、)、]、_行われた_) こんにちは、TLSサーバEAP-応答/EAP-FAST、(L=1、M=1[TLS証明書])->。
<- EAP-Request/EAP-FAST
EAP-Response/EAP-FAST
([TLS certificate(con't),]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished))->
<- EAP-Request/EAP-FAST
( TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
EAP-FAST EAP<EAP-要求/応答/EAP-FAST、[TLSが証明する、(まやかし、)、]、終わっているTLS) TLSのクライアントの_の主要な_交換、[証明書_が確かめるTLS]TLS変化_暗号_仕様、-><EAP-要求/EAP-FAST(TLS変化_暗号_仕様、終わっているTLS、EAP有効搭載量TLV(EAP-要求/アイデンティティ))
Cam-Winget, et al. Informational [Page 52] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [52ページ]情報のRFC4851速いEAP2007年5月
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
チャンネルが設立した//TLS(TLSチャンネルの中に送られたその後のメッセージEAP-FASTの中で要約されて、
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
//最初のEAP有効搭載量TLVはApplication DataとしてTLS Finishedに背負われて、TLSトンネルによって保護されます。
EAP-Payload-TLV
(EAP-Response/Identity (MyID2))->
EAP有効搭載量TLV(EAP-応答/アイデンティティ(MyID2))->。
// identity protected by TLS.
//アイデンティティはTLSによって保護されました。
<- EAP-Payload-TLV
(EAP-Request/Method X)
<EAP有効搭載量TLV(EAP-要求/方法X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
EAP有効搭載量TLV(EAP-応答/方法X)->。
// Method X exchanges followed by Protected Termination
Protected Terminationによって続かれた//方法X交換
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
<の暗号を拘束力があるTLV(CompoundMAC、バージョンは1、速いEAPバージョン=1、一回だけと等しい)、結果TLV(成功)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
暗号を拘束力があるTLV(CompoundMAC、バージョンは1、速いEAPバージョン=1、一回だけと等しい)、結果-TLV(成功)->。
// TLS channel torn down
(messages sent in clear text)
取りこわされた//TLSチャンネル(クリアテキストで送られたメッセージ)
<- EAP-Success
<EAP-成功
A.6. Sequence of EAP Methods
A.6。 EAP方法の系列
Where EAP-FAST is negotiated, with a sequence of EAP method X followed by method Y, the conversation will occur as follows:
EAP-FASTが方法Yがあとに続いているEAP方法Xの順序と交渉されるところでは、会話は以下の通り起こるでしょう:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
同輩固有識別文字を認証します。------------------- ------------- <。 速いアイデンティティEAP-応答/アイデンティティ(MyID1)->EAP-要求/<EAP-要求/EAP(S=1、A-ID)
Cam-Winget, et al. Informational [Page 53] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [53ページ]情報のRFC4851速いEAP2007年5月
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV(
EAP-Request/Identity))
EAP-応答/EAP-FAST、(TLSクライアント_、こんにちは、)、-><EAP-要求/EAP-FAST、(TLSサーバ_、こんにちは、_行われた_) こんにちは、TLS証明書、[TLSのサーバの_の主要な_交換][TLSは_要求を証明します]TLSサーバEAP-応答/EAP-FAST([TLS証明書]TLSのクライアントの_の主要な_交換、[証明書_が確かめるTLS]TLS変化_暗号_仕様、TLSは終わった)-><EAP-要求/EAP-FAST(TLS変化_暗号_仕様、終わっているTLS、EAP有効搭載量TLV(EAP-要求/アイデンティティ))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
チャンネルが設立した//TLS(TLSチャンネルの中に送られたその後のメッセージEAP-FASTの中で要約されて、
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
//最初のEAP有効搭載量TLVはApplication DataとしてTLS Finishedに背負われて、TLSトンネルによって保護されます。
EAP-Payload-TLV
(EAP-Response/Identity) ->
EAP有効搭載量TLV(EAP-応答/アイデンティティ)->。
<- EAP-Payload-TLV
(EAP-Request/Method X)
<EAP有効搭載量TLV(EAP-要求/方法X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
EAP有効搭載量TLV(EAP-応答/方法X)->。
// Optional additional X Method exchanges...
//任意の追加X Method交換…
<- EAP-Payload-TLV
(EAP-Request/Method X)
<EAP有効搭載量TLV(EAP-要求/方法X)
EAP-Payload-TLV
(EAP-Response/EAP-Type X)->
EAP有効搭載量TLV(EAP EAP-応答/タイプしているX)->。
Cam-Winget, et al. Informational [Page 54] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [54ページ]情報のRFC4851速いEAP2007年5月
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
EAP Payload TLV (EAP-Request/Method Y)
<中間結果TLV(成功)、暗号を拘束力があるTLV(CompoundMAC、1つの速いEAPバージョン=バージョンが1、一回だけと等しい)、EAP有効搭載量TLV(EAP-要求/方法Y)
// Next EAP conversation started after successful completion
of previous method X. The Intermediate-Result and Crypto-
Binding TLVs are sent in this packet to minimize round-
trips. In this example, identity request is not sent
before negotiating EAP-Type=Y.
//次のEAPの会話は前の方法X.の無事終了の後にIntermediate-結果を始めました、そして、ぐるりと旅行を最小にするためにこのパケットでCryptoの拘束力があるTLVsを送ります。 この例では、EAP-タイプ=Yを交渉する前に、アイデンティティ要求は送られません。
// Compound MAC calculated using Keys generated from
EAP methods X and the TLS tunnel.
キーズを使用することで計算された//合成MACはEAPから方法XとTLSトンネルを発生させました。
Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
EAP-Payload-TLV (EAP-Response/Method Y) ->
中間結果TLV(成功)、暗号を拘束力があるTLV(CompoundMAC、バージョンは1、速いEAPバージョン=1、一回だけと等しい)、EAP有効搭載量TLV(EAP-応答/方法Y)->。
// Optional additional Y Method exchanges...
//任意の追加Y Method交換…
<- EAP Payload TLV
(EAP-Request/Method Y)
<EAP有効搭載量TLV(EAP-要求/方法Y)
EAP Payload TLV
(EAP-Response/Method Y) ->
EAP有効搭載量TLV(EAP-応答/方法Y)->。
<- Intermediate-Result-TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
<の中間的結果TLV(成功)、暗号を拘束力があるTLV(CompoundMAC、1つの速いEAPバージョン=バージョンが1、一回だけと等しい)、結果TLV(成功)
Intermediate-Result-TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
中間的結果TLV(成功)、暗号を拘束力があるTLV(CompoundMAC、バージョンは1、速いEAPバージョン=1、一回だけと等しい)、結果-TLV(成功)->。
// Compound MAC calculated using Keys generated from EAP
methods X and Y and the TLS tunnel. Compound Keys
generated using Keys generated from EAP methods X and Y;
and the TLS tunnel.
キーズを使用することで計算された//合成MACはEAPから方法XとYとTLSトンネルを発生させました。 EAP方法XとYから発生するキーズを使用することで発生するキーズを合成してください。 そして、TLSはトンネルを堀ります。
Cam-Winget, et al. Informational [Page 55] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [55ページ]情報のRFC4851速いEAP2007年5月
// TLS channel torn down (messages sent in clear text)
取りこわされた//TLSチャンネル(クリアテキストで送られたメッセージ)
<- EAP-Success
<EAP-成功
A.7. Failed Crypto-Binding
A.7。 失敗した暗号結合
The following exchanges show a failed crypto-binding validation. The conversation will appear as follows:
以下の交換は失敗した暗号を拘束力がある合法化を示しています。 会話は以下の通りに見えるでしょう:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/EAP-FAST
(TLS Server Key Exchange,
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange,
TLS change_cipher_spec,
TLS finished)->
同輩固有識別文字を認証します。------------------- ------------- <。 アイデンティティEAP-応答/アイデンティティ(MyID1)->EAP-要求/<EAP-要求/EAP-FAST(S=1、A-ID)EAP-応答/EAP-FAST、(_PAC不透明な拡大) -><なしでこんにちは、TLSクライアントEAP-要求/EAP-FAST(TLS Server Key Exchange、TLS Server Hello Done)EAP-応答/EAP-FAST(TLS Client Key Exchange、TLS変化_暗号_仕様、TLSは終わった)->。
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished)
EAP-Payload-TLV(
EAP-Request/Identity))
<EAP-要求/EAP-FAST(TLSは_暗号_仕様を変えて、TLSは終わった)EAP有効搭載量TLV(EAP-要求/アイデンティティ)
// TLS channel established
(messages sent within the TLS channel)
チャンネルが設立した//TLS(TLSチャンネルの中に送られたメッセージ)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
//最初のEAP有効搭載量TLVはApplication DataとしてTLS Finishedに背負われて、TLSトンネルによって保護されます。
EAP-Payload TLV (EAP-Response/Identity) ->
EAP-有効搭載量TLV(EAP-応答/アイデンティティ)->。
<- EAP Payload TLV (EAP-Request/
EAP-MSCHAPV2 (Challenge))
<EAP有効搭載量TLV(EAP-要求/EAP-MSCHAPV2(挑戦))
EAP Payload TLV (EAP-Response/ EAP-MSCHAPV2 (Response)) ->
EAP有効搭載量TLV(EAP-応答/EAP-MSCHAPV2(応答))->。
Cam-Winget, et al. Informational [Page 56] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [56ページ]情報のRFC4851速いEAP2007年5月
<- EAP Payload TLV (EAP-Request/
EAP-MSCHAPV2 (Success Request))
<EAP有効搭載量TLV(EAP-要求/EAP-MSCHAPV2(成功要求))
EAP Payload TLV (EAP-Response/ EAP-MSCHAPV2 (Success Response)) ->
EAP有効搭載量TLV(EAP-応答/EAP-MSCHAPV2(成功応答))->。
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
<の暗号を拘束力があるTLV(CompoundMAC、バージョンは1、速いEAPバージョン=1、一回だけと等しい)、結果TLV(成功)
Result TLV (Failure),
Error TLV (Error Code = 2001) ->
結果TLV(失敗)、誤りTLV(エラーコード=2001)->。
// TLS channel torn down
(messages sent in clear text)
取りこわされた//TLSチャンネル(クリアテキストで送られたメッセージ)
<- EAP-Failure
<のEAP-故障
A.8. Sequence of EAP Method with Vendor-Specific TLV Exchange
A.8。 業者特有のTLV交換に伴うEAP方法の系列
Where EAP-FAST is negotiated, with a sequence of EAP method followed by Vendor-Specific TLV exchange, the conversation will occur as follows:
EAP-FASTがVendor特有のTLV交換があとに続いているEAP方法の順序と交渉されるところでは、会話は以下の通り起こるでしょう:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
同輩固有識別文字を認証します。------------------- ------------- <。 速いアイデンティティEAP-応答/アイデンティティ(MyID1)->EAP-要求/<EAP-要求/EAP(S=1、A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-応答/EAP-FAST、(TLSクライアント_、こんにちは、)、-><EAP-要求/EAP-FAST(TLSサーバ_、こんにちは、TLS証明書、[TLSのサーバの_の主要な_交換][TLSは_要求を証明します]TLSサーバ_、こんにちは、行われた_)
Cam-Winget, et al. Informational [Page 57] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [57ページ]情報のRFC4851速いEAP2007年5月
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
EAP-応答/EAP-FAST[TLS証明書]のTLSのクライアントの_の主要な_交換、[証明書_が確かめるTLS]TLS変化_暗号_仕様、終わっているTLS) -><EAP-要求/EAP-FAST(TLS変化_暗号_仕様、終わっているTLS、EAP有効搭載量TLV(EAP-要求/アイデンティティ))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
チャンネルが設立した//TLS(TLSチャンネルの中に送られたその後のメッセージEAP-FASTの中で要約されて、
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
//最初のEAP有効搭載量TLVはApplication DataとしてTLS Finishedに背負われて、TLSトンネルによって保護されます。
EAP-Payload-TLV
(EAP-Response/Identity) ->
EAP有効搭載量TLV(EAP-応答/アイデンティティ)->。
<- EAP-Payload-TLV
(EAP-Request/Method X)
<EAP有効搭載量TLV(EAP-要求/方法X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
EAP有効搭載量TLV(EAP-応答/方法X)->。
<- EAP-Payload-TLV
(EAP-Request/Method X)
<EAP有効搭載量TLV(EAP-要求/方法X)
EAP-Payload-TLV
(EAP-Response/Method X)->
EAP有効搭載量TLV(EAP-応答/方法X)->。
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
Vendor-Specific TLV
<中間結果TLV(成功)、暗号を拘束力があるTLV(CompoundMAC、1つの速いEAPバージョン=バージョンが1、一回だけと等しい)、業者特有のTLV
// Vendor Specific TLV exchange started after successful
completion of previous method X. The Intermediate-Result
and Crypto-Binding TLVs are sent with Vendor Specific TLV
in this packet to minimize round-trips.
//業者Specific TLV交換は前の方法X.の無事終了の後にIntermediate-結果を始めました、そして、周遊旅行を最小にするためにVendor Specific TLVと共にこのパケットでCryptoを拘束力があるTLVsを送ります。
// Compound MAC calculated using Keys generated from
EAP methods X and the TLS tunnel.
キーズを使用することで計算された//合成MACはEAPから方法XとTLSトンネルを発生させました。
Cam-Winget, et al. Informational [Page 58] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [58ページ]情報のRFC4851速いEAP2007年5月
Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Vendor-Specific TLV ->
中間結果TLV(成功)、暗号を拘束力があるTLV(CompoundMAC、バージョンは1、速いEAPバージョン=1、一回だけと等しい)、業者特有のTLV->。
// Optional additional Vendor-Specific TLV exchanges...
//任意の追加Vendor特有のTLV交換…
<- Vendor-Specific TLV
<の業者特有のTLV
Vendor Specific TLV ->
<- Result TLV (Success)
業者の特定のTLV-><結果TLV(成功)
Result-TLV (Success) ->
結果-TLV(成功)->。
// TLS channel torn down (messages sent in clear text)
取りこわされた//TLSチャンネル(クリアテキストで送られたメッセージ)
<- EAP-Success
<EAP-成功
Cam-Winget, et al. Informational [Page 59] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [59ページ]情報のRFC4851速いEAP2007年5月
Appendix B. Test Vectors
付録B.テストベクトル
B.1. Key Derivation
B.1。 主要な派生
PAC KEY:
PACキー:
0B 97 39 0F 37 51 78 09 81 1E FD 9C 6E 65 94 2B
63 2C E9 53 89 38 08 BA 36 0B 03 7C D1 85 E4 14
0B97 39 0F37 51 78 09 81 1EのFD9C6E65 94 2B63 2C E9 53 89 38 08Ba36 0B03 7C D1 85ユーロの4 14
Server_hello Random
サーバ_、こんにちは、無作為
3F FB 11 C4 6C BF A5 7A 54 40 DA E8 22 D3 11 D3
F7 6D E4 1D D9 33 E5 93 70 97 EB A9 B3 66 F4 2A
3F FB11C4 6C BF A5 7A54 40DA E8 22D3 11D3 F7 6D E4 1D D9 33E5 93 70 97EB A9 B3 66F4 2A
Client_hello Random
クライアント_、こんにちは、無作為
00 00 00 02 6A 66 43 2A 8D 14 43 2C EC 58 2D 2F
C7 9C 33 64 BA 04 AD 3A 52 54 D6 A5 79 AD 1E 00
1 00 00 00 02 6A66 43 2A 8D14 43 2のC EC58の2D2F C7 9C33 64Ba04AD3A52 54D6 A5 79AD E00
Master_secret = T-PRF(PAC-Key,
"PAC to master secret label hash",
server_random + Client_random,
48)
マスター_秘密=T-PRF(PAC主要で、「秘密を習得するPACは細切れ肉料理をラベルしてい」て、_無作為の+クライアントサーバ_無作為の48)
4A 1A 51 2C 01 60 BC 02 3C CF BC 83 3F 03 BC 64
88 C1 31 2F 0B A9 A2 77 16 A8 D8 E8 BD C9 D2 29
38 4B 7A 85 BE 16 4D 27 33 D5 24 79 87 B1 C5 A2
4A 1A51 2C01 60紀元前02年の3C Cf紀元前83年の3F03紀元前64 88年のC1 31 2F0B A9 A2 77 16A8 D8 8EのBD C9 D2 29 38 4B 7A85、16 4D27 33D5 24 79 87B1 C5 A2になってください。
Key_block = PRF(Master_secret,
"key expansion",
server_random + Client_random)
主要な_ブロック=PRF(無作為の状態で秘密の_「キー拡大」、サーバ_無作為の+クライアント_を習得します)
59 59 BE 8E 41 3A 77 74 8B B2 E5 D3 60 AC 4D 35
DF FB C8 1E 9C 24 9C 8B 0E C3 1D 72 C8 84 9D 57
48 51 2E 45 97 6C 88 70 BE 5F 01 D3 64 E7 4C BB
11 24 E3 49 E2 3B CD EF 7A B3 05 39 5D 64 8A 44
11 B6 69 88 34 2E 8E 29 D6 4B 7D 72 17 59 28 05
AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84
64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71
59 59、8 41Eの3A77 74 8B B2 5EのD3 60交流4D35DF FB C8 1E9C24 9C8B0E C3 1D72C8 84 9D57 48 51 2E45 97が6C88 70であったなら5F01D3 64になってください、E、7 4Cの掲示板11 24 3 49 2 3B CD EF 7A B3 05 39 5D64 8A44 11B6 69 88 34 2Eの8Eの29EのD6 4B 7D72 17 59 28 05AF F9 B7ff66 6D A1 96 8EのF0B5E06 46 7A44 84 64C1 C8 0C96 44 09 98ff92、A8 B4 C6 42 28 71
Session Key Seed
セッションの主要な種子
D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96
8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98
FF 92 A8 B4 C6 42 28 71
D6 4B 7D72 17 59 28 05AF F9 B7ff66 6D A1 96 8F0B5E06 46 7A44 84 64C1 C8 0C96 44 09 98ff92A8 B4 C6 42 28 71
Cam-Winget, et al. Informational [Page 60] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [60ページ]情報のRFC4851速いEAP2007年5月
IMCK = T-PRF(SKS,
"Inner Methods Compound Keys",
ISK,
60)
IMCKはT-PRFと等しいです。(SKS、「内側の方法はキーを合成する」ISK、60)
Note: ISK is 32 octets 0's.
以下に注意してください。 ISKは32の八重奏0です。
16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80
4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1
18 40 7B 56 BE EA A7 C5 76 5D 8F 0B C5 07 C6 B9
04 D0 69 56 72 8B 6B B8 15 EC 57 7B
8 16 15 3C3F21 55EF D9 7F34AE C8 1A4E66 80 4C C3 76F2 8A A9 6F96C2 54 5F Cの1AB65 02E18 40 7B56、EA A7 C5 76 5D8F0B C5 07C6 B9 04D0 69 56 72 8B 6B B8 15EC57 7Bになってください。
[SIMCK 1]
16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80
4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1
18 40 7B 56 BE EA A7 C5
8[SIMCK1]16 15 3C3F21 55EF D9 7F34AE C8 1A4E66 80 4C C3 76F2 8A A9 6F96C2 54 5F Cの1AB65 02E18 40 7B56、EA A7 C5になってください。
MSK = T-PRF(S-IMCKn,
"Session Key Generating Function",
64);
MSKはT-PRF(S-IMCKn、「セッションの主要な母関数」、64)と等しいです。
4D 83 A9 BE 6F 8A 74 ED 6A 02 66 0A 63 4D 2C 33
C2 DA 60 15 C6 37 04 51 90 38 63 DA 54 3E 14 B9
27 99 18 1E 07 BF 0F 5A 5E 3C 32 93 80 8C 6C 49
67 ED 24 FE 45 40 A0 59 5E 37 C2 E9 D0 5D 0A E3
4D83A9が6Fそうである、8A74、エド6A02 66 0A63 4D2C33C2 DA60 15C6 37 04 51 90 38 63DA54 3 14EのB9 27 99 18 1 07EのBF0F5A5 3EのC32 93 80 8C6C49 67教育24FE45 40、A0 59 5E37C2E9D0 5D 0A E3
EMSK = T-PRF(S-IMCKn,
"Extended Session Key Generating Function",
64);
EMSKはT-PRF(S-IMCKn、「拡張セッション主要な母関数」、64)と等しいです。
3A D4 AB DB 76 B2 7F 3B EA 32 2C 2B 74 F4 28 55
EF 2D BA 78 C9 57 2F 0D 06 CD 51 7C 20 93 98 A9
76 EA 70 21 D7 0E 25 54 97 ED B2 8A F6 ED FD 0A
2A E7 A1 58 90 10 50 44 B3 82 85 DB 06 14 D2 F9
3A D4AB DB76B2 7F 3B EA32 2C2B74F4 28 55のEFの2D Ba78C9 57 2F0D06CD51 7C20 93 98A9 76EA70 21D7 0E25 54 97エドB2 8A F6エドFD 0A 2A E7 A1 58 90 10 50 44B3 82 85DB06 14D2 F9
Cam-Winget, et al. Informational [Page 61] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [61ページ]情報のRFC4851速いEAP2007年5月
B.2. Crypto-Binding MIC
B.2。 暗号を拘束力があるMIC
[Compound MAC Key 1]
76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8
15 EC 57 7B
[合成MACキー1] 76 5D8F0B C5 07C6 B9 04D0 69 56 72 8B 6B B8 15EC57 7B
[Crypto-Binding TLV]
80 0C 00 38 00 01 01 00 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE
21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 43 24 6E 30
92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7
[暗号を拘束力があるTLV] 80 0C00 38 00 01 01 00D8 6A8C68 3C32 31A8 56 63B6 40 21FE21 14 4EのE7 54 20 79 2D42 62C9 BF53 7F54FD西暦58 43 24年の6E30 92 17 6D6Cf EのE0 69EB33 61 6A CC05C5 5B B7
[Server Nonce]
D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14
4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58
[サーバ一回だけ] F FD D8 6A8C68 3C32 31A8 56 63B6 40 21FE21 14 4EのE7 54 20 79 2D42 62C9 BF53 7 54西暦58年
[Compound MAC]
43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC
05 C5 5B B7
[合成MAC] 43 24 6E30 92 17 6D6Cf EのE0 69EB33 61 6A CC05C5 5B B7
Cam-Winget, et al. Informational [Page 62] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [62ページ]情報のRFC4851速いEAP2007年5月
Authors' Addresses
作者のアドレス
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
ナンシーカム-Wingetシスコシステムズ3625コクチマスWayサンノゼ(カリフォルニア)95134米国
EMail: ncamwing@cisco.com
メール: ncamwing@cisco.com
David McGrew Cisco Systems San Jose, CA 95134 US
デヴィッド・マグリュー・シスコシステムズカリフォルニア95134サンノゼ(米国)
EMail: mcgrew@cisco.com
メール: mcgrew@cisco.com
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
第3ジョゼフSaloweyシスコシステムズ2901Aveワシントン98121シアトル(米国)
EMail: jsalowey@cisco.com
メール: jsalowey@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
おお、4125年のハオ周シスコシステムズの高地人パークウェイリッチフィールド、44286米国
EMail: hzhou@cisco.com
メール: hzhou@cisco.com
Cam-Winget, et al. Informational [Page 63] RFC 4851 EAP-FAST May 2007
カム-Winget、他 [63ページ]情報のRFC4851速いEAP2007年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Cam-Winget, et al. Informational [Page 64]
カム-Winget、他 情報[64ページ]
一覧
スポンサーリンク
