RFC5247 日本語訳
5247 Extensible Authentication Protocol (EAP) Key ManagementFramework. B. Aboba, D. Simon, P. Eronen. August 2008. (Format: TXT=193535 bytes) (Updates RFC3748) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Aboba
Request for Comments: 5247 D. Simon
Updates: 3748 Microsoft Corporation
Category: Standards Track P. Eronen
Nokia
August 2008
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 5247のD.サイモンアップデート: 3748年のマイクロソフト社カテゴリ: 標準化過程P.Eronenノキア2008年8月
Extensible Authentication Protocol (EAP) Key Management Framework
拡張認証プロトコル(EAP)Key Managementフレームワーク
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied.
RFC3748で定義された拡張認証プロトコル(EAP)は広げることができるネットワークアクセス認証を可能にします。 このドキュメントは、「メソッド」として知られているEAP認証アルゴリズムで生成された材料とパラメタを合わせる輸送と用法にEAPの主要な階層構造を指定して、フレームワークを提供します。 また、それは詳細なシステムレベル証券分析を提供します、RFC4962で説明されたかぎ管理ガイドラインを満たすことができる状態について説明して。
Aboba, et al. Standards Track [Page 1] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[1ページ]RFC5247EAP
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
1.2. Terminology ................................................3
1.3. Overview ...................................................7
1.4. EAP Key Hierarchy .........................................10
1.5. Security Goals ............................................15
1.6. EAP Invariants ............................................16
2. Lower-Layer Operation ..........................................20
2.1. Transient Session Keys ....................................20
2.2. Authenticator and Peer Architecture .......................22
2.3. Authenticator Identification ..............................23
2.4. Peer Identification .......................................27
2.5. Server Identification .....................................29
3. Security Association Management ................................31
3.1. Secure Association Protocol ...............................32
3.2. Key Scope .................................................35
3.3. Parent-Child Relationships ................................35
3.4. Local Key Lifetimes .......................................37
3.5. Exported and Calculated Key Lifetimes .....................37
3.6. Key Cache Synchronization .................................40
3.7. Key Strength ..............................................40
3.8. Key Wrap ..................................................41
4. Handoff Vulnerabilities ........................................41
4.1. EAP Pre-Authentication ....................................43
4.2. Proactive Key Distribution ................................44
4.3. AAA Bypass ................................................46
5. Security Considerations ........................................50
5.1. Peer and Authenticator Compromise .........................51
5.2. Cryptographic Negotiation .................................53
5.3. Confidentiality and Authentication ........................54
5.4. Key Binding ...............................................59
5.5. Authorization .............................................60
5.6. Replay Protection .........................................63
5.7. Key Freshness .............................................64
5.8. Key Scope Limitation ......................................66
5.9. Key Naming ................................................66
5.10. Denial-of-Service Attacks ................................67
6. References .....................................................68
6.1. Normative References ......................................68
6.2. Informative References ....................................68
Acknowledgments ...................................................74
Appendix A - Exported Parameters in Existing Methods ..............75
1. 序論…3 1.1. 要件言語…3 1.2. 用語…3 1.3. 概要…7 1.4. EAPの主要な階層構造…10 1.5. セキュリティ目標…15 1.6. EAP不変式…16 2. 下層操作…20 2.1. 一時的なセッションキー…20 2.2. 固有識別文字と同輩アーキテクチャ…22 2.3. 固有識別文字識別…23 2.4. 同輩識別…27 2.5. サーバ識別…29 3. セキュリティ協会管理…31 3.1. 協会プロトコルを保証してください…32 3.2. 主要な範囲…35 3.3. 親子関係…35 3.4. 地方のキー生涯…37 3.5. 主要な生涯をエクスポートして、計算します…37 3.6. 主要なキャッシュ同期…40 3.7. 主要な強さ…40 3.8. 主要な包装…41 4. 移管脆弱性…41 4.1. EAPプレ認証…43 4.2. 主要な分配を予測してください…44 4.3. AAA迂回…46 5. セキュリティ問題…50 5.1. 同輩と固有識別文字は妥協します…51 5.2. 暗号の交渉…53 5.3. 秘密性と認証…54 5.4. 主要な結合…59 5.5. 承認…60 5.6. 保護を再演してください…63 5.7. 主要な新しさ…64 5.8. 主要な範囲制限…66 5.9. 主要な命名…66 5.10. サービス不能攻撃…67 6. 参照…68 6.1. 標準の参照…68 6.2. 有益な参照…68の承認…74 付録A--既存の方法によるパラメタであるとエクスポートされます…75
Aboba, et al. Standards Track [Page 2] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[2ページ]RFC5247EAP
1. Introduction
1. 序論
The Extensible Authentication Protocol (EAP), defined in [RFC3748], was designed to enable extensible authentication for network access in situations in which the Internet Protocol (IP) protocol is not available. Originally developed for use with Point-to-Point Protocol (PPP) [RFC1661], it has subsequently also been applied to IEEE 802 wired networks [IEEE-802.1X], Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306], and wireless networks such as [IEEE-802.11] and [IEEE-802.16e].
[RFC3748]で定義された拡張認証プロトコル(EAP)は、インターネットプロトコル(IP)プロトコルが利用可能でない状況におけるネットワークアクセスのための広げることができる認証を可能にするように設計されました。 元々、Pointからポイントへのプロトコル(PPP)[RFC1661]との使用のために開発されています、また、それは次に、IEEE802有線ネットワーク[IEEE-802.1X]、インターネット・キー・エクスチェンジプロトコルバージョン2(IKEv2)[RFC4306]、および[IEEE-802.11]や[IEEE-802.16e]などのワイヤレス・ネットワークに適用されました。
EAP is a two-party protocol spoken between the EAP peer and server. Within EAP, keying material is generated by EAP authentication algorithms, known as "methods". Part of this keying material can be used by EAP methods themselves, and part of this material can be exported. In addition to the export of keying material, EAP methods can also export associated parameters such as authenticated peer and server identities and a unique EAP conversation identifier, and can import and export lower-layer parameters known as "channel binding parameters", or simply "channel bindings".
EAPはEAP同輩とサーバの間で話された2パーティーのプロトコルです。EAPの中では、材料を合わせるのは「メソッド」として知られているEAP認証アルゴリズムで生成されます。 EAPメソッド自体で材料を合わせるこの一部は使用できます、そして、この材料の一部をエクスポートすることができます。 合わせることの材料の輸出に加えて、EAPメソッドは、「パラメタを縛るチャンネル」、または単に「チャンネル結合」として知られている下層パラメタを、また、認証された同輩、サーバのアイデンティティ、およびユニークなEAP会話識別子として関連パラメタにそのようなものをエクスポートすることができて、意味して、エクスポートすることができます。
This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP methods. It also provides a detailed security analysis, describing the conditions under which the requirements described in "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" [RFC4962] can be satisfied.
このドキュメントは、EAPメソッドで生成された材料とパラメタを合わせる輸送と用法にEAPの主要な階層構造を指定して、フレームワークを提供します。 また、それは詳細な証券分析を提供します、「認証、承認、および会計(AAA)Key Managementのための指導」[RFC4962]で説明された要件を満たすことができる状態について説明して。
1.1. Requirements Language
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. 用語
The terms "Cryptographic binding", "Cryptographic separation", "Key strength" and "Mutual authentication" are defined in [RFC3748] and are used with the same meaning in this document, which also frequently uses the following terms:
用語「暗号の結合」、「暗号の分離」、「主要な強さ」、および「互いの認証」は、[RFC3748]で定義されて、また、頻繁に次の用語を使用するこのドキュメントでの同じ意味と共に使用されます:
4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP)
defined in [IEEE-802.11], which confirms mutual possession of a
Pairwise Master Key by two parties and distributes a Group Key.
2回のパーティーでPairwise Master Keyの互いの所持を確認して、Group Keyを分配する[IEEE-802.11]で定義された4方法のHandshake A対状AuthenticationとKey Managementプロトコル(AKMP)。
Aboba, et al. Standards Track [Page 3] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[3ページ]RFC5247EAP
AAA Authentication, Authorization, and Accounting
AAA protocols with EAP support include "RADIUS Support for EAP"
[RFC3579] and "Diameter EAP Application" [RFC4072]. In this
document, the terms "AAA server" and "backend authentication
server" are used interchangeably.
EAPとのプロトコルがサポートするAAA Authentication、Authorization、およびAccounting AAAは「EAPの半径サポート」[RFC3579]と「直径EAPアプリケーション」[RFC4072]を含めます。 本書では、用語「AAAサーバ」と「バックエンド認証サーバ」は互換性を持って使用されます。
AAA-Key
The term AAA-Key is synonymous with Master Session Key (MSK).
Since multiple keys can be transported by AAA, the term is
potentially confusing and is not used in this document.
用語AAAキーが同義であるAAAキーMaster Session Key(MSK)。 AAAが複数のキーを輸送できるので、用語は、潜在的に混乱させていて、本書では使用されません。
Authenticator
The entity initiating EAP authentication.
固有識別文字、EAP認証を開始する実体。
Backend Authentication Server
A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this
server typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X].
バックエンドAuthentication Server Aバックエンド認証サーバは固有識別文字への認証サービスを提供する実体です。 使用されると、このサーバは固有識別文字のためにEAPメソッドを通常実行します。 また、この用語は[IEEE-802.1X]で使用されます。
Channel Binding
A secure mechanism for ensuring that a subset of the parameters
transmitted by the authenticator (such as authenticator
identifiers and properties) are agreed upon by the EAP peer and
server. It is expected that the parameters are also securely
agreed upon by the EAP peer and authenticator via the lower layer
if the authenticator advertised the parameters.
固有識別文字(固有識別文字識別子や特性などの)によって伝えられたパラメタの部分集合はEAP同輩とサーバによって同意されます。Binding Aがまた、下層でパラメタが固有識別文字であるならEAP同輩と固有識別文字によってしっかりと同意されると予想されるのを確実にするためにメカニズムを固定するチャンネルはパラメタの広告を出しました。
Derived Keying Material
Keys derived from EAP keying material, such as Transient Session
Keys (TSKs).
派生しているKeying MaterialキーズがTransient Sessionキーズなどの材料を合わせるEAPに由来していました(TSKs)。
EAP Keying Material
Keys derived by an EAP method; this includes exported keying
material (MSK, Extended MSK (EMSK), Initialization Vector (IV)) as
well as local keying material such as Transient EAP Keys (TEKs).
EAPメソッドで引き出されたEAP Keying Materialキーズ。 これは、Transient EAPキーズ(TEKs)などの材料を合わせながら、物質的であって(MSK、Extended MSK(EMSK)、初期設定Vector(IV))、地方であることでエクスポートしている合わせることを含んでいます。
EAP Pre-Authentication
The use of EAP to pre-establish EAP keying material on an
authenticator prior to arrival of the peer at the access network
managed by that authenticator.
EAP Pre-認証、同輩の到着の前にアクセスネットワークで固有識別文字の材料を合わせるEAPをあらかじめ設立するEAPの使用はその固有識別文字によって管理されました。
EAP Re-Authentication
EAP authentication between an EAP peer and a server with whom the
EAP peer shares valid unexpired EAP keying material.
EAPがじっと見るEAP同輩とサーバの間のEAP Re-認証EAP認証は材料を合わせる有効な満期になっていないEAPを共有します。
Aboba, et al. Standards Track [Page 4] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[4ページ]RFC5247EAP
EAP Server
The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where
the authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server.
EAP Server、同輩と共にEAP認証方法を終える実体。 バックエンド認証サーバがないのが使用されている場合では、EAPサーバは固有識別文字の一部です。 固有識別文字が通じて通りモードで作動する場合では、EAPサーバはバックエンド認証サーバに位置しています。
Exported Keying Material
The EAP Master Session Key (MSK), Extended Master Session Key
(EMSK), and Initialization Vector (IV).
材料を合わせながらエクスポートされて、EAPは、セッションの主要(MSK)で、拡張しているマスターセッションキー(EMSK)、および初期設定がベクトル(IV)であるとマスタリングします。
Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server
that is exported by the EAP method. The EMSK is at least 64
octets in length and is never shared with a third party. The EMSK
MUST be at least as long as the MSK in size.
材料が同輩とサーバで間それがEAPメソッドでエクスポートされる引き出した拡張Master Session Key(EMSK)の追加合わせること。 EMSKは長さにおける少なくとも64の八重奏であり、第三者と決して共有されません。 MSKとしてサイズで切望するとき、EMSK MUSTは少なくともそうです。
Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as
EAP-TLS (Transport Layer Security) [RFC5216], it cannot be used by
itself for computation of any quantity that needs to remain
secret. As a result, its use has been deprecated and it is
OPTIONAL for EAP methods to generate it. However, when it is
generated, it MUST be unpredictable.
同輩とEAPサーバの間でそれを引き出します。少なくとも64の八重奏の初期設定Vector(IV)A量、初期化ベクトル場での使用に適しています、EAP-TLS(輸送Layer Security)[RFC5216]などのメソッドでIVが知られている値であるので、秘密のままで残る必要があるどんな量の計算にもそれ自体でそれを使用できません。 その結果、使用は推奨しないです、そして、それはそれを生成するEAPメソッドのためのOPTIONALです。 しかしながら、発生しているとき、それは予測できるはずがありません。
Keying Material
Unless otherwise qualified, the term "keying material" refers to
EAP keying material as well as derived keying material.
別の方法で資格があったMaterial Unlessを合わせて、「材料を合わせる」という用語は材料を合わせながら材料を合わせて、引き出されたEAPについて言及します。
Key Scope
The parties to whom a key is available.
キーが利用可能であるパーティーの主要なScope。
Key Wrap
The encryption of one symmetric cryptographic key in another. The
algorithm used for the encryption is called a key wrap algorithm
or a key encryption algorithm. The key used in the encryption
process is called a key-encryption key (KEK).
Wrapを合わせてください。別のものの1個の左右対称の暗号化キーの暗号化。 暗号化に使用されるアルゴリズムは主要な包装アルゴリズムか主要な暗号化アルゴリズムと呼ばれます。 暗号化プロセスで使用されるキーは主要な暗号化キー(KEK)と呼ばれます。
Long-Term Credential
EAP methods frequently make use of long-term secrets in order to
enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long-term
credential is the pre-shared key. In the case of a
public-key-based method, the long-term credential is the
corresponding private key.
長い期間Credential EAPメソッドは、同輩とサーバの間の認証を可能にするのに頻繁に長期の秘密を利用します。あらかじめ共有された主要な認証に基づくメソッドの場合では、長期の資格証明書はあらかじめ共有されたキーです。 公開鍵ベースのメソッドの場合では、長期の資格証明書は対応する秘密鍵です。
Aboba, et al. Standards Track [Page 5] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[5ページ]RFC5247EAP
Lower Layer
The lower layer is responsible for carrying EAP frames between the
peer and authenticator.
下側が層にする下側のLayerは同輩と固有識別文字の間までEAPフレームを運ぶのに責任があります。
Lower-Layer Identity
A name used to identify the EAP peer and authenticator within the
lower layer.
低級層のIdentity A名は以前は下層の中でよくEAP同輩と固有識別文字を特定していました。
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server
and exported by the EAP method. The MSK is at least 64 octets in
length.
EAP同輩とサーバの間で誘導されて、EAPメソッドでエクスポートされる材料を合わせて、Session Key(MSK)をマスタリングしてください。 MSKは長さが少なくとも64の八重奏です。
Network Access Server (NAS)
A device that provides an access service for a user to a network.
アクセス・サービスをユーザに提供するAccess Server(NAS)Aデバイスをネットワークにネットワークでつないでください。
Pairwise Master Key (PMK)
Lower layers use the MSK in a lower-layer dependent manner. For
instance, in IEEE 802.11 [IEEE-802.11], Octets 0-31 of the MSK are
known as the Pairwise Master Key (PMK); the Temporal Key Integrity
Protocol (TKIP) and Advanced Encryption Standard Counter Mode with
CBC-MAC Protocol (AES CCMP) ciphersuites derive their Transient
Session Keys (TSKs) solely from the PMK, whereas the Wired
Equivalent Privacy (WEP) ciphersuite, as noted in "IEEE 802.1X
RADIUS Usage Guidelines" [RFC3580], derives its TSKs from both
halves of the MSK. In [IEEE-802.16e], the MSK is truncated to 20
octets for PMK and 20 octets for PMK2.
対状のMaster Key(PMK)の低級層は低級層の依存する方法でMSKを使用します。 例えば、IEEE802.11[IEEE-802.11]では、MSKのOctets0-31はPairwise Master Key(PMK)として知られています。 CBC-MACプロトコル(AES CCMP)ciphersuitesとTemporal Key Integrityプロトコル(TKIP)とエー・イー・エスCounter Modeは唯一PMKからそれらのTransient Sessionキーズ(TSKs)を引き出しますが、「IEEE 802.1X RADIUS用法ガイドライン」[RFC3580]に述べられるWEP(WEP)ciphersuiteがTSKsにMSKの両方の半分に由来しています。 [IEEE-802.16e]では、MSKはPMKのための20の八重奏とPMK2のための20の八重奏に先端を切られます。
Peer
The entity that responds to the authenticator. In [IEEE-802.1X],
this entity is known as the Supplicant.
じっと見てください。固有識別文字に応じる実体。 [IEEE-802.1X]では、この実体はSupplicantとして知られています。
Security Association
A set of policies and cryptographic state used to protect
information. Elements of a security association include
cryptographic keys, negotiated ciphersuites and other parameters,
counters, sequence spaces, authorization attributes, etc.
Association Aが設定する方針のセキュリティと暗号の州は以前はよく情報を保護していました。 セキュリティ協会の要素は暗号化キーと交渉されたciphersuitesと他のパラメタ、カウンタ、系列空間、承認属性などを含んでいます。
Secure Association Protocol
An exchange that occurs between the EAP peer and authenticator in
order to manage security associations derived from EAP exchanges.
The protocol establishes unicast and (optionally) multicast
security associations, which include symmetric keys and a context
for the use of the keys. An example of a Secure Association
Protocol is the 4-way handshake defined within [IEEE-802.11].
セキュリティ協会を経営するためにEAP同輩と固有識別文字の間に起こる安全なAssociationプロトコルAn交換はEAPから交換を引き出しました。 プロトコルはユニキャストと(任意に)マルチキャストセキュリティ協会を確立します。(協会はキーの使用のための対称鍵と文脈を含んでいます)。 Secure Associationプロトコルに関する例は[IEEE-802.11]の中で定義された4ウェイ握手です。
Aboba, et al. Standards Track [Page 6] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[6ページ]RFC5247EAP
Session-Id
The EAP Session-Id uniquely identifies an EAP authentication
exchange between an EAP peer (as identified by the Peer-Id(s)) and
server (as identified by the Server-Id(s)). For more information,
see Section 1.4.
EAP Session-イドが唯一EAP認証交換を特定するセッションイド、EAP同輩、(Peerイド(s))とサーバによって特定される、(Serverイド(s))によって特定されるように。 詳しくは、セクション1.4を見てください。
Transient EAP Keys (TEKs)
Session keys that are used to establish a protected channel
between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the
EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up
the protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to
subsequently protect data sent between the EAP peer and
authenticator.
EAP認証交換の間、EAP同輩とサーバの間の保護されたチャンネルを証明するのに使用される一時的なEAPキーズ(TEKs)セッションキー。 使用に、ciphersuiteがEAPの会話を保護することにおける使用のためにEAP同輩とサーバの間で交渉されている状態で、TEKsは適切です。 TEKsはEAPメソッドで局所的に保存されて、エクスポートされません。 EAP認証の間、EAP同輩とサーバの間の保護されたチャンネルをセットアップするのにおいて中古のciphersuiteがEAP同輩と固有識別文字の間に送られたデータが次に保護されるのに使用されるciphersuiteに関係ないことに注意してください。
Transient Session Keys (TSKs)
Keys used to protect data exchanged after EAP authentication has
successfully completed using the ciphersuite negotiated between
the EAP peer and authenticator.
一時的なSessionキーズ(TSKs)キーは以前はよくEAP認証が、EAP同輩と固有識別文字の間で交渉されたciphersuiteを使用するのを首尾よく完了した後に交換されたデータを保護していました。
1.3. Overview
1.3. 概要
Where EAP key derivation is supported, the conversation typically takes place in three phases:
EAPの主要な派生がサポートされるところでは、会話は三相で通常行われます:
Phase 0: Discovery
Phase 1: Authentication
1a: EAP authentication
1b: AAA Key Transport (optional)
Phase 2: Secure Association Protocol
2a: Unicast Secure Association
2b: Multicast Secure Association (optional)
フェーズ0: 発見フェーズ1: 認証1a: EAP認証1b: AAAの主要な輸送(任意)のフェーズ2: 協会プロトコルが2aであると機密保護してください: ユニキャストの安全な協会2b: マルチキャストの安全な協会(任意)です。
Of these phases, phase 0, 1b, and 2 are handled external to EAP. phases 0 and 2 are handled by the lower-layer protocol, and phase 1b is typically handled by a AAA protocol.
これらのフェーズでは、フェーズ0、1b、および2はEAPに外部であることの形で扱われます。フェーズ0と2は下位層プロトコルによって扱われます、そして、フェーズ1bはAAAプロトコルによって通常扱われます。
In the discovery phase (phase 0), peers locate authenticators and discover their capabilities. A peer can locate an authenticator providing access to a particular network, or a peer can locate an authenticator behind a bridge with which it desires to establish a Secure Association. Discovery can occur manually or automatically, depending on the lower layer over which EAP runs.
発見フェーズ(フェーズ0)では、同輩は、固有識別文字の場所を見つけて、彼らの能力を発見します。 同輩が特定のネットワークへのアクセスを提供する固有識別文字の場所を見つけることができますか、または同輩はそれがSecure Associationを設立することを望んでいるブリッジの後ろで固有識別文字の場所を見つけることができます。 EAPが稼働する下層によって、発見は手動的か自動的に起こることができます。
Aboba, et al. Standards Track [Page 7] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[7ページ]RFC5247EAP
The authentication phase (phase 1) can begin once the peer and authenticator discover each other. This phase, if it occurs, always includes EAP authentication (phase 1a). Where the chosen EAP method supports key derivation, in phase 1a, EAP keying material is derived on both the peer and the EAP server.
同輩と固有識別文字がいったん互いを発見すると、認証フェーズ(フェーズ1)は始まることができます。 起こるなら、このフェーズはいつもEAP認証を含んでいます。(フェーズ1a)。 選ばれたEAPメソッドがフェーズ1aで主要な派生をサポートするところでは、材料を合わせるEAPが同輩とEAPサーバの両方で引き出されます。
An additional step (phase 1b) is needed in deployments that include a backend authentication server, in order to transport keying material from the backend authentication server to the authenticator. In order to obey the principle of mode independence (see Section 1.6.1), where a backend authentication server is present, all keying material needed by the lower layer is transported from the EAP server to the authenticator. Since existing TSK derivation and transport techniques depend solely on the MSK, in existing implementations, this is the only keying material replicated in the AAA key transport phase 1b.
追加ステップ(フェーズ1b)がバックエンド認証サーバを含んでいる展開で必要です、バックエンド認証サーバから固有識別文字まで合わせることの材料を輸送するために。 モード独立(セクション1.6.1を見る)の原則(バックエンド認証サーバは存在している)に従うために、下層によって必要とされた材料をすべて合わせるのはEAPサーバから固有識別文字まで輸送されます。 既存のTSK派生と輸送のテクニックが既存の実装で唯一MSKによるので、これはAAAの主要な輸送フェーズ1bで模写された唯一の合わせることの材料です。
Successful completion of EAP authentication and key derivation by a peer and EAP server does not necessarily imply that the peer is committed to joining the network associated with an EAP server. Rather, this commitment is implied by the creation of a security association between the EAP peer and authenticator, as part of the Secure Association Protocol (phase 2). The Secure Association Protocol exchange (phase 2) occurs between the peer and authenticator in order to manage the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security associations between the peer and authenticator. The conversation between the parties is shown in Figure 1.
同輩とEAPサーバによるEAP認証と主要な派生の無事終了は、同輩がEAPサーバに関連しているネットワークに加わるよう心がけるのを必ず含意するというわけではありません。むしろ、この委任はEAP同輩と固有識別文字とのセキュリティ仲間の作成によって含意されます、Secure Associationプロトコル(フェーズ2)の一部として。 Secure Associationプロトコル交換(フェーズ2)は、ユニキャストの作成と削除を管理するために同輩と固有識別文字の間に起こります。(同輩と固有識別文字との2a)とマルチキャスト(フェーズ2b)セキュリティ仲間の位相を合わせてください。 パーティーでの会話は図1に示されます。
EAP peer Authenticator Auth. Server
-------- ------------- ------------
|<----------------------------->| |
| Discovery (phase 0) | |
|<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<----------------------------->|
| | AAA Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Unicast Secure association | |
| (phase 2a) | |
| | |
|<----------------------------->| |
| Multicast Secure association | |
| (optional; phase 2b) | |
| | |
EAP同輩Authenticator Auth。 サーバ-------- ------------- ------------ |<----------------------------->| | | 発見(フェーズ0)| | |<----------------------------->|<----------------------------->| | EAP auth、(1a)の位相を合わせてください。| AAA通じて通ります(任意の)。| | | | | |<----------------------------->| | | AAA Key輸送| | | (任意;、フェーズ1b) | |<----------------------------->| | | ユニキャストSecure協会| | | (2a)の位相を合わせてください。 | | | | | |<----------------------------->| | | マルチキャストSecure協会| | | (任意;、フェーズ2b) | | | | |
Aboba, et al. Standards Track [Page 8] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[8ページ]RFC5247EAP
Figure 1: Conversation Overview
図1: 会話概要
1.3.1. Examples
1.3.1. 例
Existing EAP lower layers implement phase 0, 2a, and 2b in different ways:
既存のEAP低級層は異なった方法でフェーズ0、2a、および2bを実装します:
PPP
The Point-to-Point Protocol (PPP), defined in [RFC1661], does not
support discovery, nor does it include a Secure Association
Protocol.
PPP Pointからポイントへの[RFC1661]で定義されたプロトコル(PPP)は発見をサポートしません、そして、それはSecure Associationプロトコルを含んでいません。
PPPoE
PPP over Ethernet (PPPoE), defined in [RFC2516], includes support
for a Discovery stage (phase 0). In this step, the EAP peer sends
a PPPoE Active Discovery Initiation (PADI) packet to the broadcast
address, indicating the service it is requesting. The Access
Concentrator replies with a PPPoE Active Discovery Offer (PADO)
packet containing its name, the service name, and an indication of
the services offered by the concentrator. The discovery phase is
not secured. PPPoE, like PPP, does not include a Secure
Association Protocol.
[RFC2516]で定義されたイーサネット(PPPoE)の上のPPPoE PPPはディスカバリーステージ(フェーズ0)のサポートを含んでいます。 このステップでは、EAP同輩はPPPoE ActiveディスカバリーInitiation(PADI)パケットを放送演説に送ります、それが要求しているサービスを示して。 PPPoE ActiveディスカバリーOffer(PADO)パケットが集中装置によって提供された名前、サービス名、およびサービスのしるしを含んでいて、Access Concentratorは返答します。 発見フェーズは保証されません。 PPPのようなPPPoEはSecure Associationプロトコルを含んでいません。
IKEv2
Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes
support for EAP and handles the establishment of unicast security
associations (phase 2a). However, the establishment of multicast
security associations (phase 2b) typically does not involve EAP
and needs to be handled by a group key management protocol such as
Group Domain of Interpretation (GDOI) [RFC3547], Group Secure
Association Key Management Protocol (GSAKMP) [RFC4535], Multimedia
Internet KEYing (MIKEY) [RFC3830], or Group Key Distribution
Protocol (GKDP) [GKDP]. Several mechanisms have been proposed for
the discovery of IPsec security gateways. [RFC2230] discusses the
use of Key eXchange (KX) Resource Records (RRs) for IPsec gateway
discovery; while KX RRs are supported by many Domain Name Service
(DNS) server implementations, they have not yet been widely
deployed. Alternatively, DNS SRV RRs [RFC2782] can be used for
this purpose. Where DNS is used for gateway location, DNS
security mechanisms such as DNS Security (DNSSEC) ([RFC4033],
[RFC4035]), TSIG [RFC2845], and Simple Secure Dynamic Update
[RFC3007] are available.
[RFC4306]で定義されたIKEv2インターネット・キー・エクスチェンジv2(IKEv2)はEAPのサポートを含んで、ユニキャストセキュリティ協会の設立を扱います。(フェーズ2a)。 しかしながら、マルチキャストセキュリティ協会(フェーズ2b)の設立は、EAPを通常伴わないで、Interpretation(GDOI)[RFC3547]のGroup Domainなどのグループかぎ管理プロトコル、Group Secure Association Key Managementプロトコル(GSAKMP)[RFC4535]、MultimediaインターネットKEYing(マイキー)[RFC3830]、またはGroup Key Distributionプロトコル(GKDP)[GKDP]によって扱われる必要があります。 数個のメカニズムがIPsecセキュリティゲートウェイの発見のために提案されました。 [RFC2230]はKey eXchange(KX)リソースRecords(RRs)のIPsecゲートウェイ発見の使用について議論します。 KX RRsが多くのDomain Name Service(DNS)サーバ実装によってサポートされている間、それらはまだ広く配布されていません。 あるいはまた、このために、DNS SRV RRs[RFC2782]を使用できます。 DNSがゲートウェイ位置に使用されるところでは、DNS Security(DNSSEC)[RFC4033]や、[RFC4035)や、TSIG[RFC2845]や、Simple Secureダイナミック・アップデート[RFC3007]などのDNSセキュリティー対策は利用可能です。
IEEE 802.11
IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
Beacon and Probe Request/Response mechanisms. IEEE 802.11 Access
Points (APs) periodically announce their Service Set Identifiers
(SSIDs) as well as capabilities using Beacon frames. Stations can
[IEEE-802.11]で定義されたIEEE802.11IEEE802.11はProbe Request/反応機構BeaconとIEEE802.11を通して発見を扱います。Access Points(APs)は、Beaconフレームを使用することで能力と同様に彼らのService Set Identifiers(SSIDs)を定期的に発表します。 駅はそうすることができます。
Aboba, et al. Standards Track [Page 9] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[9ページ]RFC5247EAP
query for APs by sending a Probe Request. Neither Beacon nor
Probe Request/Response frames are secured. The 4-way handshake
defined in [IEEE-802.11] enables the derivation of unicast (phase
2a) and multicast/broadcast (phase 2b) secure associations. Since
the group key exchange transports a group key from the AP to the
station, two 4-way handshakes can be needed in order to support
peer-to-peer communications. A proof of the security of the IEEE
802.11 4-way handshake, when used with EAP-TLS, is provided in
[He].
APsのために、Probe Requestを送ることによって、質問します。 BeaconもProbe Request/レスポンス・フレームも固定されていません。 [IEEE-802.11]で定義された4ウェイ握手はユニキャストの派生を可能にします。(フェーズ2a)とマルチキャスト/放送(フェーズ2b)は協会を機密保護します。 グループキー交換がAPからステーションまで主要なグループを輸送するので、2つの4ウェイ握手がピアツーピアがコミュニケーションであるとサポートするのに必要である場合があります。 EAP-TLSと共に使用すると、IEEE802.11 4ウェイ握手のセキュリティの証拠に提供します[彼]。
IEEE 802.1X
IEEE 802.1X-2004, defined in [IEEE-802.1X], does not support
discovery (phase 0), nor does it provide for derivation of unicast
or multicast secure associations.
[IEEE-802.1X]で定義されたIEEE 802.1X IEEE 802.1X-2004は、発見が(フェーズ0)であるとサポートしません、そして、それはユニキャストかマルチキャストの安全な協会の派生に備えません。
1.4. EAP Key Hierarchy
1.4. EAPの主要な階層構造
As illustrated in Figure 2, the EAP method key derivation has, at the root, the long-term credential utilized by the selected EAP method. If authentication is based on a pre-shared key, the parties store the EAP method to be used and the pre-shared key. The EAP server also stores the peer's identity as well as additional information. This information is typically used outside of the EAP method to determine whether to grant access to a service. The peer stores information necessary to choose which secret to use for which service.
図2で例証されるように、EAPのメソッドの主要な派生は根に選択されたEAPメソッドで利用された長期の資格証明書を持っています。 認証があらかじめ共有されたキーに基づいているなら、パーティーは使用されるべきEAPメソッドとあらかじめ共有されたキーを保存します。 また、EAPサーバは追加情報と同様に同輩のアイデンティティを保存します。 この情報はサービスへのアクセスを承諾するかどうか決定するEAPメソッドの外で通常使用されます。 同輩は、どのサービスにどの秘密を使用したらよいかを選ぶために必要情報を保存します。
If authentication is based on proof of possession of the private key corresponding to the public key contained within a certificate, the parties store the EAP method to be used and the trust anchors used to validate the certificates. The EAP server also stores the peer's identity, and the peer stores information necessary to choose which certificate to use for which service. Based on the long-term credential established between the peer and the server, methods derive two types of EAP keying material:
認証が証明書の中に含まれた公開鍵に対応する秘密鍵の所有物の証拠に基づいているなら、パーティーは使用されるべきEAPメソッドを保存します、そして、信頼アンカーは以前はよく証明書を有効にしていました。 また、EAPサーバは同輩のアイデンティティを保存します、そして、同輩はどのサービスにどの証明書を使用したらよいかを選ぶために必要情報を保存します。 同輩とサーバの間で確立された長期の資格証明書に基づいて、メソッドは材料を合わせるEAPの2つのタイプを引き出します:
(a) Keying material calculated locally by the EAP method but not
exported, such as the Transient EAP Keys (TEKs).
(a) 材料を合わせるのは、EAPメソッドで局所的に計算しましたが、Transient EAPキーズ(TEKs)などのようにエクスポートしませんでした。
(b) Keying material exported by the EAP method: Master Session Key
(MSK), Extended Master Session Key (EMSK), Initialization
Vector (IV).
(b) 材料を合わせるのはEAPメソッドでエクスポートしました: セッションの主要(MSK)で、拡張しているマスターセッションキー(EMSK)、初期設定ベクトル(IV)をマスタリングしてください。
As noted in [RFC3748] Section 7.10:
[RFC3748]セクション7.10に述べられるように:
In order to provide keying material for use in a subsequently
negotiated ciphersuite, an EAP method supporting key derivation
MUST export a Master Session Key (MSK) of at least 64 octets, and
an Extended Master Session Key (EMSK) of at least 64 octets.
次に交渉されたciphersuiteにおける使用のための材料を合わせながら提供するために、主要な派生をサポートするEAPメソッドは少なくとも64の八重奏のMaster Session Key(MSK)、および少なくとも64の八重奏のExtended Master Session Key(EMSK)をエクスポートしなければなりません。
Aboba, et al. Standards Track [Page 10] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[10ページ]RFC5247EAP
EAP methods also MAY export the IV; however, the use of the IV is deprecated. The EMSK MUST NOT be provided to an entity outside the EAP server or peer, nor is it permitted to pass any quantity to an entity outside the EAP server or peer from which the EMSK could be computed without breaking some cryptographic assumption, such as inverting a one-way function.
EAPメソッドもIVをエクスポートするかもしれません。 しかしながら、IVの使用は推奨しないです。 EMSK MUST NOTはEAPサーバの外で実体に提供するか、またはじっと見ます、そして、一方向関数を逆にすることなどの暗号の何らかの仮定を破らないでEMSKを計算できたEAPサーバか同輩の外でどんな量も実体に通過するのが可能にされません。
EAP methods supporting key derivation and mutual authentication SHOULD export a method-specific EAP conversation identifier known as the Session-Id, as well as one or more method-specific peer identifiers (Peer-Id(s)) and MAY export one or more method-specific server identifiers (Server-Id(s)). EAP methods MAY also support the import and export of channel binding parameters. EAP method specifications developed after the publication of this document MUST define the Peer-Id, Server-Id, and Session-Id. The Peer-Id(s) and Server-Id(s), when provided, identify the entities involved in generating EAP keying material. For existing EAP methods, the Peer-Id, Server-Id, and Session-Id are defined in Appendix A.
同輩イド(s))と5月は、1つ以上のメソッド特有のサーバが識別子であるとエクスポートします。主要な派生と互いの認証がSHOULDであるとサポートするEAPメソッドがSession-イドとして知られているメソッド特有のEAP会話識別子をエクスポートします、1つ以上のメソッド特有の同輩識別子と同様に((サーバイド(s))。 また、EAPメソッドはチャンネルの輸出入に拘束力があるパラメタをサポートするかもしれません。 このドキュメントの公表がPeer-イド、Server-イド、およびSession-アイダホ州を定義しなければならなかった後に開発されたEAPメソッド仕様 提供すると、Peer-イドとServer-イドは材料を合わせるEAPを生成するのにかかわる実体を特定します。 既存のEAPメソッドにおいて、Peer-イド、Server-イド、およびSession-イドはAppendix Aで定義されます。
Aboba, et al. Standards Track [Page 11] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[11ページ]RFC5247EAP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | |
| | | | | | V
+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^
| | | | Exported |
| Peer-Id(s), | channel | MSK (64+B) | IV (64B) by |
| Server-Id(s), | bindings | EMSK (64+B) | (Optional) EAP |
| Session-Id | & Result | | Method |
V V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | EAPメソッド| | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | | | | | | | | EAPメソッドキー| <->| 長期| | | | | 派生| | 資格証明書| | | | | | | | | | | | | +-+-+-+-+-+-+-+ | ローカル| | | | | EAP| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メソッド| | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | | TEK| |MSK、EMSK| |IV| | | | | |派生| |派生| |派生| | | | | | | | | |(推奨しない)です。 | | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | ^ | | | | | | | | | | V++、-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+ | | | | ^ | | | | エクスポートされます。| | 同輩イド| チャンネル| MSK(64+B)| IV(64B)| | サーバイド| 結合| EMSK(64+B)| (任意)です。 EAP| | セッションイド| 結果| | メソッド| V V V V V
Figure 2: EAP Method Parameter Import/Export
図2: EAPメソッドParameter Import/Export
Peer-Id
同輩イド
If an EAP method that generates keys authenticates one or more
method-specific peer identities, those identities are exported by
the method as the Peer-Id(s). It is possible for more than one
Peer-Id to be exported by an EAP method. Not all EAP methods
provide a method-specific peer identity; where this is not
defined, the Peer-Id is the null string. In EAP methods that do
not support key generation, the Peer-Id MUST be the null string.
Where an EAP method that derives keys does not provide a Peer-Id,
the EAP server will not authenticate the identity of the EAP peer
with which it derived keying material.
キーを生成するEAPメソッドが1つ以上のメソッド特有の同輩のアイデンティティを認証するなら、それらのアイデンティティはPeer-イドとしてメソッドでエクスポートされます。 1つ以上のPeer-イドがEAPメソッドでエクスポートされるのは、可能です。 すべてのEAPメソッドがメソッド特有の同輩のアイデンティティを提供するというわけではありません。 これが定義されないところでは、Peer-イドはヌルストリングです。 キー生成をサポートしないEAPメソッドで、Peer-イドはヌルストリングであるに違いありません。 キーを引き出すEAPメソッドがPeer-イドを提供しないところでは、EAPサーバはそれと合わせることの材料を誘導したEAP同輩のアイデンティティを認証しないでしょう。
Aboba, et al. Standards Track [Page 12] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[12ページ]RFC5247EAP
Server-Id
サーバイド
If an EAP method that generates keys authenticates one or more
method-specific server identities, those identities are exported
by the method as the Server-Id(s). It is possible for more than
one Server-Id to be exported by an EAP method. Not all EAP
methods provide a method-specific server identity; where this is
not defined, the Server-Id is the null string. If the EAP method
does not generate keying material, the Server-Id MUST be the null
string. Where an EAP method that derives keys does not provide a
Server-Id, the EAP peer will not authenticate the identity of the
EAP server with which it derived EAP keying material.
キーを生成するEAPメソッドが1つ以上のメソッド特有のサーバのアイデンティティを認証するなら、それらのアイデンティティはServer-イドとしてメソッドでエクスポートされます。 1つ以上のServer-イドがEAPメソッドでエクスポートされるのは、可能です。 すべてのEAPメソッドがメソッド特有のサーバのアイデンティティを提供するというわけではありません。 これが定義されないところでは、Server-イドはヌルストリングです。 EAPメソッドが、合わせるのが材料であると生成しないなら、Server-イドはヌルストリングであるに違いありません。 キーを引き出すEAPメソッドがServer-イドを提供しないところでは、EAP同輩はそれが材料を合わせるEAPを引き出したEAPサーバのアイデンティティを認証しないでしょう。
Session-Id
セッションイド
The Session-Id uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-Id) and server (as identified by
the Server-Id). Where non-expanded EAP Type Codes are used (EAP
Type Code not equal to 254), the EAP Session-Id is the
concatenation of the single octet EAP Type Code and a temporally
unique identifier obtained from the method (known as the
Method-Id):
Session-イドは唯一EAP同輩(Peer-イドによって特定されるように)とサーバとのEAPセッションを特定します(Server-イドによって特定されるように)。 非拡張しているEAP Type Codesが使用されているところでは(254と等しくないEAP Type Code)、EAP Session-イドはメソッド(Method-イドとして、知られている)から入手されたただ一つの八重奏EAP Type Codeと時間的にユニークな識別子の連結です:
Session-Id = Type-Code || Method-Id
セッションイド=タイプコード|| メソッドイド
Where expanded EAP Type Codes are used, the EAP Session-Id
consists of the Expanded Type Code (including the Type, Vendor-Id
(in network byte order) and Vendor-Type fields (in network byte
order) defined in [RFC3748] Section 5.7), concatenated with a
temporally unique identifier obtained from the method (Method-Id):
拡張EAP Type Codesが使用されているところでは、EAP Session-イドはメソッド(メソッドイド)から時間的にユニークな識別子を得ていて連結されたExpanded Type Code(Type、[RFC3748]セクション5.7で定義されたVendor-イド(ネットワークバイトオーダーにおける)とVendor-タイプ分野(ネットワークバイトオーダーにおける)を含んでいる)から成ります:
Session-Id = 0xFE || Vendor-Id || Vendor-Type || Method-Id
セッションイド=0xFE|| ベンダーイド|| ベンダータイプ|| メソッドイド
The Method-Id is typically constructed from nonces or counters
used within the EAP method exchange. The inclusion of the Type
Code or Expanded Type Code in the EAP Session-Id ensures that each
EAP method has a distinct Session-Id space. Since an EAP session
is not bound to a particular authenticator or specific ports on
the peer and authenticator, the authenticator port or identity are
not included in the Session-Id.
Method-イドはEAPメソッド交換の中で使用された一回だけかカウンタから通常構成されます。 EAP Session-イドでのType CodeかExpanded Type Codeの包含は、それぞれのEAPメソッドには異なったSession-イドスペースがあるのを確実にします。 EAPセッションが特定の固有識別文字に縛られないか、または同輩と固有識別文字の特定のポート、固有識別文字ポートまたはアイデンティティがSession-アイダホ州で含められていないので
Aboba, et al. Standards Track [Page 13] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[13ページ]RFC5247EAP
Channel Binding
チャンネル結合
Channel binding is the process by which lower-layer parameters are
verified for consistency between the EAP peer and server. In
order to avoid introducing media dependencies, EAP methods that
transport channel binding parameters MUST treat this data as
opaque octets. See Section 5.3.3 for further discussion.
チャンネル結合は下層パラメタがEAP同輩とサーバの間の一貫性のために確かめられるプロセスです。メディアの依存を導入するのを避けるために、パラメタを縛るチャンネルを輸送するEAPメソッドは不透明な八重奏としてこのデータを扱わなければなりません。 さらなる議論に関してセクション5.3.3を見てください。
1.4.1. Key Naming
1.4.1. 主要な命名
Each key created within the EAP key management framework has a name (a unique identifier), as well as a scope (the parties to whom the key is available). The scope of exported keying material and TEKs is defined by the authenticated method-specific peer identities (Peer-Id(s)) and the authenticated server identities (Server-Id(s)), where available.
EAPかぎ管理フレームワークの中で作成された各キーは名前(ユニークな識別子)を持っています、範囲(キーが利用可能であるパーティー)と同様に。 エクスポートしている合わせることの材料とTEKsの範囲が認証されたメソッド特有の同輩のアイデンティティによって定義される、(同輩イド(s))と認証されたサーバのアイデンティティ、(入手できるところのサーバイド(s))。
MSK and EMSK Names
The MSK and EMSK are exported by the EAP peer and EAP server,
and MUST be named using the EAP Session-Id and a binary or
textual indication of the EAP keying material being referred to.
MSKとEMSK NamesのMSKとEMSKをEAP同輩とEAPサーバによってエクスポートされて、言及される材料を合わせるEAPのEAP Session-イドと2進の、または、原文のしるしを使用すると命名しなければなりません。
PMK Name
This document does not specify a naming scheme for the Pairwise
Master Key (PMK). The PMK is only identified by the name of the
key from which it is derived.
PMK Name ThisドキュメントはPairwise Master Key(PMK)の命名体系を指定しません。 PMKはそれが引き出されるキーの名前によって特定されるだけです。
Note: IEEE 802.11 names the PMK for the purposes of being able
to refer to it in the Secure Association Protocol; the PMK name
(known as the PMKID) is based on a hash of the PMK itself as
well as some other parameters (see [IEEE-802.11] Section
8.5.1.2).
以下に注意してください。 IEEE802.11はPMKをSecure Associationプロトコルでそれについて言及できる目的にちなんで命名します。 [IEEE-802.11]セクション8.5を見てください。PMK名(PMKIDとして、知られている)がある他のパラメタと同様にPMK自身のハッシュに基づいている、(.1 .2)。
TEK Name
Transient EAP Keys (TEKs) MAY be named; their naming is
specified in the EAP method specification.
TEK Name Transient EAPキーズ(TEKs)は命名されるかもしれません。 彼らの命名はEAPメソッド仕様で指定されます。
TSK Name
Transient Session Keys (TSKs) are typically named. Their naming
is specified in the lower layer so that the correct set of TSKs
can be identified for processing a given packet.
TSK Name Transient Sessionキーズ(TSKs)は通常命名されます。 彼らの命名は、与えられたパケットを処理するためにTSKsの正しいセットを特定できるように下層で指定されます。
Aboba, et al. Standards Track [Page 14] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[14ページ]RFC5247EAP
1.5. Security Goals
1.5. セキュリティ目標
The goal of the EAP conversation is to derive fresh session keys between the EAP peer and authenticator that are known only to those parties, and for both the EAP peer and authenticator to demonstrate that they are authorized to perform their roles either by each other or by a trusted third party (the backend authentication server).
EAPの会話の目標は、それらのパーティーだけにおいて知られているEAP同輩と固有識別文字の間の新鮮なセッションキーを引き出して、EAP同輩と固有識別文字の両方が、互いか信頼できる第三者機関(バックエンド認証サーバ)で彼らが自分達の役割を実行するのが認可されるのを実施説明することです。
Completion of an EAP method exchange (phase 1a) supporting key derivation results in the derivation of EAP keying material (MSK, EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s)) and EAP server (identified by the Server-Id(s)). Both the EAP peer and EAP server know this keying material to be fresh. The Peer-Id and Server-Id are discussed in Sections 1.4, 2.4, and 2.5 as well as in Appendix A. Key freshness is discussed in Sections 3.4, 3.5, and 5.7.
EAPメソッド交換の完成、(EAP同輩だけにおいて知られている材料(MSK、EMSK、TEKs)を合わせるEAPの派生における主要な派生結果をサポートする1a)の位相を合わせてください、(Peerイド(s))とEAPサーバによって特定される、(Serverイド(s))で、特定されます。 ともに、EAP同輩とEAPサーバは、新鮮になるように材料を合わせながら、これを知っています。 セクション1.4、2.4、および2.5でPeer-イドとServer-イドについてセクション3.4、3.5、および5.7でAppendix A.Keyで新しさについて議論するのと同じくらいよく議論します。
Completion of the AAA exchange (phase 1b) results in the transport of keying material from the EAP server (identified by the Server-Id(s)) to the EAP authenticator (identified by the NAS-Identifier) without disclosure to any other party. Both the EAP server and EAP authenticator know this keying material to be fresh. Disclosure issues are discussed in Sections 3.8 and 5.3; security properties of AAA protocols are discussed in Sections 5.1 - 5.9.
AAA交換(フェーズ1b)の完成はEAPサーバから材料を合わせる輸送をもたらします。(Server-イドで、いかなる他のパーティーへの公開なしでもEAP固有識別文字(NAS-識別子で、特定される)に(s))を特定しました。 ともに、EAPサーバとEAP固有識別文字は、新鮮になるように材料を合わせながら、これを知っています。 セクション3.8と5.3で公開問題について議論します。 セクション5.1でAAAプロトコルのセキュリティの特性について議論します--5.9。
The backend authentication server is trusted to transport keying material only to the authenticator that was established with the peer, and it is trusted to transport that keying material to no other parties. In many systems, EAP keying material established by the EAP peer and EAP server are combined with publicly available data to derive other keys. The backend authentication server is trusted to refrain from deriving these same keys or acting as a man-in-the-middle even though it has access to the keying material that is needed to do so.
バックエンド認証サーバは同輩と共に確立された固有識別文字だけに材料を合わせる輸送に任せられます、そして、どんな相手にも材料を合わせないことでそれを輸送すると信じられます。 多くのシステムでは、EAP同輩とEAPサーバによって確立された材料を合わせるEAPは、他のキーを引き出すために公的に利用可能なデータに結合されます。 バックエンド認証サーバは、そうするのに必要であるこれらの同じキーを引き出すのを控えると信じられるか、アクセスを合わせるのに物質的にしますが、または中央の男性として機能することです。
The authenticator is also a trusted party. The authenticator is trusted not to distribute keying material provided by the backend authentication server to any other parties. If the authenticator uses a key derivation function to derive additional keying material, the authenticator is trusted to distribute the derived keying material only to the appropriate party that is known to the peer, and no other party. When this approach is used, care must be taken to ensure that the resulting key management system meets all of the principles in [RFC4962], confirming that keys used to protect data are to be known only by the peer and authenticator.
また、固有識別文字は信じられたパーティーです。 サーバがバックエンド認証でいかなる他のもパーティーへ行くなら、固有識別文字が合わせることの材料を分配しないと信じられます。 固有識別文字が追加合わせることの材料を誘導するのに主要な派生機能を使用するなら、固有識別文字が同輩にもかかわらず、他のパーティーがないのにおいて知られている適切なパーティーだけに材料を合わせながら派生を分配すると信じられます。 このアプローチが使用されているとき、結果として起こるかぎ管理システムが[RFC4962]の原則のすべてに会うのを保証するために注意しなければなりません、データを保護するのに使用されるキーが単に同輩と固有識別文字によって知られていることになっていると確認して。
Aboba, et al. Standards Track [Page 15] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[15ページ]RFC5247EAP
Completion of the Secure Association Protocol (phase 2) results in the derivation or transport of Transient Session Keys (TSKs) known only to the EAP peer (identified by the Peer-Id(s)) and authenticator (identified by the NAS-Identifier). Both the EAP peer and authenticator know the TSKs to be fresh. Both the EAP peer and authenticator demonstrate that they are authorized to perform their roles. Authorization issues are discussed in Sections 4.3.2 and 5.5; security properties of Secure Association Protocols are discussed in Section 3.1.
Secure Associationプロトコル(フェーズ2)の完成はEAP同輩だけにおいて知られているTransient Sessionキーズ(TSKs)の派生か輸送をもたらします。(Peerイド(s))と固有識別文字(NAS-識別子で、特定される)で、特定されます。 ともに、EAP同輩と固有識別文字は、TSKsが新鮮であることを知っています。 ともに、EAP同輩と固有識別文字は、彼らが自分達の役割を実行するのが認可されるのを示します。 セクション4.3.2と5.5で承認問題について議論します。 セクション3.1でSecure Associationプロトコルのセキュリティの特性について議論します。
1.6. EAP Invariants
1.6. EAP不変式
Certain basic characteristics, known as "EAP Invariants", hold true for EAP implementations:
「EAP不変式」として知られているある基本特性はEAP実装に当てはまります:
Mode independence
Media independence
Method independence
Ciphersuite independence
モード独立メディア独立Method独立Ciphersuite独立
1.6.1. Mode Independence
1.6.1. モード独立
EAP is typically deployed to support extensible network access authentication in situations where a peer desires network access via one or more authenticators. Where authenticators are deployed standalone, the EAP conversation occurs between the peer and authenticator, and the authenticator locally implements one or more EAP methods. However, when utilized in "pass-through" mode, EAP enables the deployment of new authentication methods without requiring the development of new code on the authenticator.
EAPは、広げることができるネットワークアクセスが同輩が1つ以上の固有識別文字でネットワークアクセスを望んでいる状況で認証であるとサポートするために通常配布されます。 固有識別文字がスタンドアロンであると配布されるところでは、EAPの会話は同輩と固有識別文字の間に起こります、そして、固有識別文字は局所的に1つ以上のEAPメソッドを実装します。 しかしながら、「通じて、通り」モードで利用されると、固有識別文字における新法の開発を必要としないで、EAPは新しい認証方法の展開を可能にします。
While the authenticator can implement some EAP methods locally and use those methods to authenticate local users, it can at the same time act as a pass-through for other users and methods, forwarding EAP packets back and forth between the backend authentication server and the peer. This is accomplished by encapsulating EAP packets within the Authentication, Authorization, and Accounting (AAA) protocol spoken between the authenticator and backend authentication server. AAA protocols supporting EAP include RADIUS [RFC3579] and Diameter [RFC4072].
他のユーザとメソッドのために通じて通るのと同じ時間条例に使用できます、固有識別文字が局所的にいくつかのEAPメソッドを実装して、地元のユーザを認証するそれらのメソッドを使用できる間、バックエンド認証サーバと同輩の間で前後にパケットをEAPに送って、使用します。 これは、Authentication、Authorization、および固有識別文字とバックエンド認証サーバの間で話されたAccounting(AAA)プロトコルの中でパケットをEAPにカプセルに入れることによって、達成されます。EAPをサポートするAAAプロトコルがRADIUS[RFC3579]とDiameter[RFC4072]を含んでいます。
It is a fundamental property of EAP that at the EAP method layer, the conversation between the EAP peer and server is unaffected by whether the EAP authenticator is operating in "pass-through" mode. EAP methods operate identically in all aspects, including key derivation and parameter import/export, regardless of whether or not the authenticator is operating as a pass-through.
それはEAP固有識別文字が「通じて、通り」モードで作動しているかどうかによってEAPメソッド層、EAP同輩とサーバとの会話のときに影響を受けないEAPの基本財産です。 EAPメソッドは同様に全面で作動します、主要な派生とパラメタ輸入/輸出を含んでいて、固有識別文字が通じて通るとして作動しているかどうかにかかわらず。
Aboba, et al. Standards Track [Page 16] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[16ページ]RFC5247EAP
The successful completion of an EAP method that supports key derivation results in the export of EAP keying material and parameters on the EAP peer and server. Even though the EAP peer or server can import channel binding parameters that can include the identity of the EAP authenticator, this information is treated as opaque octets. As a result, within EAP, the only relevant identities are the Peer-Id(s) and Server-Id(s). Channel binding parameters are only interpreted by the lower layer.
主要な派生をサポートするEAPメソッドの無事終了はEAP同輩とサーバに関する材料とパラメタを合わせるEAPの輸出をもたらします。EAP同輩かサーバがEAP固有識別文字のアイデンティティを含むことができる拘束力があるパラメタをチャンネルに意味できますが、この情報は不透明な八重奏として扱われます。 その結果、唯一の関連アイデンティティが、EAPの中では、Peer-イドとServer-イドです。 チャンネルの拘束力があるパラメタは下層によって解釈されるだけです。
Within EAP, the primary function of the AAA protocol is to maintain the principle of mode independence. As far as the EAP peer is concerned, its conversation with the EAP authenticator, and all consequences of that conversation, are identical, regardless of the authenticator mode of operation.
EAPの中では、AAAプロトコルのプライマリ機能はモード独立の原則を維持することです。 EAP同輩に関する限り、EAP固有識別文字との会話、およびその会話のすべての結果が同じです、固有識別文字運転モードにかかわらず。
1.6.2. Media Independence
1.6.2. メディア独立
One of the goals of EAP is to allow EAP methods to function on any lower layer meeting the criteria outlined in [RFC3748] Section 3.1. For example, as described in [RFC3748], EAP authentication can be run over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and wireless networks such as 802.11 [IEEE-802.11] and 802.16 [IEEE-802.16e].
EAPの目標の1つは評価基準が[RFC3748]セクション3.1に概説したどんな下層ミーティングのときにも機能するメソッドをEAPに許容することです。 例えば、[RFC3748]で説明されるようにPPP[RFC1661]の上にEAP認証を実行できて、IEEE802はネットワーク[IEEE-802.1X]、802.11などのワイヤレス・ネットワーク[IEEE-802.11]、および802.16[IEEE-802.16e]を配線しました。
In order to maintain media independence, it is necessary for EAP to avoid consideration of media-specific elements. For example, EAP methods cannot be assumed to have knowledge of the lower layer over which they are transported, and cannot be restricted to identifiers associated with a particular usage environment (e.g., Medium Access Control (MAC) addresses).
メディア独立を維持するために、EAPがメディア特有の要素の考慮を避けるのが必要です。 例えば、EAPメソッドは、それらが輸送される下層に関する知識を持っていると思うことができないで、特定の用法環境(例えば、Medium Access Control(MAC)アドレス)に関連している識別子に制限されない場合があります。
Note that media independence can be retained within EAP methods that support channel binding or method-specific identification. An EAP method need not be aware of the content of an identifier in order to use it. This enables an EAP method to use media-specific identifiers such as MAC addresses without compromising media independence. Channel binding parameters are treated as opaque octets by EAP methods so that handling them does not require media-specific knowledge.
チャンネル結合かメソッド特有の識別をサポートするEAPメソッドの中でメディア独立を保有できることに注意してください。 EAPメソッドは、それを使用するために識別子の内容を意識している必要はありません。 これはメディアが独立であると感染することのないMACアドレスなどのメディア特有の識別子を使用するEAPメソッドを可能にします。 チャンネルの拘束力があるパラメタがEAPメソッドで不透明な八重奏として扱われるので、それらを扱うのはメディア特有の知識を必要としません。
Aboba, et al. Standards Track [Page 17] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[17ページ]RFC5247EAP
1.6.3. Method Independence
1.6.3. メソッド独立
By enabling pass-through, authenticators can support any method implemented on the peer and server, not just locally implemented methods. This allows the authenticator to avoid having to implement the EAP methods configured for use by peers. In fact, since a pass-through authenticator need not implement any EAP methods at all, it cannot be assumed to support any EAP method-specific code. As noted in [RFC3748] Section 2.3:
通じて通るのを可能にすることによって、固有識別文字はメソッドであるとちょうど局所的に実装されるのではなく、同輩とサーバで実装されたどんなメソッドもサポートすることができます。 これで、固有識別文字は、使用のために同輩によって構成されたEAPメソッドを実装しなければならないのを避けることができます。 事実上、通じて通り固有識別文字が全く少しのEAPメソッドも実装する必要はないので、どんなEAPもメソッド特有のコードであるとサポートすると思うことができません。 [RFC3748]セクション2.3に述べられるように:
Compliant pass-through authenticator implementations MUST by
default forward EAP packets of any Type.
対応する通じて通り固有識別文字実装はデフォルトでどんなTypeのパケットもEAPに送らなければなりません。
This is useful where there is no single EAP method that is both mandatory to implement and offers acceptable security for the media in use. For example, the [RFC3748] mandatory-to-implement EAP method (MD5-Challenge) does not provide dictionary attack resistance, mutual authentication, or key derivation, and as a result, is not appropriate for use in Wireless Local Area Network (WLAN) authentication [RFC4017]. However, despite this, it is possible for the peer and authenticator to interoperate as long as a suitable EAP method is supported both on the EAP peer and server.
これは実装するためにともに義務的であり、使用中のメディアのために許容できるセキュリティを提供するただ一つのEAPメソッドがないのがあるところで役に立ちます。 例えば、[RFC3748]実装するために義務的なEAPメソッド(MD5-挑戦)は辞書攻撃抵抗、互いの認証、または主要な派生を提供しません、そして、aとして、Wirelessローカル・エリア・ネットワーク(WLAN)認証[RFC4017]における使用には、結果は適切ではありません。 しかしながら、これにもかかわらず、適当なEAPメソッドがEAP同輩とサーバでサポートされる限り、同輩と固有識別文字が共同利用するのは、可能です。
1.6.4. Ciphersuite Independence
1.6.4. Ciphersuite独立
Ciphersuite Independence is a requirement for media independence. Since lower-layer ciphersuites vary between media, media independence requires that exported EAP keying material be large enough (with sufficient entropy) to handle any ciphersuite.
Ciphersuite Independenceはメディア独立のための要件です。 下層ciphersuitesがメディアの間で異なるので、メディア独立は、材料を合わせるエクスポートしているEAPがどんなciphersuiteも扱うことができるくらい大きいのを(十分なエントロピーがある)必要とします。
While EAP methods can negotiate the ciphersuite used in protection of the EAP conversation, the ciphersuite used for the protection of the data exchanged after EAP authentication has completed is negotiated between the peer and authenticator within the lower layer, outside of EAP.
EAPメソッドがEAPの会話の保護に使用されるciphersuiteを交渉できる間、認証が完成したデータの交換された後EAPの保護に使用されるciphersuiteは下層(EAPの外部)の中で同輩と固有識別文字の間で交渉されます。
For example, within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP) defined in [RFC1968], after EAP authentication is completed. Within [IEEE-802.11], the AP ciphersuites are advertised in the Beacon and Probe Responses prior to EAP authentication and are securely verified during a 4-way handshake exchange.
例えば、ciphersuiteは[RFC1968]で定義されたEncryption Controlプロトコル(ECP)の中でPPPの中では、交渉されます、EAP認証が終了した後に。 [IEEE-802.11]の中では、AP ciphersuitesはEAP認証の前にBeaconとProbe Responsesに広告を出して、4ウェイ握手交換の間、しっかりと確かめられます。
Aboba, et al. Standards Track [Page 18] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[18ページ]RFC5247EAP
Since the ciphersuites used to protect data depend on the lower layer, requiring that EAP methods have knowledge of lower-layer ciphersuites would compromise the principle of media independence. As a result, methods export EAP keying material that is ciphersuite independent. Since ciphersuite negotiation occurs in the lower layer, there is no need for lower-layer ciphersuite negotiation within EAP.
データを保護するのに使用されるciphersuitesが下層によるので、EAPメソッドには下層ciphersuitesに関する知識があるのが必要であるのがメディア独立の原則に感染するでしょう。 その結果、メソッドはciphersuite独立者である材料を合わせるEAPをエクスポートします。 ciphersuite交渉が下層で起こるので、EAPの中に下層ciphersuite交渉の必要は全くありません。
In order to allow a ciphersuite to be usable within the EAP keying framework, the ciphersuite specification needs to describe how TSKs suitable for use with the ciphersuite are derived from exported EAP keying material. To maintain method independence, algorithms for deriving TSKs MUST NOT depend on the EAP method, although algorithms for TEK derivation MAY be specific to the EAP method.
ciphersuiteがフレームワークを合わせるEAPの中で使用可能であることを許容するために、ciphersuite仕様は、材料を合わせるエクスポートしているEAPからciphersuiteとの使用に適したTSKsをどう得るかを説明する必要があります。 メソッド独立を維持するために、TSKsを引き出すためのアルゴリズムはEAPメソッドによってはいけません、TEK派生のためのアルゴリズムがEAPメソッドに特定であるかもしれませんが。
Advantages of ciphersuite-independence include:
ciphersuite-独立の利点は:
Reduced update requirements
Ciphersuite independence enables EAP methods to be used with new
ciphersuites without requiring the methods to be updated. If
EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a
new ciphersuite is developed. In addition, backend
authentication servers might not be usable with all EAP-capable
authenticators, since the backend authentication server would
also need to be updated each time support for a new ciphersuite
is added to the authenticator.
減少しているアップデート要件Ciphersuite独立は新しいciphersuitesと共にアップデートされるべきメソッドを必要としないで使用されるべきEAPメソッドを可能にします。 EAPメソッドが各ciphersuiteのために一時的なセッションキーを引き出す方法を指定することであるなら、それらは、新しいciphersuiteが開発されているたびにアップデートする必要があります。 さらに、バックエンド認証サーバはすべてのEAPできる固有識別文字で使用可能でないかもしれません、また、バックエンド認証サーバが、新しいciphersuiteのサポートが固有識別文字に追加されるたびにアップデートする必要があるでしょう、したがって。
Reduced EAP method complexity
Ciphersuite independence enables EAP methods to avoid having to
include ciphersuite-specific code. Requiring each EAP method to
include ciphersuite-specific code for transient session key
derivation would increase method complexity and result in
duplicated effort.
減少しているEAPメソッド複雑さCiphersuite独立はciphersuite特有のコードを含まなければならないのを避けるEAPメソッドを可能にします。 一時的なセッション主要な派生はメソッドの複雑さと結果を増やすでしょう、したがって、ciphersuite特有のコードを含むそれぞれのEAPメソッドを必要とすると、取り組みはコピーされました。
Simplified configuration
Ciphersuite independence enables EAP method implementations on
the peer and server to avoid having to configure
ciphersuite-specific parameters. The ciphersuite is negotiated
between the peer and authenticator outside of EAP. Where the
authenticator operates in "pass-through" mode, the EAP server is
not a party to this negotiation, nor is it involved in the data
flow between the EAP peer and authenticator. As a result, the
EAP server does not have knowledge of the ciphersuites and
negotiation policies implemented by the peer and authenticator,
nor is it aware of the ciphersuite negotiated between them. For
example, since Encryption Control Protocol (ECP) negotiation
occurs after authentication, when run over PPP, the EAP peer and
簡易型の構成Ciphersuite独立は、同輩とサーバに関するEAPメソッド実装が、ciphersuite特有のパラメタを構成しなければならないのを避けるのを可能にします。 ciphersuiteはEAPの外で同輩と固有識別文字の間で交渉されます。 どこで、固有識別文字は「通じて、通り」モードで作動して、EAPサーバはこの交渉に関係しないで、またそれはEAP同輩と固有識別文字の間のデータフローにかかわらないか。 その結果、同輩と固有識別文字でciphersuitesと交渉方針に関する知識を実装しません、そして、EAPサーバでそれはそれらの間で交渉されたciphersuiteを意識していません。 そして例えば、PPPの上に実行されるとEncryption Controlプロトコル(ECP)交渉が認証の後に起こるのでEAPがじっと見る。
Aboba, et al. Standards Track [Page 19] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[19ページ]RFC5247EAP
server cannot anticipate the negotiated ciphersuite, and
therefore, this information cannot be provided to the EAP
method.
サーバは交渉されたciphersuiteを予期できません、そして、したがって、この情報はEAPメソッドに提供できません。
2. Lower-Layer Operation
2. 下層操作
On completion of EAP authentication, EAP keying material and parameters exported by the EAP method are provided to the lower layer and AAA layer (if present). These include the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s), and Session-Id. The Initialization Vector (IV) is deprecated, but might be provided.
EAP認証の完成のときに、EAPメソッドでエクスポートされた材料とパラメタを合わせるEAPを下層とAAA層に提供します(存在しているなら)。 これらはMaster Session Key(MSK)、Extended Master Session Key(EMSK)、Peer-イド、Server-イド、およびSession-アイダホ州を含んでいます。 初期設定Vector(IV)を推奨しないのですが、提供するかもしれません。
In order to preserve the security of EAP keying material derived within methods, lower layers MUST NOT export keys passed down by EAP methods. This implies that EAP keying material passed down to a lower layer is for the exclusive use of that lower layer and MUST NOT be used within another lower layer. This prevents compromise of one lower layer from compromising other applications using EAP keying material.
メソッドの中で誘導された材料を合わせるEAPのセキュリティを保持するために、下層はEAPメソッドで伝えられたキーをエクスポートしてはいけません。 これは、下層まで渡された材料を合わせるEAPがその下層の専用のためにあって、別の下層の中で使用されてはいけないのを含意します。 これは、材料を合わせるEAPを使用することで1つの下層の感染が他のアプリケーションに感染するのを防ぎます。
EAP keying material provided to a lower layer MUST NOT be transported to another entity. For example, EAP keying material passed down to the EAP peer lower layer MUST NOT leave the peer; EAP keying material passed down or transported to the EAP authenticator lower layer MUST NOT leave the authenticator.
下層に提供された材料を合わせるEAPを別の実体に輸送してはいけません。 例えば、材料を合わせるEAPが低級層が同輩を置き去りにしてはいけないEAP同輩まで通りました。 EAPの固有識別文字の低級層に伝えるか、または輸送する材料を合わせるEAPは固有識別文字を残してはいけません。
On the EAP server, keying material and parameters requested by and passed down to the AAA layer MAY be replicated to the AAA layer on the authenticator (with the exception of the EMSK). On the authenticator, the AAA layer provides the replicated keying material and parameters to the lower layer over which the EAP authentication conversation took place. This enables mode independence to be maintained.
EAPサーバでは、層が要求されて、AAAまで渡された材料とパラメタを合わせるのは固有識別文字(EMSKを除いた)のAAA層に模写されるかもしれません。 固有識別文字では、AAA層はEAP認証の会話が行われた下層への材料とパラメタを模写された合わせるのに供給します。 これは、モード独立が維持されるのを可能にします。
The EAP layer, as well as the peer and authenticator layers, MUST NOT modify or cache keying material or parameters (including channel bindings) passing in either direction between the EAP method layer and the lower layer or AAA layer.
EAPメソッド層と下層かAAA層の間のどちらの方向にも通って、EAP層、同輩、および固有識別文字層は、材料を合わせるか、パラメタを変更してはいけませんし、またキャッシュしてはいけません(チャンネル結合を含んでいます)。
2.1. Transient Session Keys
2.1. 一時的なセッションキー
Where explicitly supported by the lower layer, lower layers MAY cache keying material, including exported EAP keying material and/or TSKs; the structure of this key cache is defined by the lower layer. So as to enable interoperability, new lower-layer specifications MUST describe key caching behavior. Unless explicitly specified by the lower layer, the EAP peer, server, and authenticator MUST assume that
下層によって明らかにサポートされるところでは、下層が材料を合わせる、材料を合わせるEAPであるとエクスポートされた包含、そして/または、TSKsをキャッシュするかもしれません。 この主要なキャッシュの構造は下層によって定義されます。 相互運用性を可能にするために、新しい下層仕様は振舞いをキャッシュするキーについて説明しなければなりません。 下層によって明らかに指定されない場合、EAP同輩、サーバ、および固有識別文字はそれを仮定しなければなりません。
Aboba, et al. Standards Track [Page 20] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[20ページ]RFC5247EAP
peers and authenticators do not cache keying material. Existing EAP lower layers and AAA layers handle the generation of transient session keys and caching of EAP keying material in different ways:
同輩と固有識別文字は合わせることの材料をキャッシュしません。 既存のEAP低級層とAAA層は一時的なセッションキーの世代と異なった方法で材料を合わせるEAPのキャッシュを扱います:
IEEE 802.1X-2004
When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X]
does not support link-layer ciphersuites, and as a result, it
does not provide for the generation of TSKs or caching of EAP
keying material and parameters. Once EAP authentication
completes, it is assumed that EAP keying material and parameters
are discarded; on IEEE 802 wired networks, there is no
subsequent Secure Association Protocol exchange. Perfect
Forward Secrecy (PFS) is only possible if the negotiated EAP
method supports this.
有線ネットワークと共に使用されるIEEE 802.1X-2004 When、IEEE 802.1X-2004[IEEE-802.1X]はリンクレイヤがciphersuitesであるとサポートしません、そして、その結果、それはTSKsの世代か材料とパラメタを合わせるEAPのキャッシュに備えません。 一度、EAP認証が完成する、材料とパラメタを合わせるEAPが捨てられると思われます。 IEEE802有線ネットワークには、どんなその後のSecure Associationプロトコル交換もありません。 交渉されたEAPメソッドがこれをサポートする場合にだけ、完全なForward Secrecy(PFS)は可能です。
PPP
PPP, defined in [RFC1661], does not include support for a Secure
Association Protocol, nor does it support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716] Section 3.5.
This is NOT RECOMMENDED, since if PPP were to support caching of
EAP keying material, this could result in TSK reuse. As a
result, once the PPP session is terminated, EAP keying material
and parameters MUST be discarded. Since caching of EAP keying
material is not permitted within PPP, there is no way to handle
TSK re-key without EAP re-authentication. Perfect Forward
Secrecy (PFS) is only possible if the negotiated EAP method
supports this.
PPP PPP, defined in [RFC1661], does not include support for a Secure Association Protocol, nor does it support caching of EAP keying material or parameters. PPP ciphersuites derive their TSKs directly from the MSK, as described in [RFC2716] Section 3.5. This is NOT RECOMMENDED, since if PPP were to support caching of EAP keying material, this could result in TSK reuse. As a result, once the PPP session is terminated, EAP keying material and parameters MUST be discarded. Since caching of EAP keying material is not permitted within PPP, there is no way to handle TSK re-key without EAP re-authentication. Perfect Forward Secrecy (PFS) is only possible if the negotiated EAP method supports this.
IKEv2
IKEv2, defined in [RFC4306], only uses the MSK for
authentication purposes and not key derivation. The EMSK, IV,
Peer-Id, Server-Id or Session-Id are not used. As a result, the
TSKs derived by IKEv2 are cryptographically independent of the
EAP keying material and re-key of IPsec SAs can be handled
without requiring EAP re-authentication. Within IKEv2, it is
possible to negotiate PFS, regardless of which EAP method is
negotiated. IKEv2 as specified in [RFC4306] does not cache EAP
keying material or parameters; once IKEv2 authentication
completes, it is assumed that EAP keying material and parameters
are discarded. The Session-Timeout Attribute is therefore
interpreted as a limit on the VPN session time, rather than an
indication of the MSK key lifetime.
IKEv2 IKEv2, defined in [RFC4306], only uses the MSK for authentication purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id or Session-Id are not used. As a result, the TSKs derived by IKEv2 are cryptographically independent of the EAP keying material and re-key of IPsec SAs can be handled without requiring EAP re-authentication. Within IKEv2, it is possible to negotiate PFS, regardless of which EAP method is negotiated. IKEv2 as specified in [RFC4306] does not cache EAP keying material or parameters; once IKEv2 authentication completes, it is assumed that EAP keying material and parameters are discarded. The Session-Timeout Attribute is therefore interpreted as a limit on the VPN session time, rather than an indication of the MSK key lifetime.
IEEE 802.11
IEEE 802.11 enables caching of the MSK, but not the EMSK, IV,
Peer-Id, Server-Id, or Session-Id. More details about the
structure of the cache are available in [IEEE-802.11]. In IEEE
IEEE 802.11 IEEE 802.11 enables caching of the MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id. More details about the structure of the cache are available in [IEEE-802.11]. In IEEE
Aboba, et al. Standards Track [Page 21] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 21] RFC 5247 EAP Key Management Framework August 2008
802.11, TSKs are derived from the MSK using a Secure Association
Protocol known as the 4-way handshake, which includes a nonce
exchange. This guarantees TSK freshness even if the MSK is
reused. The 4-way handshake also enables TSK re-key without EAP
re-authentication. PFS is only possible within IEEE 802.11 if
caching is not enabled and the negotiated EAP method supports
PFS.
802.11, TSKs are derived from the MSK using a Secure Association Protocol known as the 4-way handshake, which includes a nonce exchange. This guarantees TSK freshness even if the MSK is reused. The 4-way handshake also enables TSK re-key without EAP re-authentication. PFS is only possible within IEEE 802.11 if caching is not enabled and the negotiated EAP method supports PFS.
IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e], supports caching of the
MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id.
IEEE 802.16e supports a Secure Association Protocol in which
TSKs are chosen by the authenticator without any contribution by
the peer. The TSKs are encrypted, authenticated, and integrity
protected using the MSK and are transported from the
authenticator to the peer. TSK re-key is possible without EAP
re-authentication. PFS is not possible even if the negotiated
EAP method supports it.
IEEE 802.16e IEEE 802.16e, defined in [IEEE-802.16e], supports caching of the MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id. IEEE 802.16e supports a Secure Association Protocol in which TSKs are chosen by the authenticator without any contribution by the peer. The TSKs are encrypted, authenticated, and integrity protected using the MSK and are transported from the authenticator to the peer. TSK re-key is possible without EAP re-authentication. PFS is not possible even if the negotiated EAP method supports it.
AAA
Existing implementations and specifications for RADIUS/EAP
[RFC3579] or Diameter EAP [RFC4072] do not support caching of
keying material or parameters. In existing AAA clients, proxy
and server implementations, exported EAP keying material (MSK,
EMSK, and IV), as well as parameters and derived keys are not
cached and MUST be presumed lost after the AAA exchange
completes.
AAA Existing implementations and specifications for RADIUS/EAP [RFC3579] or Diameter EAP [RFC4072] do not support caching of keying material or parameters. In existing AAA clients, proxy and server implementations, exported EAP keying material (MSK, EMSK, and IV), as well as parameters and derived keys are not cached and MUST be presumed lost after the AAA exchange completes.
In order to avoid key reuse, the AAA layer MUST delete
transported keys once they are sent. The AAA layer MUST NOT
retain keys that it has previously sent. For example, a AAA
layer that has transported the MSK MUST delete it, and keys MUST
NOT be derived from the MSK from that point forward.
In order to avoid key reuse, the AAA layer MUST delete transported keys once they are sent. The AAA layer MUST NOT retain keys that it has previously sent. For example, a AAA layer that has transported the MSK MUST delete it, and keys MUST NOT be derived from the MSK from that point forward.
2.2. Authenticator and Peer Architecture
2.2. Authenticator and Peer Architecture
This specification does not impose constraints on the architecture of the EAP authenticator or peer. For example, any of the authenticator architectures described in [RFC4118] can be used. As a result, lower layers need to identify EAP peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures.
This specification does not impose constraints on the architecture of the EAP authenticator or peer. For example, any of the authenticator architectures described in [RFC4118] can be used. As a result, lower layers need to identify EAP peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures.
Aboba, et al. Standards Track [Page 22] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 22] RFC 5247 EAP Key Management Framework August 2008
For example, it is possible for multiple base stations and a "controller" (e.g., WLAN switch) to comprise a single EAP authenticator. In such a situation, the "base station identity" is irrelevant to the EAP method conversation, except perhaps as an opaque blob to be used in channel binding. Many base stations can share the same authenticator identity. An EAP authenticator or peer:
For example, it is possible for multiple base stations and a "controller" (e.g., WLAN switch) to comprise a single EAP authenticator. In such a situation, the "base station identity" is irrelevant to the EAP method conversation, except perhaps as an opaque blob to be used in channel binding. Many base stations can share the same authenticator identity. An EAP authenticator or peer:
(a) can contain one or more physical or logical ports;
(b) can advertise itself as one or more "virtual" authenticators
or peers;
(c) can utilize multiple CPUs;
(d) can support clustering services for load balancing or
failover.
(a) can contain one or more physical or logical ports; (b) can advertise itself as one or more "virtual" authenticators or peers; (c) can utilize multiple CPUs; (d) can support clustering services for load balancing or failover.
Both the EAP peer and authenticator can have more than one physical or logical port. A peer can simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator can offer network access to multiple peers, each via a separate physical or logical port. When a single physical authenticator advertises itself as multiple virtual authenticators, it is possible for a single physical port to belong to multiple virtual authenticators.
Both the EAP peer and authenticator can have more than one physical or logical port. A peer can simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator can offer network access to multiple peers, each via a separate physical or logical port. When a single physical authenticator advertises itself as multiple virtual authenticators, it is possible for a single physical port to belong to multiple virtual authenticators.
An authenticator can be configured to communicate with more than one EAP server, each of which is configured to communicate with a subset of the authenticators. The situation is illustrated in Figure 3.
An authenticator can be configured to communicate with more than one EAP server, each of which is configured to communicate with a subset of the authenticators. The situation is illustrated in Figure 3.
2.3. Authenticator Identification
2.3. Authenticator Identification
The EAP method conversation is between the EAP peer and server. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purpose of channel binding (see Section 5.3.3). However, the authenticator identity is important in two other exchanges - the AAA protocol exchange and the Secure Association Protocol conversation.
The EAP method conversation is between the EAP peer and server. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purpose of channel binding (see Section 5.3.3). However, the authenticator identity is important in two other exchanges - the AAA protocol exchange and the Secure Association Protocol conversation.
The AAA conversation is between the EAP authenticator and the backend authentication server. From the point of view of the backend authentication server, keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier Attribute. Since an EAP authenticator MUST NOT share EAP keying material or parameters with another party, if the EAP peer or backend authentication server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised.
The AAA conversation is between the EAP authenticator and the backend authentication server. From the point of view of the backend authentication server, keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier Attribute. Since an EAP authenticator MUST NOT share EAP keying material or parameters with another party, if the EAP peer or backend authentication server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised.
Aboba, et al. Standards Track [Page 23] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 23] RFC 5247 EAP Key Management Framework August 2008
The Secure Association Protocol conversation is between the peer and the authenticator. For lower layers that support key caching, it is particularly important for the EAP peer, authenticator, and backend server to have a consistent view of the usage scope of the transported keying material. In order to enable this, it is RECOMMENDED that the Secure Association Protocol explicitly communicate the usage scope of the EAP keying material passed down to the lower layer, rather than implicitly assuming that this is defined by the authenticator and peer endpoint addresses.
The Secure Association Protocol conversation is between the peer and the authenticator. For lower layers that support key caching, it is particularly important for the EAP peer, authenticator, and backend server to have a consistent view of the usage scope of the transported keying material. In order to enable this, it is RECOMMENDED that the Secure Association Protocol explicitly communicate the usage scope of the EAP keying material passed down to the lower layer, rather than implicitly assuming that this is defined by the authenticator and peer endpoint addresses.
+-+-+-+-+
| EAP |
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \ Authenticator
| | | | | | | | | Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth1 | | Auth2 | | Auth3 |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | \ |
\ | \ |
\ | \ |
EAP over AAA \ | \ |
(optional) \ | \ |
\ | \ |
\ | \ |
\ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | Authentication
| Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+ | EAP | | Peer | +-+-+-+-+ | | | Peer Ports / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ Authenticator | | | | | | | | | Ports +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | Auth1 | | Auth2 | | Auth3 | | | | | | | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ \ | \ | \ | \ | \ | \ | EAP over AAA \ | \ | (optional) \ | \ | \ | \ | \ | \ | \ | \ | +-+-+-+-+-+ +-+-+-+-+-+ Backend | EAP | | EAP | Authentication | Server1 | | Server2 | Servers +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP Peer, Authenticator, and Server
Figure 3: Relationship between EAP Peer, Authenticator, and Server
Since an authenticator can have multiple ports, the scope of the authenticator key cache cannot be described by a single endpoint address. Similarly, where a peer can have multiple ports and sharing of EAP keying material and parameters between peer ports of the same
Since an authenticator can have multiple ports, the scope of the authenticator key cache cannot be described by a single endpoint address. Similarly, where a peer can have multiple ports and sharing of EAP keying material and parameters between peer ports of the same
Aboba, et al. Standards Track [Page 24] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 24] RFC 5247 EAP Key Management Framework August 2008
link type is allowed, the extent of the peer key cache cannot be communicated by using a single endpoint address. Instead, it is RECOMMENDED that the EAP peer and authenticator consistently identify themselves utilizing explicit identifiers, rather than endpoint addresses or port identifiers.
link type is allowed, the extent of the peer key cache cannot be communicated by using a single endpoint address. Instead, it is RECOMMENDED that the EAP peer and authenticator consistently identify themselves utilizing explicit identifiers, rather than endpoint addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client MUST be co-resident, this mechanism is applicable to the identification of EAP authenticators.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client MUST be co-resident, this mechanism is applicable to the identification of EAP authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address attributes. Since a NAS can have more than one IP address, the NAS-Identifier Attribute is RECOMMENDED for explicit identification of the authenticator, both within the AAA protocol exchange and the Secure Association Protocol conversation.
RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address attributes. Since a NAS can have more than one IP address, the NAS-Identifier Attribute is RECOMMENDED for explicit identification of the authenticator, both within the AAA protocol exchange and the Secure Association Protocol conversation.
Problems that can arise where the peer and authenticator implicitly identify themselves using endpoint addresses include the following:
Problems that can arise where the peer and authenticator implicitly identify themselves using endpoint addresses include the following:
(a) It is possible that the peer will not be able to determine which
authenticator ports are associated with which authenticators.
As a result, the EAP peer will be unable to utilize the
authenticator key cache in an efficient way, and will also be
unable to determine whether EAP keying material has been shared
outside its authorized scope, and therefore needs to be
considered compromised.
(a) It is possible that the peer will not be able to determine which authenticator ports are associated with which authenticators. As a result, the EAP peer will be unable to utilize the authenticator key cache in an efficient way, and will also be unable to determine whether EAP keying material has been shared outside its authorized scope, and therefore needs to be considered compromised.
(b) It is possible that the authenticator will not be able to
determine which peer ports are associated with which peers,
preventing the peer from communicating with it utilizing
multiple peer ports.
(b) It is possible that the authenticator will not be able to determine which peer ports are associated with which peers, preventing the peer from communicating with it utilizing multiple peer ports.
(c) It is possible that the peer will not be able to determine with
which virtual authenticator it is communicating. For example,
multiple virtual authenticators can share a MAC address, but
utilize different NAS-Identifiers.
(c) It is possible that the peer will not be able to determine with which virtual authenticator it is communicating. For example, multiple virtual authenticators can share a MAC address, but utilize different NAS-Identifiers.
(d) It is possible that the authenticator will not be able to
determine with which virtual peer it is communicating. Multiple
virtual peers can share a MAC address, but utilize different
Peer-Ids.
(d) It is possible that the authenticator will not be able to determine with which virtual peer it is communicating. Multiple virtual peers can share a MAC address, but utilize different Peer-Ids.
(e) It is possible that the EAP peer and server will not be able to
verify the authenticator identity via channel binding.
(e) It is possible that the EAP peer and server will not be able to verify the authenticator identity via channel binding.
Aboba, et al. Standards Track [Page 25] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 25] RFC 5247 EAP Key Management Framework August 2008
For example, problems (a), (c), and (e) occur in [IEEE-802.11], which utilizes peer and authenticator MAC addresses within the 4-way handshake. Problems (b) and (d) do not occur since [IEEE-802.11] only allows a virtual peer to utilize a single port.
For example, problems (a), (c), and (e) occur in [IEEE-802.11], which utilizes peer and authenticator MAC addresses within the 4-way handshake. Problems (b) and (d) do not occur since [IEEE-802.11] only allows a virtual peer to utilize a single port.
The following steps enable lower-layer identities to be securely verified by all parties:
The following steps enable lower-layer identities to be securely verified by all parties:
(f) Specify the lower-layer parameters used to identify the
authenticator and peer. As noted earlier, endpoint or port
identifiers are not recommended for identification of the
authenticator or peer when it is possible for them to have
multiple ports.
(f) Specify the lower-layer parameters used to identify the authenticator and peer. As noted earlier, endpoint or port identifiers are not recommended for identification of the authenticator or peer when it is possible for them to have multiple ports.
(g) Communicate the lower-layer identities between the peer and
authenticator within phase 0. This allows the peer and
authenticator to determine the key scope if a key cache is
utilized.
(g) Communicate the lower-layer identities between the peer and authenticator within phase 0. This allows the peer and authenticator to determine the key scope if a key cache is utilized.
(h) Communicate the lower-layer authenticator identity between the
authenticator and backend authentication server within the NAS-
Identifier Attribute.
(h) Communicate the lower-layer authenticator identity between the authenticator and backend authentication server within the NAS- Identifier Attribute.
(i) Include the lower-layer identities within channel bindings (if
supported) in phase 1a, ensuring that they are communicated
between the EAP peer and server.
(i) Include the lower-layer identities within channel bindings (if supported) in phase 1a, ensuring that they are communicated between the EAP peer and server.
(j) Support the integrity-protected exchange of identities within
phase 2a.
(j) Support the integrity-protected exchange of identities within phase 2a.
(k) Utilize the advertised lower-layer identities to enable the peer
and authenticator to verify that keys are maintained within the
advertised scope.
(k) Utilize the advertised lower-layer identities to enable the peer and authenticator to verify that keys are maintained within the advertised scope.
2.3.1. Virtual Authenticators
2.3.1. Virtual Authenticators
When a single physical authenticator advertises itself as multiple virtual authenticators, if the virtual authenticators do not maintain logically separate key caches, then by authenticating to one virtual authenticator, the peer can gain access to the other virtual authenticators sharing a key cache.
When a single physical authenticator advertises itself as multiple virtual authenticators, if the virtual authenticators do not maintain logically separate key caches, then by authenticating to one virtual authenticator, the peer can gain access to the other virtual authenticators sharing a key cache.
Aboba, et al. Standards Track [Page 26] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 26] RFC 5247 EAP Key Management Framework August 2008
For example, where a physical authenticator implements "Guest" and "Corporate Intranet" virtual authenticators, an attacker acting as a peer could authenticate with the "Guest" virtual authenticator and derive EAP keying material. If the "Guest" and "Corporate Intranet" virtual authenticators share a key cache, then the peer can utilize the EAP keying material derived for the "Guest" network to obtain access to the "Corporate Intranet" network.
For example, where a physical authenticator implements "Guest" and "Corporate Intranet" virtual authenticators, an attacker acting as a peer could authenticate with the "Guest" virtual authenticator and derive EAP keying material. If the "Guest" and "Corporate Intranet" virtual authenticators share a key cache, then the peer can utilize the EAP keying material derived for the "Guest" network to obtain access to the "Corporate Intranet" network.
The following steps can be taken to mitigate this vulnerability:
The following steps can be taken to mitigate this vulnerability:
(a) Authenticators are REQUIRED to cache associated authorizations
along with EAP keying material and parameters and to apply
authorizations to the peer on each network access, regardless of
which virtual authenticator is being accessed. This ensures
that an attacker cannot obtain elevated privileges even where
the key cache is shared between virtual authenticators, and a
peer obtains access to one virtual authenticator utilizing a key
cache entry created for use with another virtual authenticator.
(a) Authenticators are REQUIRED to cache associated authorizations along with EAP keying material and parameters and to apply authorizations to the peer on each network access, regardless of which virtual authenticator is being accessed. This ensures that an attacker cannot obtain elevated privileges even where the key cache is shared between virtual authenticators, and a peer obtains access to one virtual authenticator utilizing a key cache entry created for use with another virtual authenticator.
(b) It is RECOMMENDED that physical authenticators maintain separate
key caches for each virtual authenticator. This ensures that a
cache entry created for use with one virtual authenticator
cannot be used for access to another virtual authenticator.
Since a key cache entry can no longer be shared between virtual
authentications, this step provides protection beyond that
offered in (a). This is valuable in situations where
authorizations are not used to enforce access limitations. For
example, where access is limited using a filter installed on a
router rather than using authorizations provided to the
authenticator, a peer can gain unauthorized access to resources
by exploiting a shared key cache entry.
(b) It is RECOMMENDED that physical authenticators maintain separate key caches for each virtual authenticator. This ensures that a cache entry created for use with one virtual authenticator cannot be used for access to another virtual authenticator. Since a key cache entry can no longer be shared between virtual authentications, this step provides protection beyond that offered in (a). This is valuable in situations where authorizations are not used to enforce access limitations. For example, where access is limited using a filter installed on a router rather than using authorizations provided to the authenticator, a peer can gain unauthorized access to resources by exploiting a shared key cache entry.
(c) It is RECOMMENDED that each virtual authenticator identify
itself consistently to the peer and to the backend
authentication server, so as to enable the peer to verify the
authenticator identity via channel binding (see Section 5.3.3).
(c) It is RECOMMENDED that each virtual authenticator identify itself consistently to the peer and to the backend authentication server, so as to enable the peer to verify the authenticator identity via channel binding (see Section 5.3.3).
(d) It is RECOMMENDED that each virtual authenticator identify
itself distinctly, in order to enable the peer and backend
authentication server to tell them apart. For example, this can
be accomplished by utilizing a distinct value of the NAS-
Identifier Attribute.
(d) It is RECOMMENDED that each virtual authenticator identify itself distinctly, in order to enable the peer and backend authentication server to tell them apart. For example, this can be accomplished by utilizing a distinct value of the NAS- Identifier Attribute.
2.4. Peer Identification
2.4. Peer Identification
As described in [RFC3748] Section 7.3, the peer identity provided in the EAP-Response/Identity can be different from the peer identities authenticated by the EAP method. For example, the identity provided
As described in [RFC3748] Section 7.3, the peer identity provided in the EAP-Response/Identity can be different from the peer identities authenticated by the EAP method. For example, the identity provided
Aboba, et al. Standards Track [Page 27] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 27] RFC 5247 EAP Key Management Framework August 2008
in the EAP-Response/Identity can be a privacy identifier as described in "The Network Access Identifier" [RFC4282] Section 2. As noted in [RFC4284], it is also possible to utilize a Network Access Identifier (NAI) for the purposes of source routing; an NAI utilized for source routing is said to be "decorated" as described in [RFC4282] Section 2.7.
in the EAP-Response/Identity can be a privacy identifier as described in "The Network Access Identifier" [RFC4282] Section 2. As noted in [RFC4284], it is also possible to utilize a Network Access Identifier (NAI) for the purposes of source routing; an NAI utilized for source routing is said to be "decorated" as described in [RFC4282] Section 2.7.
When the EAP peer provides the Network Access Identity (NAI) within the EAP-Response/Identity, as described in [RFC3579], the authenticator copies the NAI included in the EAP-Response/Identity into the User-Name Attribute included within the Access-Request. As the Access-Request is forwarded toward the backend authentication server, AAA proxies remove decoration from the NAI included in the User-Name Attribute; the NAI included within the EAP-Response/Identity encapsulated in the Access-Request remains unchanged. As a result, when the Access-Request arrives at the backend authentication server, the EAP-Response/Identity can differ from the User-Name Attribute (which can have some or all of the decoration removed). In the absence of a Peer-Id, the backend authentication server SHOULD use the contents of the User-Name Attribute, rather than the EAP-Response/Identity, as the peer identity.
When the EAP peer provides the Network Access Identity (NAI) within the EAP-Response/Identity, as described in [RFC3579], the authenticator copies the NAI included in the EAP-Response/Identity into the User-Name Attribute included within the Access-Request. As the Access-Request is forwarded toward the backend authentication server, AAA proxies remove decoration from the NAI included in the User-Name Attribute; the NAI included within the EAP-Response/Identity encapsulated in the Access-Request remains unchanged. As a result, when the Access-Request arrives at the backend authentication server, the EAP-Response/Identity can differ from the User-Name Attribute (which can have some or all of the decoration removed). In the absence of a Peer-Id, the backend authentication server SHOULD use the contents of the User-Name Attribute, rather than the EAP-Response/Identity, as the peer identity.
It is possible for more than one Peer-Id to be exported by an EAP method. For example, a peer certificate can contain more than one peer identity; in a tunnel method, peer identities can be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Peer-Id in the form of a Relative Distinguished Name (RDN), whereas an inner exchange could identify the peer via its NAI or MAC address. Where EAP keying material is determined solely from the outer exchange, only the outer Peer-Id(s) are exported; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Peer-Id(s) are exported by the tunnel method.
It is possible for more than one Peer-Id to be exported by an EAP method. For example, a peer certificate can contain more than one peer identity; in a tunnel method, peer identities can be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Peer-Id in the form of a Relative Distinguished Name (RDN), whereas an inner exchange could identify the peer via its NAI or MAC address. Where EAP keying material is determined solely from the outer exchange, only the outer Peer-Id(s) are exported; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Peer-Id(s) are exported by the tunnel method.
Aboba, et al. Standards Track [Page 28] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 28] RFC 5247 EAP Key Management Framework August 2008
2.5. Server Identification
2.5. Server Identification
It is possible for more than one Server-Id to be exported by an EAP method. For example, a server certificate can contain more than one server identity; in a tunnel method, server identities could be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Server-Id in the form of an IP address, whereas an inner exchange could identify the server via its Fully-Qualified Domain Name (FQDN) or hostname. Where EAP keying material is determined solely from the outer exchange, only the outer Server-Id(s) are exported by the EAP method; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Server-Id(s) are exported by the EAP method.
It is possible for more than one Server-Id to be exported by an EAP method. For example, a server certificate can contain more than one server identity; in a tunnel method, server identities could be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Server-Id in the form of an IP address, whereas an inner exchange could identify the server via its Fully-Qualified Domain Name (FQDN) or hostname. Where EAP keying material is determined solely from the outer exchange, only the outer Server-Id(s) are exported by the EAP method; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Server-Id(s) are exported by the EAP method.
As shown in Figure 3, an authenticator can be configured to communicate with multiple EAP servers; the EAP server that an authenticator communicates with can vary according to configuration and network and server availability. While the EAP peer can assume that all EAP servers within a realm have access to the credentials necessary to validate an authentication attempt, it cannot assume that all EAP servers share persistent state.
As shown in Figure 3, an authenticator can be configured to communicate with multiple EAP servers; the EAP server that an authenticator communicates with can vary according to configuration and network and server availability. While the EAP peer can assume that all EAP servers within a realm have access to the credentials necessary to validate an authentication attempt, it cannot assume that all EAP servers share persistent state.
Authenticators can be configured with different primary or secondary EAP servers, in order to balance the load. Also, the authenticator can dynamically determine the EAP server to which requests will be sent; in the event of a communication failure, the authenticator can fail over to another EAP server. For example, in Figure 3, Authenticator2 can be initially configured with EAP server1 as its primary backend authentication server, and EAP server2 as the backup, but if EAP server1 becomes unavailable, EAP server2 can become the primary server.
Authenticators can be configured with different primary or secondary EAP servers, in order to balance the load. Also, the authenticator can dynamically determine the EAP server to which requests will be sent; in the event of a communication failure, the authenticator can fail over to another EAP server. For example, in Figure 3, Authenticator2 can be initially configured with EAP server1 as its primary backend authentication server, and EAP server2 as the backup, but if EAP server1 becomes unavailable, EAP server2 can become the primary server.
In general, the EAP peer cannot direct an authentication attempt to a particular EAP server within a realm, this decision is made by AAA clients, nor can the peer determine with which EAP server it will be communicating, prior to the start of the EAP method conversation. The Server-Id is not included in the EAP-Request/Identity, and since the EAP server may be determined dynamically, it typically is not possible for the authenticator to advertise the Server-Id during the discovery phase. Some EAP methods do not export the Server-Id so that it is possible that the EAP peer will not learn with which server it was conversing after the EAP conversation completes successfully.
In general, the EAP peer cannot direct an authentication attempt to a particular EAP server within a realm, this decision is made by AAA clients, nor can the peer determine with which EAP server it will be communicating, prior to the start of the EAP method conversation. The Server-Id is not included in the EAP-Request/Identity, and since the EAP server may be determined dynamically, it typically is not possible for the authenticator to advertise the Server-Id during the discovery phase. Some EAP methods do not export the Server-Id so that it is possible that the EAP peer will not learn with which server it was conversing after the EAP conversation completes successfully.
As a result, an EAP peer, on connecting to a new authenticator or reconnecting to the same authenticator, can find itself communicating with a different EAP server. Fast reconnect, defined in [RFC3748]
As a result, an EAP peer, on connecting to a new authenticator or reconnecting to the same authenticator, can find itself communicating with a different EAP server. Fast reconnect, defined in [RFC3748]
Aboba, et al. Standards Track [Page 29] RFC 5247 EAP Key Management Framework August 2008
Aboba, et al. Standards Track [Page 29] RFC 5247 EAP Key Management Framework August 2008
Section 7.2, can fail if the EAP server with which the peer communicates is not the same one with which it initially established a security association. For example, an EAP peer attempting an EAP-TLS session resume can find that the new EAP-TLS server will not have access to the TLS Master Key identified by the TLS Session-Id, and therefore the session resumption attempt will fail, requiring completion of a full EAP-TLS exchange.
Section 7.2, can fail if the EAP server with which the peer communicates is not the same one with which it initially established a security association. For example, an EAP peer attempting an EAP-TLS session resume can find that the new EAP-TLS server will not have access to the TLS Master Key identified by the TLS Session-Id, and therefore the session resumption attempt will fail, requiring completion of a full EAP-TLS exchange.
EAP methods that export the Server-Id MUST authenticate the server. However, not all EAP methods supporting mutual authentication provide a non-null Server-Id; some methods only enable the EAP peer to verify that the EAP server possesses a long-term secret, but do not provide the identity of the EAP server. In this case, the EAP peer will know that an authenticator has been authorized by an EAP server, but will not confirm the identity of the EAP server. Where the EAP method does not provide a Server-Id, the peer cannot identify the EAP server with which it generated keying material. This can make it difficult for the EAP peer to identify the location of a key possessed by that EAP server.
EAP methods that export the Server-Id MUST authenticate the server. However, not all EAP methods supporting mutual authentication provide a non-null Server-Id; some methods only enable the EAP peer to verify that the EAP server possesses a long-term secret, but do not provide the identity of the EAP server. In this case, the EAP peer will know that an authenticator has been authorized by an EAP server, but will not confirm the identity of the EAP server. Where the EAP method does not provide a Server-Id, the peer cannot identify the EAP server with which it generated keying material. This can make it difficult for the EAP peer to identify the location of a key possessed by that EAP server.
As noted in [RFC5216] Section 5.2, EAP methods supporting authentication using server certificates can determine the Server-Id from the subject or subjectAltName fields in the server certificate. Validating the EAP server identity can help the EAP peer to decide whether a specific EAP server is authorized. In some cases, such as where the certificate extensions defined in [RFC4334] are included in the server certificate, it can even be possible for the peer to verify some channel binding parameters from the server certificate.
As noted in [RFC5216] Section 5.2, EAP methods supporting authentication using server certificates can determine the Server-Id from the subject or subjectAltName fields in the server certificate. Validating the EAP server identity can help the EAP peer to decide whether a specific EAP server is authorized. In some cases, such as where the certificate extensions defined in [RFC4334] are included in the server certificate, it can even be possible for the peer to verify some channel binding parameters from the server certificate.
It is possible for problems to arise in situations where the EAP server identifies itself differently to the EAP peer and authenticator. For example, it is possible that the Server-Id exported by EAP methods will not be identical to the Fully Qualified Domain Name (FQDN) of the backend authentication server. Where certificate-based authentication is used within RADIUS or Diameter, it is possible that the subjectAltName used in the backend authentication server certificate will not be identical to the Server-Id or backend authentication server FQDN. This is not normally an issue in EAP, as the authenticator will be unaware of the identities used between the EAP peer and server. However, this can be an issue for key caching, if the authenticator is expected to locate a backend authentication server corresponding to a Server-Id provided by an EAP peer.
It is possible for problems to arise in situations where the EAP server identifies itself differently to the EAP peer and authenticator. For example, it is possible that the Server-Id exported by EAP methods will not be identical to the Fully Qualified Domain Name (FQDN) of the backend authentication server. Where certificate-based authentication is used within RADIUS or Diameter, it is possible that the subjectAltName used in the backend authentication server certificate will not be identical to the Server-Id or backend authentication server FQDN. This is not normally an issue in EAP, as the authenticator will be unaware of the identities used between the EAP peer and server. However, this can be an issue for key caching, if the authenticator is expected to locate a backend authentication server corresponding to a Server-Id provided by an EAP peer.
Where the backend authentication server FQDN differs from the subjectAltName in the backend authentication server certificate, it is possible that the AAA client will not be able to determine whether it is talking to the correct backend authentication server. Where
AAAのクライアントが、それが正しいバックエンド認証サーバと. どこを話しているかどうか決定できないのが、バックエンド認証サーバFQDNがバックエンド認証サーバ証明書でsubjectAltNameと異なっているのが可能であるところ
Aboba, et al. Standards Track [Page 30] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[30ページ]RFC5247EAP
the Server-Id and backend authentication server FQDN differ, it is possible that the combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP conversation identifier (Session-Id) will not be sufficient to determine where the key resides. For example, the authenticator can identify backend authentication servers by their IP address (as occurs in RADIUS), or using a Fully Qualified Domain Name (as in Diameter). If the Server-Id does not correspond to the IP address or FQDN of a known backend authentication server, then it may not be possible to locate which backend authentication server possesses the key.
キーの組み合わせが見られるのは、Server-イドとバックエンド認証サーバFQDNが異なるのが可能です。(同輩イド、Serverイド(s))、およびEAP会話識別子(セッションイド)は、キーがどこに住んでいるかを決定するために十分ではありません。 例えば、固有識別文字は、それらのIPアドレス(RADIUSに起こるとき)、またはFully Qualified Domain Nameを使用することによって、バックエンド認証サーバを特定できます(Diameterのように)。 Server-イドが知られているバックエンド認証サーバのIPのアドレスかFQDNに対応していないなら、どのバックエンド認証サーバの場所を見つけるかがキーを所有しているのは、可能でないかもしれません。
3. Security Association Management
3. セキュリティ協会管理
EAP, as defined in [RFC3748], supports key derivation, but does not provide for the management of lower-layer security associations. Missing functionality includes:
EAPは[RFC3748]で定義されるように主要な派生をサポートしますが、下層セキュリティ協会の経営に備えません。 なくなった機能性は:
(a) Security Association negotiation. EAP does not negotiate
lower-layer unicast or multicast security associations,
including cryptographic algorithms or traffic profiles. EAP
methods only negotiate cryptographic algorithms for their own
use, not for the underlying lower layers. EAP also does not
negotiate the traffic profiles to be protected with the
negotiated ciphersuites; in some cases the traffic to be
protected can have lower-layer source and destination addresses
different from the lower-layer peer or authenticator addresses.
(a) セキュリティAssociation交渉。 EAPは暗号アルゴリズムかトラフィックプロフィールを含む下層ユニキャストかマルチキャストセキュリティ協会を交渉しません。 EAPメソッドは基本的な下層ではなく、それら自身の使用のための暗号アルゴリズムを交渉するだけです。 EAPも交渉されたciphersuitesで保護されるためにトラフィックプロフィールを交渉しません。 いくつかの場合、保護されるべきトラフィックは下層ソースと下層同輩と異なった送付先アドレスか固有識別文字アドレスを持つことができます。
(b) Re-key. EAP does not support the re-keying of exported EAP
keying material without EAP re-authentication, although EAP
methods can support "fast reconnect" as defined in [RFC3748]
Section 7.2.1.
(b) 再キー。 EAPはEAP再認証なしで材料を合わせるエクスポートしているEAPを再の合わせることをサポートしません、EAPメソッドが[RFC3748]セクション7.2.1で定義されるように「速く再接続してください」をサポートすることができますが。
(c) Key delete/install semantics. EAP does not synchronize
installation or deletion of keying material on the EAP peer and
authenticator.
(c) キーは、意味論を削除するか、またはインストールします。 EAPはEAP同輩と固有識別文字における合わせることの材料のインストールか削除を同時にさせません。
(d) Lifetime negotiation. EAP does not support lifetime negotiation
for exported EAP keying material, and existing EAP methods also
do not support key lifetime negotiation.
(d) 生涯交渉。 EAPは材料を合わせるエクスポートしているEAPのために生涯交渉をサポートしません、そして、既存のEAPメソッドも主要な生涯交渉をサポートしません。
(e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs
can be reused if EAP keying material is cached.
(e) 保証されたTSKの新しさ。 ポスト-EAP握手がなければ、材料を合わせるEAPがキャッシュされるなら、TSKsを再利用できます。
These deficiencies are typically addressed via a post-EAP handshake known as the Secure Association Protocol.
これらの欠乏はSecure Associationプロトコルとして知られているポスト-EAP握手で通常扱われます。
Aboba, et al. Standards Track [Page 31] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[31ページ]RFC5247EAP
3.1. Secure Association Protocol
3.1. 安全な協会プロトコル
Since neither EAP nor EAP methods provide for establishment of lower-layer security associations, it is RECOMMENDED that these facilities be provided within the Secure Association Protocol, including:
EAPもEAPメソッドも下層セキュリティ協会の設立に備えないので、Secure Associationプロトコルの中でこれらの施設を提供するのは、RECOMMENDEDです、である:
(a) Entity Naming. A basic feature of a Secure Association Protocol
is the explicit naming of the parties engaged in the exchange.
Without explicit identification, the parties engaged in the
exchange are not identified and the scope of the EAP keying
parameters negotiated during the EAP exchange is undefined.
(a) 実体命名。 Secure Associationプロトコルに関する基本的特徴は交換に従事しているパーティーの明白な命名です。 明白な識別がなければ、交換に従事しているパーティーは特定されません、そして、EAP交換の間に交渉されたパラメタを合わせるEAPの範囲は未定義です。
(b) Mutual proof of possession of EAP keying material. During the
Secure Association Protocol, the EAP peer and authenticator MUST
demonstrate possession of the keying material transported
between the backend authentication server and authenticator
(e.g., MSK), in order to demonstrate that the peer and
authenticator have been authorized. Since mutual proof of
possession is not the same as mutual authentication, the peer
cannot verify authenticator assertions (including the
authenticator identity) as a result of this exchange.
Authenticator identity verification is discussed in Section 2.3.
(b) EAPの所持が材料を合わせるという互いの証拠。 Secure Associationプロトコルの間、EAP同輩と固有識別文字は材料がバックエンド認証サーバと固有識別文字(例えば、MSK)の間で輸送した合わせることの所有物のデモをしなければなりません、同輩と固有識別文字が権限を与えられたのを示すために。 所有物の互いの証拠が互いの認証と同じでないので、同輩はこの交換の結果、固有識別文字主張(固有識別文字のアイデンティティを含んでいる)について確かめることができません。 セクション2.3で固有識別文字アイデンティティ検証について議論します。
(c) Secure capabilities negotiation. In order to protect against
spoofing during the discovery phase, ensure selection of the
"best" ciphersuite, and protect against forging of negotiated
security parameters, the Secure Association Protocol MUST
support secure capabilities negotiation. This includes the
secure negotiation of usage modes, session parameters (such as
security association identifiers (SAIDs) and key lifetimes),
ciphersuites and required filters, including confirmation of
security-relevant capabilities discovered during phase 0. The
Secure Association Protocol MUST support integrity and replay
protection of all capability negotiation messages.
(c) 能力が交渉であると機密保護してください。 発見段階の間、だまさないように保護して、「最も良い」ciphersuiteの選択を確実にして、交渉されたセキュリティパラメタの鍛造物から守るために、Secure Associationプロトコルは、安全な能力が交渉であるとサポートしなければなりません。 これは用法モード、セッションパラメタ(セキュリティ協会識別子(SAIDs)や主要な生涯などの)、ciphersuites、および必要なフィルタの安全な交渉を含んでいます、段階0の間に発見されたセキュリティ関連している能力の確認を含んでいて。 Secure Associationプロトコルはすべての能力交渉メッセージの保全と反復操作による保護をサポートしなければなりません。
(d) Key naming and selection. Where key caching is supported, it is
possible for the EAP peer and authenticator to share more than
one key of a given type. As a result, the Secure Association
Protocol MUST explicitly name the keys used in the proof of
possession exchange, so as to prevent confusion when more than
one set of keying material could potentially be used as the
basis for the exchange. Use of the key naming mechanism
described in Section 1.4.1 is RECOMMENDED.
(d) 主要な命名と選択。 与えられたタイプの1個以上のキーを共有するEAP同輩と固有識別文字に、それが主要なキャッシュがサポートされるのが可能であるところ。 その結果、Secure Associationプロトコルは明らかに所有物交換の証拠に使用されるキーを命名しなければなりません、交換の基礎として潜在的に材料を合わせる1セット以上を使用できたとき、混乱を防ぐために。 セクション1.4.1で説明された主要な命名メカニズムの使用はRECOMMENDEDです。
In order to support the correct processing of phase 2 security
associations, the Secure Association (phase 2) protocol MUST
support the naming of phase 2 security associations and
そしてSecure Association(フェーズ2)プロトコルがフェーズ2セキュリティ協会の正しい処理をサポートするためにフェーズ2セキュリティ協会の命名をサポートしなければならない。
Aboba, et al. Standards Track [Page 32] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[32ページ]RFC5247EAP
associated transient session keys so that the correct set of
transient session keys can be identified for processing a given
packet. The phase 2 Secure Association Protocol also MUST
support transient session key activation and SHOULD support
deletion so that establishment and re-establishment of transient
session keys can be synchronized between the parties.
与えられたパケットを処理するために正しいセットの一時的なセッションキーを特定できるように一時的なセッションキーを関連づけました。 フェーズ2Secure Associationプロトコルも、一時的なセッションキーの設立と再建がパーティーの間で同時にすることができるように、一時的なセッション主要な起動とSHOULDがサポート削除であるとサポートしなければなりません。
(e) Generation of fresh transient session keys (TSKs). Where the
lower layer supports caching of keying material, the EAP peer
lower layer can initiate a new session using keying material
that was derived in a previous session. Were the TSKs to be
derived solely from a portion of the exported EAP keying
material, this would result in reuse of the session keys that
could expose the underlying ciphersuite to attack.
新鮮な一時的なセッションキー(TSKs)の(e)世代。 下層が、材料、低級層が開始できるEAP同輩を合わせるキャッシュが新しいセッションであると合わせることの材料を使用することでサポートするところでは、それは前のセッションのときに引き出されました。 TSKsが唯一材料を合わせるエクスポートしているEAPの一部から引き出されることになっているなら、これは攻撃するために基本的なciphersuiteを暴露することができたセッションキーの再利用をもたらすでしょうに。
In lower layers where caching of keying material is supported,
the Secure Association Protocol phase is REQUIRED, and MUST
support the derivation of fresh unicast and multicast TSKs, even
when the transported keying material provided by the backend
authentication server is not fresh. This is typically supported
via the exchange of nonces or counters, which are then mixed
with the keying material in order to generate fresh unicast
(phase 2a) and possibly multicast (phase 2b) session keys. By
not using exported EAP keying material directly to protect data,
the Secure Association Protocol protects it against compromise.
合わせることの材料のキャッシュがサポートされる低級層では、Secure Associationプロトコルフェーズは、REQUIREDであり、新鮮なユニキャストとマルチキャストTSKsの派生をサポートしなければなりません、バックエンド認証サーバによって供給された輸送された合わせることの材料が新鮮でないときにさえ。 これは一回だけかカウンタの交換で通常サポートされます。(次に、カウンタは、新鮮なユニキャストを生成するために合わせることの材料に混ぜられます)。(2a)とことによるとマルチキャスト(フェーズ2b)セッションキーの位相を合わせてください。 データを保護するために直接材料を合わせるエクスポートしているEAPを使用しないことによって、Secure Associationプロトコルは感染に対してそれを保護します。
(f) Key lifetime management. This includes explicit key lifetime
negotiation or seamless re-key. EAP does not support the
re-keying of EAP keying material without re-authentication, and
existing EAP methods do not support key lifetime negotiation.
As a result, the Secure Association Protocol MAY handle the
re-key and determination of the key lifetime. Where key caching
is supported, secure negotiation of key lifetimes is
RECOMMENDED. Lower layers that support re-key, but not key
caching, may not require key lifetime negotiation. For example,
a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that
in IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the
SA is responsible for enforcing its own lifetime policy on the
SA and re-keying the SA when necessary.
(f) 主要な生涯管理。 これは明白な主要な生涯交渉かシームレスの再キーを含んでいます。 EAPは再認証なしで材料を合わせるEAPを再の合わせることをサポートしません、そして、既存のEAPメソッドは主要な生涯交渉をサポートしません。 その結果、Secure Associationプロトコルは主要な生涯の再キーと決断を扱うかもしれません。 主要なキャッシュがサポートされて、安全であるところでは、主要な生涯の交渉はRECOMMENDEDです。 主要なキャッシュではなく、再キーを支える下層は主要な生涯交渉を必要としないかもしれません。 例えば、IKEv1[RFC2409]とIKEv2[RFC4306]の違いはIKEv1 SAでは、寿命が交渉されたということです。 IKEv2では、SAのそれぞれの端はそれ自身の生涯方針にSAに押しつけて、必要であるときにSAを再合わせるのに責任があります。
(g) Key state resynchronization. It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions
or all of the key cache. Therefore, key lifetime negotiation
cannot guarantee that the key cache will remain synchronized,
and it may not be possible for the peer to determine before
attempting to use a key whether it exists within the
authenticator cache. It is therefore RECOMMENDED for the EAP
lower layer to provide a mechanism for key state
(g) 主要な州の再同期。 同輩か固有識別文字に、リソースをリブートするか、または取り戻すのが可能です、主要なキャッシュを部分かすべてから取り除いて。 したがって、主要な生涯交渉は、主要なキャッシュが連動したままで残るのを保証できません、そして、同輩が、キーを使用するのを試みる前にそれが固有識別文字キャッシュの中に存在するかどうかと決心しているのは、可能でないかもしれません。 したがって、それはEAPの低級層が主要な状態へのメカニズムを提供するRECOMMENDEDです。
Aboba, et al. Standards Track [Page 33] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[33ページ]RFC5247EAP
resynchronization, either via the SAP or using a lower layer
indication (see [RFC3748] Section 3.4). Where the peer and
authenticator do not jointly possess a key with which to protect
the resynchronization exchange, secure resynchronization is not
possible, and alternatives (such as an initiation of EAP
re-authentication after expiration of a timer) are needed to
ensure timely resynchronization.
SAPか下層指示([RFC3748]セクション3.4を見る)を使用することを通した再同期。 同輩と固有識別文字が共同で、再同期交換を保護するキーを所有していないところでは、安全な再同期は可能ではありません、そして、代替手段(タイマの満了の後のEAP再認証の開始などの)が、タイムリーな再同期を確実にするのに必要です。
(h) Key scope synchronization. To support key scope determination,
the Secure Association Protocol SHOULD provide a mechanism by
which the peer can determine the scope of the key cache on each
authenticator and by which the authenticator can determine the
scope of the key cache on a peer. This includes negotiation of
restrictions on key usage.
(h) 主要な範囲同期。 主要な範囲決断をサポートするために、Secure AssociationプロトコルSHOULDは同輩が各固有識別文字で主要なキャッシュの範囲を決定できて、固有識別文字が同輩の上で主要なキャッシュの範囲を決定できるメカニズムを提供します。 これは主要な用法の制限の交渉を含んでいます。
(i) Traffic profile negotiation. The traffic to be protected by a
lower-layer security association will not necessarily have the
same lower-layer source or destination address as the EAP peer
and authenticator, and it is possible for the peer and
authenticator to negotiate multiple security associations, each
with a different traffic profile. Where this is the case, the
profile of protected traffic SHOULD be explicitly negotiated.
For example, in IKEv2 it is possible for an Initiator and
Responder to utilize EAP for authentication, then negotiate a
Tunnel Mode Security Association (SA), which permits passing of
traffic originating from hosts other than the Initiator and
Responder. Similarly, in IEEE 802.16e, a Subscriber Station
(SS) can forward traffic to the Base Station (BS), which
originates from the Local Area Network (LAN) to which it is
attached. To enable this, Security Associations within IEEE
802.16e are identified by the Connection Identifier (CID), not
by the EAP peer and authenticator MAC addresses. In both IKEv2
and IEEE 802.16e, multiple security associations can exist
between the EAP peer and authenticator, each with their own
traffic profile and quality of service parameters.
(i) トラフィックは交渉の輪郭を描きます。 下層セキュリティ協会によって保護されるべきトラフィックには、EAP同輩と固有識別文字として同じ下層ソースか送付先アドレスが必ずあるというわけではないでしょう、そして、同輩と固有識別文字に、複数のセキュリティ協会を交渉するのは可能です、それぞれ異なったトラフィックプロフィールで。 これがそうであるところでは、交渉されて、保護されたトラフィックSHOULDのプロフィールは明らかにそうです。 例えば、IKEv2では、InitiatorとResponderが認証にEAPを利用して、次に、トンネル・モードSecurity Association(SA)を交渉するのは、可能です。(Security AssociationはトラフィックがInitiatorとResponder以外のホストから発するのを通過するのを可能にします)。 同様に、IEEE 802.16eでは、Subscriber駅(SS)は基地の駅(BS)にトラフィックを送ることができます。(それは、それが付けているローカル・エリア・ネットワーク(LAN)から発します)。 これを可能にするために、IEEE 802.16eの中のSecurity AssociationsはEAP同輩と固有識別文字MACアドレスではなく、Connection Identifier(CID)によって特定されます。 IKEv2とIEEE 802.16eの両方では、複数のセキュリティ協会がEAP同輩と固有識別文字の間に存在できます、それぞれそれら自身のトラフィックプロフィールとサービスの質パラメタで。
(j) Direct operation. Since the phase 2 Secure Association Protocol
is concerned with the establishment of security associations
between the EAP peer and authenticator, including the derivation
of transient session keys, only those parties have "a need to
know" the transient session keys. The Secure Association
Protocol MUST operate directly between the peer and
authenticator and MUST NOT be passed-through to the backend
authentication server or include additional parties.
(j) 操作を指示してください。 以来、それらのパーティーだけには「知る必要性」があることを一時的なセッションキーの派生を含むEAP同輩と固有識別文字とのセキュリティ仲間の設立にフェーズ2Secure Associationプロトコルを心配させます。一時的なセッションキー。 Secure Associationプロトコルは、同輩と固有識別文字の間で直営しなければならなくて、バックエンド認証サーバに通り抜けてはいけませんし、また追加パーティーを含んではいけません。
(k) Bi-directional operation. While some ciphersuites only require
a single set of transient session keys to protect traffic in
both directions, other ciphersuites require a unique set of
(k) 双方向の操作。 いくらかのciphersuitesである間、両方の方向にトラフィックを保護するために一時的なセッションキーを1セットにしか要求しないでください、と他のciphersuitesはユニークなセットを必要とします。
Aboba, et al. Standards Track [Page 34] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[34ページ]RFC5247EAP
transient session keys in each direction. The phase 2 Secure
Association Protocol SHOULD provide for the derivation of
unicast and multicast keys in each direction, so as not to
require two separate phase 2 exchanges in order to create a
bi-directional phase 2 security association. See [RFC3748]
Section 2.4 for more discussion.
各方向への一時的なセッションキー。 フェーズ2Secure AssociationプロトコルSHOULDはユニキャストとマルチキャストキーの派生に各方向に備えます、双方向のフェーズ2セキュリティ協会を創設するために2の別々のフェーズ2交換を必要としないように。 より多くの議論に関して[RFC3748]セクション2.4を見てください。
3.2. Key Scope
3.2. 主要な範囲
Absent explicit specification within the lower layer, after the completion of phase 1b, transported keying material, and parameters are bound to the EAP peer and authenticator, but are not bound to a specific peer or authenticator port.
下層の中の欠けている明白な仕様、1b、輸送された合わせることの材料、およびパラメタは、フェーズの完成の後に、EAP同輩と固有識別文字に縛られますが、特定の同輩か固有識別文字ポートに縛られません。
While EAP keying material passed down to the lower layer is not intrinsically bound to particular authenticator and peer ports, TSKs MAY be bound to particular authenticator and peer ports by the Secure Association Protocol. However, a lower layer MAY also permit TSKs to be used on multiple peer and/or authenticator ports, provided that TSK freshness is guaranteed (such as by keeping replay counter state within the authenticator).
下層まで渡された材料を合わせるEAPが本質的に特定の固有識別文字と同輩ポートに縛られていない間、TSKsはSecure Associationプロトコルによって特定の固有識別文字と同輩ポートに縛られるかもしれません。 しかしながら、また、下層は、TSKsが複数の同輩、そして/または、固有識別文字ポートの上で使用されることを許可するかもしれません、TSKの新しさが保証されていれば(固有識別文字の中に再生カウンタ州を維持などなどの)。
In order to further limit the key scope, the following measures are suggested:
さらに主要な範囲を制限するために、以下の測定は示されます:
(a) The lower layer MAY specify additional restrictions on key
usage, such as limiting the use of EAP keying material and
parameters on the EAP peer to the port over which the EAP
conversation was conducted.
(a) 下層は主要な用法で追加制限を指定するかもしれません、材料とパラメタをEAP同輩に合わせるEAPの使用をEAPの会話が行われたポートに制限するのなどように。
(b) The backend authentication server and authenticator MAY
implement additional attributes in order to further restrict the
scope of keying material. For example, in IEEE 802.11, the
backend authentication server can provide the authenticator with
a list of authorized Called or Calling-Station-Ids and/or SSIDs
for which keying material is valid.
(b) バックエンド認証サーバと固有識別文字は、さらに合わせることの材料の範囲を制限するために追加属性を実装するかもしれません。 例えば、IEEE802.11では、バックエンド認証サーバは材料を合わせるのが有効である認可されたCalledかCalling駅のイド、そして/または、SSIDsのリストを固有識別文字に提供できます。
(c) Where the backend authentication server provides attributes
restricting the key scope, it is RECOMMENDED that restrictions
be securely communicated by the authenticator to the peer. This
can be accomplished using the Secure Association Protocol, but
also can be accomplished via the EAP method or the lower layer.
バックエンド認証サーバが主要な範囲を制限する属性を提供する(c)、制限が同輩への固有識別文字によってしっかりと伝えられるのは、RECOMMENDEDです。 これをSecure Associationプロトコルを使用することで達成できますが、EAPメソッドか下層でまた達成できます。
3.3. Parent-Child Relationships
3.3. 親子関係
When an EAP re-authentication takes place, new EAP keying material is exported by the EAP method. In EAP lower layers where EAP re-authentication eventually results in TSK replacement, the maximum
EAP再認証が行われるとき、材料を合わせる新しいEAPがEAPメソッドでエクスポートされます。 EAP再認証が結局TSK交換、最大をもたらすEAPの低級層で
Aboba, et al. Standards Track [Page 35] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[35ページ]RFC5247EAP
lifetime of derived keying material (including TSKs) can be less than or equal to that of EAP keying material (MSK/EMSK), but it cannot be greater.
誘導合わせることの材料(TSKsを含んでいる)の寿命はEAP合わせることの材料の、よりもの以下であるかもしれません(MSK/EMSK)が、それは、よりすばらしいはずがありません。
Where TSKs are derived from or are wrapped by exported EAP keying material, compromise of that exported EAP keying material implies compromise of TSKs. Therefore, if EAP keying material is considered stale, not only SHOULD EAP re-authentication be initiated, but also replacement of child keys, including TSKs.
材料を合わせるEAP、材料を合わせるエクスポートしているEAPがTSKsで妥協するのを含意するその感染であるとエクスポートされて、TSKsを派生するか、または包装します。 しかし、SHOULD EAP再認証しないだけ、そして開始されてください。したがって、材料を合わせるEAPが考えられるなら古くさくなってください、子供キー(含んでいるTSKs)の交換も。
Where EAP keying material is used only for entity authentication but not for TSK derivation (as in IKEv2), compromise of exported EAP keying material does not imply compromise of the TSKs. Nevertheless, the compromise of EAP keying material could enable an attacker to impersonate an authenticator, so that EAP re-authentication and TSK re-key are RECOMMENDED.
材料を合わせるEAPが実体認証にだけ使用されますが、TSK派生に使用されるというわけではないところでは(IKEv2のように)、材料を合わせるエクスポートしているEAPの感染はTSKsの感染を含意しません。 それにもかかわらず、材料を合わせるEAPの感染が、攻撃者が固有識別文字をまねるのを可能にするかもしれないので、そのEAP再認証とTSK再キーはRECOMMENDEDです。
With respect to IKEv2, Section 5.2 of [RFC4718], "IKEv2 Clarifications and Implementation Guidelines", states:
IKEv2に関して、「IKEv2明確化と実施要綱」という[RFC4718]のセクション5.2は以下を述べます。
Rekeying the IKE_SA and reauthentication are different concepts in
IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA
and resets the Message ID counters, but it does not authenticate
the parties again (no AUTH or EAP payloads are involved)... This
means that reauthentication also establishes new keys for the
IKE_SA and CHILD_SAs. Therefore while rekeying can be performed
more often than reauthentication, the situation where
"authentication lifetime" is shorter than "key lifetime" does not
make sense.
IKE_SAをRekeyingして、再認証はIKEv2の異なった概念です。 IKE_SAをRekeyingすると、新しいキーがIKE_SAのために設立されて、Message IDカウンタはリセットされますが、再びパーティーを認証しません(どんなAUTHもEAPペイロードもかかわりません)… これは、また、再認証がIKE_SAとCHILD_SAsのために新しいキーを設立することを意味します。 したがって、再認証よりしばしば「再-合わせ」ることを実行できる間、「認証生涯」が「主要な生涯」より短い状況は理解できません。
Child keys that are used frequently (such as TSKs that are used for traffic protection) can expire sooner than the exported EAP keying material on which they are dependent, so that it is advantageous to support re-key of child keys prior to EAP re-authentication. Note that deletion of the MSK/EMSK does not necessarily imply deletion of TSKs or child keys.
頻繁に使用される子供キー(トラフィック保護に使用されるTSKsなどの)はそれらが依存している材料を合わせるエクスポートしているEAPより早く期限が切れることができます、EAP再認証の前に子供キーの再キーを支えるのが有利であるように。 MSK/EMSKの削除が必ずTSKsか子供キーの削除を含意するというわけではないことに注意してください。
Failure to mutually prove possession of exported EAP keying material during the Secure Association Protocol exchange need not be grounds for deletion of keying material by both parties; rate-limiting Secure Association Protocol exchanges could be used to prevent a brute force attack.
互いにSecure Associationプロトコル交換の間に材料を合わせるエクスポートしているEAPの所持を立証しないことは双方による合わせることの材料の削除の根拠である必要はありません。 ブルートフォースアタックを防ぐのにレートを制限するSecure Associationプロトコル交換は使用できました。
Aboba, et al. Standards Track [Page 36] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[36ページ]RFC5247EAP
3.4. Local Key Lifetimes
3.4. 地方の主要な生涯
The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. TEKs are typically created during an EAP conversation, used until the end of the conversation and then discarded. However, methods can re-key TEKs during an EAP conversation.
Transient EAPキーズ(TEKs)はEAPの会話を保護するのに使用されるセッションキーです。 TEKsはEAPメソッドに内部であり、エクスポートされません。 TEKsはEAPの会話の間、通常作成されて、会話の終わりまで使用されて、次に、捨てられます。 しかしながら、メソッドはEAPの会話の間の再主要なTEKsをそうすることができます。
When using TEKs within an EAP conversation or across conversations, it is necessary to ensure that replay protection and key separation requirements are fulfilled. For instance, if a replay counter is used, TEK re-key MUST occur prior to wrapping of the counter. Similarly, TSKs MUST remain cryptographically separate from TEKs despite TEK re-keying or caching. This prevents TEK compromise from leading directly to compromise of the TSKs and vice versa.
EAPの会話以内か会話の向こう側にTEKsを使用するとき、反復操作による保護と主要な分離要件が実現するのを保証するのが必要です。 例えば、再生カウンタが使用されているなら、TEK再キーはカウンタのラッピングの前に現れなければなりません。 同様に、暗号でTEK再の合わせますが、TEKsから分離するか、またはキャッシュして、TSKsは残らなければなりません。 これは、TEK感染が逆もまた同様に直接TSKsの感染につながるのを防ぎます。
EAP methods MAY cache local EAP keying material (TEKs) that can persist for multiple EAP conversations when fast reconnect is used [RFC3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC5216]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local EAP keying material calculated within the EAP method is defined by the method. Note that in general, when using fast reconnect, there is no guarantee that the original long-term credentials are still in the possession of the peer. For instance, a smart-card holding the private key for EAP-TLS may have been removed. EAP servers SHOULD also verify that the long-term credentials are still valid, such as by checking that certificate used in the original authentication has not yet expired.
速いときに、複数のEAPの会話が再接続されるので、持続できる材料(TEKs)を合わせるEAPメソッド5月のキャッシュの地方のEAPは使用されています[RFC3748]。 例えば、TLS(EAP-TLS[RFC5216]などの)に基づくEAPメソッドは、TLS Master Secretを引き出して、キャッシュします、通常かなりの期間に。 EAPメソッドの中で計算された材料を合わせる他の地方のEAPの寿命はメソッドで定義されます。 速く使用するときには一般に、再接続してください、オリジナルの長期の資格証明書がまだ同輩の所有物にあるという保証が全くないことに注意してください。 例えば、EAP-TLSのための秘密鍵を保持するスマートカードを取り除いたかもしれません。 また、EAPサーバSHOULDは、長期の資格証明書がまだ有効であることを確かめます、オリジナルの認証に使用される証明書がまだ期限が切れていないのをチェックするのなどように。
3.5. Exported and Calculated Key Lifetimes
3.5. エクスポートしていて計算された主要な生涯
The following mechanisms are available for communicating the lifetime of keying material between the EAP peer, server, and authenticator:
以下のメカニズムはEAP同輩と、サーバと、固有識別文字の間の材料を合わせる生涯を伝えるのに利用可能です:
AAA protocols (backend authentication server and authenticator)
Lower-layer mechanisms (authenticator and peer)
EAP method-specific negotiation (peer and server)
AAAプロトコル(バックエンド認証サーバと固有識別文字)下層メカニズム(固有識別文字と同輩)のEAPのメソッド特有の交渉(同輩とサーバ)
Where the EAP method does not support the negotiation of the lifetime of exported EAP keying material, and a key lifetime negotiation mechanism is not provided by the lower layer, it is possible that there will not be a way for the peer to learn the lifetime of keying material. This can leave the peer uncertain of how long the authenticator will maintain keying material within the key cache. In this case the lifetime of keying material can be managed as a system parameter on the peer and authenticator; a default lifetime of 8 hours is RECOMMENDED.
同輩が材料を合わせる生涯を学ぶ方法がないのは、EAPメソッドがどこでエクスポートしているEAPの生涯の交渉が材料を合わせて、主要な生涯交渉メカニズムであるとサポートしないか下層によって提供されないのが可能です。 これは同輩を固有識別文字がどれくらい長い間主要なキャッシュの中で物質的に合わせることを維持するかに不確実なままにできます。 この場合、同輩と固有識別文字に関するシステム・パラメータとして材料を合わせる生涯に対処できます。 aはデフォルトとします。8時間の寿命はRECOMMENDEDです。
Aboba, et al. Standards Track [Page 37] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[37ページ]RFC5247EAP
3.5.1. AAA Protocols
3.5.1. AAAプロトコル
AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be used to communicate the maximum key lifetime from the backend authentication server to the authenticator.
最大の主要なバックエンド認証サーバから固有識別文字までの生涯を伝えるのにRADIUS[RFC2865]やDiameter[RFC4072]などのAAAプロトコルを使用できます。
The Session-Timeout Attribute is defined for RADIUS in [RFC2865] and for Diameter in [RFC4005]. Where EAP is used for authentication, [RFC3580] Section 3.17, indicates that a Session-Timeout Attribute sent in an Access-Accept along with a Termination-Action value of RADIUS-Request specifies the maximum number of seconds of service provided prior to EAP re-authentication.
Session-タイムアウトAttributeは[RFC2865]のRADIUSと[RFC4005]のDiameterのために定義されます。 RADIUS-要求のTermination-動作値と共にAccess受け入れてください。EAPが認証、[RFC3580]セクション3.17に使用されるところでは、送られたそのa Session-タイムアウトAttributeが示す、EAP再認証の前に提供された秒のサービスの最大数を指定します。
However, there is also a need to be able to specify the maximum lifetime of cached keying material. Where EAP pre-authentication is supported, cached keying material can be pre-established on the authenticator prior to session start and will remain there until expiration. EAP lower layers supporting caching of keying material MAY also persist that material after the end of a session, enabling the peer to subsequently resume communication utilizing the cached keying material. In these situations it can be desirable for the backend authentication server to specify the maximum lifetime of cached keying material.
しかしながら、また、キャッシュされた合わせることの材料の最大の生涯を指定できる必要があります。 EAPプレ認証がサポートされるところでは、キャッシュされた合わせることの材料は、セッション始めの前に固有識別文字であらかじめ確立できて、そこに満了まで留まるでしょう。 また、合わせることの材料のキャッシュをサポートするEAPの低級層はセッションの終わりの後にその材料を固持するかもしれません、同輩が次に材料を合わせながらキャッシュを利用するコミュニケーションを再開するのを可能にして。 これらの状況で、バックエンド認証サーバがキャッシュされた合わせることの材料の最大の生涯を指定するのは、望ましい場合があります。
To accomplish this, [IEEE-802.11] overloads the Session-Timeout Attribute, assuming that it represents the maximum time after which transported keying material will expire on the authenticator, regardless of whether transported keying material is cached.
これを達成するために、[IEEE-802.11]はSession-タイムアウトAttributeを積みすぎます、どれが合わせることの材料を輸送したかが固有識別文字で期限が切れた後に最大の時間を表すと仮定して、輸送された合わせることの材料がキャッシュされるかどうかにかかわらず。
An IEEE 802.11 authenticator receiving transported keying material is expected to initialize a timer to the Session-Timeout value, and once the timer expires, the transported keying material expires. Whether this results in session termination or EAP re-authentication is controlled by the value of the Termination-Action Attribute. Where EAP re-authentication occurs, the transported keying material is replaced, and with it, new calculated keys are put in place. Where session termination occurs, transported and derived keying material is deleted.
材料を合わせる受信が輸送したIEEE802.11固有識別文字がSession-タイムアウト値にタイマを初期化すると予想されて、タイマがいったん期限が切れると、輸送された合わせることの材料は期限が切れます。 これがセッション終了かEAP再認証をもたらすかどうかがTermination-動作Attributeの値によって制御されます。 EAP再認証が起こるところと、輸送された合わせることの材料を取り替えます、そして、それで、新しい計算されたキーを適所に置きます。 セッション終了が起こるところでは、輸送されて誘導された合わせることの材料は削除されます。
Overloading the Session-Timeout Attribute is problematic in situations where it is necessary to control the maximum session time and key lifetime independently. For example, it might be desirable to limit the lifetime of cached keying material to 5 minutes while permitting a user once authenticated to remain connected for up to an hour without re-authenticating. As a result, in the future, additional attributes can be specified to control the lifetime of cached keys; these attributes MAY modify the meaning of the Session-Timeout Attribute in specific circumstances.
Session-タイムアウトAttributeを積みすぎるのは独自に最大のセッション時間と主要な生涯を制御するのが必要であるところで状況で問題が多いです。 例えば、キャッシュされた合わせることの生涯を制限するために、一度認証されたユーザが残っているのを許容している間、5分までの材料が再認証のない1時間まで接続したのは、望ましいかもしれません。 その結果と、将来、キャッシュされたキーの生涯を制御するために追加属性を指定できます。 これらの属性は特定の事情のSession-タイムアウトAttributeの意味を変更するかもしれません。
Aboba, et al. Standards Track [Page 38] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[38ページ]RFC5247EAP
Since the TSK lifetime is often determined by authenticator resources, and the backend authentication server has no insight into the TSK derivation process by the principle of ciphersuite independence, it is not appropriate for the backend authentication server to manage any aspect of the TSK derivation process, including the TSK lifetime.
TSK寿命がしばしば固有識別文字リソースで決定して、バックエンド認証サーバがciphersuite独立の原則でTSK派生プロセスに洞察力を全く持っていないので、バックエンド認証サーバがTSK派生プロセスのどんな局面も管理するのは、適切ではありません、TSK生涯を含んでいて。
3.5.2. Lower-Layer Mechanisms
3.5.2. 下層メカニズム
Lower-layer mechanisms can be used to enable the lifetime of keying material to be negotiated between the peer and authenticator. This can be accomplished either using the Secure Association Protocol or within the lower-layer transport.
材料を合わせる寿命が同輩と固有識別文字の間で交渉されるのを可能にするのに下層メカニズムを使用できます。 Secure Associationプロトコルを使用することで達成されるか、下層輸送の中にこれはあることができます。
Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include support for TSK re-key. Where the TSK is taken directly from the MSK, there is no need to manage the TSK lifetime as a separate parameter, since the TSK lifetime and MSK lifetime are identical.
TSKsがSecure Associationプロトコル交換の結果と書き立てられるところでは、Secure AssociationプロトコルがTSK再キーのサポートを含んでいるのは、RECOMMENDEDです。 TSKが直接MSKから取られるところには、別々のパラメタとしてTSK生涯を管理する必要は全くありません、TSK生涯とMSK寿命が同じであるので。
3.5.3. EAP Method-Specific Negotiation
3.5.3. EAPのメソッド特有の交渉
As noted in [RFC3748] Section 7.10:
[RFC3748]セクション7.10に述べられるように:
In order to provide keying material for use in a subsequently
negotiated ciphersuite, an EAP method supporting key derivation
MUST export a Master Session Key (MSK) of at least 64 octets, and
an Extended Master Session Key (EMSK) of at least 64 octets. EAP
Methods deriving keys MUST provide for mutual authentication
between the EAP peer and the EAP Server.
次に交渉されたciphersuiteにおける使用のための材料を合わせながら提供するために、主要な派生をサポートするEAPメソッドは少なくとも64の八重奏のMaster Session Key(MSK)、および少なくとも64の八重奏のExtended Master Session Key(EMSK)をエクスポートしなければなりません。 キーを引き出すEAP MethodsはEAP同輩とEAP Serverの間の互いの認証に備えなければなりません。
However, EAP does not itself support the negotiation of lifetimes for exported EAP keying material such as the MSK, EMSK, and IV.
しかしながら、EAPは、エクスポートしているEAPのためにMSKや、EMSKや、IVなどの材料を合わせながら、どんなサポート自体にも生涯の交渉をしません。
While EAP itself does not support lifetime negotiation, it would be possible to specify methods that do. However, systems that rely on key lifetime negotiation within EAP methods would only function with these methods. Also, there is no guarantee that the key lifetime negotiated within the EAP method would be compatible with backend authentication server policy. In the interest of method independence and compatibility with backend authentication server implementations, management of the lifetime of keying material SHOULD NOT be provided within EAP methods.
EAP自身は生涯交渉をサポートしませんが、そうするメソッドを指定するのは可能でしょう。 しかしながら、EAPメソッドの中で主要な生涯交渉に依存するシステムはこれらのメソッドで機能するだけでしょう。 また、EAPメソッドの中で交渉された主要な寿命はバックエンド認証サーバ方針と互換性があるだろうという保証が全くありません。 メソッド独立とバックエンド認証サーバ実装との互換性、材料SHOULD NOTを合わせる生涯の管理のために、EAPメソッドの中で提供してください。
Aboba, et al. Standards Track [Page 39] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[39ページ]RFC5247EAP
3.6. Key Cache Synchronization
3.6. 主要なキャッシュ同期
Key lifetime negotiation alone cannot guarantee key cache synchronization. Even where a lower-layer exchange is run immediately after EAP in order to determine the lifetime of keying material, it is still possible for the authenticator to purge all or part of the key cache prematurely (e.g., due to reboot or need to reclaim memory).
主要な生涯交渉だけが主要なキャッシュ同期を保証できません。 下層交換がEAP直後材料を合わせる生涯を決定するために実行さえされるところで、固有識別文字が早まって(例えば、リブートするか、またはメモリを取り戻すのが必要である)すべてか部分から主要なキャッシュを清めるのは、まだ可能です。
The lower layer can utilize the Discovery phase 0 to improve key cache synchronization. For example, if the authenticator manages the key cache by deleting the oldest key first, the relative creation time of the last key to be deleted could be advertised within the Discovery phase, enabling the peer to determine whether keying material had been prematurely expired from the authenticator key cache.
下層は、主要なキャッシュ同期を改良するのにディスカバリーフェーズ0を利用できます。 例えば、固有識別文字が最初に最も古いキーを削除することによって主要なキャッシュを管理するなら、ディスカバリーフェーズの中に最後のキーが削除される相対的な作成時間の広告を出すかもしれません、同輩が、材料を合わせるのが早まって固有識別文字の主要なキャッシュから吐き出されていたかどうかと決心しているのを可能にして。
3.7. Key Strength
3.7. 主要な強さ
As noted in Section 2.1, EAP lower layers determine TSKs in different ways. Where exported EAP keying material is utilized in the derivation, encryption or authentication of TSKs, it is possible for EAP key generation to represent the weakest link.
セクション2.1に述べられるように、EAPの低級層は異なった方法でTSKsを決定します。 材料を合わせるエクスポートしているEAPがTSKsの派生、暗号化または認証で利用されるところでは、EAPキー生成が最も弱いリンクを表すのは、可能です。
In order to ensure that methods produce EAP keying material of an appropriate symmetric key strength, it is RECOMMENDED that EAP methods utilizing public key cryptography choose a public key that has a cryptographic strength providing the required level of attack resistance. This is typically provided by configuring EAP methods, since there is no coordination between the lower layer and EAP method with respect to minimum required symmetric key strength.
メソッドが適切な対称鍵の強さの材料を合わせながらEAPを生産するのを確実にするために、公開鍵暗号を利用するEAPメソッドが必要なレベルの攻撃抵抗を提供する暗号の力を持っている公開鍵を選ぶのは、RECOMMENDEDです。 EAPメソッドを構成することによって、これを通常提供します、下層とEAPメソッドの間には、最小の必要な対称鍵の強さに関してコーディネートが全くないので。
Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
BCP86[RFC3766]のセクション5はビットの必要なRSAかDHモジュールとDSAサブグループサイズでアドバイスします、ビットにおける、与えられたレベルの攻撃抵抗のために。 また、StandardsとTechnology(NIST)のためのNational Instituteは[SP800-57]の適切な主要なサイズでアドバイスします。
Aboba, et al. Standards Track [Page 40] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[40ページ]RFC5247EAP
3.8. Key Wrap
3.8. 主要な包装
The key wrap specified in [RFC2548], which is based on an MD5-based stream cipher, has known problems, as described in [RFC3579] Section 4.3. RADIUS uses the shared secret for multiple purposes, including per-packet authentication and attribute hiding, considerable information is exposed about the shared secret with each packet. This exposes the shared secret to dictionary attacks. MD5 is used both to compute the RADIUS Response Authenticator and the Message-Authenticator Attribute, and concerns exist relating to the security of this hash [MD5Collision].
MD5ベースのストリーム暗号に基づいている[RFC2548]で指定された主要な包装は既知の問題を持っています、[RFC3579]セクション4.3で説明されるように。 RADIUSは複数の目的に共有秘密キーを使用します、1パケットあたりの認証と属性隠れることを含んでいてかなりの情報が各パケットで共有秘密キーに関して暴露されます。 これは辞書攻撃に共有秘密キーを暴露します。 MD5はともにRADIUS Response AuthenticatorとMessage-固有識別文字Attributeを計算するのに使用されます、そして、関心は、このハッシュ[MD5Collision]のセキュリティに関連しながら、存在しています。
As discussed in [RFC3579] Section 4.3, the security vulnerabilities of RADIUS are extensive, and therefore development of an alternative key wrap technique based on the RADIUS shared secret would not substantially improve security. As a result, [RFC3579] Section 4.2 recommends running RADIUS over IPsec. The same approach is taken in Diameter EAP [RFC4072], which in Section 4.1.3 defines the EAP-Master-Session-Key Attribute-Value Pair (AVP) in clear-text, to be protected by IPsec or TLS.
[RFC3579]セクション4.3で論じられるように、RADIUSのセキュリティの脆弱性は大規模です、そして、したがって、RADIUS共有秘密キーに基づく代替の主要な包装のテクニックの開発はセキュリティを実質的に向上させないでしょう。 その結果、[RFC3579]セクション4.2は、IPsecの上にRADIUSを実行することを勧めます。 同じアプローチは中に入れているDiameter EAP[RFC4072]です。(IPsecかTLSによって保護されるように、そのDiameter EAPはセクション4.1.3でEAPマスターセッションキーAttribute-値のPair(AVP)をクリアテキストで定義します)。
4. Handoff Vulnerabilities
4. 移管脆弱性
A handoff occurs when an EAP peer moves to a new authenticator. Several mechanisms have been proposed for reducing handoff latency within networks utilizing EAP. These include:
EAP同輩が新しい固有識別文字に移行すると、移管は起こります。 数個のメカニズムが、EAPを利用するネットワークの中で移管レイテンシを減少させるために提案されました。 これらは:
EAP pre-authentication
In EAP pre-authentication, an EAP peer pre-establishes EAP keying
material with an authenticator prior to arrival. EAP
pre-authentication only affects the timing of EAP authentication,
but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
exchanges; Discovery (phase 0) and Secure Association Protocol
(phase 2) exchanges occur as described in Section 1.3. As a
result, the primary benefit is to enable EAP authentication to be
removed from the handoff critical path, thereby reducing latency.
Use of EAP pre-authentication within IEEE 802.11 is described in
[IEEE-802.11] and [8021XPreAuth].
EAPプレ認証In EAPプレ認証、EAP同輩は到着の前の固有識別文字で材料を合わせるEAPをあらかじめ設立します。 EAPプレ認証はEAP認証のタイミングに影響するだけです、EAPを短くしないか、または排除しませんが。(1a)かAAA(フェーズ1b)交換の位相を合わせてください。 発見(フェーズ0)とSecure Associationプロトコル(フェーズ2)交換はセクション1.3で説明されるように起こります。 その結果、主要便益はEAP認証が移管クリティカルパスから取り除かれるのを可能にすることです、その結果、レイテンシを減少させます。 IEEE802.11の中のEAPプレ認証の使用は[IEEE-802.11]と[8021XPreAuth]で説明されます。
Aboba, et al. Standards Track [Page 41] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[41ページ]RFC5247EAP
Proactive key distribution
In proactive key distribution, keying material and authorizations
are transported from the backend authentication server to a
candidate authenticator in advance of a handoff. As a result, EAP
(phase 1a) is not needed, but the Discovery (phase 0), and Secure
Association Protocol exchanges (phase 2) are still necessary.
Within the AAA exchange (phase 1b), authorization and key
distribution functions are typically supported, but not
authentication. Proactive key distribution is described in
[MishraPro], [IEEE-03-084], and [HANDOFF].
先を見越す主要な分配In先を見越す主要な分配、材料を合わせて、承認は移管の前にバックエンド認証サーバから候補固有識別文字まで輸送されます。 EAP、aとして、なってください。(フェーズ1a)は必要でなく、唯一のディスカバリーは(フェーズ0)です、そして、Secure Associationプロトコル交換(フェーズ2)がまだ必要です。 AAAの中では、認証ではなく、機能が通常サポートされる(フェーズ1b)、承認、および主要な分配を交換してください。 先を見越す主要な分配は[MishraPro]、[IEEE-03-084]、および[HANDOFF]で説明されます。
Key caching
Caching of EAP keying material enables an EAP peer to re-attach to
an authenticator without requiring EAP (phase 1a) or AAA (phase
1b) exchanges. However, Discovery (phase 0) and Secure
Association Protocol (phase 2) exchanges are still needed. Use of
key caching within IEEE 802.11 is described in [IEEE-802.11].
材料を合わせるEAPの主要なキャッシュしているCachingは、EAP同輩がEAPを必要としないで固有識別文字に再付くのを可能にします。(フェーズ1a)かAAA(フェーズ1b)が交換します。 しかしながら、ディスカバリー(フェーズ0)とSecure Associationプロトコル(フェーズ2)交換がまだ必要です。 IEEE802.11の中の主要なキャッシュの使用は[IEEE-802.11]で説明されます。
Context transfer
In context transfer schemes, keying material and authorizations
are transferred between a previous authenticator and a new
authenticator. This can occur in response to a handoff request by
the EAP peer, or in advance, as in proactive key distribution. As
a result, EAP (phase 1a) is eliminated, but not the Discovery
(phase 0) or Secure Association Protocol exchanges (phase 2). If
a secure channel can be established between the new and previous
authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated;
otherwise, it is still needed, although it can be shortened.
Context transfer protocols are described in [IEEE-802.11F] (now
deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067].
"Fast Authentication Methods for Handovers between IEEE 802.11
Wireless LANs" [Bargh] analyzes fast handoff techniques, including
context transfer mechanisms.
文脈転送In文脈転送体系、材料を合わせて、および承認を前の固有識別文字と新しい固有識別文字の間に移します。 これはあらかじめEAP同輩による移管要求に対応して起こることができます、先を見越す主要な分配のように。 EAP、aとして、なってください。(フェーズ1a)は排除されますが、いずれのディスカバリー(フェーズ0)もSecure Associationプロトコルも(フェーズ2)を交換しません。 新しく前の固有識別文字の間でバックエンド認証サーバから支援なしで安全なチャンネルを確立できるなら、AAA交換(フェーズ1b)を排除できます。 さもなければ、それを短くすることができますが、それがまだ必要です。 文脈転送プロトコルは[IEEE-802.11F]で説明されます、そして、(現在推奨しない)「文脈転送は(CXTP)について議定書の中で述べる」[RFC4067]。 「IEEE802.11Wireless LANの間のHandoversのための速いAuthentication Methods」[Bargh]は文脈トランスファ・メカニズムを含む速い移管のテクニックを分析します。
Aboba, et al. Standards Track [Page 42] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[42ページ]RFC5247EAP
Token distribution
In token distribution schemes, the EAP peer is provided with a
credential, subsequently enabling it to authenticate with one or
more additional authenticators. During the subsequent
authentications, EAP (phase 1a) is eliminated or shortened; the
Discovery (phase 0) and Secure Association Protocol exchanges
(phase 2) still occur, although the latter can be shortened. If
the token includes authorizations and can be validated by an
authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated;
otherwise, it is still needed, although it can be shortened.
Token-based schemes, initially proposed in early versions of IEEE
802.11i [IEEE-802.11i], are described in [Token], [Tokenk], and
[SHORT-TERM].
トークン分配Inトークン分配体系、EAP同輩に資格証明書を提供します、次に1以上で追加固有識別文字を認証するのを可能にして。 その後の認証、EAP、(フェーズ1a)は排除されるか、または短くされます。 後者を短くすることができますが、ディスカバリー(フェーズ0)とSecure Associationプロトコル交換(フェーズ2)はまだ起こっています。 トークンを承認を含んで、固有識別文字でバックエンド認証サーバから支援なしで有効にすることができるなら、AAA交換(フェーズ1b)を排除できます。 さもなければ、それを短くすることができますが、それがまだ必要です。 トークンベースの初めはIEEE 802.11i[IEEE-802.11i]の早めのバージョンで提案された体系は[トークン]、[Tokenk]、および[SHORT-TERM]で説明されます。
The sections that follow discuss the security vulnerabilities introduced by the above schemes.
従うセクションは上の体系によって導入されたセキュリティの脆弱性について論じます。
4.1. EAP Pre-Authentication
4.1. EAPプレ認証
EAP pre-authentication differs from a normal EAP conversation primarily with respect to the lower-layer encapsulation. For example, in [IEEE-802.11], EAP pre-authentication frames utilize a distinct Ethertype, but otherwise conforms to the encapsulation described in [IEEE-802.1X]. As a result, an EAP pre-authentication conversation differs little from the model described in Section 1.3, other than the introduction of a delay between phase 1 and phase 2.
EAPプレ認証は主として下層カプセル化に関して通常のEAPの会話と異なっています。 例えば、[IEEE-802.11]では、EAPプレ認証フレームは、異なったEthertypeを利用しますが、そうでなければ、[IEEE-802.1X]で説明されたカプセル化に一致しています。 その結果、EAPプレ認証の会話は少ししかフェーズ1とフェーズ2の間の遅れの導入以外のセクション1.3で説明されたモデルと異なっていません。
EAP pre-authentication relies on lower-layer mechanisms for discovery of candidate authenticators. Where discovery can provide information on candidate authenticators outside the immediate listening range, and the peer can determine whether it already possesses valid EAP keying material with candidate authenticators, the peer can avoid unnecessary EAP pre-authentications and can establish EAP keying material well in advance, regardless of the coverage overlap between authenticators. However, if the peer can only discover candidate authenticators within listening range and cannot determine whether it can reuse existing EAP keying material, then it is possible that the peer will not be able to complete EAP pre-authentication prior to connectivity loss or that it can pre-authenticate multiple times with the same authenticator, increasing backend authentication server load.
EAPプレ認証は候補固有識別文字の発見のために下層メカニズムを当てにします。 発見が即座の聴取範囲の外の候補固有識別文字の情報を前提とすることができて、同輩が、それが既に候補固有識別文字がある材料を合わせる有効なEAPを所有するかどうかと決心できるところでは、同輩は、不要なEAPプレ認証を避けることができて、あらかじめ材料をよく合わせるEAPを設立できます、固有識別文字の間の適用範囲オーバラップにかかわらず。 しかしながら、同輩が、聴取の中の候補固有識別文字が及ぶと発見できるだけであって、それが材料を合わせる既存のEAPを再利用できるかどうかと決心できないなら、同輩が接続性の損失の前にEAPプレ認証を終了できませんし、また同じ固有識別文字がある複数の回をあらかじめまたは認証できるのが、可能です、バックエンド認証サーバ負荷を増強して。
Since a peer can complete EAP pre-authentication with an authenticator without eventually attaching to it, it is possible that phase 2 will not occur. In this case, an Accounting-Request signifying the start of service will not be sent, or will only be sent with a substantial delay after the completion of authentication.
同輩が固有識別文字で結局それに付かないでEAPプレ認証を終了できるので、フェーズ2が起こらないのは、可能です。 この場合、サービスの始まりを意味するAccounting-要求を、送らないか、または認証の完成の後にかなりの遅れと共に送るだけでしょう。
Aboba, et al. Standards Track [Page 43] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[43ページ]RFC5247EAP
As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA exchange resulting from EAP pre-authentication differs little from an ordinary exchange described in "RADIUS Support for EAP" [RFC3579]. For example, since in IEEE 802.11 [IEEE-802.11] an Association exchange does not occur prior to EAP pre-authentication, the SSID is not known by the authenticator at authentication time, so that an Access-Request cannot include the SSID within the Called-Station-Id attribute as described in [RFC3580] Section 3.20.
「IEEE 802.1X RADIUS用法ガイドライン」[RFC3580]に述べられるように、EAPプレ認証から生じるAAA交換は少ししか「EAPの半径サポート」[RFC3579]で説明された普通の交換と異なっていません。 例えば、Association交換がEAPプレ認証の前にIEEE802.11[IEEE-802.11]に起こらないので、SSIDは認証時に固有識別文字が知られていません、Access-要求が[RFC3580]セクション3.20で説明されるようにCalled駅のイド属性の中にSSIDを含むことができないように。
Since only the absence of an SSID in the Called-Station-Id attribute distinguishes an EAP pre-authentication attempt, if the authenticator does not always include the SSID for a normal EAP authentication attempt, it is possible that the backend authentication server will not be able to determine whether a session constitutes an EAP pre-authentication attempt, potentially resulting in authorization or accounting problems. Where the number of simultaneous sessions is limited, the backend authentication server can refuse to authorize a valid EAP pre-authentication attempt or can enable the peer to engage in more simultaneous sessions than they are authorized for. Where EAP pre-authentication occurs with an authenticator which the peer never attaches to, it is possible that the backend accounting server will not be able to determine whether the absence of an Accounting-Request was due to packet loss or a session that never started.
以来、Called駅のイド属性が、SSIDの不在だけがEAPプレ認証試みを区別します; 固有識別文字がいつも通常のEAP認証試みのためのSSIDを含んでいるというわけではないなら、バックエンド認証サーバが、セッションがEAPプレ認証試みを構成するかどうか決定できないのは、可能です、潜在的に承認か会計問題をもたらして; 同時のセッションの数が限られているところでは、バックエンド認証サーバは、有効なEAPプレ認証試みを認可するのを拒否できるか、または同輩がそれらが認可されるより同時のセッションに従事するのを可能にすることができます。 EAPプレ認証が同輩が決して付かない固有識別文字で起こるところでは、バックエンド会計サーバが、Accounting-要求の欠如がパケット損失のためでしたかそれともセッションが決して出発しなかったかを決定できないのは、可能です。
In order to enable pre-authentication requests to be handled more reliably, it is RECOMMENDED that AAA protocols explicitly identify EAP pre-authentication. In order to suppress unnecessary EAP pre-authentication exchanges, it is RECOMMENDED that authenticators unambiguously identify themselves as described in Section 2.3.
より確かに扱われるというプレ認証要求を可能にするために、AAAプロトコルが明らかにEAPプレ認証を特定するのは、RECOMMENDEDです。 不要なEAPプレ認証交換を抑圧するために、固有識別文字がセクション2.3で説明されるように明白に自分たちを特定するのは、RECOMMENDEDです。
4.2. Proactive Key Distribution
4.2. 先を見越す主要な分配
In proactive key distribution schemes, the backend authentication server transports keying material and authorizations to an authenticator in advance of the arrival of the peer. The authenticators selected to receive the transported key material are selected based on past patterns of peer movement between authenticators known as the "neighbor graph". In order to reduce handoff latency, proactive key distribution schemes typically only demonstrate proof of possession of transported keying material between the EAP peer and authenticator. During a handoff, the backend authentication server is not provided with proof that the peer successfully authenticated to an authenticator; instead, the authenticator generates a stream of accounting messages without a corresponding set of authentication exchanges. As described in [MishraPro], knowledge of the neighbor graph can be established via static configuration or analysis of authentication exchanges. In
先を見越す主要な分配体系では、バックエンド認証サーバは同輩の到着の前に材料を合わせて、承認を固有識別文字に輸送します。 輸送された主要な材料を受け取るのが選択された固有識別文字は「隣人グラフ」として知られている固有識別文字の間の同輩運動の過去のパターンに基づいて選択されます。 移管レイテンシを減少させるために、先を見越す主要な分配体系はEAP同輩と固有識別文字の間の輸送された合わせることの材料の所持の証拠を通常示すだけです。 移管の間、同輩が首尾よく固有識別文字に認証した証拠はバックエンド認証サーバに提供されません。 代わりに、固有識別文字は対応する認証交換なしで会計メッセージのストリームを生成します。 [MishraPro]で説明されるように、認証交換の静的な構成か分析で隣人グラフに関する知識を確立できます。 コネ
Aboba, et al. Standards Track [Page 44] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[44ページ]RFC5247EAP
order to prevent corruption of the neighbor graph, new neighbor graph entries can only be created as the result of a successful EAP exchange, and accounting packets with no corresponding authentication exchange need to be verified to correspond to neighbor graph entries (e.g., corresponding to handoffs between neighbors).
隣人グラフの不正を防ぐ命令、うまくいっているEAP交換の結果として新しい隣人グラフエントリーを作成できるだけです、そして、対応する認証交換のない会計パケットは隣人グラフエントリー(例えば、隣人の間でhandoffsに対応している)に相当するように確かめられる必要があります。
In order to prevent compromise of one authenticator from resulting in compromise of other authenticators, cryptographic separation needs to be maintained between the keying material transported to each authenticator. However, even where cryptographic separation is maintained, an attacker compromising an authenticator can still disrupt the operation of other authenticators. As noted in [RFC3579] Section 4.3.7, in the absence of spoofing detection within the AAA infrastructure, it is possible for EAP authenticators to impersonate each other. By forging NAS identification attributes within authentication messages, an attacker compromising one authenticator could corrupt the neighbor graph, tricking the backend authentication server into transporting keying material to arbitrary authenticators. While this would not enable recovery of EAP keying material without breaking fundamental cryptographic assumptions, it could enable subsequent fraudulent accounting messages, or allow an attacker to disrupt service by increasing load on the backend authentication server or thrashing the authenticator key cache.
1つの固有識別文字の感染が他の固有識別文字の感染をもたらすのを防ぐために、暗号の分離は、材料が各固有識別文字に輸送した合わせることの間で維持される必要があります。 しかしながら、暗号の分離が維持さえされるところで、固有識別文字に感染する攻撃者はまだ他の固有識別文字の操作を中断できます。 AAAインフラストラクチャの中で検出を偽造することが不在のとき[RFC3579]セクション4.3.7で注意されるように、EAP固有識別文字が互いをまねるのは、可能です。 認証メッセージの中でNAS識別属性を鍛造することによって、1つの固有識別文字に感染する攻撃者は隣人グラフを崩壊させることができるでしょう、任意の固有識別文字に材料を合わせながらバックエンド認証サーバを輸送にだまして。 これが壊れている基本的な暗号の仮定なしで材料を合わせるEAPの回復を可能にしていないだろうという間、それは、その後の詐欺的な会計メッセージを可能にするか、または攻撃者がバックエンド認証サーバで負荷を増強するか、または固有識別文字の主要なキャッシュを打たせることによってサービスを中断するのを許容するかもしれません。
Since proactive key distribution requires the distribution of derived keying material to candidate authenticators, the effectiveness of this scheme depends on the ability of backend authentication server to anticipate the movement of the EAP peer. Since proactive key distribution relies on backend authentication server knowledge of the neighbor graph, it is most applicable to intra-domain handoff scenarios. However, in inter-domain handoff, where there can be many authenticators, peers can frequently connect to authenticators that have not been previously encountered, making it difficult for the backend authentication server to derive a complete neighbor graph.
先を見越す主要な分配が誘導合わせることの材料の分配を候補固有識別文字に必要とするので、この体系の有効性はバックエンド認証サーバがEAP同輩の動きを予期する能力に依存します。 先を見越す主要な分配が隣人グラフに関するバックエンド認証サーバ知識を当てにするので、それはイントラドメイン移管シナリオに最も適切です。 しかしながら、相互ドメイン移管では、多くの固有識別文字があることができるところで同輩は以前に遭遇していない固有識別文字に頻繁に接続できます、バックエンド認証サーバが完全な隣人グラフを引き出すのを難しくして。
Since proactive key distribution schemes typically require introduction of server-initiated messages as described in [RFC5176] and [HANDOFF], security issues described in [RFC5176] Section 6 are applicable, including authorization (Section 6.1) and replay detection (Section 6.3) problems.
先を見越す主要な分配体系が[RFC5176]と[HANDOFF]で説明されるようにサーバで開始しているメッセージの導入を通常必要とするので、[RFC5176]セクション6で説明された安全保障問題は適切です、承認(セクション6.1)と再生検出(セクション6.3)問題を含んでいて。
Aboba, et al. Standards Track [Page 45] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[45ページ]RFC5247EAP
4.3. AAA Bypass
4.3. AAA迂回
Fast handoff techniques that enable elimination of the AAA exchange (phase 1b) differ fundamentally from typical network access scenarios (dial-up, wired LAN, etc.) that include user authentication as well as authorization for the offered service. Where the AAA exchange (phase 1b) is omitted, authorizations and keying material are not provided by the backend authentication server, and as a result, they need to be supplied by other means. This section describes some of the implications.
AAA交換(フェーズ1b)の除去を可能にする速い移管のテクニックが基本的に提供サービスのための承認と同様にユーザー認証を含んでいる典型的なネットワークアクセスシナリオ(ダイヤルアップ、ワイヤードなLANなど)と異なっています。 AAA交換(フェーズ1b)が省略されるところには、承認と材料を合わせるのがバックエンド認証サーバによって提供されません、そして、その結果、それらが他の手段で供給される必要があります。 このセクションは含意のいくつかについて説明します。
4.3.1. Key Transport
4.3.1. 主要な輸送
Where transported keying material is not supplied by the backend authentication server, it needs to be provided by another party authorized to access that keying material. As noted in Section 1.5, only the EAP peer, authenticator, and server are authorized to possess transported keying material. Since EAP peers do not trust each other, if the backend authentication server does not supply transported keying material to a new authenticator, it can only be provided by a previous authenticator.
輸送されているところには、材料を合わせるのがバックエンド認証サーバによって供給されないで、それは、材料を合わせながらそれにアクセスするのに権限を与えられた別のパーティーによって提供される必要があります。 セクション1.5に述べられるように、EAP同輩、固有識別文字、およびサーバだけには輸送された合わせることの材料があるのに権限を与えられます。 バックエンド認証サーバが輸送された合わせることの材料を新しい固有識別文字に供給しないならEAP同輩が互いを信じないので、前の固有識別文字はそれを提供できるだけです。
As noted in Section 1.5, the goal of the EAP conversation is to derive session keys known only to the peer and the authenticator. If keying material is replicated between a previous authenticator and a new authenticator, then the previous authenticator can possess session keys used between the peer and new authenticator. Also, the new authenticator can possess session keys used between the peer and the previous authenticator.
セクション1.5に述べられるように、EAPの会話の目標は同輩と固有識別文字だけに知られているセッションキーを引き出すことです。 合わせることの材料が前の固有識別文字と新しい固有識別文字の間で模写されるなら、前の固有識別文字は同輩と新しい固有識別文字の間で使用されるセッションキーを所有できます。 また、新しい固有識別文字は同輩と前の固有識別文字の間で使用されるセッションキーを所有できます。
If a one-way function is used to derive the keying material to be transported to the new authenticator, then the new authenticator cannot possess previous session keys without breaking a fundamental cryptographic assumption.
一方向関数が新しい固有識別文字に輸送されるために合わせることの材料を誘導するのに使用されるなら、基本的な暗号の仮定を破らないで、新しい固有識別文字は前のセッションキーを所有できません。
4.3.2. Authorization
4.3.2. 承認
As a part of the authentication process, the backend authentication server determines the user's authorization profile and transmits the authorizations to the authenticator along with the transported keying material. Typically, the profile is determined based on the user identity, but a certificate presented by the user can also provide authorization information.
認証過程の一部として、バックエンド認証サーバは、材料を合わせながら、ユーザの承認プロフィールを決定して、輸送と共に承認を固有識別文字に伝えます。 プロフィールはユーザアイデンティティに基づいて通常、断固としていますが、また、ユーザによって提示された証明書は承認情報を提供できます。
The backend authentication server is responsible for making a user authorization decision, which requires answering the following questions:
バックエンド認証サーバは以下の質問に答えるのを必要とするユーザ承認決定をするのに原因となります:
Aboba, et al. Standards Track [Page 46] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[46ページ]RFC5247EAP
(a) Is this a legitimate user of this network?
(a) これはこのネットワークの正統のユーザですか?
(b) Is the user allowed to access this network?
(b) ユーザはこのネットワークにアクセスできますか?
(c) Is the user permitted to access this network on this day and at
this time?
(c) ユーザがこの日、このときこのネットワークにアクセスすることが許可されていますか?
(d) Is the user within the concurrent session limit?
(d) ユーザは同時発生のセッション限界の中にいますか?
(e) Are there any fraud, credit limit, or other concerns that could
lead to access denial?
(e) 何か詐欺、それが否定にアクセスするように導くことができた掛貸限度額の、または、他の関心がありますか?
(f) If access is to be granted, what are the service parameters
(mandatory tunneling, bandwidth, filters, and so on) to be
provisioned for the user?
(f) 与えるためにアクセスがあるなら、サービスパラメタ(義務的なトンネリング、帯域幅、フィルタなど)はユーザのために食糧を供給されるべき、何ですか?
While the authorization decision is, in principle, simple, the distributed decision making process can add complexity. Where brokers or proxies are involved, all of the AAA entities in the chain from the authenticator to the home backend authentication server are involved in the decision. For example, a broker can deny access even if the home backend authentication server would allow it, or a proxy can add authorizations (e.g., bandwidth limits).
承認決定が原則として簡単である間、分配された意志決定プロセスは複雑さを加えることができます。 ブローカーかプロキシがかかわるところでは、固有識別文字からホームバックエンド認証サーバまでのチェーンにおけるAAA実体のすべてが決定にかかわります。 例えば、ホームバックエンド認証サーバがそれを許容するだろう、またはプロキシが承認(例えば、帯域幅限界)を加えることができても、ブローカーはアクセスを拒絶できます。
Decisions can be based on static policy definitions and profiles as well as dynamic state (e.g., time of day or concurrent session limits). In addition to the Accept/Reject decisions made by AAA entities, service parameters or constraints can be communicated to the authenticator.
決定は動態(例えば、時刻か同時発生のセッション限界)と同様に静的な方針定義とプロフィールに基づくことができます。 AAA実体によってされたAccept/廃棄物決定に加えて、サービスパラメタか規制を固有識別文字に伝えることができます。
The criteria for Accept/Reject decisions or the reasons for choosing particular authorizations are typically not communicated to the authenticator, only the final result is. As a result, the authenticator has no way to know on what the decision was based. Was a set of authorization parameters sent because this service is always provided to the user, or was the decision based on the time of day and the capabilities of the authenticator?
Accept/廃棄物決定の評価基準か特定の承認を選ぶ理由が固有識別文字に通常伝えられないで、最終的な唯一の結果はそうです。 その結果、固有識別文字には、決定が何に基づいたかを知る方法が全くありません。 いつもこのサービスをユーザに提供するので、1セットの承認パラメタを送りましたか、または決定を時刻と固有識別文字の能力に基礎づけましたか?
4.3.3. Correctness
4.3.3. 正当性
When the AAA exchange (phase 1b) is bypassed, several challenges arise in ensuring correct authorization:
AAA交換(フェーズ1b)が迂回するとき、いくつかの挑戦が正しい承認を確実にする際に起こります:
Theft of service
Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to
extend their network access or gain access to services they are
not entitled to.
サービスBypassing AAA交換(フェーズ1b)SHOULD NOTの窃盗は、ユーザが彼らのネットワークアクセスを広げているか、またはそれらが権利を与えられないサービスへのアクセスを得るのを可能にします。
Aboba, et al. Standards Track [Page 47] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[47ページ]RFC5247EAP
Consideration of network-wide state
Handoff techniques SHOULD NOT render the backend authentication
server incapable of keeping track of network-wide state. For
example, a backend authentication server can need to keep track of
simultaneous user sessions.
HandoffテクニックSHOULD NOTがネットワーク全体の状態の動向をおさえることができないバックエンド認証サーバを表すネットワーク全体の状態の考慮。 例えば、バックエンド認証サーバは、同時のユーザセッションの動向をおさえる必要があることができます。
Elevation of privilege
Backend authentication servers often perform conditional
evaluation, in which the authorizations returned in an
Access-Accept message are contingent on the authenticator or on
dynamic state such as the time of day. In this situation,
bypassing the AAA exchange could enable unauthorized access unless
the restrictions are explicitly encoded within the authorizations
provided by the backend authentication server.
サーバがしばしば条件付きの評価か、Access受け入れているメッセージで返された承認が固有識別文字次第でどれであるか、そして、時刻などの動態に実行する特権Backend認証の高度。 この状況で、AAA交換を迂回させると、制限がバックエンド認証サーバによって提供された承認の中で明らかにコード化されない場合、不正アクセスは可能にされるかもしれません。
A handoff mechanism that provides proper authorization is said to be "correct". One condition for correctness is as follows:
適切な承認を提供する移管メカニズムは「正しい」と言われています。 正当性のための1つの状態は以下の通りです:
For a handoff to be "correct" it MUST establish on the new
authenticator the same authorizations as would have been created
had the new authenticator completed a AAA conversation with the
backend authentication server.
移管が「正しい」ように、それは新しい固有識別文字がバックエンド認証サーバとのAAAの会話を終了したなら作成されたように新しい固有識別文字で同じ承認を確立しなければなりません。
A properly designed handoff scheme will only succeed if it is "correct" in this way. If a successful handoff would establish "incorrect" authorizations, it is preferable for it to fail. Where the supported services differ between authenticators, a handoff that bypasses the backend authentication server is likely to fail. Section 1.1 of [RFC2865] states:
それがこのように「正しい」場合にだけ、適切に設計された移管体系は成功するでしょう。 うまくいっている移管が「不正確な」承認を確立するなら、失敗するのは望ましいです。 サポートしているサービスが固有識別文字の間で異なるところでは、バックエンド認証サーバを迂回させる移管は失敗しそうです。 [RFC2865]州のセクション1.1:
A authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. For example, a
authenticator that is unable to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead.
与えられたサービスを実装しない固有識別文字は、そのサービスのためにRADIUSが属性であると実装してはいけません。 例えば、サービスをARAPに提供できない固有識別文字は、ARAPのためにRADIUSが属性であると実装してはいけません。 代わりにアクセス廃棄物として入手できないサービスを認可して、固有識別文字はアクセスして受け入れた状態でRADIUSを扱わなければなりません。
This behavior applies to attributes that are known, but not implemented. For attributes that are unknown, Section 5 of [RFC2865] states:
この振舞いは知られていますが、実装されない属性に適用されます。 未知であることの属性のために、[RFC2865]のセクション5は以下を述べます。
A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type.
RADIUSサーバは未知のTypeとAttributesを無視するかもしれません。 RADIUSクライアントは未知のTypeとAttributesを無視するかもしれません。
In order to perform a correct handoff, if a new authenticator is provided with RADIUS authorizations for a known but unavailable service, then it MUST process these authorizations the same way it would handle a RADIUS Access-Accept requesting an unavailable
知られていますが、入手できないサービスのためにRADIUS承認を新しい固有識別文字に提供するなら正しい移管を実行するためにRADIUS Access受け入れている要求を扱うだろうという同じようにこれらの承認を処理しなければならない、入手できませんさ
Aboba, et al. Standards Track [Page 48] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[48ページ]RFC5247EAP
service; this MUST cause the handoff to fail. However, if a new authenticator is provided with authorizations including unknown attributes, then these attributes MAY be ignored. The definition of a "known but unsupported service" MUST encompass requests for unavailable security services. This includes vendor-specific attributes related to security, such as those described in [RFC2548]. Although it can seem somewhat counter-intuitive, failure is indeed the "correct" result where a known but unsupported service is requested.
サービス。 これは移管に失敗されなければなりません。 しかしながら、未知の属性を含む承認を新しい固有識別文字に提供するなら、これらの属性を無視するかもしれません。 「知られていますが、サポートされないサービス」の定義は入手できないセキュリティー・サービスを求める要求を包含しなければなりません。 これは[RFC2548]で説明されたものなどのセキュリティに関連するベンダー特有の属性を含んでいます。 いくらか直観に反するように見えることができますが、本当に、失敗は知られていますが、サポートされないサービスが要求されている「正しい」結果です。
Presumably, a correctly configured backend authentication server would not request that an authenticator provide a service that it does not implement. This implies that if the new authenticator were to complete a AAA conversation, it would be likely to receive different service instructions. Failure of the handoff is the desired result since it will cause the new authenticator to go back to the backend server in order to receive the appropriate service definition.
おそらく、正しく構成されたバックエンド認証サーバは、固有識別文字がそれが実装しないサービスを提供するよう要求しないでしょう。 これは、新しい固有識別文字がAAAの会話を終了することであるなら、異なったサービス指示を受けそうであるのを含意します。 新しい固有識別文字が適切なサービス定義を受けるためにそれでバックエンドサーバに戻るので、移管の失敗は必要な結果です。
Handoff mechanisms that bypass the backend authentication server are most likely to be successful when employed in a homogeneous deployment within a single administrative domain. In a heterogeneous deployment, the backend authentication server can return different authorizations depending on the authenticator making the request in order to make sure that the requested service is consistent with the authenticator capabilities. Where a backend authentication server would send different authorizations to the new authenticator than were sent to a previous authenticator, transferring authorizations between the previous authenticator and the new authenticator will result in incorrect authorization.
ただ一つの管理ドメインの中の均質の展開で使われると、バックエンド認証サーバを迂回させる移管メカニズムはうまくいく最も傾向があります。 異種の展開では、バックエンド認証サーバは、要求されたサービスが固有識別文字能力と一致しているのを確実にするために要求をしながら、固有識別文字による異なった承認を返すことができます。 バックエンド認証サーバが異なった承認を新しい固有識別文字に送るだろうところでは、前の固有識別文字と新しい固有識別文字の間に承認を移すのは前の固有識別文字に送ったより不正確な承認に結果として生じるでしょう。
Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS support for dynamic VLANs is described in [RFC3580] and [RFC4675]. If some authenticators support dynamic VLANs while others do not, then attributes present in the Access-Request (such as the NAS-Port-Type, NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier) could be examined by the backend authentication server to determine when VLAN attributes will be returned, and if so, which ones. However, if the backend authenticator is bypassed, then a handoff occurring between authenticators supporting different VLAN capabilities could result in a user obtaining access to an unauthorized VLAN (e.g., a user with access to a guest VLAN being given unrestricted access to the network).
バーチャルLAN(VLAN)サポートは[IEEE-802.1Q]で定義されます。 ダイナミックなVLANsのRADIUSサポートは[RFC3580]と[RFC4675]で説明されます。 いくつかの固有識別文字が他のものがサポートしていない間、ダイナミックなVLANsをサポートするなら、Access-要求(NASポートタイプや、NAS IPアドレスや、NAS-IPv6-アドレスや、NAS-識別子などの)の現在の属性はバックエンド認証サーバによって調べられて、VLAN属性がいつ返されるかを決定するかもしれない、そうだとすれば、どれですか? しかしながら、バックエンド固有識別文字が迂回するなら、異なったVLAN能力をサポートしながら固有識別文字の間に起こる移管は権限のないVLAN(例えば、ゲストVLANへのネットワークへの無制限なアクセスを与えるアクセスでのユーザ)へのアクセスを得るユーザをもたらすかもしれません。
Aboba, et al. Standards Track [Page 49] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[49ページ]RFC5247EAP
Similarly, it is preferable for a handoff between an authenticator providing confidentiality and another that does not to fail, since if the handoff were successful, the user would be moved from a secure to an insecure channel without permission from the backend authentication server.
同様に、秘密性を提供する固有識別文字とそれがする別のことの間の移管には、失敗しないのは望ましいです、移管がうまくいくなら、ユーザが不安定なチャンネルに、バックエンド認証サーバからの許可なしに安全なaから動かされるので。
5. Security Considerations
5. セキュリティ問題
The EAP threat model is described in [RFC3748] Section 7.1. The security properties of EAP methods (known as "security claims") are described in [RFC3748] Section 7.2.1. EAP method requirements for applications such as Wireless LAN authentication are described in [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 4.1, and responses to these threats are described in [RFC3579], Sections 4.2 and 4.3.
EAP脅威モデルは[RFC3748]セクション7.1で説明されます。 EAPメソッド(「セキュリティは要求します」のように、知っている)のセキュリティの特性は[RFC3748]セクション7.2.1で説明されます。 Wireless LAN認証などの応用のためのEAPメソッド要件は[RFC4017]で説明されます。 RADIUS脅威モデルは[RFC3579]セクション4.1で説明されます、そして、応答は[RFC3579](セクション4.2と4.3)にこれらの脅威に説明されます。
However, in addition to threats against EAP and AAA, there are other system level threats. In developing the threat model, it is assumed that:
しかしながら、EAPとAAAに対する脅威に加えて、他のシステムレベルの脅威はいます。 脅威モデルを開発する際に、以下のことと思われます。
All traffic is visible to the attacker.
The attacker can alter, forge, or replay messages.
The attacker can reroute messages to another principal.
The attacker can be a principal or an outsider.
The attacker can compromise any key that is sufficiently old.
攻撃者にとって、すべてのトラフィックが目に見えます。 攻撃者は、メッセージを変更するか、鍛造するか、または再演できます。 攻撃者は別の主体にメッセージを別ルートで送ることができます。 攻撃者は、元本か部外者であるかもしれません。 攻撃者はどんな十分古いキーにも感染することができます。
Threats arising from these assumptions include:
これらの仮定から起こる脅威は:
(a) An attacker can compromise or steal an EAP peer or
authenticator, in an attempt to gain access to other EAP peers
or authenticators or to obtain long-term secrets.
(a) 攻撃者は、EAP同輩か固有識別文字を感染するか、または横取りできます、他のEAP同輩か固有識別文字へのアクセスを得るか、または長期の秘密を得る試みで。
(b) An attacker can attempt a downgrade attack in order to exploit
known weaknesses in an authentication method or cryptographic
algorithm.
(b) 攻撃者は、認証方法か暗号アルゴリズムで知られている弱点を開発するためにダウングレード攻撃を試みることができます。
(c) An attacker can try to modify or spoof packets, including
Discovery or Secure Association Protocol frames, EAP or AAA
packets.
(c) 攻撃者は、パケットを変更しようとするか、または偽造しようとすることができます、ディスカバリー、Secure Associationプロトコルフレーム、EAPまたはAAAパケットを含んでいて。
(d) An attacker can attempt to induce an EAP peer, authenticator, or
server to disclose keying material to an unauthorized party, or
utilize keying material outside the context that it was intended
for.
(d) 攻撃者は、EAP同輩、固有識別文字、またはサーバが権限のないパーティーに合わせることの材料を明らかにするか、またはそれが意図した文脈の外で合わせることの材料を利用するのを引き起こすのを試みることができます。
(e) An attacker can alter, forge, or replay packets.
(e) 攻撃者は、パケットを変更するか、鍛造するか、または再演できます。
Aboba, et al. Standards Track [Page 50] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[50ページ]RFC5247EAP
(f) An attacker can cause an EAP peer, authenticator, or server to
reuse a stale key. Use of stale keys can also occur
unintentionally. For example, a poorly implemented backend
authentication server can provide stale keying material to an
authenticator, or a poorly implemented authenticator can reuse
nonces.
(f) 攻撃者はEAP同輩、固有識別文字、またはサーバに聞き古したキーを再利用させることができます。 また、聞き古したキーの使用は何気なく起こることができます。 例えば、認証サーバが固有識別文字、または不十分に実装している固有識別文字への聞き古した合わせることの材料を供給できる不十分に実装しているバックエンドは一回だけを再利用できます。
(g) An authenticated attacker can attempt to obtain elevated
privilege in order to access information that it does not have
rights to.
(g) 認証された攻撃者は、それが権利を持っていない情報にアクセスするために高い特権を得るのを試みることができます。
(h) An attacker can attempt a man-in-the-middle attack in order to
gain access to the network.
(h) 攻撃者は、ネットワークへのアクセスを得るために介入者攻撃を試みることができます。
(i) An attacker can compromise an EAP authenticator in an effort to
commit fraud. For example, a compromised authenticator can
provide incorrect information to the EAP peer and/or server via
out-of-band mechanisms (such as via a AAA or lower-layer
protocol). This includes impersonating another authenticator,
or providing inconsistent information to the peer and EAP
server.
(i) 攻撃者は、詐欺を犯すために取り組みにおけるEAP固有識別文字に感染することができます。 例えば、バンドで出ているメカニズム(AAAか下位層プロトコルを通したなど)で感染している固有識別文字はEAP同輩、そして/または、サーバに不正確な情報を提供できます。 これは、同輩とEAPサーバに別の固有識別文字をまねるか、または矛盾した情報を提供するのを含んでいます。
(j) An attacker can launch a denial-of-service attack against the
EAP peer, authenticator, or backend authentication server.
(j) 攻撃者はEAP同輩、固有識別文字、またはバックエンド認証サーバに対してサービス不能攻撃に着手できます。
In order to address these threats, [RFC4962] Section 3 describes required and recommended security properties. The sections that follow analyze the compliance of EAP methods, AAA protocols, and Secure Association Protocols with those guidelines.
これらの脅威を扱うために、[RFC4962]セクション3は必要でお勧めのセキュリティの特性について説明します。 従うセクションはそれらのガイドラインでEAPメソッド、AAAプロトコル、およびSecure Associationプロトコルのコンプライアンスを分析します。
5.1. Peer and Authenticator Compromise
5.1. 同輩と固有識別文字感染
Requirement: In the event that an authenticator is compromised or stolen, an attacker can gain access to the network through that authenticator, or can obtain the credentials needed for the authenticator/AAA client to communicate with one or more backend authentication servers. Similarly, if a peer is compromised or stolen, an attacker can obtain credentials needed to communicate with one or more authenticators. A mandatory requirement from [RFC4962] Section 3:
要件: 固有識別文字が感染されるか、または盗まれる場合、攻撃者は、その固有識別文字を通してネットワークへのアクセスを得ることができるか、または固有識別文字/AAAのクライアントが1つ以上のバックエンド認証サーバとコミュニケートするのに必要である資格証明書を得ることができます。 同様に、同輩が感染されるか、または盗まれるなら、攻撃者は1つ以上の固有識別文字で交信するのに必要である資格証明書を得ることができます。 [RFC4962]セクション3からの義務的な要件:
Prevent the Domino effect
Domino効果を防いでください。
Compromise of a single peer MUST NOT compromise keying material
held by any other peer within the system, including session keys
and long-term keys. Likewise, compromise of a single
authenticator MUST NOT compromise keying material held by any
other authenticator within the system. In the context of a key
システムの中のいかなる他の同輩によっても保たれた材料を合わせて、独身の同輩の感染は妥協してはいけません、セッションキーと長期のキーを含んでいて。 同様に、システムの中のいかなる他の固有識別文字によっても保たれた材料を合わせて、ただ一つの固有識別文字の感染は妥協してはいけません。 キーの文脈で
Aboba, et al. Standards Track [Page 51] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[51ページ]RFC5247EAP
hierarchy, this means that the compromise of one node in the key
hierarchy must not disclose the information necessary to
compromise other branches in the key hierarchy. Obviously, the
compromise of the root of the key hierarchy will compromise all of
the keys; however, a compromise in one branch MUST NOT result in
the compromise of other branches. There are many implications of
this requirement; however, two implications deserve highlighting.
First, the scope of the keying material must be defined and
understood by all parties that communicate with a party that holds
that keying material. Second, a party that holds keying material
in a key hierarchy must not share that keying material with
parties that are associated with other branches in the key
hierarchy.
階層構造、これは主要な階層構造の1つのノードの感染が主要な階層構造で他のブランチに感染するために必要情報を明らかにしてはいけないことを意味します。 明らかに、主要な階層構造の根の感染はキーのすべてに感染するでしょう。 しかしながら、1つのブランチにおける感染は他のブランチの感染をもたらしてはいけません。 この要件の多くの含意があります。 しかしながら、2つの含意がハイライトに値します。 まず最初に、合わせることの材料の範囲を定義されて、材料を合わせながらそれを保持するパーティーとコミュニケートするすべてのパーティーに解釈しなければなりません。 2番目に、主要な階層構造で材料を合わせながら成立するパーティーは、主要な階層構造で他のブランチに関連しているパーティーに伴う材料を合わせながら、それを共有してはいけません。
Group keys are an obvious exception. Since all members of the
group have a copy of the same key, compromise of any one of the
group members will result in the disclosure of the group key.
グループキーは明白な例外です。 グループのすべてのメンバーには同じキーのコピーがあるので、グループのメンバーのどれかの感染はグループキーの公開をもたらすでしょう。
Some of the implications of the requirement are as follows:
要件の含意のいくつかは以下の通りです:
Key Sharing
In order to be able to determine whether keying material has
been shared, it is necessary for the identity of the EAP
authenticator (NAS-Identifier) to be defined and understood by
all parties that communicate with it. EAP lower-layer
specifications such as [IEEE-802.11], [IEEE-802.16e],
[IEEE-802.1X], IKEv2 [RFC4306], and PPP [RFC1661] do not involve
key sharing.
材料を合わせるのが共有されたかどうか決定できる主要なSharing In命令、EAP固有識別文字(NAS-識別子)のアイデンティティが定義されて、それで交信するすべてのパーティーに解釈されるのが必要です。 [IEEE-802.11]や、[IEEE-802.16e]や、[IEEE-802.1X]や、IKEv2[RFC4306]や、PPP[RFC1661]などのEAP下層仕様は主要な共有を伴いません。
AAA Credential Sharing
AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
keys or certificates) MUST NOT be shared between AAA clients,
since if one AAA client were compromised, this would enable an
attacker to impersonate other AAA clients to the backend
authentication server, or even to impersonate a backend
authentication server to other AAA clients.
AAAのクライアントの間でAAA Credential Sharing AAA資格証明書(あらかじめ共有されたRADIUS共有秘密キー、IPsecなどのようにキーか証明書)を共有してはいけません、1人のAAAのクライアントが感染されるなら、これが、攻撃者がバックエンド認証サーバに他のAAAのクライアントをまねるか、または他のAAAのクライアントにバックエンド認証サーバをまねるのさえ可能にするので。
Compromise of Long-Term Credentials
An attacker obtaining keying material (such as TSKs, TEKs, or
the MSK) MUST NOT be able to obtain long-term user credentials
such as pre-shared keys, passwords, or private-keys without
breaking a fundamental cryptographic assumption. The mandatory
requirements of [RFC4017] Section 2.2 include generation of EAP
keying material, capability to generate EAP keying material with
128 bits of effective strength, resistance to dictionary
attacks, shared state equivalence, and protection against
man-in-the-middle attacks.
基本的な暗号の仮定を破らないで、材料(TSKs、TEKs、またはMSKなどの)を合わせるLong-用語Credentials An攻撃者入手の感染はあらかじめ共有されたキー、パスワード、または秘密鍵などの長期のユーザ資格証明書を得ることができるはずがありません。 [RFC4017]セクション2.2の義務的な要件は材料(有効な強さ、辞書攻撃への抵抗、共有された州の等価性、および介入者攻撃に対する保護の128ビットで材料を合わせるEAPを生成する能力)を合わせるEAPの世代を含んでいます。
Aboba, et al. Standards Track [Page 52] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[52ページ]RFC5247EAP
5.2. Cryptographic Negotiation
5.2. 暗号の交渉
Mandatory requirements from [RFC4962] Section 3:
[RFC4962]セクション3からの義務的な要件:
Cryptographic algorithm independent
暗号アルゴリズム独立者
The AAA key management protocol MUST be cryptographic algorithm
independent. However, an EAP method MAY depend on a specific
cryptographic algorithm. The ability to negotiate the use of a
particular cryptographic algorithm provides resilience against
compromise of a particular cryptographic algorithm. Algorithm
independence is also REQUIRED with a Secure Association Protocol
if one is defined. This is usually accomplished by including an
algorithm identifier and parameters in the protocol, and by
specifying the algorithm requirements in the protocol
specification. While highly desirable, the ability to negotiate
key derivation functions (KDFs) is not required. For
interoperability, at least one suite of mandatory-to-implement
algorithms MUST be selected. Note that without protection by
IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does
not meet this requirement, since the integrity protection
algorithm cannot be negotiated.
AAAかぎ管理プロトコルは暗号アルゴリズム独立者であるに違いありません。 しかしながら、EAPメソッドは特定の暗号アルゴリズムによるかもしれません。 特定の暗号アルゴリズムの使用を交渉する能力は特定の暗号アルゴリズムの感染に対して弾力を提供します。 また、1つが定義されるなら、アルゴリズム独立はSecure AssociationプロトコルがあるREQUIREDです。 通常、これは、プロトコルにアルゴリズム識別子とパラメタを含んでいて、プロトコル仕様でアルゴリズム要件を指定することによって、達成されます。 非常に望ましい間、主要な派生機能(KDFs)を交渉する能力は必要ではありません。 相互運用性において、実装するために義務的なアルゴリズムの少なくとも1つのスイートを選択しなければなりません。 [RFC3579]セクション4.2で説明されるIPsecによる保護がなければ、RADIUS[RFC2865]がこの必要条件を満たさないことに注意してください、保全保護アルゴリズムを交渉できないので。
This requirement does not mean that a protocol must support both
public-key and symmetric-key cryptographic algorithms. It means
that the protocol needs to be structured in such a way that
multiple public-key algorithms can be used whenever a public-key
algorithm is employed. Likewise, it means that the protocol needs
to be structured in such a way that multiple symmetric-key
algorithms can be used whenever a symmetric-key algorithm is
employed.
この要件は、プロトコルが、両方が公開鍵と対称鍵の暗号のアルゴリズムであるとサポートしなければならないことを意味しません。それは、プロトコルが、公開鍵アルゴリズムが採用しているときはいつも、複数の公開鍵アルゴリズムを使用できるような方法で構造化される必要を意味します。 同様に、それは、プロトコルが、対称鍵アルゴリズムが採用しているときはいつも、複数の対称鍵アルゴリズムを使用できるような方法で構造化される必要を意味します。
Confirm ciphersuite selection
ciphersuite選択を確認してください。
The selection of the "best" ciphersuite SHOULD be securely
confirmed. The mechanism SHOULD detect attempted roll-back
attacks.
確認されて、「最も良い」ciphersuite SHOULDの選択はしっかりとそうです。 SHOULDが検出するメカニズムは後退復帰攻撃を試みました。
EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements and AAA protocols utilizing transmission-layer security are capable of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes the "protected ciphersuite negotiation" security claim that refers to the ability of an EAP method to negotiate the ciphersuite used to protect the EAP method conversation, as well as to integrity protect the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP methods satisfying this security claim. Since TLS v1.2 [RFC5246] and IKEv2 [RFC4306] support negotiation of Key Derivation Functions (KDFs), EAP methods based on TLS or IKEv2 will, if properly designed,
[RFC4017]セクション2.2の義務的な要件を満たすEAPメソッドとトランスミッション層のセキュリティを利用するAAAプロトコルはダウングレード攻撃を扱うことができます。 [RFC3748]セクション7.2 .1 EAPメソッドの会話を保護して、ciphersuite交渉を保全に保護するのに使用されるciphersuiteを交渉するEAPメソッドの能力について言及する「保護されたciphersuite交渉」セキュリティクレームについて説明します。 [RFC4017]セクション2.2はこのセキュリティクレームを満たすEAPメソッドを必要とします。 TLSかIKEv2に基づくEAPメソッドはサポートするでしょう、TLS v1.2[RFC5246]とIKEv2[RFC4306]がKey Derivation Functions(KDFs)の交渉をサポートするので、適切に設計されるなら、サポートします。
Aboba, et al. Standards Track [Page 53] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[53ページ]RFC5247EAP
inherit this capability. However, negotiation of KDFs is not required by RFC 4962 [RFC4962], and EAP methods based on neither TLS nor IKEv2 typically do not support KDF negotiation.
この能力を引き継いでください。 しかしながら、KDFsの交渉はRFC4962[RFC4962]によって必要とされません、そして、どちらもTLSかIKEv2に基づくEAPメソッドはKDFが交渉であると通常サポートしません。
When AAA protocols utilize TLS [RFC5246] or IPsec [RFC4301] for transmission layer security, they can leverage the cryptographic algorithm negotiation support provided by IKEv2 [RFC4306] or TLS [RFC5246]. RADIUS [RFC3579] by itself does not support cryptographic algorithm negotiation and relies on MD5 for integrity protection, authentication, and confidentiality. Given the known weaknesses in MD5 [MD5Collision], this is undesirable, and can be addressed via use of RADIUS over IPsec, as described in [RFC3579] Section 4.2.
AAAプロトコルがTLS[RFC5246]かIPsec[RFC4301]をトランスミッション層のセキュリティに利用するとき、彼らは、暗号アルゴリズム交渉がIKEv2[RFC4306]かTLS[RFC5246]によって提供されたサポートであると利用することができます。 それ自体でRADIUS[RFC3579]は暗号アルゴリズムが交渉であるとサポートしないで、保全保護、認証、および秘密性のためにMD5を当てにします。 MD5[MD5Collision]の知られている弱点を考えて、これは、望ましくなく、IPsecの上でRADIUSの使用で扱うことができます、[RFC3579]セクション4.2で説明されるように。
To ensure against downgrade attacks within lower-layer protocols, algorithm independence is REQUIRED with lower layers using EAP for key derivation. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Lower-layer protocols supporting EAP for key derivation SHOULD also support secure ciphersuite negotiation as well as KDF negotiation.
下位層プロトコルの中でダウングレード攻撃から身を守るために、アルゴリズム独立は下層が主要な派生にEAPを使用しているREQUIREDです。 相互運用性において、実装するために義務的なアルゴリズムの少なくとも1つのスイートを選択しなければなりません。 また、主要な派生SHOULDのためにEAPをサポートする下位層プロトコルは安全なciphersuiteが交渉であり、KDFが交渉であるとサポートします。
As described in [RFC1968], PPP ECP does not support secure ciphersuite negotiation. While [IEEE-802.16e] and [IEEE-802.11] support ciphersuite negotiation for protection of data, they do not support negotiation of the cryptographic primitives used within the Secure Association Protocol, such as message integrity checks (MICs) and KDFs.
[RFC1968]で説明されるように、PPP ECPは、安全なciphersuiteが交渉であるとサポートしません。 [IEEE-802.16e]と[IEEE-802.11]が、ciphersuiteがデータの保護のための交渉であるとサポートしている間、Secure Associationプロトコルの中で使用された暗号の基関数の交渉をサポートしません、メッセージの保全チェック(MICs)やKDFsのように。
5.3. Confidentiality and Authentication
5.3. 秘密性と認証
Mandatory requirements from [RFC4962] Section 3:
[RFC4962]セクション3からの義務的な要件:
Authenticate all parties
すべてのパーティーを認証してください。
Each party in the AAA key management protocol MUST be
authenticated to the other parties with whom they communicate.
Authentication mechanisms MUST maintain the confidentiality of any
secret values used in the authentication process. When a secure
association protocol is used to establish session keys, the
parties involved in the secure association protocol MUST identify
themselves using identities that are meaningful in the lower-layer
protocol environment that will employ the session keys. In this
situation, the authenticator and peer may be known by different
identifiers in the AAA protocol environment and the lower-layer
protocol environment, making authorization decisions difficult
without a clear key scope. If the lower-layer identifier of the
AAAかぎ管理プロトコルにおける各当事者を彼らと交信する相手に認証しなければなりません。 認証機構は認証過程に使用されるどんな秘密の値の秘密性も維持しなければなりません。 安全な協会プロトコルがセッションキーを証明するのに使用されるとき、セッションキーを使う下位層プロトコル環境で重要なアイデンティティを使用して、安全な協会プロトコルにかかわるパーティーは身元を明らかにしなければなりません。 この状況で、固有識別文字と同輩はAAAプロトコル環境と下位層プロトコル環境における異なった識別子によって知られているかもしれません、承認決定を明確な主要な範囲なしで難しくして。 下層識別子です。
Aboba, et al. Standards Track [Page 54] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[54ページ]RFC5247EAP
peer will be used to make authorization decisions, then the pair
of identifiers associated with the peer MUST be authorized by the
authenticator and/or the AAA server.
同輩は承認決定をするのに使用されて、固有識別文字、そして/または、AAAサーバで次に、同輩に関連している識別子の組に権限を与えなければなりません。
AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588],
provide a mechanism for the identification of AAA clients; since
the EAP authenticator and AAA client are always co-resident, this
mechanism is applicable to the identification of EAP
authenticators.
RADIUS[RFC2865]やDiameterなどのAAAプロトコル[RFC3588]はAAAのクライアントの識別にメカニズムを提供します。 いつもEAP固有識別文字とAAAのクライアントがコレジデントであるので、このメカニズムはEAP固有識別文字の識別に適切です。
When multiple base stations and a "controller" (such as a WLAN
switch) comprise a single EAP authenticator, the "base station
identity" is not relevant; the EAP method conversation takes place
between the EAP peer and the EAP server. Also, many base stations
can share the same authenticator identity. The authenticator
identity is important in the AAA protocol exchange and the secure
association protocol conversation.
複数の基地局と「コントローラ」(WLANスイッチなどの)がただ一つのEAP固有識別文字を包括するとき、「基地局のアイデンティティ」は関連していません。 EAPメソッドの会話はEAP同輩とEAPサーバの間の場所を取ります。また、多くの基地局が同じ固有識別文字のアイデンティティを共有できます。 固有識別文字のアイデンティティはAAAプロトコル交換と安全な協会プロトコルの会話で重要です。
Authentication mechanisms MUST NOT employ plaintext passwords.
Passwords may be used provided that they are not sent to another
party without confidentiality protection.
認証機構は平文パスワードを使ってはいけません。 それらが秘密性保護なしで別のパーティーに送られなければ、パスワードは使用されるかもしれません。
Keying material confidentiality and integrity
物質的な秘密性と保全を合わせます。
While preserving algorithm independence, confidentiality and
integrity of all keying material MUST be maintained.
アルゴリズム独立を保存している間、材料を合わせるすべての秘密性と保全を維持しなければなりません。
Conformance to these requirements is analyzed in the sections that follow.
これらの要件への順応は従うセクションで分析されます。
5.3.1. Spoofing
5.3.1. スプーフィング
Per-packet authentication and integrity protection provides protection against spoofing attacks.
1パケットあたりの認証と保全保護はスプーフィング攻撃に対する保護を提供します。
Diameter [RFC3588] provides support for per-packet authentication and integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides for per-packet authentication and integrity protection via use of the Message-Authenticator Attribute.
直径[RFC3588]はIPsecかTLSの使用で1パケットあたりの認証と保全保護のサポートを提供します。 Message-固有識別文字Attributeの使用でRADIUS/EAP[RFC3579]は1パケットあたりの認証と保全保護に備えます。
[RFC3748] Section 7.2.1 describes the "integrity protection" security claim and [RFC4017] Section 2.2 requires EAP methods supporting this claim.
[RFC3748]セクション7.2 .1 このクレームをサポートするセキュリティが要求して、[RFC4017]セクション2.2が必要とする「保全保護」EAPメソッドを説明します。
In order to prevent forgery of Secure Association Protocol frames, per-frame authentication and integrity protection is RECOMMENDED on all messages. IKEv2 [RFC4306] supports per-frame integrity
Secure Associationプロトコルフレームの偽造を防ぐために、1フレームあたりの認証と保全保護はすべてのメッセージのRECOMMENDEDです。 IKEv2[RFC4306]は1フレームあたりの保全をサポートします。
Aboba, et al. Standards Track [Page 55] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[55ページ]RFC5247EAP
protection and authentication, as does the Secure Association Protocol defined in [IEEE-802.16e]. [IEEE-802.11] supports per-frame integrity protection and authentication on all messages within the 4-way handshake except the first message. An attack leveraging this omission is described in [Analysis].
[IEEE-802.16e]で定義されたSecure Associationプロトコルのような保護と認証。 最初のメッセージを除いて、[IEEE-802.11]は、4ウェイ握手の中ですべてのメッセージで1フレームあたりの保全が保護と認証であるとサポートします。 この省略を利用する攻撃は[分析]で説明されます。
5.3.2. Impersonation
5.3.2. ものまね
Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are potentially vulnerable to a rogue authenticator impersonating another authenticator. While both protocols support mutual authentication between the AAA client/authenticator and the backend authentication server, the security mechanisms vary.
RADIUS[RFC2865]とDiameter[RFC3588]実装の両方が潜在的に別の固有識別文字をまねる凶暴な固有識別文字に被害を受け易いです。 両方のプロトコルがAAAクライアント/固有識別文字とバックエンド認証サーバの間の互いの認証をサポートしている間、セキュリティー対策は異なります。
In RADIUS, the shared secret used for authentication is determined by the source address of the RADIUS packet. However, when RADIUS Access-Requests are forwarded by a proxy, the NAS-IP-Address, NAS-Identifier, or NAS-IPv6-Address attributes received by the RADIUS server will not correspond to the source address. As noted in [RFC3579] Section 4.3.7, if the first-hop proxy does not check the NAS identification attributes against the source address in the Access-Request packet, it is possible for a rogue authenticator to forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162], or NAS-Identifier [RFC2865] attributes in order to impersonate another authenticator; attributes such as the Called-Station-Id [RFC2865] and Calling-Station-Id [RFC2865] can be forged as well. Among other things, this can result in messages (and transported keying material) being sent to the wrong authenticator.
RADIUSでは、認証に使用される共有秘密キーはRADIUSパケットのソースアドレスで決定します。 しかしながら、RADIUS Access-要求がプロキシによって転送されるとき、RADIUSサーバによって受け取られたNAS IPアドレス、NAS-識別子、またはNAS-IPv6-アドレス属性はソースアドレスと食い違うでしょう。 [RFC3579]セクション4.3.7で注意されるように、最初に、ホッププロキシがAccess-リクエスト・パケットのソースアドレスに対してNAS識別属性をチェックしないなら、凶暴な固有識別文字がNAS IPアドレス[RFC2865]、NAS-IPv6-アドレス[RFC3162]、またはNAS-識別子[RFC2865]属性を偽造するのは、別の固有識別文字をまねるために可能です。 また、Called駅のイド[RFC2865]やCalling駅のイド[RFC2865]などの属性を鍛造できます。 特に、これは、間違った固有識別文字に送りながら、メッセージ(そして、材料を合わせながら、輸送される)をもたらすことができます。
While [RFC3588] requires use of the Route-Record AVP, this utilizes Fully Qualified Domain Names (FQDNs), so that impersonation detection requires DNS A, AAAA, and PTR Resource Records (RRs) to be properly configured. As a result, Diameter is as vulnerable to this attack as RADIUS, if not more so. [RFC3579] Section 4.3.7 recommends mechanisms for impersonation detection; to prevent access to keying material by proxies without a "need to know", it is necessary to allow the backend authentication server to communicate with the authenticator directly, such as via the redirect functionality supported in [RFC3588].
[RFC3588]はRoute記録的なAVPの使用を必要としますが、これはFully Qualified Domain Names(FQDNs)を利用します、ものまね検出が、DNS A、AAAA、およびPTR Resource Records(RRs)が適切に構成されるのを必要とするように。 その結果、Diameterはこの攻撃に同じくらい被害を受け易いか、またはRADIUSよりそうです。 [RFC3579]セクション4.3 .7 ものまね検出のためにメカニズムを推薦します。 プロキシで「知る必要性」なしで材料を合わせることへのアクセスを防ぐのに、バックエンド認証サーバが固有識別文字で直接交信するのを許容するのが必要です、[RFC3588]でサポートされた再直接の機能性などで。
5.3.3. Channel Binding
5.3.3. チャンネル結合
It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This can enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via AAA or the lower layer).
感染しているか、または不十分に実装しているEAP固有識別文字がEAP同輩、そして/または、サーバに不正確な情報を伝えるのは、可能です。これは、バンドで出ているメカニズム(AAAか下層を通したなど)で、固有識別文字が別の固有識別文字をまねるか、または不正確な情報を伝えるのを可能にすることができます。
Aboba, et al. Standards Track [Page 56] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[56ページ]RFC5247EAP
Where EAP is used in pass-through mode, the EAP peer does not verify the identity of the pass-through authenticator within the EAP conversation. Within the Secure Association Protocol, the EAP peer and authenticator only demonstrate mutual possession of the transported keying material; they do not mutually authenticate. This creates a potential security vulnerability, described in [RFC3748] Section 7.15.
EAPが通じて通りモードで使用されるところでは、EAP同輩はEAPの会話の中で通じて通り固有識別文字のアイデンティティについて確かめません。 Secure Associationプロトコルの中では、EAP同輩と固有識別文字は材料を合わせながら、輸送の互いの所有物のデモをするだけです。 彼らは互いに認証しません。 これは[RFC3748]セクション7.15で説明された潜在的セキュリティの脆弱性を作成します。
As described in [RFC3579] Section 4.3.7, it is possible for a first-hop AAA proxy to detect a AAA client attempting to impersonate another authenticator. However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the backend authentication server while communicating misleading information to the EAP peer via the lower layer.
[RFC3579]セクション4.3.7で説明されるように、最初に、ホップAAAプロキシが、AAAのクライアントが、別の固有識別文字をまねるのを試みるのを検出するのは、可能です。 しかしながら、AAAのクライアントとして機能する通じて通り固有識別文字に、バックエンド認証サーバに正確な情報を提供するのは下層で紛らわしい情報をEAP同輩に伝えている間、可能です。
For example, a compromised authenticator can utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via the lower layer. Also, a pass-through authenticator acting as a AAA client can provide an incorrect peer Calling-Station-Id [RFC2865] [RFC3580] to the backend authentication server via the AAA protocol.
例えば、感染している固有識別文字は下層でEAP同輩とコミュニケートする際に別の固有識別文字のCalled駅のイドかNAS-識別子を利用できます。 また、AAAのクライアントとして機能する通じて通り固有識別文字はAAAプロトコルで不正確な同輩Calling駅のイド[RFC2865][RFC3580]をバックエンド認証サーバに提供できます。
As noted in [RFC3748] Section 7.15, this vulnerability can be addressed by EAP methods that support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865] [RFC3580], Calling-Station-Id [RFC2865] [RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162].
[RFC3748]セクション7.15に述べられるように、終点識別子などのチャンネルの特性の保護された交換をサポートするEAPメソッドでこの脆弱性を扱うことができます、(他)を含んでいて: 呼ばれた駅のイド[RFC2865][RFC3580]、呼んでいる駅のイド[RFC2865][RFC3580]、NAS-識別子[RFC2865]、NAS IPアドレス[RFC2865]、およびNAS-IPv6-アドレス[RFC3162。]
Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Typically, the EAP method imports channel binding parameters from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer or AAA layer. However, transport can occur from EAP server to peer, or can be bi-directional. On the side of the exchange (peer or server) where channel binding is verified, the lower layer or AAA layer passes the result of the verification (TRUE or FALSE) up to the EAP method. While the verification can be done either by the peer or the server, typically only the server has the knowledge to determine the correctness of the values, as opposed to merely verifying their equality. For further discussion, see [EAP-SERVICE].
そのような保護された交換を使用して、固有識別文字によってEAPメソッドの中で交換されたものに対するバンドで出ているメカニズムで提供されたチャンネル資産に匹敵するのは可能です。 EAPメソッドは、通常、同輩の上の下層からチャンネルに拘束力があるパラメタを意味して、しっかりとEAPサーバにそれらを伝えます。(それは、下層かAAA層にそれらをエクスポートします)。 しかしながら、輸送は、EAPサーバから同輩まで起こることができるか、または双方向である場合があります。 チャンネル結合が確かめられる交換(同輩かサーバ)の側では、下層かAAA層が検証(TRUEかFALSE)の結果をEAPメソッドまで通過します。 同輩かサーバで確かめることができますが、サーバだけには通常、値の正当性を決定する知識があります、単にそれらの平等について確かめることと対照的に。 さらなる議論に関しては、[EAP-SERVICE]を見てください。
It is also possible to perform channel binding without transporting data over EAP, as described in [EAP-CHANNEL]. In this approach the EAP method includes channel binding parameters in the calculation of exported EAP keying material, making it impossible for the peer and
また、[EAP-CHANNEL]で説明されるようにEAPの上でデータを輸送しないでチャンネル結合を実行するのも可能です。 そしてこのアプローチでは、EAPメソッドは材料を合わせるエクスポートしているEAPの計算にパラメタを縛るチャンネルを含んでいます、それを同輩にとって不可能にして。
Aboba, et al. Standards Track [Page 57] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[57ページ]RFC5247EAP
authenticator to complete the Secure Association Protocol if there is a mismatch in the channel binding parameters. However, this approach can only be applied where methods generating EAP keying material are used along with lower layers that utilize EAP keying material. For example, this mechanism would not enable verification of channel binding on wired IEEE 802 networks using [IEEE-802.1X].
そこであるなら、パラメタを縛るチャンネルでSecure Associationプロトコルを完成する固有識別文字はミスマッチです。 しかしながら、材料を合わせながら、材料を合わせるEAPを生成するメソッドがEAPを利用する下層と共に使用されるところにこのアプローチを適用できるだけです。 例えば、このメカニズムは、[IEEE-802.1X]を使用することでワイヤードなIEEE802ネットワークにおけるチャンネル結合の検証を可能にしないでしょう。
5.3.4. Mutual Authentication
5.3.4. 互いの認証
[RFC3748] Section 7.2.1 describes the "mutual authentication" and "dictionary attack resistance" claims, and [RFC4017] requires EAP methods satisfying these claims. EAP methods complying with [RFC4017] therefore provide for mutual authentication between the EAP peer and server.
[RFC3748]セクション7.2 .1 EAP同輩とサーバの間で「互いの認証」と「辞書攻撃抵抗」クレームについて説明して、したがって. [RFC4017]に従うEAPメソッドが互いの認証に備えるというこれらのクレームを満たすEAPメソッドを必要とします[RFC4017]。
[RFC3748] Section 7.2.1 also describes the "Cryptographic binding" security claim, and [RFC4017] Section 2.2 requires support for this claim. As described in [EAP-BINDING], EAP method sequences and compound authentication mechanisms can be subject to man-in-the-middle attacks. When such attacks are successfully carried out, the attacker acts as an intermediary between a victim and a legitimate authenticator. This allows the attacker to authenticate successfully to the authenticator, as well as to obtain access to the network.
[RFC3748]セクション7.2 .1 また、このクレームのセクション2.2が必要とする「暗号の結合」セキュリティクレーム、および[RFC4017]サポートについて説明します。 [EAP-BINDING]で説明されるように、EAPメソッド系列と複合認証機構は介入者攻撃を受けることがある場合があります。 そのような攻撃が首尾よく行われるとき、攻撃者は犠牲者と正統の固有識別文字の間の仲介者として務めます。 これはネットワークへのアクセスを得るほど噴出するように首尾よく固有識別文字に認証する攻撃者を許容します。
In order to prevent these attacks, [EAP-BINDING] recommends derivation of a compound key by which the EAP peer and server can prove that they have participated in the entire EAP exchange. Since the compound key MUST NOT be known to an attacker posing as an authenticator, and yet must be derived from EAP keying material, it MAY be desirable to derive the compound key from a portion of the EMSK. Where this is done, in order to provide proper key hygiene, it is RECOMMENDED that the compound key used for man-in-the-middle protection be cryptographically separate from other keys derived from the EMSK.
これらの攻撃を防ぐために、[EAP-BINDING]はEAP同輩とサーバが全体のEAP交換に参加したと立証できる合成キーの派生を推薦します。 合成キーを固有識別文字のふりをしている攻撃者にとって知っていてはいけませんが、材料を合わせるEAPから得なければならないので、EMSKの一部から主要な化合物を引き出すのは望ましいかもしれません。 これが完了しているところでは、中央の男性保護に使用される合成キーがEMSKから得られた他のキーから暗号で分離することであることは、適切な主要な衛生を提供するRECOMMENDEDです。
Diameter [RFC3588] provides for per-packet authentication and integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also provides for per-packet authentication and integrity protection. Where the authenticator/AAA client and backend authentication server communicate directly and credible key wrap is used (see Section 3.8), this ensures that the AAA Key Transport (phase 1b) achieves its security objectives: mutually authenticating the AAA client/authenticator and backend authentication server and providing transported keying material to the EAP authenticator and to no other party.
直径[RFC3588]はIPsecかTLSを通して1パケットあたりの認証と保全保護に備えます、そして、また、RADIUS/EAP[RFC3579]は1パケットあたりの認証と保全保護に備えます。 固有識別文字/AAAのクライアントとバックエンド認証サーバが直接伝達して、確かな主要な包装が使用されているところでは(セクション3.8を見てください)、これは、AAA Key Transport(フェーズ1b)がセキュリティ目的を達成するのを確実にします: 互いに、EAP固有識別文字と、そして、どんな相手にも材料を合わせないことで輸送されたAAAクライアント/固有識別文字、バックエンド認証サーバ、および提供を認証します。
Aboba, et al. Standards Track [Page 58] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[58ページ]RFC5247EAP
[RFC2607] Section 7 describes the security issues occurring when the authenticator/AAA client and backend authentication server do not communicate directly. Where a AAA intermediary is present (such as a RADIUS proxy or a Diameter agent), and data object security is not used, transported keying material can be recovered by an attacker in control of the intermediary. As discussed in Section 2.1, unless the TSKs are derived independently from EAP keying material (as in IKEv2), possession of transported keying material enables decryption of data traffic sent between the peer and the authenticator to whom the keying material was transported. It also allows the AAA intermediary to impersonate the authenticator or the peer. Since the peer does not authenticate to a AAA intermediary, it has no ability to determine whether it is authentic or authorized to obtain keying material.
[RFC2607]セクション7は固有識別文字/AAAのクライアントとバックエンド認証サーバが直接伝達しないとき起こる安全保障問題について説明します。 AAAの仲介者が出席していて(RADIUSプロキシかDiameterエージェントなどの)、データ・オブジェクトセキュリティが使用されていないところでは、攻撃者は仲介者のコントロールで輸送された合わせることの材料を回収できます。 セクション2.1で議論するように、TSKsが材料を合わせるEAPから独自に得られない場合(IKEv2のように)、輸送された合わせることの材料の所持は同輩と固有識別文字に間合わせることの材料が輸送された送られたデータ通信量の復号化を可能にします。 また、それで、AAAの仲介者は固有識別文字か同輩をまねることができます。 以来、同輩が認証しない、AAAの仲介者に、それは合わせることの材料を得るのが正統であるか、または認可されているかを決定する能力を全く持っていません。
However, as long as transported keying material or keys derived from it are only utilized by a single authenticator, compromise of the transported keying material does not enable an attacker to impersonate the peer to another authenticator. Vulnerability to compromise of a AAA intermediary can be mitigated by implementation of redirect functionality, as described in [RFC3588] and [RFC4072].
しかしながら、輸送されて、材料を合わせるか、それから得られたキーがただ一つの固有識別文字によって利用されるだけであり、材料を合わせる輸送の感染は、攻撃者が別の固有識別文字に同輩をまねるのを可能にしません。 再直接の機能性の実装でAAAの仲介者の感染への脆弱性を緩和できます、[RFC3588]と[RFC4072]で説明されるように。
The Secure Association Protocol does not provide for mutual authentication between the EAP peer and authenticator, only mutual proof of possession of transported keying material. In order for the peer to verify the identity of the authenticator, mutual proof of possession needs to be combined with impersonation prevention and channel binding. Impersonation prevention (described in Section 5.3.2) enables the backend authentication server to determine that the transported keying material has been provided to the correct authenticator. When utilized along with impersonation prevention, channel binding (described in Section 5.3.3) enables the EAP peer to verify that the EAP server has authorized the authenticator to possess the transported keying material. Completion of the Secure Association Protocol exchange demonstrates that the EAP peer and the authenticator possess the transported keying material.
Secure AssociationプロトコルはEAP同輩と固有識別文字(輸送された合わせることの材料の所持の互いの証拠だけ)の間の互いの認証に備えません。 同輩が固有識別文字のアイデンティティについて確かめるように、所有物の互いの証拠は、ものまね防止とチャンネル結合に結合される必要があります。 ものまね防止(セクション5.3.2では、説明される)は、バックエンド認証サーバが、輸送された合わせることの材料が正しい固有識別文字に提供されたことを決定するのを可能にします。 ものまね防止と共に利用されると、チャンネル結合(セクション5.3.3では、説明される)は、EAP同輩が、EAPサーバが、材料を合わせながら固有識別文字が輸送を所有しているのを認可したことを確かめるのを可能にします。 Secure Associationプロトコル交換の完成は、EAP同輩と固有識別文字が材料を合わせながら輸送を所有しているのを示します。
5.4. Key Binding
5.4. 主要な結合
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの義務的な要件:
Bind key to its context
文脈に主要なひも
Keying material MUST be bound to the appropriate context. The
context includes the following:
適切な関係に材料を合わせるのを縛らなければなりません。 文脈は以下を含んでいます:
o The manner in which the keying material is expected to be used.
o 合わせることの材料が使用されると予想される方法。
Aboba, et al. Standards Track [Page 59] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[59ページ]RFC5247EAP
o The other parties that are expected to have access to the
keying material.
o アクセスを合わせるのに物質的にすると予想される相手。
o The expected lifetime of the keying material. Lifetime of a
child key SHOULD NOT be greater than the lifetime of its parent
in the key hierarchy.
o 合わせることの材料の予想された生涯。 子供の寿命は親の生涯より長いコネが主要な階層構造であったならSHOULD NOTを合わせます。
Any party with legitimate access to keying material can determine
its context. In addition, the protocol MUST ensure that all
parties with legitimate access to keying material have the same
context for the keying material. This requires that the parties
are properly identified and authenticated, so that all of the
parties that have access to the keying material can be determined.
材料を合わせることへの正統のアクセスがあるどんなパーティーも文脈を決定できます。 さらに、プロトコルは、材料を合わせることへの正統のアクセスがあるすべてのパーティーには合わせることの材料のための同じ文脈があるのを確実にしなければなりません。 これは、パーティーが適切に特定されて、認証されるのを必要とします、合わせることの材料に近づく手段を持っているパーティーのすべてが決定できるように。
The context will include the peer and NAS identities in more than
one form. One (or more) name form is needed to identify these
parties in the authentication exchange and the AAA protocol.
Another name form may be needed to identify these parties within
the lower layer that will employ the session key.
文脈は1つ以上のフォームに同輩とNASのアイデンティティを含むでしょう。 1つ(さらに)の名前フォームが、認証交換とAAAプロトコルにおけるこれらのパーティーを特定するのに必要です。 別の名前フォームが、セッションキーを使う下層の中でこれらのパーティーを特定するのに必要であるかもしれません。
Within EAP, exported keying material (MSK, EMSK,IV) is bound to the Peer-Id(s) and Server-Id(s), which are exported along with the keying material. However, not all EAP methods support authenticated server identities (see Appendix A).
材料を合わせながらエクスポートされたEAPの中では、(MSK、EMSK、IV)はPeer-イドとServer-イドに縛られます。(それは、合わせることの材料と共にエクスポートされます)。 しかしながら、すべてのEAPメソッドサポートがサーバのアイデンティティを認証したというわけではありません(Appendix Aを見てください)。
Within the AAA protocol, transported keying material is destined for the EAP authenticator identified by the NAS-Identifier Attribute within the request, and is for use by the EAP peer identified by the Peer-Id(s), User-Name [RFC2865], or Chargeable User Identity (CUI) [RFC4372] attributes. The maximum lifetime of the transported keying material can be provided, as discussed in Section 3.5.1. Key usage restrictions can also be included as described in Section 3.2. Key lifetime issues are discussed in Sections 3.3, 3.4, and 3.5.
材料を合わせながら輸送されたAAAプロトコルの中に、Peer-イド、User-名前[RFC2865]、またはChargeable User Identity(CUI)[RFC4372]属性によって特定された同輩は、要求の中でNAS-識別子Attributeによって特定されたEAP固有識別文字のために運命づけられていて、EAPによる使用のためにいます。 セクション3.5.1で議論するように材料を合わせる輸送の最大の生涯を提供できます。 また、セクション3.2で説明されるように主要な使用制限を含むことができます。 セクション3.3、3.4、および3.5で主要な生涯問題について議論します。
5.5. Authorization
5.5. 承認
Requirement: The Secure Association Protocol (phase 2) conversation may utilize different identifiers from the EAP conversation (phase 1a), so that binding between the EAP and Secure Association Protocol identities is REQUIRED.
要件: Secure Associationプロトコル(フェーズ2)の会話はEAPの会話と異なった識別子を利用するかもしれません。(フェーズ1a)、したがって、EAPとSecure Associationプロトコルのアイデンティティの間のその結合はREQUIREDです。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの義務的な要件:
Peer and authenticator authorization
同輩と固有識別文字承認
Peer and authenticator authorization MUST be performed. These
entities MUST demonstrate possession of the appropriate keying
material, without disclosing it. Authorization is REQUIRED
同輩と固有識別文字承認を実行しなければなりません。 それを明らかにしないで、これらの実体は適切な合わせることの材料の所持を示さなければなりません。 承認はREQUIREDです。
Aboba, et al. Standards Track [Page 60] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[60ページ]RFC5247EAP
whenever a peer associates with a new authenticator. The
authorization checking prevents an elevation of privilege attack,
and it ensures that an unauthorized authenticator is detected.
同輩が新しい固有識別文字と交際するときはいつも。 許可検査は特権攻撃の高度を防ぎます、そして、それは権限のない固有識別文字が検出されるのを確実にします。
Authorizations SHOULD be synchronized between the peer, NAS, and
backend authentication server. Once the AAA key management
protocol exchanges are complete, all of these parties should hold
a common view of the authorizations associated with the other
parties.
承認SHOULDが同輩の間で連動して、バックエンド認証サーバNAS、およびかつてのAAAかぎ管理プロトコル交換はそうです。完全です、これらのパーティーは皆、相手に関連しているとして承認の共通認識を保持するべきです。
In addition to authenticating all parties, key management
protocols need to demonstrate that the parties are authorized to
possess keying material. Note that proof of possession of keying
material does not necessarily prove authorization to hold that
keying material. For example, within an IEEE 802.11, the 4-way
handshake demonstrates that both the peer and authenticator
possess the same EAP keying material. However, by itself, this
possession proof does not demonstrate that the authenticator was
authorized by the backend authentication server to possess that
keying material. As noted in [RFC3579] in Section 4.3.7, where
AAA proxies are present, it is possible for one authenticator to
impersonate another, unless each link in the AAA chain implements
checks against impersonation. Even with these checks in place, an
authenticator may still claim different identities to the peer and
the backend authentication server. As described in [RFC3748]
Section 7.15, channel binding is required to enable the peer to
verify that the authenticator claim of identity is both consistent
and correct.
すべてのパーティーを認証することに加えて、かぎ管理プロトコルは、パーティーには合わせることの材料があるのに権限を与えられるのを示す必要があります。 合わせることの材料の所持の証拠が、材料を合わせながら承認がそれを保持すると必ず立証するというわけではないことに注意してください。 例えば、IEEE802.11の中では、4ウェイ握手は、同輩と固有識別文字の両方が材料を合わせる同じEAPを所有しているのを示します。 しかしながら、この所有物証拠自体は、バックエンド認証サーバによって固有識別文字が材料を合わせながらそれを所有しているのが認可されたのを示しません。 [RFC3579]にAAAプロキシが出席しているセクション4.3.7で述べられるように、1つの固有識別文字が別のものをまねるのは、可能です、AAAチェーン道具の各リンクがものまねに対してチェックしない場合。 これらのチェックさえ適所にある場合、固有識別文字はまだ同輩とバックエンド認証サーバへの異なったアイデンティティを要求しているかもしれません。[RFC3748]セクション7.15で説明されるように、チャンネル結合は、同輩が、アイデンティティの固有識別文字クレームがともに一貫していることを確かめるのを可能にするのが必要であり、正しいです。
Recommendation from [RFC4962] Section 3:
[RFC4962]セクション3からの推薦:
Authorization restriction
承認制限
If peer authorization is restricted, then the peer SHOULD be made
aware of the restriction. Otherwise, the peer may inadvertently
attempt to circumvent the restriction. For example, authorization
restrictions in an IEEE 802.11 environment include:
承認は同輩であるなら制限されて、次に、同輩はSHOULDです。制限を意識しているのに作られてください。 さもなければ、同輩は、制限を回避するのをうっかり試みるかもしれません。 例えば、IEEE802.11環境における承認制限は:
o Key lifetimes, where the keying material can only be used for a
certain period of time;
o ある期間の間、合わせることの材料を使用できるだけであるところの主要な生涯
o SSID restrictions, where the keying material can only be used
with a specific IEEE 802.11 SSID;
o SSID制限そこでは特定のIEEE802.11SSIDと共に合わせることの材料を使用できるだけです。
o Called-Station-ID restrictions, where the keying material can
only be used with a single IEEE 802.11 BSSID; and
o 呼ばれた駅のID制限そこでは独身のIEEE802.11BSSIDと共に合わせることの材料を使用できるだけです。 そして
Aboba, et al. Standards Track [Page 61] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[61ページ]RFC5247EAP
o Calling-Station-ID restrictions, where the keying material can
only be used with a single peer IEEE 802 MAC address.
o 802MACが扱う呼んでいる駅のID制限。(そこでは、独身の同輩IEEEと共に合わせることの材料を使用できるだけです)。
As described in Section 2.3, consistent identification of the EAP authenticator enables the EAP peer to determine the scope of keying material provided to an authenticator, as well as to confirm with the backend authentication server that an EAP authenticator proving possession of EAP keying material during the Secure Association Protocol was authorized to obtain it.
セクション2.3で説明されるように、EAP固有識別文字の一貫した識別は、EAP同輩が、固有識別文字に提供された合わせることの材料の範囲を決心して、バックエンド認証サーバでSecure Associationプロトコルの間に材料を合わせるEAPの所持を立証するEAP固有識別文字がそれを得るのが認可されたと確認するのを可能にします。
Within the AAA protocol, the authorization attributes are bound to the transported keying material. While the AAA exchange provides the AAA client/authenticator with authorizations relating to the EAP peer, neither the EAP nor AAA exchanges provide authorizations to the EAP peer. In order to ensure that all parties hold the same view of the authorizations, it is RECOMMENDED that the Secure Association Protocol enable communication of authorizations between the EAP authenticator and peer.
AAAプロトコルの中では、承認属性は材料を合わせる輸送に縛られます。 AAA交換がEAP同輩に関連する承認をAAAクライアント/固有識別文字に提供している間、EAPも交換が承認を供給するAAAもEAPとしてじっと見ません。 すべてのパーティーが承認の同じ視点を保持するのを確実にするために、Secure AssociationプロトコルがEAP固有識別文字と同輩の間の承認に関するコミュニケーションを可能にするのは、RECOMMENDEDです。
In lower layers where the authenticator consistently identifies itself to the peer and backend authentication server and the EAP peer completes the Secure Association Protocol exchange with the same authenticator through which it completed the EAP conversation, authorization of the authenticator is demonstrated to the peer by mutual authentication between the peer and authenticator as discussed in the previous section. Identification issues are discussed in Sections 2.3, 2.4, and 2.5 and key scope issues are discussed in Section 3.2.
固有識別文字が一貫して同輩とバックエンド認証サーバにそれ自体を特定して、EAP同輩がそれがEAPの会話を終了したのと同じ固有識別文字でSecure Associationプロトコル交換を終了する低級層では、固有識別文字の承認は前項で議論するように同輩と固有識別文字の間の互いの認証で同輩に示されます。 セクション2.3、2.4、および2.5で識別問題について議論します、そして、セクション3.2で主要な範囲問題について議論します。
Where the EAP peer utilizes different identifiers within the EAP method and Secure Association Protocol conversations, peer authorization can be difficult to demonstrate to the authenticator without additional restrictions. This problem does not exist in IKEv2 where the Identity Payload is used for peer identification both within IKEv2 and EAP, and where the EAP conversation is cryptographically protected within IKEv2 binding the EAP and IKEv2 exchanges. However, within [IEEE-802.11], the EAP peer identity is not used within the 4-way handshake, so that it is necessary for the authenticator to require that the EAP peer utilize the same MAC address for EAP authentication as for the 4-way handshake.
EAP同輩がEAPメソッドとSecure Associationプロトコルの会話の中で異なった識別子を利用するところでは、同輩承認は追加制限なしで固有識別文字に示すのが難しい場合があります。 この問題はIdentity有効搭載量が同輩識別にIKEv2とEAPの中で使用されて、EAPの会話がEAPを縛るIKEv2とIKEv2交換の中に暗号で保護されるIKEv2に存在していません。 しかしながら、EAP同輩のアイデンティティは4ウェイ握手の中で[IEEE-802.11]の中では、使用されません、固有識別文字が、EAP同輩が4ウェイ握手のようにEAP認証のための同じMACアドレスを利用するのを必要とするのが必要であるように。
Aboba, et al. Standards Track [Page 62] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[62ページ]RFC5247EAP
5.6. Replay Protection
5.6. 反復操作による保護
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの義務的な要件:
Replay detection mechanism
再生検出メカニズム
The AAA key management protocol exchanges MUST be replay
protected, including AAA, EAP and Secure Association Protocol
exchanges. Replay protection allows a protocol message recipient
to discard any message that was recorded during a previous
legitimate dialogue and presented as though it belonged to the
current dialogue.
AAAかぎ管理プロトコル交換はAAA、EAP、およびSecure Associationプロトコル交換を含んでいて、保護された再生であるに違いありません。 反復操作による保護で、プロトコルメッセージ受取人はまるで現在の対話に属すかのように前の正統の対話の間、記録されて、提示されたどんなメッセージも捨てることができます。
[RFC3748] Section 7.2.1 describes the "replay protection" security claim, and [RFC4017] Section 2.2 requires use of EAP methods supporting this claim.
[RFC3748]セクション7.2 .1 このクレームをサポートするEAPメソッドのセキュリティが要求して、[RFC4017]セクション2.2が必要とする「反復操作による保護」使用について説明します。
Diameter [RFC3588] provides support for replay protection via use of IPsec or TLS. "RADIUS Support for EAP" [RFC3579] protects against replay of keying material via the Request Authenticator. According to [RFC2865] Section 3:
直径[RFC3588]はIPsecかTLSの使用で反復操作による保護のサポートを提供します。 「EAPのためのRADIUS Support」[RFC3579]はRequest Authenticatorを通して合わせることの材料の再生から守ります。 [RFC2865]セクション3によると:
In Access-Request Packets, the Authenticator value is a 16 octet
random number, called the Request Authenticator.
Packets、Authenticator値はAccess-要求では、16八重奏です。Request Authenticatorと呼ばれる乱数。
However, some RADIUS packets are not replay protected. In Accounting, Disconnect, and Care-of Address (CoA)-Request packets, the Request Authenticator contains a keyed Message Integrity Code (MIC) rather than a nonce. The Response Authenticator in Accounting, Disconnect, and CoA-Response packets also contains a keyed MIC whose calculation does not depend on a nonce in either the Request or Response packets. Therefore, unless an Event-Timestamp attribute is included or IPsec is used, it is possible that the recipient will not be able to determine whether these packets have been replayed. This issue is discussed further in [RFC5176] Section 6.3.
しかしながら、いくつかのRADIUSパケットは保護された再生ではありません。 そして、Accounting、DisconnectでCare、-、Address(CoA)リクエスト・パケット、Request Authenticatorは一回だけよりむしろ合わせられたMessage Integrity Code(MIC)を含んでいます。 また、Accounting、Disconnect、およびCoA-応答パケットのResponse AuthenticatorはRequestかResponseパケットに計算が一回だけによらない合わせられたMICを含んでいます。 したがって、Event-タイムスタンプ属性が含まれているか、またはIPsecが使用されていない場合、受取人が、これらのパケットが再演されたかどうか決定できないのは、可能です。 [RFC5176]セクション6.3で、より詳しくこの問題について議論します。
In order to prevent replay of Secure Association Protocol frames, replay protection is REQUIRED on all messages. [IEEE-802.11] supports replay protection on all messages within the 4-way handshake; IKEv2 [RFC4306] also supports this.
Secure Associationプロトコルフレームの再生を防ぐために、反復操作による保護はすべてのメッセージのREQUIREDです。 [IEEE-802.11]は4ウェイ握手の中ですべてのメッセージで反復操作による保護をサポートします。 また、IKEv2[RFC4306]はこれをサポートします。
Aboba, et al. Standards Track [Page 63] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[63ページ]RFC5247EAP
5.7. Key Freshness
5.7. 主要な新しさ
Requirement: A session key SHOULD be considered compromised if it remains in use beyond its authorized lifetime. Mandatory requirement from [RFC4962] Section 3:
要件: 認可された生涯使用中であり残っているなら感染された状態で考えられて、セッションはSHOULDを合わせます。 [RFC4962]セクション3からの義務的な要件:
Strong, fresh session keys
強くて、新鮮なセッションキー
While preserving algorithm independence, session keys MUST be
strong and fresh. Each session deserves an independent session
key. Fresh keys are required even when a long replay counter
(that is, one that "will never wrap") is used to ensure that loss
of state does not cause the same counter value to be used more
than once with the same session key.
アルゴリズム独立を保存している間、セッションキーは、強くて、新鮮であるに違いありません。 各セッションは独立しているセッションキーに値します。 長い再生カウンタ(すなわち、それが「決して包装しない」1つ)が同じセッションキーによる一度ほど状態の損失で同じ対価を使用しないのを保証するのに使用さえされるとき、新鮮なキーが必要です。
Some EAP methods are capable of deriving keys of varying strength,
and these EAP methods MUST permit the generation of keys meeting a
minimum equivalent key strength. 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 [SP800-57].
いくつかのEAPメソッドが異なった強さのキーを派生させることができます、そして、これらのEAPメソッドは最小の同等な主要な強さを達成するキーの世代を可能にしなければなりません。 BCP86[RFC3766]は適切な主要なサイズでアドバイスします。 また、StandardsとTechnology(NIST)のためのNational Instituteは[SP800-57]の適切な主要なサイズでアドバイスします。
A fresh cryptographic key is one that is generated specifically
for the intended use. In this situation, a secure association
protocol is used to establish session keys. The AAA protocol and
EAP method MUST ensure that the keying material supplied as an
input to session key derivation is fresh, and the secure
association protocol MUST generate a separate session key for each
session, even if the keying material provided by EAP is cached. A
cached key persists after the authentication exchange has
completed. For the AAA/EAP server, key caching can happen when
state is kept on the server. For the NAS or client, key caching
can happen when the NAS or client does not destroy keying material
immediately following the derivation of session keys.
新鮮な暗号化キーは特に意図している使用のために生成されるものです。 この状況で、安全な協会プロトコルは、セッションキーを証明するのに使用されます。 AAAプロトコルとEAPメソッドは、材料が入力としてセッションの主要な派生に供給した合わせるのが新鮮であり、安全な協会プロトコルが各セッションのために主要な別々のセッションを生成しなければならないのを確実にしなければなりません、EAPによって供給された合わせることの材料がキャッシュされても。 キャッシュされたキーは交換が終了した認証の後に持続します。 状態がサーバに維持されるとき、AAA/EAPサーバのために、主要なキャッシュは起こることができます。NASかクライアントがすぐに合わせることの材料を破壊しないとき、NASかクライアントに関して、セッションキーの派生に続いて、主要なキャッシュは起こることができます。
Session keys MUST NOT be dependent on one another. Multiple
session keys may be derived from a higher-level shared secret as
long as a one-time value, usually called a nonce, is used to
ensure that each session key is fresh. The mechanism used to
generate session keys MUST ensure that the disclosure of one
session key does not aid the attacker in discovering any other
session keys.
セッションキーはお互いに依存しているはずがありません。 1回の通常、一回だけと呼ばれた値がそれぞれのセッションキーが確実に新鮮になるようにするのに使用される限り、よりハイレベルの共有秘密キーから複数のセッションキーを得るかもしれません。 セッションキーを生成するのに使用されるメカニズムは、1個のセッションキーの公開がいかなる他のセッションキーも発見する際に攻撃者を支援しないのを確実にしなければなりません。
EAP, AAA, and the lower layer each bear responsibility for ensuring the use of fresh, strong session keys. EAP methods need to ensure the freshness and strength of EAP keying material provided as an input to session key derivation. [RFC3748] Section 7.10 states:
EAP、AAA、およびそれぞれ下層は、新鮮で、強いセッションキーの使用を確実にするために責任を負います。 EAPメソッドは、入力としてセッションの主要な派生に提供された材料を合わせるEAPの新しさと強さを確実にする必要があります。 [RFC3748]セクション7.10州:
Aboba, et al. Standards Track [Page 64] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[64ページ]RFC5247EAP
EAP methods SHOULD ensure the freshness of the MSK and EMSK, even
in cases where one party may not have a high quality random number
generator. A RECOMMENDED method is for each party to provide a
nonce of at least 128 bits, used in the derivation of the MSK and
EMSK.
EAPメソッドSHOULDはMSKとEMSKの新しさを確実にします、1回のパーティーが高品質の乱数発生器を持っていないかもしれない場合でさえ。 RECOMMENDEDメソッドは各当事者が少なくとも128ビットの一回だけを提供することです、MSKとEMSKの派生では、使用されています。
The contribution of nonces enables the EAP peer and server to ensure that exported EAP keying material is fresh.
一回だけの貢献は、EAP同輩とサーバが材料を合わせるEAPであるとエクスポートされたそれが確実に新鮮になるようにするのを可能にします。
[RFC3748] Section 7.2.1 describes the "key strength" and "session independence" security claims, and [RFC4017] requires EAP methods supporting these claims as well as methods capable of providing equivalent key strength of 128 bits or greater. See Section 3.7 for more information on key strength.
[RFC3748]セクション7.2 .1 「主要な強さ」と「セッション独立」セキュリティクレームについて説明して、これらのクレームをと同様にサポートするEAPメソッドを必要とします[RFC4017]。 主要な強さの詳しい情報に関してセクション3.7を見てください。
The AAA protocol needs to ensure that transported keying material is fresh and is not utilized outside its recommended lifetime. Replay protection is necessary for key freshness, but an attacker can deliver a stale (and therefore potentially compromised) key in a replay-protected message, so replay protection is not sufficient. As discussed in Section 3.5, the Session-Timeout Attribute enables the backend authentication server to limit the exposure of transported keying material.
AAAプロトコルは、材料を合わせながら輸送されたそれが確実に新鮮になるようにするのが必要であり、お勧めの生涯、利用されません。 反復操作による保護が主要な新しさに必要ですが、攻撃者が再生で保護されたメッセージで聞き古した(したがって、潜在的に感染されます)のキーを提供できるので、反復操作による保護は十分ではありません。 セクション3.5で議論するように、Session-タイムアウトAttributeは、バックエンド認証サーバが輸送された合わせることの材料の展示を制限するのを可能にします。
The EAP Session-Id, described in Section 1.4, enables the EAP peer, authenticator, and server to distinguish EAP conversations. However, unless the authenticator keeps track of EAP Session-Ids, the authenticator cannot use the Session-Id to guarantee the freshness of keying material.
セクション1.4で説明されたEAP Session-イドは、EAP同輩、固有識別文字、およびサーバがEAPの会話を区別するのを可能にします。 しかしながら、固有識別文字がEAP Session-イドの動向をおさえない場合、固有識別文字は、材料を合わせる新しさを保証するのにSession-イドを使用できません。
The Secure Association Protocol, described in Section 3.1, MUST generate a fresh session key for each session, even if the EAP keying material and parameters provided by methods are cached, or either the peer or authenticator lack a high entropy random number generator. A RECOMMENDED method is for the peer and authenticator to each provide a nonce or counter used in session key derivation. If a nonce is used, it is RECOMMENDED that it be at least 128 bits. While [IEEE-802.11] and IKEv2 [RFC4306] satisfy this requirement, [IEEE-802.16e] does not, since randomness is only contributed from the Base Station.
セクション3.1で説明されたSecure Associationプロトコルは各セッションのために主要な新鮮なセッションを生成しなければなりません、メソッドで供給された材料とパラメタを合わせるEAPがキャッシュされていて同輩であるか固有識別文字不足が高いエントロピー乱数発生器であっても。 RECOMMENDEDメソッドは同輩と固有識別文字がそれぞれセッションの主要な派生に使用される一回だけかカウンタを提供することです。 一回だけが使用されているなら、それが少なくとも128ビットであることはRECOMMENDEDです。 [IEEE-802.11]とIKEv2[RFC4306]がこの要件を満たしている間、基地の駅から偶発性を寄付するだけであって、[IEEE-802.16e]は満たしません。
Aboba, et al. Standards Track [Page 65] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[65ページ]RFC5247EAP
5.8. Key Scope Limitation
5.8. 主要な範囲制限
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの義務的な要件:
Limit key scope
限界キー範囲
Following the principle of least privilege, parties MUST NOT have
access to keying material that is not needed to perform their
role. A party has access to a particular key if it has access to
all of the secret information needed to derive it.
最少の特権の原則に従って、パーティーは彼らの役割を実行するのに必要でない材料を合わせるのにアクセスを持ってはいけません。 それを引き出すのに必要である秘密の情報のすべてに近づく手段を持っているなら、パーティーは特定のキーに近づく手段を持っています。
Any protocol that is used to establish session keys MUST specify
the scope for session keys, clearly identifying the parties to
whom the session key is available.
セッションキーを証明するのに使用されるどんなプロトコルもセッションキーに範囲を指定しなければなりません、明確に、セッションキーが利用可能であるパーティーを特定して。
Transported keying material is permitted to be accessed by the EAP peer, authenticator and server. The EAP peer and server derive EAP keying material during the process of mutually authenticating each other using the selected EAP method. During the Secure Association Protocol exchange, the EAP peer utilizes keying material to demonstrate to the authenticator that it is the same party that authenticated to the EAP server and was authorized by it. The EAP authenticator utilizes the transported keying material to prove to the peer not only that the EAP conversation was transported through it (this could be demonstrated by a man-in-the-middle), but that it was uniquely authorized by the EAP server to provide the peer with access to the network. Unique authorization can only be demonstrated if the EAP authenticator does not share the transported keying material with a party other than the EAP peer and server. TSKs are permitted to be accessed only by the EAP peer and authenticator (see Section 1.5); TSK derivation is discussed in Section 2.1. Since demonstration of authorization within the Secure Association Protocol exchange depends on possession of transported keying material, the backend authentication server can obtain TSKs unless it deletes the transported keying material after sending it.
EAP同輩、固有識別文字、およびサーバによって輸送された合わせることの材料がアクセスされることが許可されています。EAP同輩とサーバは選択されたEAPメソッドを使用することで互いに互いを認証するプロセスの間に材料を合わせるEAPを引き出します。 Secure Associationプロトコル交換の間、EAP同輩は、それがそれによってEAPサーバに認証している、認可されたのと同じパーティーであることを固有識別文字に示すのに合わせることの材料を利用します。 EAP固有識別文字は、EAPの会話がそれを通して輸送されなかっただけが(中央の男性はこれを示すことができました)、EAPサーバによってネットワークへのアクセスを同輩に提供するのが唯一認可されたと同輩に立証するために材料を合わせながら、輸送を利用します。 EAP固有識別文字がEAP同輩とサーバ以外のパーティーに伴う材料を合わせながら輸送を共有しない場合にだけ、ユニークな承認を示すことができます。EAP同輩と固有識別文字だけによってTSKsがアクセスされることが許可されています(セクション1.5を見てください)。 セクション2.1でTSK派生について議論します。 Secure Associationプロトコル交換の中の承認のデモンストレーションが輸送された合わせることの材料の所持によるので、それを送った後に材料を合わせながら輸送を削除しない場合、バックエンド認証サーバはTSKsを入手できます。
5.9. Key Naming
5.9. 主要な命名
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]セクション3からの義務的な要件:
Uniquely named keys
唯一キーと命名されます。
AAA key management proposals require a robust key naming scheme,
particularly where key caching is supported. The key name
provides a way to refer to a key in a protocol so that it is clear
to all parties which key is being referenced. Objects that cannot
be named cannot be managed. All keys MUST be uniquely named, and
the key name MUST NOT directly or indirectly disclose the keying
AAAかぎ管理提案は主要なキャッシュがサポートされる特にところで強健な主要な命名体系を必要とします。 主要な名前がプロトコルでキーについて言及する方法を提供するので、すべてのパーティーにおいて、どのキーが参照をつけられているかは、明確です。 命名できないオブジェクトに対処できません。 唯一すべてのキーを命名しなければなりません、そして、主要な名前は直接か間接的に合わせることを明らかにしてはいけません。
Aboba, et al. Standards Track [Page 66] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[66ページ]RFC5247EAP
material. If the key name is not based on the keying material,
then one can be sure that it cannot be used to assist in a search
for the key value.
材料。 主要な名前が合わせることの材料に基づいていないなら、1つはキー値の検索を助けるのにそれを使用できないのを確信している場合があります。
EAP key names (defined in Section 1.4.1), along with the Peer-Id(s) and Server-Id(s), uniquely identify EAP keying material, and do not directly or indirectly expose EAP keying material.
EAPの主要な名(セクション1.4.1では、定義される)は、Peer-イドとServer-イドと共に材料を合わせるEAPを唯一特定して、直接か間接的に材料を合わせるEAPを暴露しません。
Existing AAA server implementations do not distribute key names along with the transported keying material. However, Diameter EAP [RFC4072] Section 4.1.4 defines the EAP-Key-Name AVP for the purpose of transporting the EAP Session-Id. Since the EAP-Key-Name AVP is defined within the RADIUS attribute space, it can be used either with RADIUS or Diameter.
既存のAAAサーバ実装は、輸送と共に材料を合わせながら、主要な名前を分配しません。 しかしながら、Diameter EAP[RFC4072]部4.1の.4はEAP Session-アイダホ州を輸送する目的のためにEAPの主要な名のAVPを定義します。 EAPの主要な名のAVPがRADIUS属性スペースの中で定義されるので、RADIUSかDiameterと共にそれを使用できます。
Since the authenticator is not provided with the name of the transported keying material by existing backend authentication server implementations, existing Secure Association Protocols do not utilize EAP key names. For example, [IEEE-802.11] supports PMK caching; to enable the peer and authenticator to determine the cached PMK to utilize within the 4-way handshake, the PMK needs to be named. For this purpose, [IEEE-802.11] utilizes a PMK naming scheme that is based on the key. Since IKEv2 [RFC4306] does not cache transported keying material, it does not need to refer to transported keying material.
輸送の名前が既存のバックエンド認証サーバ実装で材料を合わせながら固有識別文字に提供されないので、既存のSecure AssociationプロトコルはEAPの主要な名を利用しません。 例えば、[IEEE-802.11]はPMKキャッシュをサポートします。 同輩とキャッシュされたPMKが4ウェイ握手の中で利用することを決定する固有識別文字、PMKを有効にするのは、命名される必要があります。 このために、[IEEE-802.11]はキーに基づいているPMK命名体系を利用します。 IKEv2[RFC4306]が輸送された合わせることの材料をキャッシュしないので、それは輸送された合わせることの材料について言及する必要はありません。
5.10. Denial-of-Service Attacks
5.10. サービス不能攻撃
Key caching can result in vulnerability to denial-of-service attacks. For example, EAP methods that create persistent state can be vulnerable to denial-of-service attacks on the EAP server by a rogue EAP peer.
主要なキャッシュはサービス不能攻撃への脆弱性をもたらすことができます。 例えば、永続的な状態を創設するEAPメソッドはEAPサーバで凶暴なEAP同輩でサービス不能攻撃に被害を受け易い場合があります。
To address this vulnerability, EAP methods creating persistent state can limit the persistent state created by an EAP peer. For example, for each peer an EAP server can choose to limit persistent state to a few EAP conversations, distinguished by the EAP Session-Id. This prevents a rogue peer from denying access to other peers.
この脆弱性を扱うために、永続的な状態を創設するEAPメソッドはEAP同輩によって創設された永続的な状態を制限できます。 例えば、各同輩のために、EAPサーバは、永続的な状態をEAP Session-アイダホ州によって区別されたいくつかのEAPの会話に制限するのを選ぶことができます。 これによって、凶暴な同輩は他の同輩へのアクセスを拒絶できません。
Similarly, to conserve resources an authenticator can choose to limit the persistent state corresponding to each peer. This can be accomplished by limiting each peer to persistent state corresponding to a few EAP conversations, distinguished by the EAP Session-Id.
同様に、資源を節約するために、固有識別文字は、永続的な州の対応を各同輩に制限するのを選ぶことができます。 各同輩をいくつかのEAPの会話に対応する、EAP Session-アイダホ州で顕著な永続的な状態に制限することによって、これを達成できます。
Whether creation of new TSKs implies deletion of previously derived TSKs depends on the EAP lower layer. Where there is no implied deletion, the authenticator can choose to limit the number of TSKs and associated state that can be stored for each peer.
新しいTSKsの作成が以前に派生しているTSKsの削除を含意するかどうかがEAPの低級層によります。 どんな暗示している削除もないところでは、固有識別文字は、各同輩のために保存できるTSKsの数と準国家を制限するのを選ぶことができます。
Aboba, et al. Standards Track [Page 67] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[67ページ]RFC5247EAP
6. References
6. 参照
6.1. Normative References
6.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月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3748] AbobaとB.とBlunkとL.とVollbrechtとJ.とカールソン、J.とH.Levkowetz、エド、「拡張認証プロトコル(EAP)」、RFC3748(2004年6月)
[RFC4962] Housley, R. and B. Aboba, "Guidance for
Authentication, Authorization, and Accounting (AAA)
Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley、R.とB.Aboba、「認証、承認、および会計(AAA)Key Managementのための指導」BCP132、RFC4962(2007年7月)。
6.2. Informative References
6.2. 有益な参照
[8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff
in a Public Wireless LAN Based on IEEE 802.1x Model",
Proceedings of the IFIP TC6/WG6.8 Working Conference
on Personal Wireless Communications, p.175-182,
October 23-25, 2002.
[8021XPreAuth]パック(S.とY.チェ)は、「IEEE 802.1xモデルに基づく公共のワイヤレスのLANにおける速い移管をあらかじめ認証しました」、パーソナルWireless Communicationsの上のIFIP TC6/WG6.8 WorkingコンファレンスのProceedings、p.175-182、2002年10月23日〜25日。
[Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way
Handshake", Proceedings of the 2004 ACM Workshop on
Wireless Security, pp. 43-50, ISBN: 1-58113-925-X.
Wireless Security、ページの[分析]の彼とC.とJ.ミッチェル、「802.11i4ウェイ握手の分析」、2004ACM WorkshopのProceedings 43-50、ISBN: 1-58113-925X。
[Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A.,
Wang, H. and P. Schoo, "Fast Authentication Methods
for Handovers between IEEE 802.11 Wireless LANs",
Proceedings of the 2nd ACM international workshop on
Wireless mobile applications and services on WLAN
hotspots, October, 2004.
[Bargh] BarghとM.とHulseboschとR.とEertinkとE.とプラサードとA.とワングとH.とP.Schooと「IEEE802.11ワイヤレスのLANの間の身柄の引き渡しのための速い認証方法」とWirelessのモバイルアプリケーションに関する2番目のACMの国際的なワークショップのProceedingsとWLANホットスポット(2004年10月)におけるサービス。
[GKDP] Dondeti, L., Xiang, J., and S. Rowles, "GKDP: Group
Key Distribution Protocol", Work in Progress, March
2006.
[GKDP] Dondeti、L.、翔、J.、およびS.ラウルズ、「GKDP:」 「グループの主要な分配プロトコル」、進行中の仕事、2006年3月。
[He] He, C., Sundararajan, M., Datta, A. Derek, A. and J.
C. Mitchell, "A Modular Correctness Proof of TLS and
IEEE 802.11i", ACM Conference on Computer and
Communications Security (CCS '05), November, 2005.
[彼] 彼とC.とSundararajanとM.とダッタとA.デリックとA.とJ.C.ミッチェルと「TLSとIEEE 802.11iのモジュールの正当性の証明」とコンピュータの上のACMコンファレンスと通信秘密保全(CCS'05)(2005'年11月)。
Aboba, et al. Standards Track [Page 68] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[68ページ]RFC5247EAP
[IEEE-802.11] Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific Requirements
Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE Standard
802.11-2007, 2007.
[IEEE-802.11]米国電気電子技術者学会、「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--特定のRequirements Part11:、」 「ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、IEEE規格802.11-2007、2007。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers,
"Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X-2004,
December 2004.
[IEEE-802.1X]米国電気電子技術者学会、「地方とメトロポリタンエリアネットワーク:」 「ポートベースのネットワークアクセスコントロール」、IEEEの標準の802.1X-2004、2004年12月。
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area
Networks: Draft Standard for Virtual Bridged Local
Area Networks, P802.1Q-2003, January 2003.
地方とメトロポリタンエリアネットワークの[IEEE-802.1Q]IEEE規格: 2003年1月に仮想のブリッジしているローカル・エリア・ネットワーク、P802.1Q-2003の規格を作成してください。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN
Specific Requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications: Specification for Enhanced Security",
IEEE 802.11i/D1, 2001.
[IEEE-802.11i]米国電気電子技術者学会、「システムの間のテレコミュニケーションと情報交換--LAN/男性決められた一定の要求--パート11の規格に補ってください」 ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様: 「警備の強化のための仕様」、IEEE 802.11i/D1、2001。
[IEEE-802.11F] Institute of Electrical and Electronics Engineers,
"Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol
Across Distribution Systems Supporting IEEE 802.11
Operation", IEEE 802.11F, July 2003 (now deprecated).
2003(現在推奨しない)年7月の[IEEE-802.11F]の米国電気電子技術者学会、「Inter-アクセスPointプロトコルAcross Distribution Systems Supporting IEEE802.11Operationを通したMulti-ベンダーAccess Point Interoperabilityのためのお勧めのPractice」IEEE802.11F。
[IEEE-802.16e] Institute of Electrical and Electronics Engineers,
"IEEE Standard for Local and Metropolitan Area
Networks: Part 16: Air Interface for Fixed and Mobile
Broadband Wireless Access Systems: Amendment for
Physical and Medium Access Control Layers for Combined
Fixed and Mobile Operations in Licensed Bands" IEEE
802.16e, August 2005.
[IEEE-802.16e]米国電気電子技術者学会、「地方とメトロポリタンエリアネットワークのIEEE規格:」 パート16: 修理されてモバイルの広帯域のワイヤレス・アクセスシステムのためにインタフェースを放送してください: 「認可されたバンドにおける結合した修理されてモバイルの操作のための物理的で中型のアクセス制御層のための修正」IEEE 802.16e(2005年8月)。
[IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K.
Jang, "Proactive Key Distribution to support fast and
secure roaming", IEEE 802.11 Working Group, IEEE-03-
084r1-I, http://www.ieee802.org/11/Documents/
DocumentHolder/3-084.zip, January 2003.
[IEEE-03-084]Mishra(A.、Shin、M.、Arbaugh、W.、リー、I.、およびK.Jang)は「ローミングを速くサポートして、保証するためにKey Distributionを予測します」、IEEE802.11作業部会、IEEE-03- 084r1-I、 http://www.ieee802.org/11/Documents/ DocumentHolder/3-084.zip、2003年1月。
Aboba, et al. Standards Track [Page 69] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[69ページ]RFC5247EAP
[EAP-SERVICE] Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", Work in Progress, October 2005.
「拡張認証プロトコル(EAP)のための認証されたサービス情報」という[EAP-サービス]のArkko、J.、およびP.Eronenは進歩、2005年10月に働いています。
[SHORT-TERM] Friedman, A., Sheffer, Y., and A. Shaqed, "Short-Term
Certificates", Work in Progress, June 2007.
[短期的な] フリードマン、A.、シェーファー、Y.、およびA.Shaqed、「短期的な証明書」が進歩、2007年6月に働いています。
[HANDOFF] Arbaugh, W. and B. Aboba, "Handoff Extension to
RADIUS", Work in Progress, October 2003.
「半径への移管拡大」という[移管]Arbaugh、W.、およびB.Abobaは進歩、2003年10月に働いています。
[EAP-CHANNEL] Ohba, Y., Parthasrathy, M., and M. Yanagiya, "Channel
Binding Mechanism Based on Parameter Binding in Key
Derivation", Work in Progress, June 2007.
[EAP-チャンネル]オオバ、Y.、Parthasrathy(M.、およびM.柳屋)は「主要な派生におけるパラメタ結合に基づく結合機構を向けます」、処理中の作業、2007年6月。
[EAP-BINDING] Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
"The Compound Authentication Binding Problem", Work in
Progress, October 2003.
J.とロルツとV.とPalekar、A.とD.サイモン、「合成の認証の拘束力がある問題」という[拘束力があるEAPを]のPuthenkulamは進歩、2003年10月に働いています。
[MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions
Within a Minute", Cryptology ePrint Archive, March
2006, http://eprint.iacr.org/2006/105.pdf
[MD5Collision]クリマ(V.)は「ハッシュ関数で以下にトンネルを堀ります」。 「1分以内のMD5衝突」、ePrintが2006年3月に格納する暗号理論、 http://eprint.iacr.org/2006/105.pdf
[MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key
Distribution using Neighbor Graphs", IEEE Wireless
Communications, vol. 11, February 2004.
[MishraPro]Mishra(A.、Shin、M.、およびW.Arbaugh)は「隣人グラフを使用して、主要な分配を予測します」、IEEE Wireless Communications、vol.11、2004年2月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、エド、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol
(ECP)", RFC 1968, June 1996.
G.、「ppp暗号化制御プロトコル(ECP)」、RFC1968 1996年6月の[RFC1968]マイヤー。
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the
DNS", RFC 2230, November 1997.
[RFC2230] アトキンソン、R.、「DNSに、主要な交換委譲記録」、RFC2230、1997年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone,
D., and R. Wheeler, "A Method for Transmitting PPP
Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516] Mamakos、L.、Lidl、K.、エバーツ、J.、個人閲覧室、D.、シモン、D.、およびR.ウィーラー、「イーサネットの上にpppを伝えるためのメソッド(PPPoE)」、RFC2516(1999年2月)。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
Attributes", RFC 2548, March 1999.
[RFC2548] ゾルン、G.、「マイクロソフトのベンダー特有の半径属性」、RFC2548、1999年3月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
Policy Implementation in Roaming", RFC 2607, June
1999.
[RFC2607] Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日
Aboba, et al. Standards Track [Page 70] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[70ページ]RFC5247EAP
[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月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
for specifying the location of services (DNS SRV)",
RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie(P.、グドムンソン、O.、イーストレーク3番目、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、2000年11月のB.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3162] AbobaとB.とゾルン、G.とD.ミットンと「半径とIPv6"、RFC3162、2001年8月。」
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
"The Group Domain of Interpretation", RFC 3547, July
2003.
2003年7月の[RFC3547]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[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月)。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
Roese, "IEEE 802.1X Remote Authentication Dial In User
Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003.
[RFC3580] コングドン、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.Roese、「ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル」、RFC3580(2003年9月)。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[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月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC
3830, August 2004.
[RFC3830] Arkko、J.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、2004年8月。
Aboba, et al. Standards Track [Page 71] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[71ページ]RFC5247EAP
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC
4005, August 2005.
[RFC4005] カルフーンとP.とゾルンとG.とスペンス、D.とD.ミットン、「直径ネットワークアクセス・サーバーアプリケーション」、RFC4005、2005年8月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4017] スタンリー、D.、ウォーカー、J.、およびB.Aboba、「ワイヤレスのLANのための拡張認証プロトコル(EAP)メソッド要件」、RFC4017(2005年3月)。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4035]Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
[RFC4067] Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R.
Koodli, "Context Transfer Protocol (CXTP)", RFC 4067,
July 2005.
[RFC4067] Loughney、J.、エド、NakhjiriとM.とパーキンス、C.とR.Koodli、「文脈転送プロトコル(CXTP)」RFC4067、7月2005日
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application",
RFC 4072, August 2005.
[RFC4072] Eronen、P.、エド、ヒラー、T.、およびG.ゾルン、「直径拡張認証プロトコル(EAP)アプリケーション」、RFC4072、8月2005日
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture
Taxonomy for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118]の陽、L.、Zerfos、P.、およびE.Sadot、「ワイヤレス・アクセスのコントロールと食糧を供給するアーキテクチャ分類学は(CAPWAP)を指します」、RFC4118、2005年6月。
[RFC4186] Haverinen, H., Ed., and J. Salowey, Ed., "Extensible
Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity
Modules (EAP-SIM)", RFC 4186, January 2006.
[RFC4186]Haverinen、H.(エド)、およびJ.Salowey(エド)、「広げることができる認証は汎欧州デジタルセルラーシステム(GSM)加入者アイデンティティモジュール(EAP-SIM)のためにメソッドを議定書の中で述べます」、RFC4186、2006年1月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and
Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187] Arkko、J.、およびH.Haverinen、「広げることができる認証は第3世代認証のためのメソッドと主要な協定(EAP-別名)について議定書の中で述べます」、RFC4187、2006年1月。
[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。
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
"Identity Selection Hints for the Extensible
Authentication Protocol (EAP)", RFC 4284, January
2006.
[RFC4284] Adrangi、F.、ロルツ、V.、バリ、F.、およびP.Eronen、「アイデンティティ選択は拡張認証プロトコル(EAP)のために暗示します」、RFC4284、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
Aboba, et al. Standards Track [Page 72] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[72ページ]RFC5247EAP
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006.
[RFC4372] AdrangiとF.とLiorとA.とKorhonen、J.とJ.Loughney、「請求できるユーザのアイデンティティ」、RFC4372、2006年1月。
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Networks
(WLAN)", RFC 4334, February 2006.
[RFC4334]Housley(R.とT.ムーア)は「認証が指すポイントのプロトコル(ppp)とワイヤレスのローカル・エリア・ネットワーク(WLAN)であるとサポートする拡大と属性を証明します」、RFC4334、2006年2月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006.
[RFC4535] ハーニー、H.、メタンフェタミン、U.、コールグローブ、A.、およびG.グロス、「GSAKMP:」 「グループの安全な協会Key Managementプロトコル」、RFC4535、2006年6月。
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible
Authentication Protocol Method for Shared-secret
Authentication and Key Establishment (EAP-SAKE)", RFC
4763, November 2006.
[RFC4763]バンダビーン、M.とH.ソリマン、「共有秘密キー認証と主要な設立(EAP-酒)のための拡張認証プロトコルメソッド」RFC4763(2006年11月)。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS
Attributes for Virtual LAN and Priority Support", RFC
4675, September 2006.
[RFC4675] コングドン、P.、サンチェス、M.、およびB.Aboba、「バーチャルLANと優先権サポートのための半径属性」、RFC4675、2006年9月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] EronenとP.とP.ホフマン、「IKEv2明確化と実装ガイドライン」、RFC4718、2006年10月。
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol:
A Pre-Shared Key Extensible Authentication Protocol
(EAP) Method", RFC 4764, January 2007.
[RFC4764] ベルサニ、F.、およびH.Tschofenig、「EAP-PSKは議定書を作ります」。 「あらかじめ共有された主要な拡張認証プロトコル(EAP)メソッド」、RFC4764、2007年1月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC
5176, January 2008.
[RFC5176] 千葉、M.、Dommety、G.、エクルンド、M.、ミットン、D.、およびB.Aboba、「リモート認証へのダイナミックな承認拡大はユーザでサービス(半径)にダイヤルします」、RFC5176、2008年1月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
2008年3月の[RFC5216]サイモンとD.とAboba、B.とR.ハースト、「EAP-TLS認証プロトコル」RFC5216。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, August
2008.
[RFC5246] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2008年8月にバージョン1.2インチ、RFC5246について議定書の中で述べます」。
[SP800-57] National Institute of Standards and Technology,
"Recommendation for Key Management", Special
Publication 800-57, May 2006.
[SP800-57]米国商務省標準技術局(「Key Managementのための推薦」、特別な公表800-57)は2006がそうするかもしれません。
Aboba, et al. Standards Track [Page 73] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[73ページ]RFC5247EAP
[Token] Fantacci, R., Maccari, L., Pecorella, T., and F.
Frosali, "A secure and performant token-based
authentication for infrastructure and mesh 802.1X
networks", IEEE Conference on Computer Communications,
June 2006.
コンピュータCommunications(2006年6月)の上の[トークン]Fantacci、R.、Maccari、L.、Pecorella、T.、およびF.Frosali、「インフラストラクチャとメッシュ802.1Xネットワークのための安全、そして、performantのトークンベースの認証」IEEEコンファレンス。
[Tokenk] Ohba, Y., Das, S., and A. Duttak, "Kerberized Handover
Keying: A Media-Independent Handover Key Management
Architecture", Mobiarch 2007.
[Tokenk] オオバ、Y.、ダス、S.、およびA.Duttak、「以下を合わせるKerberized引き渡し」 「メディアから独立している引き渡しKey Managementアーキテクチャ」、Mobiarch2007。
Acknowledgments
承認
Thanks to Ashwin Palekar, Charlie Kaufman, and Tim Moore of Microsoft, Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco, and Russ Housley of Vigil Security for useful feedback.
役に立つフィードバックについてエリクソンのArkko、アルーバNetworksのドロシー・スタンリー、TruSecureのボブ・マスコウィッツ、インテルのジェシー・ウォーカー、シスコのジョーSalowey、およびVigil SecurityのラスHousleyにマイクロソフト、ヤリのAshwin Palekar、チャーリー・カウフマン、およびティム・ムーアに感謝します。
Aboba, et al. Standards Track [Page 74] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[74ページ]RFC5247EAP
Appendix A - Exported Parameters in Existing Methods
付録A--既存の方法によるエクスポートしているパラメタ
This Appendix specifies Session-Id, Peer-Id, Server-Id and Key-Lifetime for EAP methods that have been published prior to this specification. Future EAP method specifications MUST include a definition of the Session-Id, Peer-Id and Server-Id (could be the null string). In the descriptions that follow, all fields comprising the Session-Id are assumed to be in network byte order.
このAppendixはSession-イド、Peer-イド、Server-イド、およびKey生涯をこの仕様の前に発行されたEAPメソッドに指定します。 将来のEAPメソッド仕様はSession-イド、Peer-イド、およびServer-イド(ヌルストリングであるかもしれない)の定義を含まなければなりません。 続く記述では、ネットワークバイトオーダーにはSession-イドを包括するすべての分野があると思われます。
EAP-Identity
EAP-アイデンティティ
The EAP-Identity method is defined in [RFC3748]. It does not
derive keys, and therefore does not define the Session-Id. The
Peer-Id and Server-Id are the null string (zero length).
EAP-アイデンティティメソッドは[RFC3748]で定義されます。 それは、キーを引き出さないで、またしたがって、Session-アイダホ州を定義しません。 Peer-イドとServer-イドはヌルストリング(ゼロ・レングス)です。
EAP-Notification
EAP-通知
The EAP-Notification method is defined in [RFC3748]. It does not
derive keys and therefore does not define the Session-Id. The
Peer-Id and Server-Id are the null string (zero length).
EAP-通知メソッドは[RFC3748]で定義されます。 それは、キーを引き出さないで、またしたがって、Session-アイダホ州を定義しません。 Peer-イドとServer-イドはヌルストリング(ゼロ・レングス)です。
EAP-MD5-Challenge
EAP-MD5-挑戦
The EAP-MD5-Challenge method is defined in [RFC3748]. It does not
derive keys and therefore does not define the Session-Id. The
Peer-Id and Server-Id are the null string (zero length).
EAP-MD5-挑戦メソッドは[RFC3748]で定義されます。 それは、キーを引き出さないで、またしたがって、Session-アイダホ州を定義しません。 Peer-イドとServer-イドはヌルストリング(ゼロ・レングス)です。
EAP-GTC
EAP-GTC
The EAP-GTC method is defined in [RFC3748]. It does not derive
keys and therefore does not define the Session-Id. The Peer-Id
and Server-Id are the null string (zero length).
EAP-GTCメソッドは[RFC3748]で定義されます。 それは、キーを引き出さないで、またしたがって、Session-アイダホ州を定義しません。 Peer-イドとServer-イドはヌルストリング(ゼロ・レングス)です。
EAP-OTP
EAP-OTP
The EAP-OTP method is defined in [RFC3748]. It does not derive
keys and therefore does not define the Session-Id. The Peer-Id
and Server-Id are the null string (zero length).
EAP-OTPメソッドは[RFC3748]で定義されます。 それは、キーを引き出さないで、またしたがって、Session-アイダホ州を定義しません。 Peer-イドとServer-イドはヌルストリング(ゼロ・レングス)です。
Aboba, et al. Standards Track [Page 75] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[75ページ]RFC5247EAP
EAP-AKA
EAP-別名
EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of
the AUTN field in the AT_AUTN attribute:
EAP-AKAは[RFC4187]で定義されます。 EAP-AKA Session-イドはAT_AUTN属性におけるAUTN分野のコンテンツがあとに続いたAT_RAND属性からのRAND分野のコンテンツがあるEAP Type Code(0×17)の連結です:
Session-Id = 0x17 || RAND || AUTN
セッションイド=0x17|| 底ならし革|| AUTN
The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast EAP
re-authentication identity. The Server-Id is the null string
(zero length).
Peer-イドはしかしながら、始めからActual Identity Length八重奏だけを使用して、IDENTITYが結果と考えるAT_からのIdentity分野のコンテンツです。それらが伝えられること伝えられたアイデンティティが永久的であるか、匿名の、または、速いEAP再認証のアイデンティティであったかどうかにかかわらず内容が使用されることに注意してください。 Server-イドはヌルストリング(ゼロ・レングス)です。
EAP-SIM
EAP-シム
EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the
concatenation of the EAP Type Code (0x12) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of
the NONCE_MT field in the AT_NONCE_MT attribute:
EAP-SIMは[RFC4186]で定義されます。 EAP-SIM Session-イドはAT_NONCE_MT属性におけるNONCE_MT分野のコンテンツがあとに続いたAT_RAND属性からのRAND分野のコンテンツがあるEAP Type Code(0×12)の連結です:
Session-Id = 0x12 || RAND || NONCE_MT
セッションイド=0x12|| 底ならし革|| 一回だけ_MT
The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast EAP
re-authentication identity. The Server-Id is the null string
(zero length).
Peer-イドはしかしながら、始めからActual Identity Length八重奏だけを使用して、IDENTITYが結果と考えるAT_からのIdentity分野のコンテンツです。それらが伝えられること伝えられたアイデンティティが永久的であるか、匿名の、または、速いEAP再認証のアイデンティティであったかどうかにかかわらず内容が使用されることに注意してください。 Server-イドはヌルストリング(ゼロ・レングス)です。
EAP-PSK
EAP-PSK
EAP-PSK is defined in [RFC4764]. The EAP-PSK Session-Id is the
concatenation of the EAP Type Code (0x2F) with the peer (RAND_P)
and server (RAND_S) nonces:
EAP-PSKは[RFC4764]で定義されます。 EAP-PSK Session-イドは同輩(RAND_P)とサーバ(RAND_S)一回だけがあるEAP Type Code(0x2F)の連結です:
Session-Id = 0x2F || RAND_P || RAND_S
セッションイド=0x2F|| 底ならし革_P|| 底ならし革_S
The Peer-Id is the contents of the ID_P field and the Server-Id is
the contents of the ID_S field.
Peer-イドはID_P分野のコンテンツです、そして、Server-イドはID_S分野のコンテンツです。
Aboba, et al. Standards Track [Page 76] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[76ページ]RFC5247EAP
EAP-SAKE
EAP-酒
EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the
concatenation of the EAP Type Code (0x30) with the contents of the
RAND_S field from the AT_RAND_S attribute, followed by the
contents of the RAND_P field in the AT_RAND_P attribute:
EAP-SAKEは[RFC4763]で定義されます。 EAP-SAKE Session-イドはAT_RAND_P属性におけるRAND_P分野のコンテンツがあとに続いたAT_RAND_S属性からのRAND_S分野のコンテンツがあるEAP Type Code(0×30)の連結です:
Session-Id = 0x30 || RAND_S || RAND_P
セッションイド=0x30|| 底ならし革_S|| 底ならし革_P
Note that the EAP-SAKE Session-Id is not the same as the "Session
ID" parameter chosen by the Server, which is sent in the first
message, and replicated in subsequent messages. The Peer-Id is
contained within the value field of the AT_PEERID attribute and
the Server-Id, if available, is contained in the value field of
the AT_SERVERID attribute.
「Session ID」パラメタが最初のメッセージで送られるServerで選んで、その後のメッセージで模写されたので、EAP-SAKE Session-イドが同じでないことに注意してください。 Peer-イドはAT_PEERID属性の値の分野の中に保管されています、そして、利用可能であるなら、Server-イドはAT_SERVERID属性の値の分野に保管されています。
EAP-TLS
EAP-TLS
For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in
[RFC5216].
EAP-TLSに関しては、Peer-イド、Server-イド、およびSession-イドは[RFC5216]で定義されます。
Aboba, et al. Standards Track [Page 77] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[77ページ]RFC5247EAP
Authors' Addresses
作者のアドレス
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
メール: bernarda@microsoft.com 電話: +1 425 706、6605Fax: +1 425 936 7329
Dan Simon
Microsoft Research
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
ダンサイモンマイクロソフト研究マイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: dansimon@microsoft.com
Phone: +1 425 706 6711
Fax: +1 425 936 7329
メール: dansimon@microsoft.com 電話: +1 425 706、6711Fax: +1 425 936 7329
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
パシEronenノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
EMail: pasi.eronen@nokia.com
メール: pasi.eronen@nokia.com
Aboba, et al. Standards Track [Page 78] RFC 5247 EAP Key Management Framework August 2008
Aboba、他 管理フレームワーク2008年8月に主要な標準化過程[78ページ]RFC5247EAP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Aboba, et al. Standards Track [Page 79]
Aboba、他 標準化過程[79ページ]
一覧
スポンサーリンク
