RFC4017 日本語訳
4017 Extensible Authentication Protocol (EAP) Method Requirements forWireless LANs. D. Stanley, J. Walker, B. Aboba. March 2005. (Format: TXT=22183 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Stanley
Request for Comments: 4017 Agere Systems
Category: Informational J. Walker
Intel Corporation
B. Aboba
Microsoft Corporation
March 2005
コメントを求めるワーキンググループD.スタンリー要求をネットワークでつないでください: 4017年のAgereシステムカテゴリ: 2005年の情報のJ.のウォーカーのインテル社のB.Abobaマイクロソフト社行進
Extensible Authentication Protocol (EAP) Method Requirements
for Wireless LANs
ワイヤレスのLANのための拡張認証プロトコル(EAP)メソッド要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes.
IEEE 802.11i MAC Security Enhancements AmendmentはIEEE 802.1Xを利用します。(順番に、IEEE 802.1Xは拡張認証プロトコル(EAP)を当てにします)。 このドキュメントはIEEE802.11ワイヤレスのLAN展開に使用されるEAPメソッドのための要件を定義します。 材料をIEEE802.11が本書では承認して、情報の目的のためのIETF RFCとして寄贈しています。
Table of Contents
目次
1. Introduction ................................................. 2
1.1. Requirements Specification ............................. 2
1.2. Terminology ............................................ 2
2. Method Requirements .......................................... 3
2.1. Credential Types ....................................... 3
2.2. Mandatory Requirements ................................. 4
2.3. Recommended Requirements ............................... 5
2.4. Optional Features ...................................... 5
2.5. Non-compliant EAP Authentication Methods ............... 5
3. Security Considerations ...................................... 6
4. References ................................................... 8
Acknowledgments .................................................. 9
Authors' Addresses ............................................... 10
Full Copyright Statement ......................................... 11
1. 序論… 2 1.1. 要件仕様… 2 1.2. 用語… 2 2. メソッド要件… 3 2.1. 資格証明タイプ… 3 2.2. 義務的な要件… 4 2.3. 要件を推薦します… 5 2.4. 任意の特徴… 5 2.5. 不従順なEAP認証方法… 5 3. セキュリティ問題… 6 4. 参照… 8つの承認… 9人の作者のアドレス… 10 完全な著作権宣言文… 11
Stanley, et al. Informational [Page 1] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[1ページ]のRFC4017EAPメソッド要件
1. Introduction
1. 序論
The IEEE 802.11i MAC Security Enhancements Amendment [IEEE802.11i] makes use of IEEE 802.1X [IEEE802.1X], which in turn relies on the Extensible Authentication Protocol (EAP), defined in [RFC3748].
IEEE 802.11i MAC Security Enhancements Amendment[IEEE802.11i]はIEEE 802.1X[IEEE802.1X]を利用します。(順番に、IEEE 802.1Xは[RFC3748]で定義された拡張認証プロトコル(EAP)を当てにします)。
Today, deployments of IEEE 802.11 wireless LANs are based on EAP and use several EAP methods, including EAP-TLS [RFC2716], EAP-TTLS [TTLS], PEAP [PEAP], and EAP-SIM [EAPSIM]. These methods support authentication credentials that include digital certificates, user- names and passwords, secure tokens, and SIM secrets.
今日、展開、IEEEでは、802.11の無線LANが、EAPに基づいていて、いくつかのEAPメソッドを使用します、EAP-TLS[RFC2716]、EAP-TTLS[TTLS]、PEAP[PEAP]、およびEAP-シム[EAPSIM]を含んでいて。 これらのメソッドは、認証がデジタル証明書を含んでいる資格証明書と、ユーザ名と、パスワードと、安全なトークンと、SIM秘密であるとサポートします。
This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. EAP methods claiming conformance to the IEEE 802.11 EAP method requirements for wireless LANs must complete IETF last call review.
このドキュメントはIEEE802.11ワイヤレスのLAN展開に使用されるEAPメソッドのための要件を定義します。 無線LANのためのIEEE802.11EAPメソッド要件への順応がIETFを完成しなければならないと主張するEAPメソッドは、最後にレビューと呼びます。
1.1. Requirements Specification
1.1. 要件仕様
In this document, several words are used to signify the requirements of the specification. 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]で説明されるように本書では解釈されることであるべきですか?
An EAP authentication method is not compliant with this specification if it fails to satisfy one or more of the MUST or MUST NOT requirements. An EAP authentication method that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT requirements is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements is said to be "conditionally compliant".
1つか以上を満たさないならEAP認証方法がこの仕様で対応でない、NOT要件はそうしなければなりません。 すべてを満たすEAP認証方法、NOT、SHOULD、およびSHOULD NOT要件は「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、すべてのSHOULDかSHOULD NOT要件だけが「条件付きに言いなりになる」と言われているというわけではないというNOT要件はそうしなければなりません。
1.2. Terminology
1.2. 用語
authenticator
The end of the link initiating EAP authentication. The term
authenticator is used in [IEEE802.1X], and authenticator has the
same meaning in this document.
リンクの開始しているEAP認証の終わりの固有識別文字。 用語固有識別文字は[IEEE802.1X]で使用されます、そして、固有識別文字には、同じ意味が本書ではあります。
peer
The end of the link that responds to the authenticator. In
[IEEE802.1X], this end is known as the supplicant.
じっと見てください。固有識別文字に応じるリンクの端。 [IEEE802.1X]では、この終わりは哀願者として知られています。
Supplicant
The end of the link that responds to the authenticator in
[IEEE802.1X].
哀願者、[IEEE802.1X]の固有識別文字に応じるリンクの端。
Stanley, et al. Informational [Page 2] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[2ページ]のRFC4017EAPメソッド要件
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 [IEEE802.1X].
バックエンド認証サーバAバックエンド認証サーバは固有識別文字への認証サービスを提供する実体です。 使用されると、このサーバは固有識別文字のためにEAPメソッドを通常実行します。 また、この用語は[IEEE802.1X]で使用されます。
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サーバ、同輩と共にEAP認証方法を終える実体。 バックエンド認証サーバがないのが使用されている場合では、EAPサーバは固有識別文字の一部です。 固有識別文字が通じて通りモードで作動する場合では、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. In existing implementations, an AAA server acting as an
EAP server transports the MSK to the authenticator.
EAP同輩とサーバの間で誘導されて、EAPメソッドでエクスポートされる材料を合わせて、Session Key(MSK)をマスタリングしてください。 MSKは長さが少なくとも64の八重奏です。 既存の実装では、EAPサーバとして機能するAAAサーバはMSKを固有識別文字に輸送します。
Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client and
server that is exported by the EAP method. The EMSK is at least
64 octets in length. The EMSK is not shared with the
authenticator or any other third party. The EMSK is reserved for
future uses that are not yet defined.
材料がEAPクライアントとサーバで間それがEAPメソッドでエクスポートされる引き出した拡張Master Session Key(EMSK)の追加合わせること。 EMSKは長さが少なくとも64の八重奏です。 EMSKは固有識別文字かいかなる他の第三者とも共有されません。 EMSKはまだ定義されていない将来の用途のために予約されます。
4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP)
defined in [IEEE802.11i], which confirms mutual possession of a
Pairwise Master Key by two parties and distributes a Group Key.
2回のパーティーでPairwise Master Keyの互いの所持を確認して、Group Keyを分配する[IEEE802.11i]で定義された4方法のHandshake A対状AuthenticationとKey Managementプロトコル(AKMP)。
2. Method Requirements
2. メソッド要件
2.1. Credential Types
2.1. 資格証明タイプ
The IEEE 802.11i MAC Security Enhancements Amendment requires that EAP authentication methods be available. Wireless LAN deployments are expected to use different credential types, including digital certificates, user-names and passwords, existing secure tokens, and mobile network credentials (GSM and UMTS secrets). Other credential types that may be used include public/private key (without necessarily requiring certificates) and asymmetric credential support (such as password on one side, public/private key on the other).
IEEE 802.11i MAC Security Enhancements Amendmentは、EAP認証方法が利用可能であることを必要とします。 無線LAN展開が異なった資格証明タイプを使用すると予想されます、デジタル証明書、ユーザ名、パスワード、既存の安全なトークン、およびモバイルネットワーク資格証明書(GSMとUMTS秘密)を含んでいて。 使用されるかもしれない他の資格証明タイプは公衆/秘密鍵(必ず証明書を必要とすることのない)と非対称の資格証明サポート(半面に関するパスワード、もう片方に関する公衆/秘密鍵などの)を入れます。
Stanley, et al. Informational [Page 3] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[3ページ]のRFC4017EAPメソッド要件
2.2. Mandatory Requirements
2.2. 義務的な要件
EAP authentication methods suitable for use in wireless LAN authentication MUST satisfy the following criteria:
無線LAN認証における使用に適したEAP認証方法は以下の評価基準を満たさなければなりません:
[1] Generation of symmetric keying material. This corresponds to
the "Key derivation" security claim defined in [RFC3748],
Section 7.2.1.
左右対称の合わせることの材料の[1]世代。 これは[RFC3748]、セクション7.2.1で定義された「主要な派生」セキュリティクレームに対応しています。
[2] Key strength. An EAP method suitable for use with IEEE 802.11
MUST be capable of generating keying material with 128-bits of
effective key strength, as defined in [RFC3748], Section 7.2.1.
As noted in [RFC3748], Section 7.10, 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.
[2] 主要な強さ。 生成するのはIEEE802.11との使用に適したEAPメソッドが有効な主要な強さの128ビットがある材料を合わせることができなければなりません、[RFC3748]、セクション7.2.1で定義されるように。 [RFC3748]、セクション7.10に述べられるように、主要な派生をサポートするEAPメソッドは少なくとも64の八重奏のMaster Session Key(MSK)、および少なくとも64の八重奏のExtended Master Session Key(EMSK)をエクスポートしなければなりません。
[3] Mutual authentication support. This corresponds to the "Mutual
authentication" security claim defined in [RFC3748], Section
7.2.1.
[3] 互いの認証サポート。 これは[RFC3748]、セクション7.2.1で定義された「互いの認証」セキュリティクレームに対応しています。
[4] Shared state equivalence. The shared EAP method state of the
EAP peer and server must be equivalent when the EAP method is
successfully completed on both sides. This includes the
internal state of the authentication protocol but not the state
external to the EAP method, such as the negotiation occurring
prior to initiation of the EAP method. The exact state
attributes that are shared may vary from method to method, but
typically include the method version number, the credentials
presented and accepted by both parties, the cryptographic keys
shared, and the EAP method specific attributes negotiated, such
as ciphersuites and limitations of usage on all protocol state.
Both parties must be able to distinguish this instance of the
protocol from all other instances of the protocol, and they must
share the same view regarding which state attributes are public
and which are private to the two parties alone. The server must
obtain the authenticated peer name, and the peer must obtain the
authenticated server name (if the authenticated server name is
available).
[4] 共有された州の等価性。 EAPメソッドが両側で首尾よく完成するとき、EAP同輩とサーバの共有されたEAPメソッド事情は同等であるに違いありません。 これはEAPメソッドへの外部の状態ではなく、認証プロトコルの内部の事情を含んでいます、EAPメソッドの開始の前に起こる交渉などのように。 メソッドによって共有される正確な州の属性は異なるかもしれませんが、メソッドバージョン番号を通常含めてください、と資格証明書はすべてのプロトコル状態における用法のciphersuitesや制限のように交渉された双方、共有された暗号化キー、およびEAPのメソッドの特定の属性で、提示して、受け入れました。 双方はプロトコルの他のすべてのインスタンスとプロトコルのこのインスタンスを区別できなければなりません、そして、それらは州の属性が公共であり、どれが2に個人的であるかが単独でパーティーへ行くのと同じ視点を共有しなければなりません。 サーバは認証された同輩名を得なければなりません、そして、同輩は認証されたサーバー名を得なければなりません(認証されたサーバー名が利用可能であるなら)。
[5] Resistance to dictionary attacks. This corresponds to the
"Dictionary attack resistance" security claim defined in
[RFC3748], Section 7.2.1.
[5] 辞書への抵抗は攻撃されます。 これは[RFC3748]、セクション7.2.1で定義された「辞書攻撃抵抗」セキュリティクレームに対応しています。
[6] Protection against man-in-the-middle attacks. This corresponds
to the "Cryptographic binding", "Integrity protection", "Replay
protection", and "Session independence" security claims defined
in [RFC3748], Section 7.2.1.
[6] 中央の男性に対する保護は攻撃されます。 これはセキュリティクレームが[RFC3748]、セクション7.2.1で定義した「暗号の結合」、「保全保護」、「反復操作による保護」、および「セッション独立」に対応しています。
Stanley, et al. Informational [Page 4] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[4ページ]のRFC4017EAPメソッド要件
[7] Protected ciphersuite negotiation. If the method negotiates the
ciphersuite used to protect the EAP conversation, then it MUST
support the "Protected ciphersuite negotiation" security claim
defined in [RFC3748], Section 7.2.1.
[7] 保護されたciphersuite交渉。 メソッドがEAPの会話を保護するのに使用されるciphersuiteを交渉するなら、それは[RFC3748]、セクション7.2.1で定義された「保護されたciphersuite交渉」セキュリティクレームをサポートしなければなりません。
2.3. Recommended Requirements
2.3. お勧めの要件
EAP authentication methods used for wireless LAN authentication SHOULD support the following features:
無線LAN認証SHOULDに使用されるEAP認証方法は以下の特徴をサポートします:
[8] Fragmentation. This implies support for the "Fragmentation"
claim defined in [RFC3748], Section 7.2.1. [RFC3748], Section
3.1 states: "EAP methods can assume a minimum EAP MTU of 1020
octets, in the absence of other information. EAP methods SHOULD
include support for fragmentation and reassembly if their
payloads can be larger than this minimum EAP MTU."
[8] 断片化。 これは「断片化」という[RFC3748]、セクション7.2.1で定義されたクレームのサポートを含意します。 [RFC3748]、セクション3.1は以下を述べます。 「EAPメソッドは他の情報がないとき1020の八重奏の最小のEAP MTUを仮定できます。」 「EAPメソッドSHOULDは断片化のサポートを含んで、それらのペイロードがこの最小のEAP MTUより大きい場合があるなら、再アセンブリします。」
[9] End-user identity hiding. This corresponds to the
"Confidentiality" security claim defined in [RFC3748], Section
7.2.1.
[9] エンドユーザアイデンティティ隠れること。 これは「秘密性」という[RFC3748]、セクション7.2.1で定義されたセキュリティクレームに対応しています。
2.4. Optional Features
2.4. オプション機能
EAP authentication methods used for wireless LAN authentication MAY support the following features:
無線LAN認証に使用されるEAP認証方法は以下の特徴をサポートするかもしれません:
[10] Channel binding. This corresponds to the "Channel binding"
security claim defined in [RFC3748], Section 7.2.1.
[10] 拘束力があった状態で、精神を集中してください。 これは[RFC3748]、セクション7.2.1で定義された「チャンネル結合」セキュリティクレームに対応しています。
[11] Fast reconnect. This corresponds to the "Fast reconnect"
security claim defined in [RFC3748], Section 7.2.1.
[11] 速く再接続してください。 これは「速く再接続してください」という[RFC3748]、セクション7.2.1で定義されたセキュリティクレームに対応しています。
2.5. Non-compliant EAP Authentication Methods
2.5. 不従順なEAP認証方法
EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication method), is defined in [RFC3748], Section 5.4. As defined in [RFC3748], EAP-MD5-Challenge, One-Time Password (Section 5.5), and Generic Token Card (Section 5.6) are non-compliant with the requirements specified in this document. As noted in [RFC3748], these methods do not support any of the mandatory requirements defined in Section 2.2, including key derivation and mutual authentication. In addition, these methods do not support any of the recommended features defined in Section 2.3 or any of the optional features defined in Section 2.4.
(現在の実装するために義務的なEAP認証方法)にEAP-MD5挑戦して、[RFC3748]、セクション5.4で定義されます。 [RFC3748]で定義されるように、要件が本書では指定されている状態で、EAP-MD5-挑戦、One-時間Password(セクション5.5)、およびGeneric Token Card(セクション5.6)は不従順です。 [RFC3748]に述べられるように、これらのメソッドはセクション2.2で定義された義務的な要件のいずれもサポートしません、主要な派生と互いの認証を含んでいて。 さらに、これらのメソッドはセクション2.3で定義されたお勧めの特徴のどれかかセクション2.4で定義されたオプション機能のいずれもサポートしません。
Stanley, et al. Informational [Page 5] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[5ページ]のRFC4017EAPメソッド要件
3. Security Considerations
3. セキュリティ問題
Within [IEEE802.11i], EAP is used for both authentication and key exchange between the EAP peer and server. Given that wireless local area networks provide ready access to an attacker within range, EAP usage within [IEEE802.11i] is subject to the threats outlined in [RFC3748], Section 7.1. Security considerations relating to EAP are discussed in [RFC3748], Sections 7; where an authentication server is utilized, the security considerations described in [RFC3579], Section 4, will apply.
[IEEE802.11i]の中では、EAPはEAP同輩とサーバの間の認証と主要な交換の両方に使用されます。ワイヤレスのローカル・エリア・ネットワークが範囲の中の攻撃者への持ち合わせのアクセスを提供するなら、[IEEE802.11i]の中のEAP用法は[RFC3748]に概説された脅威を受けることがあります、セクション7.1。 [RFC3748]、セクション7でEAPに関連するセキュリティ問題について議論します。 認証サーバが利用されているところでは、[RFC3579]で説明されたセキュリティ問題(セクション4)は適用されるでしょう。
The system security properties required to address the threats described in [RFC3748], Section 7.1, are noted in [Housley56]. In the material below, the requirements articulated in [Housley56] are listed, along with the corresponding recommendations.
特性が[RFC3748]で説明された脅威を扱うのを必要としたシステムセキュリティ(セクション7.1)は[Housley56]に述べられます。 以下の材料の中では、[Housley56]で明確に話された要件は対応する推薦と共にリストアップされています。
Algorithm independence
Requirement: "Wherever cryptographic algorithms are chosen, the
algorithms must be negotiable, in order to provide resilience
against compromise of a particular cryptographic algorithm."
アルゴリズム独立Requirement: 「暗号アルゴリズムがどこで選ばれても、アルゴリズムは交渉可能であるに違いありません、特定の暗号アルゴリズムの感染に対して弾力を提供するために。」
This issue is addressed by mandatory requirement [7] in Section
2.2. Algorithm independence is one of the EAP invariants
described in [KEYFRAME].
この問題はセクション2.2で義務的な要件[7]によって扱われます。 アルゴリズム独立は[KEYFRAME]で説明されたEAP不変式の1つです。
Strong, fresh session keys
Requirement: "Session keys must be demonstrated to be strong and
fresh in all circumstances, while at the same time retaining
algorithm independence."
強くて、新鮮なセッションキーRequirement: 「すべての事情で強くて、新鮮であるように同時にアルゴリズム独立を保有している間、セッションキーを実施説明しなければなりません」。
Key strength is addressed by mandatory requirement [2] in Section
2.2. Recommendations for ensuring the Freshness of keys derived
by EAP methods are discussed in [RFC3748], Section 7.10.
主要な強さはセクション2.2で義務的な要件[2]によって扱われます。 [RFC3748]、セクション7.10でEAPメソッドで引き出されたキーのFreshnessを確実にするための推薦について議論します。
Replay protection
Requirement: "All protocol exchanges must be replay protected."
保護Requirementを再演してください: 「すべてのプロトコル交換が保護された再生であるに違いありません。」
This is addressed by mandatory requirement [6] in Section 2.2.
これはセクション2.2で義務的な要件[6]によって扱われます。
Authentication
Requirements: "All parties need to be authenticated. The
confidentiality of the authenticator must be maintained. No
plaintext passwords are allowed."
認証要件: 「すべてのパーティーが、認証される必要があります。」 固有識別文字の秘密性を維持しなければなりません。 「平文パスワードは全く許容されていません。」
Stanley, et al. Informational [Page 6] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[6ページ]のRFC4017EAPメソッド要件
Mutual authentication is required as part of mandatory requirement
[3] in Section 2.2. Identity protection is a recommended
capability, described in requirement [9] in Section 2.3. EAP does
not support plaintext passwords, as noted in [RFC3748], Section
7.14.
互いの認証が義務的な要件[3]の一部としてセクション2.2で必要です。 アイデンティティ保護はセクション2.3で要件[9]で説明されたお勧めの能力です。 EAPは[RFC3748]、セクション7.14に述べられるように平文パスワードをサポートしません。
Authorization
Requirement: "EAP peer and authenticator authorization must be
performed."
承認要件: 「EAPはじっと見ます、そして、固有識別文字承認を実行しなければなりません。」
Authorization issues are discussed in [RFC3748], Sections 1.2 and
7.16. Authentication, Authorization, and Accounting (AAA)
protocols such as RADIUS [RFC2865][RFC3579] may be used to enable
authorization of EAP peers by a central authority. AAA
authorization issues are discussed in [RFC3579], Sections 2.6.3
and 4.3.7.
[RFC3748]、セクション1.2と7.16で承認問題について議論します。 RADIUS[RFC2865][RFC3579]などの認証、Authorization、およびAccounting(AAA)プロトコルは、主要な権威でEAP同輩の承認を可能にするのに使用されるかもしれません。 セクション2.6 [RFC3579]、.3、および4.3で.7にAAA承認問題について議論します。
Session keys
Requirement: "Confidentiality of session keys must be maintained."
セッションキーRequirement: 「セッションキーの秘密性を維持しなければなりません。」
Issues relating to Key Derivation are described in [RFC3748],
Section 7.10, as well as in [KEYFRAME].
Key Derivationに関連する問題が[RFC3748]、セクション7.10と[KEYFRAME]で説明されます。
Ciphersuite negotiation
Requirement: "The selection of the "best" ciphersuite must be
securely confirmed."
Ciphersuite交渉Requirement: 「しっかりと「最も良い」ciphersuiteの選択を確認しなければなりません。」
This is addressed in mandatory requirement [7] in Section 2.2.
これはセクション2.2で義務的な要件[7]で扱われます。
Unique naming
Requirement: "Session keys must be uniquely named."
ユニークな命名Requirement: 「唯一セッションキーを命名しなければなりません。」
Key naming issues are addressed in [KEYFRAME].
主要な命名問題は[KEYFRAME]で扱われます。
Domino effect
Requirement: "Compromise of a single authenticator cannot
compromise any other part of the system, including session keys
and long-term secrets."
ドミノ効果Requirement: 「ただ一つの固有識別文字の感染はセッションキーと長期の秘密を含むシステムのいかなる他の部分にも感染することができません。」
This issue is addressed by mandatory requirement [6] in Section
2.2.
この問題はセクション2.2で義務的な要件[6]によって扱われます。
Key binding
Requirement: "The key must be bound to the appropriate context."
主要な拘束力があるRequirement: 「適切な関係にキーを縛らなければなりません。」
This issue is addressed in optional requirement [10] in Section
2.4. Channel binding is also discussed in Section 7.15 of
[RFC3748] and Section 4.3.7 of [RFC3579].
この問題はセクション2.4で任意の要件[10]で扱われます。 また、[RFC3748]のセクション7.15と.7セクション4.3[RFC3579]でチャンネル結合について議論します。
Stanley, et al. Informational [Page 7] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[7ページ]のRFC4017EAPメソッド要件
4. References
4. 参照
4.1. Normative References
4.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月。
[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月)。
[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月)。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3748]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[802.11] 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 Std. 802.11-
2003, 2003.
[802.11]情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--特定のRequirements Part11: ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様、IEEE Std。 802.11- 2003, 2003.
[IEEE802.1X] IEEE Standards for Local and Metropolitan Area
Networks: Port based Network Access Control, IEEE Std
802.1X-2004, December 2004.
地方とメトロポリタンエリアネットワークの[IEEE802.1X]IEEE規格: ポートは2004年12月にNetwork Access Control、IEEE Std 802.1X-2004を基礎づけました。
[IEEE802.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,
July 2004.
[IEEE802.11i]米国電気電子技術者学会、「システムの間のテレコミュニケーションと情報交換--LAN/男性決められた一定の要求--パート11の規格に補ってください」 ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様: 「警備の強化のための仕様」、IEEE 802.11i、2004年7月。
Stanley, et al. Informational [Page 8] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[8ページ]のRFC4017EAPメソッド要件
4.2. Informative References
4.2. 有益な参照
[Housley56] Housley, R., "Key Management in AAA", Presentation to
the AAA WG at IETF 56,
http://www.ietf.org/proceedings/03mar/slides/aaa-
5/index.html, March 2003.
[Housley56] Housley、R.、「AAAにおけるKey Management」、IETF56、 http://www.ietf.org/proceedings/03mar/slides/aaa- 5/index.html、2003年3月のAAA WGへのプレゼンテーション。
[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月。
[PEAP] Palekar, A., et al., "Protected EAP Protocol (PEAP)",
Work in Progress, July 2004.
[PEAP] Palekar、A.、他、「保護されたEAPプロトコル(PEAP)」、Progress、2004年7月のWork。
[TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol (EAP-TTLS)", Work in Progress,
August 2004.
[TTLS] 「EAPはTLS認証プロトコル(EAP-TTLS)にトンネルを堀った」というファンク、P.、およびS.ブレーク-ウィルソンは進歩、2004年8月に働いています。
[EAPSIM] Haverinen, H. and J. Salowey, "EAP SIM Authentication",
Work in Progress, April 2004.
[EAPSIM] 「EAP SIM認証」というHaverinen、H.、およびJ.Saloweyは進歩、2004年4月に働いています。
[KEYFRAME] Aboba, B., et al., "EAP Key Management Framework", Work
in Progress, July 2004.
[KEYFRAME] Aboba、B.、他、「EAP Key Managementフレームワーク」、Progress、2004年7月のWork。
Acknowledgements
承認
The authors would like to acknowledge contributions to this document from members of the IEEE 802.11i Task Group, including Russ Housley of Vigil Security, David Nelson of Enterasys Networks and Clint Chaplin of Symbol Technologies, as well as members of the EAP WG including Joe Salowey of Cisco Systems, Pasi Eronen of Nokia, Jari Arkko of Ericsson, and Florent Bersani of France Telecom.
作者はIEEE 802.11i Task Groupのメンバーからのこのドキュメントへの貢献を承諾したがっています、Vigil SecurityのラスHousley、Enterasys Networksのデヴィッド・ネルソン、およびSymbol Technologiesのクリント・チャップリンを含んでいて、シスコシステムズのジョーSalowey、ノキアのパシEronen、エリクソンのヤリArkko、およびフランステレコムのフローラン・ベルサニを含むEAP WGのメンバーと同様に。
Stanley, et al. Informational [Page 9] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[9ページ]のRFC4017EAPメソッド要件
Authors' Addresses
作者のアドレス
Dorothy Stanley Agere Systems 2000 North Naperville Rd. Naperville, IL 60566
ドロシースタンリーAgere Systems2000の北のナパービル通り ナパービル、イリノイ 60566
Phone: +1 630 979 1572 EMail: dstanley@agere.com
以下に電話をしてください。 +1 1572年の630 979メール: dstanley@agere.com
Jesse R. Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214
第25ジェシーR.ウォーカーインテル社2111東北Avenueヒースボロー、または97214
EMail: jesse.walker@intel.com
メール: jesse.walker@intel.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 818 4011 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 425 818、4011Fax: +1 7329年の425 936メール: bernarda@microsoft.com
Stanley, et al. Informational [Page 10] RFC 4017 EAP Method Requirements for Wireless LANs March 2005
スタンリー、他 ワイヤレスのLAN行進2005年の情報[10ページ]のRFC4017EAPメソッド要件
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Stanley, et al. Informational [Page 11]
スタンリー、他 情報[11ページ]
一覧
スポンサーリンク
