RFC4962 日本語訳
4962 Guidance for Authentication, Authorization, and Accounting (AAA)Key Management. R. Housley, B. Aboba. July 2007. (Format: TXT=54927 bytes) (Also BCP0132) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 4962 Vigil Security
BCP: 132 B. Aboba
Category: Best Current Practice Microsoft
July 2007
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4962不寝番セキュリティBCP: 132B.Abobaカテゴリ: 最も良い現在の練習マイクロソフト2007年7月
Guidance for Authentication, Authorization, and Accounting (AAA)
Key Management
認証、承認、および会計(AAA)Key Managementのための指導
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management.
このドキュメントはAuthentication、Authorization、およびAccounting(AAA)かぎ管理プロトコルのデザイナーに指導を提供します。 また、指導もAAAかぎ管理プロトコルを含んでいるシステムとソリューションのデザイナーの役に立ちます。 分野の専門家で安全で、持続的なかぎ管理アルゴリズムとプロトコルを設計することにおける複雑さと苦労を考えて、その領域の深い専門的技術のないIETFワーキンググループがAuthentication、Authorization、およびAccounting(AAA)プロトコルに基づくそれら自身のかぎ管理アルゴリズムとプロトコルを設計しているのは、ほぼ確実に不適当です。 ガイドラインは本書ではIETF RFCsとして公表を要求するドキュメントに適用されます。 さらに、これらのガイドラインはAAAかぎ管理を指定する他の規格開発組織(SDOs)の役に立ちます。
Housley & Aboba Best Current Practice [Page 1] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[1ページ]RFC4962指導
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Specification .................................3
1.2. Mandatory to Implement .....................................3
1.3. Terminology ................................................3
2. AAA Environment Concerns ........................................5
3. AAA Key Management Requirements .................................7
4. AAA Key Management Recommendations .............................13
5. Security Considerations ........................................14
6. Normative References ...........................................15
7. Informative References .........................................15
Appendix: AAA Key Management History ..............................20
Acknowledgments ...................................................22
1. 序論…2 1.1. 要件仕様…3 1.2. 実装するために義務的…3 1.3. 用語…3 2. AAA環境関心…5 3. AAA Key Management要件…7 4. AAA Key Management推薦…13 5. セキュリティ問題…14 6. 標準の参照…15 7. 有益な参照…15付録: AAA Key Management歴史…20の承認…22
1. Introduction
1. 序論
This document provides architectural guidance to designers of AAA key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols.
このドキュメントはAAAかぎ管理プロトコルのデザイナーに建築指導を提供します。 また、指導もAAAかぎ管理プロトコルを含んでいるシステムとソリューションのデザイナーの役に立ちます。
AAA key management often includes a collection of protocols, one of which is the AAA protocol. Other protocols are used in conjunction with the AAA protocol to provide an overall solution. These other protocols often provide authentication and security association establishment.
AAAかぎ管理はしばしばプロトコルの収集を含んでいます。その1つはAAAプロトコルです。 他のプロトコルは、総合的な解決法を提供するのにAAAプロトコルに関連して使用されます。 これらの他のプロトコルはしばしば協会設立を認証とセキュリティに提供します。
Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization and Accounting (AAA) protocols. These guidelines apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management that depends on IETF specifications for protocols such as Extensible Authentication Protocol (EAP) [RFC3748], Remote Authentication Dial-In User Service (RADIUS) [RFC2865], and Diameter [RFC3588].
分野の専門家で安全で、持続的なかぎ管理アルゴリズムとプロトコルを設計することにおける複雑さと苦労を考えて、その領域の深い専門的技術のないIETFワーキンググループがAuthenticationに基づくそれら自身のかぎ管理アルゴリズムとプロトコルを設計しているのは、ほぼ確実に不適当です、AuthorizationとAccounting(AAA)プロトコル。 これらのガイドラインはIETF RFCsとして公表を要求するドキュメントに適用されます。 さらに、これらのガイドラインは拡張認証プロトコル(EAP)などのプロトコル[RFC3748]のためにIETF仕様によるAAAかぎ管理、中のRemote Authentication Dial User Service(RADIUS)[RFC2865]、およびDiameter[RFC3588]を指定する他の規格開発組織(SDOs)の役に立ちます。
In March 2003, at the IETF 56 AAA Working Group Session, Russ Housley gave a presentation on "Key Management in AAA" [H]. That presentation established the vast majority of the requirements contained in this document. Over the last three years, this collection of requirements have become known as the "Housley Criteria".
2003年3月に、IETF56AAA作業部会Sessionでは、ラスHousleyは「AAAにおけるKey Management」におけるプレゼンテーションに[H]を与えました。 そのプレゼンテーションは本書では含まれた要件のかなりの大部分を確立しました。 最終の上では、3年、要件のこの収集は「Housley評価基準」として知られるようになりました。
Housley & Aboba Best Current Practice [Page 2] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[2ページ]RFC4962指導
1.1. Requirements Specification
1.1. 要件仕様
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119].
キーワードが解釈しなければならない、本書では現れるとき、RFC2119[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
An AAA key management proposal is not compliant with this specification if it fails to satisfy one or more of the MUST or MUST NOT statements. An AAA key management proposal that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT statements is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT statements but not all the SHOULD or SHOULD NOT requirements is said to be "conditionally compliant".
1つか以上を満たさないならAAAかぎ管理提案がこの仕様で対応でない、NOT声明はそうしなければなりません。 すべてを満たすAAAかぎ管理提案、NOT、SHOULD、およびSHOULD NOT声明は「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、すべてのSHOULDかSHOULD NOT要件だけが「条件付きに言いなりになる」と言われているというわけではないというNOT声明はそうしなければなりません。
1.2. Mandatory to Implement
1.2. 実装するために、義務的です。
The guidance provided in this document is mandatory to implement. However, it is not mandatory to use. That is, configuration at the time of deployment may result in a deployed implementation that does not conform with all of these requirements.
本書では提供された指導は、実装するために義務的です。 しかしながら、それは、使用するために義務的ではありません。 すなわち、展開時点の構成はこれらの要件のすべてに従わない配布している実装をもたらすかもしれません。
For example, [RFC4072] enables EAP keying material to be delivered from a AAA server to an AAA client without disclosure to third parties. Thus, key confidentiality is mandatory to implement in Diameter [RFC3588]. However, key confidentiality is not mandatory to use.
例えば、[RFC4072]は、材料を合わせるEAPが公開なしで第三者にAAAサーバからAAAのクライアントまで提供されるのを可能にします。 したがって、主要な秘密性は、Diameter[RFC3588]で実装するために義務的です。 しかしながら、主要な秘密性は、使用するために義務的ではありません。
1.3. Terminology
1.3. 用語
This section defines terms that are used in this document.
このセクションは本書では使用される用語を定義します。
AAA
Authentication, Authorization, and Accounting (AAA). AAA
protocols include RADIUS [RFC2865] and Diameter [RFC3588].
AAA認証、承認、および会計(AAA)。 AAAプロトコルはRADIUS[RFC2865]とDiameter[RFC3588]を含んでいます。
Authenticator
The party initiating EAP authentication. The term
authenticator is used in [802.1X], and authenticator has the
same meaning in this document.
固有識別文字、EAP認証を開始するパーティー。 用語固有識別文字は[802.1X]で使用されます、そして、固有識別文字には、同じ意味が本書ではあります。
Backend authentication server
A backend authentication server is an entity that provides an
authentication service to an authenticator. This terminology
is also used in [802.1X].
バックエンド認証サーバAバックエンド認証サーバは固有識別文字への認証サービスを提供する実体です。 また、この用語は[802.1X]で使用されます。
Housley & Aboba Best Current Practice [Page 3] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[3ページ]RFC4962指導
CHAP
Challenge Handshake Authentication Protocol; a one-way
challenge/response authentication protocol defined in
[RFC1994].
チャレンジハンドシェイク式認証プロトコルのひびが切れてください。 [RFC1994]で定義された一方向挑戦/応答認証プロトコル。
EAP
Extensible Authentication Protocol, defined in [RFC3748].
[RFC3748]で定義されたEAP拡張認証プロトコル。
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サーバはバックエンド認証サーバに位置しています。
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)と呼ばれます。
PAP
Password Authentication Protocol; a deprecated cleartext
password PPP authentication protocol, originally defined in
[RFC1334].
乳首パスワード認証プロトコル。 元々[RFC1334]で定義された推奨しないcleartextパスワードPPP認証プロトコル。
Party
A party is a processing entity that can be identified as a
single role in a protocol.
パーティAパーティーはプロトコルにおけるただ一つの役割として特定できる処理実体です。
Peer
The end of the link that responds to the authenticator. In
[802.1X], this end is known as the supplicant.
じっと見てください。固有識別文字に応じるリンクの端。 [802.1X]では、この終わりは哀願者として知られています。
PPP
Point-to-Point Protocol, defined in [RFC1661], provides support
for multiprotocol serial datalinks. PPP is the primary IP
datalink used for dial-in NAS connection service.
PPP Pointからポイントへの[RFC1661]で定義されたプロトコルは「マルチ-プロトコル」の連続のデータリンクのサポートを提供します。 PPPはダイヤルインのNAS接続サービスに使用されるプライマリIPデータリンクです。
Secure Association Protocol
A protocol for managing security associations derived from EAP
and/or AAA exchanges. The protocol establishes a security
association, which includes 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 [802.11i].
セキュリティ協会を経営するための安全なAssociationプロトコルAプロトコルはEAP、そして/または、AAAから交換を引き出しました。 プロトコルはセキュリティ協会を設立します。(それは、キーの使用のための対称鍵と文脈を含んでいます)。 Secure Associationプロトコルに関する例は[802.11i]の中で定義された4ウェイ握手です。
Housley & Aboba Best Current Practice [Page 4] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[4ページ]RFC4962指導
Session Keys
Keying material used to protect data exchanged after
authentication has successfully completed, using the negotiated
ciphersuite.
セッションキーズKeyingの材料は以前はよく交渉されたciphersuiteを使用して、首尾よく完成されていた状態で認証が交換した後に交換したデータを保護していました。
Network Access Server (NAS)
A device that provides an access service for a user to a
network. The service may be a network connection, or a value
added service such as terminal emulation, as described in
[RFC2881].
アクセス・サービスをユーザに提供するAccess Server(NAS)Aデバイスをネットワークにネットワークでつないでください。 サービスは、[RFC2881]で説明されるようにネットワーク接続、またはターミナルエミュレーションなどの付加価値が付いたサービスであるかもしれません。
4-Way Handshake
A Secure Association Protocol, defined in [802.11i], which
confirms mutual possession of a Pairwise Master Key by two
parties and distributes a Group Key.
2でPairwise Master Keyの互いの所持を確認する[802.11i]で定義された4方法のHandshake A Secure Associationプロトコルが、パーティーへ行って、Group Keyを分配します。
2. AAA Environment Concerns
2. AAA環境関心
Examples of serious flaws plague the history of key management protocol development, starting with the very first attempt to define a key management protocol in the open literature, which was published in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the fix was broken in 1994 [AN]. In 1995 [L], a new flaw was found in the original 1978 version, in an area not affected by the 1981/1994 issue. All of these flaws were blindingly obvious once described, yet no one spotted them earlier. Note that the original protocol, if it were revised to employ certificates, which of course had yet to be invented, was only three messages. Many proposed AAA key management schemes are significantly more complicated.
重大な欠陥に関する例はかぎ管理プロトコル開発の歴史を苦しめます、開いている文学でかぎ管理プロトコルを定義するまさしくその最初の試みから始まって。文学は1978年[NS]に発行されました。 欠点とフィックスは1981年[DS]に発行されました、そして、フィックスは1994年[AN]に壊れていました。 1995[L]では、新しい欠点は1978年のオリジナルのバージョンで見つけられました、1981/1994号で影響を受けない領域で。 いったん説明されるとこれらの欠点のすべてが盲目に明白であった、しかし、だれも、より早くそれらを見つけませんでした。 それが証明書を使うために改訂された場合にだけオリジナルのプロトコルが3つのメッセージであったことに注意してください。証明書はもちろんまだ発明されていませんでした。 多くの提案されたAAAかぎ管理体系がかなり複雑です。
This bit of history shows that key management protocols are subtle. Experts can easily miss a flaw. As a result, peer review by multiple experts is essential, especially since many proposed AAA key management schemes are significantly more complicated. In addition, formal methods can help uncover problems [M].
歴史のこのビットは、かぎ管理プロトコルが微妙であることを示します。 専門家は容易に欠点を逃すことができます。 その結果、複数の専門家による同輩レビューは不可欠です、特に多くの提案されたAAAかぎ管理体系がかなり複雑であるので。 さらに、正式なメソッドは、問題[M]を発見するのを助けることができます。
AAA-based key management is being incorporated into standards developed by the IETF and other standards development organizations (SDOs), such as IEEE 802. However, due to ad hoc development of AAA-based key management, AAA-based key distribution schemes have poorly understood security properties, even when well-studied cryptographic algorithms are employed. More academic research is needed to fully understand the security properties of AAA-based key management in the diverse protocol environments where it is being employed today. In the absence of such research results, pragmatic guidance based on sound security engineering principles is needed.
AAAを拠点とするかぎ管理はIETFが発展させた規格と他の規格開発組織(SDOs)に組み入れられています、IEEE802などのように。 しかしながら、AAAを拠点とするかぎ管理の臨時の発展のため、AAAベースの主要な分配体系はセキュリティの特性を不十分に理解していました、よく研究された暗号アルゴリズムが採用してさえいるとき。 よりアカデミックな研究が、今日それが就職であるさまざまのプロトコル環境におけるAAAを拠点とするかぎ管理のセキュリティの特性を完全に理解するのに必要です。 そのような研究結果がないとき、音のセキュリティ工学原理に基づく実践的な指導が必要です。
Housley & Aboba Best Current Practice [Page 5] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[5ページ]RFC4962指導
In addition to the need for interoperability, cryptographic algorithm independent solutions are greatly preferable. Without algorithm independence, the AAA-based key management protocol must be changed whenever a problem is discovered with any of the selected algorithms. As AAA history shows, problems are inevitable. Problems can surface due to age or design failure.
相互運用性の必要性に加えて、暗号アルゴリズムの独立している解決は大いに望ましいです。 アルゴリズム独立がなければ、問題が選択されたアルゴリズムのどれかで発見されるときはいつも、AAAベースのかぎ管理プロトコルを変えなければなりません。AAA歴史が示すように、問題は必然です。 問題は時代かデザイン失敗のため表面化できます。
DES [FIPS46] was a well-designed encryption algorithm, and it provided protection for many years. Yet, the 56-bit key size was eventually overcome by Moore's Law. No significant cryptographic deficiencies have been discovered in DES.
デス[FIPS46]はよく設計された暗号化アルゴリズムでした、そして、それは何年間も保護を提供しました。 しかし、56ビットの主要なサイズは結局、ムーアの法則によって打ち勝たれました。 どんな重要な暗号の欠乏もDESで発見されていません。
The history of AAA underlines the importance of algorithm independence as flaws have been found in authentication mechanisms such as CHAP, MS-CHAPv1 [SM1], MS-CHAPv2 [SM2], Kerberos [W][BM][DLS], and LEAP [B]. Unfortunately, RADIUS [RFC2865] mandates use of the MD5 algorithm for integrity protection, which has known deficiencies, and RADIUS has no provisions to negotiate substitute algorithms. Similarly, the vendor-specific key wrap mechanism defined in [RFC2548] has no provisions to negotiate substitute algorithms.
欠点がケルベロスのCHAPや、MS-CHAPv1[SM1]や、MS-CHAPv2[SM2]や、[W][BM][DLS]や、LEAP[B]などの認証機構で見つけられたようにAAAの歴史はアルゴリズム独立の重要を強調します。 残念ながら、RADIUS[RFC2865]は、代わりのアルゴリズムを交渉するためにMD5アルゴリズムの保全保護とRADIUSの使用には条項が全くないのを強制します。保護は欠乏を知っていました。同様に、[RFC2548]で定義されたベンダー特有の主要な包装メカニズムは代わりのアルゴリズムを交渉する条項を全く持っていません。
The principle of least privilege is an important design guideline. This principle requires that a party be given no more privilege than necessary to perform the task assigned to them. Ensuring least privilege requires clear identification of the tasks assigned to each party, and explicit determination of the minimum set of privileges required to perform those tasks. Only those privileges necessary to perform the tasks are granted. By denying to parties unneeded privileges, those denied privileges cannot be used to circumvent security policy or enable attackers. With this principle in mind, AAA key management schemes need to be designed in a manner where each party has only the privileges necessary to perform their role. That is, no party should have access to any keying material that is not needed to perform their own role. A party has access to a particular key if it has access to all of the secret information needed to derive it.
最少の特権の原則は重要なデザインガイドラインです。 この原則は、それらに割り当てられたタスクを実行するために必要とするより多くの特権がパーティーに与えられていないのを必要とします。 最少の特権を確実にするのは各当事者に配属されたタスクの明確な識別を必要とします、そして、最小のセットの特権の明白な決断がそれらのタスクを実行するのが必要です。 タスクを実行するのに必要なそれらの特権だけを与えます。 不要な特権をパーティーに対して否定することによって、ものは、安全保障政策を回避するか、または攻撃者を可能にするのに特権を使用できないことを否定しました。 この原則が念頭にある状態で、AAAかぎ管理体系は、各当事者が特権だけをそれらの役割を実行するのに必要にする方法で設計されている必要があります。 すなわち、どんなパーティーも、それら自身の役割を実行するのに必要でない材料を合わせながら、いずれにも近づく手段を持つべきではありません。 それを引き出すのに必要である秘密の情報のすべてに近づく手段を持っているなら、パーティーは特定のキーに近づく手段を持っています。
EAP is being used in new ways. The inclusion of support for EAP within Internet Key Exchange Protocol version 2 (IKEv2) and the standardization of robust Wireless LAN security [802.11i] based on EAP are two examples. EAP has also been proposed within IEEE 802.16e [802.16e] and by the IETF PANA Working Group. AAA-based key management is being incorporated into standards developed by the IETF and other standards development organizations (SDOs), such as IEEE 802. However, due to ad hoc development of AAA-based key management, AAA-based key distribution schemes have poorly understood security properties, even when well-studied cryptographic algorithms are
EAPは新しい方法で使用されています。 インターネット・キー・エクスチェンジプロトコルバージョン2(IKEv2)の中のEAPのサポートの包含とEAPに基づく強健なWireless LANセキュリティ[802.11i]の標準化は2つの例です。 また、EAPはIETF PANA作業部会によってIEEE 802.16e[802.16e]以内と提案されました。 AAAを拠点とするかぎ管理はIETFが発展させた規格と他の規格開発組織(SDOs)に組み入れられています、IEEE802などのように。 しかしながら、AAAを拠点とするかぎ管理の臨時の発展のため、AAAベースの主要な分配体系はセキュリティの特性を不十分に理解していました、よく研究された暗号アルゴリズムがそうときにさえ
Housley & Aboba Best Current Practice [Page 6] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[6ページ]RFC4962指導
employed. More academic research is needed to fully understand the security properties of AAA-based key management in the diverse protocol environments where it is being employed today. In the absence of research results, pragmatic guidance based on sound security engineering principles is needed.
採用。 よりアカデミックな研究が、今日それが就職であるさまざまのプロトコル環境におけるAAAを拠点とするかぎ管理のセキュリティの特性を完全に理解するのに必要です。 研究結果がないとき、音のセキュリティ工学原理に基づく実践的な指導が必要です。
EAP selects one end-to-end authentication mechanism. The mechanisms defined in [RFC3748] only support unilateral authentication, and they do not support mutual authentication or key derivation. As a result, these mechanisms do not fulfill the security requirements for many deployment scenarios, including Wireless LAN authentication [RFC4017].
EAPは片端から端への認証機構を選択します。 [RFC3748]で定義されたメカニズムは一方的な認証をサポートするだけです、そして、それらは互いの認証か主要な派生をサポートしません。 その結果、これらのメカニズムはWireless LAN認証[RFC4017]を含む多くの展開シナリオのためのセキュリティ要件を実現させません。
To ensure adequate security and interoperability, EAP applications need to specify mandatory-to-implement algorithms. As described in [RFC3748], EAP methods seeking publication as an IETF RFC need to document their security claims. However, some EAP methods are not based on well-studied models, which makes the validity of these security claims difficult to determine.
十分な安全性と相互運用性を確実にするのに、EAPアプリケーションは、実装するために義務的なアルゴリズムを指定する必要があります。しかしながら、[RFC3748](彼らのセキュリティクレームを記録するIETF RFCの必要性として公表を求めるEAPメソッド)で説明されるように、いくつかのEAPメソッドはよく研究されたモデルに基づいていません(これらの正当性を決定するのが難しいセキュリティクレームにします)。
In the context of EAP, the EAP peer and server are the parties involved in the EAP method conversation, and they gain access to key material when the conversation completes successfully. However, the lower-layer needs keying material to provide the desired protection through the use of cryptographic mechanisms. As a result, a "pass- through" mode is used to provide the keying material, and the lower- layer keying material is replicated from the AAA server to the authenticator. The only parties authorized to obtain all of the keying material are the EAP peer and server; the authenticator obtains only the keying material necessary for its specific role. No other party can obtain direct access to any of the keying material; however, other parties may receive keys that are derived from this keying material for a specific purpose as long as the requirements defined in the next section are met.
EAPの文脈では、EAP同輩とサーバはEAPメソッドの会話にかかわるパーティーであり、彼らは会話であるなら物質的なキーへのアクセスが首尾よく完成する利得です。 しかしながら、下層は、暗号のメカニズムの使用で必要な保護を提供するために材料を合わせる必要があります。その結果、「通じて通ってください」というモードは合わせることの材料を供給するのに使用されます、そして、材料を合わせる低級層はAAAサーバから固有識別文字まで模写されます。 合わせることの材料のすべてを得るのに権限を与えられた唯一のパーティーが、EAP同輩とサーバです。 固有識別文字は特定の役割に必要な合わせることの材料だけを得ます。 どんな相手も合わせることの材料のどれかに直接アクセスを得ることができません。 しかしながら、相手はある特定の目的で次のセクションで定義された必要条件が満たされる限り、材料を合わせながらこれから得られるキーを受け取るかもしれません。
3. AAA Key Management Requirements
3. AAA Key Management要件
The overall goal of AAA key management is to provide cryptographic keying material in situations where key derivation cannot be used by the peer and authenticator. It may not be possible because the authenticator lacks computational power, because it lacks the resources necessary to implement the various authentication mechanisms that might be required, or because it is undesirable for each authenticator to engage in a separate key management conversation.
AAAかぎ管理の全体的な目的は同輩と固有識別文字で主要な派生を使用できない状況に暗号の合わせることの材料を供給することです。 固有識別文字がコンピュータのパワーを欠いているので、それは可能でないかもしれません、必要であるかもしれない様々な認証機構を実装するのに必要なリソースを欠いているか、または各固有識別文字が別々のかぎ管理の会話に従事しているのが、望ましくないので。
Housley & Aboba Best Current Practice [Page 7] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[7ページ]RFC4962指導
This section provides guidance to AAA protocol designers, EAP method designers, and security association protocol designers. Acceptable solutions MUST meet all of these requirements.
このセクションはAAAのプロトコルデザイナー、EAPメソッドデザイナー、およびセキュリティ協会のプロトコルデザイナーに指導を提供します。 許容できるソリューションはこれらの要件のすべてに会わなければなりません。
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.
この要件は、プロトコルが、両方が公開鍵と対称鍵の暗号のアルゴリズムであるとサポートしなければならないことを意味しません。それは、プロトコルが、公開鍵アルゴリズムが採用しているときはいつも、複数の公開鍵アルゴリズムを使用できるような方法で構造化される必要を意味します。 同様に、それは、プロトコルが、対称鍵アルゴリズムが採用しているときはいつも、複数の対称鍵アルゴリズムを使用できるような方法で構造化される必要を意味します。
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]の適切な主要なサイズでアドバイスします。
Housley & Aboba Best Current Practice [Page 8] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[8ページ]RFC4962指導
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個のセッションキーの公開がいかなる他のセッションキーも発見する際に攻撃者を支援しないのを確実にしなければなりません。
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.
セッションキーを証明するのに使用されるどんなプロトコルもセッションキーに範囲を指定しなければなりません、明確に、セッションキーが利用可能であるパーティーを特定して。
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プロトコル交換を含んでいて、保護された再生であるに違いありません。 反復操作による保護で、プロトコルメッセージ受取人はまるで現在の対話に属すかのように前の正統の対話の間、記録されて、提示されたどんなメッセージも捨てることができます。
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.
AAAかぎ管理プロトコルにおける各当事者を彼らと交信する相手に認証しなければなりません。 認証機構は認証過程に使用されるどんな秘密の値の秘密性も維持しなければなりません。
Housley & Aboba Best Current Practice [Page 9] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[9ページ]RFC4962指導
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 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サーバで同輩に関連している識別子の組に権限を与えなければなりません。
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.
認証機構は平文パスワードを使ってはいけません。 それらが秘密性保護なしで別のパーティーに送られなければ、パスワードは使用されるかもしれません。
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
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.
同輩と固有識別文字承認を実行しなければなりません。 それを明らかにしないで、これらの実体は適切な合わせることの材料の所持を示さなければなりません。 同輩が新しい固有識別文字と交際するときはいつも、承認はREQUIREDです。 許可検査は特権攻撃の高度を防ぎます、そして、それは権限のない固有識別文字が検出されるのを確実にします。
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かぎ管理プロトコル交換はそうです。完全です、これらのパーティーは皆、相手に関連しているとして承認の共通認識を保持するべきです。
Housley & Aboba Best Current Practice [Page 10] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[10ページ]RFC4962指導
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.11i, 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 RFC 3579 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 RFC
3748 in Section 7.15, channel binding is required to enable the
peer to verify that the authenticator claim of identity is both
consistent and correct.
すべてのパーティーを認証することに加えて、かぎ管理プロトコルは、パーティーには合わせることの材料があるのに権限を与えられるのを示す必要があります。 合わせることの材料の所持の証拠が、材料を合わせながら承認がそれを保持すると必ず立証するというわけではないことに注意してください。 例えば、IEEE 802.11iの中では、4ウェイ握手は、同輩と固有識別文字の両方が材料を合わせる同じEAPを所有しているのを示します。 しかしながら、この所有物証拠自体は、バックエンド認証サーバによって固有識別文字が材料を合わせながらそれを所有しているのが認可されたのを示しません。 RFC3579にAAAプロキシが出席しているセクション4.3.7で述べられるように、1つの固有識別文字が別のものをまねるのは、可能です、AAAチェーン道具の各リンクがものまねに対してチェックしない場合。 これらのチェックさえ適所にある場合、固有識別文字はまだ同輩とバックエンド認証サーバへの異なったアイデンティティを要求しているかもしれません。セクション7.15でRFC3748で説明されるように、チャンネル結合は、同輩が、アイデンティティの固有識別文字クレームがともに一貫していることを確かめるのを可能にするのが必要であり、正しいです。
Keying material confidentiality and integrity
物質的な秘密性と保全を合わせます。
While preserving algorithm independence, confidentiality and
integrity of all keying material MUST be maintained.
アルゴリズム独立を保存している間、材料を合わせるすべての秘密性と保全を維持しなければなりません。
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が検出するメカニズムは後退復帰攻撃を試みました。
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 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.
AAAかぎ管理提案は主要なキャッシュがサポートされる特にところで強健な主要な命名体系を必要とします。 主要な名前がプロトコルでキーについて言及する方法を提供するので、すべてのパーティーにおいて、どのキーが参照をつけられているかは、明確です。 命名できないオブジェクトに対処できません。 唯一すべてのキーを命名しなければなりません、そして、主要な名前は直接か間接的に合わせることの材料を明らかにしてはいけません。 主要な名前が合わせることの材料に基づいていないなら、1つはキー値の検索を助けるのにそれを使用できないのを確信している場合があります。
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
システムの中のいかなる他の同輩によっても保たれた材料を合わせて、独身の同輩の感染は妥協してはいけません、セッションキーと長期のキーを含んでいて。 同様にシングルの感染
Housley & Aboba Best Current Practice [Page 11] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[11ページ]RFC4962指導
authenticator MUST NOT compromise keying material held by any
other authenticator within the system. In the context of a key
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.
グループキーは明白な例外です。 グループのすべてのメンバーには同じキーのコピーがあるので、グループのメンバーのどれかの感染はグループキーの公開をもたらすでしょう。
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 合わせることの材料が使用されると予想される方法。
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.
材料を合わせることへの正統のアクセスがあるどんなパーティーも文脈を決定できます。 さらに、プロトコルは、材料を合わせることへの正統のアクセスがあるすべてのパーティーには合わせることの材料のための同じ文脈があるのを確実にしなければなりません。 これは、パーティーが適切に特定されて、認証されるのを必要とします、合わせることの材料に近づく手段を持っているパーティーのすべてが決定できるように。
Housley & Aboba Best Current Practice [Page 12] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[12ページ]RFC4962指導
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プロトコルにおけるこれらのパーティーを特定するのに必要です。 別の名前フォームが、セッションキーを使う下層の中でこれらのパーティーを特定するのに必要であるかもしれません。
4. AAA Key Management Recommendations
4. AAA Key Management推薦
Acceptable solutions SHOULD meet all of these requirements.
許容できるソリューションSHOULDはこれらの要件のすべてに会います。
Confidentiality of identity
アイデンティティの秘密性
In many environments, it is important to provide
confidentiality protection for identities. However, this is
not important in other environments. For this reason, EAP
methods are encouraged to provide a mechanism for identity
protection of EAP peers, but such protection is not a
requirement.
多くの環境で、アイデンティティのための秘密性保護を提供するのは重要です。 しかしながら、これは他の環境で重要ではありません。 この理由で、EAPメソッドがEAP同輩のアイデンティティ保護にメカニズムを提供するよう奨励されますが、そのような保護は要件ではありません。
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と共に合わせることの材料を使用できるだけです。 そして
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と共に合わせることの材料を使用できるだけです)。
Housley & Aboba Best Current Practice [Page 13] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[13ページ]RFC4962指導
5. Security Considerations
5. セキュリティ問題
This document provides architectural guidance to designers of AAA key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols.
このドキュメントはAAAかぎ管理プロトコルのデザイナーに建築指導を提供します。 また、指導もAAAかぎ管理プロトコルを含んでいるシステムとソリューションのデザイナーの役に立ちます。
In some deployment scenarios, more than one party in the AAA key management protocol can reside on the same host. For example, the EAP authenticator and AAA client are expected to reside on the same entity. Colocation enables a single unique authenticator identity to be sent by the authenticator to the AAA server as well as by the authenticator to the EAP peer. Use of the same identity in both conversations enables the peer and AAA server to confirm that the authenticator is consistent in its identification, avoiding potential impersonation attacks. If the authenticator and AAA client are not colocated, then the authenticator and AAA client identities will differ, and the key scope will not be synchronized between the EAP peer, authenticator, and server. Lack of key scope synchronization enables a number of security vulnerabilities, including impersonation. For this reason, a design needs to include mechanisms to ensure that the key scope and key naming are unambiguous.
いくつかの展開シナリオでは、AAAかぎ管理プロトコルにおける1回以上のパーティーが同じホストの上に住むことができます。 例えば、EAP固有識別文字とAAAのクライアントが同じ実体に住んでいると予想されます。 コロケーションは、ただ一つのユニークな固有識別文字のアイデンティティがAAAサーバへの固有識別文字とEAP同輩への固有識別文字によって送られるのを可能にします。 両方の会話における同じアイデンティティの使用は、同輩とAAAサーバが、固有識別文字が識別で一貫していると確認するのを可能にします、潜在的ものまね攻撃を避けて。 固有識別文字とAAAのクライアントがcolocatedされないと、固有識別文字とAAAクライアントのアイデンティティは異なるでしょう、そして、主要な範囲はEAP同輩と、固有識別文字と、サーバの間で連動しないでしょう。主要な範囲同期の不足は多くのセキュリティの脆弱性を可能にします、ものまねを含んでいて。 この理由で、デザインは、主要な範囲と主要な命名が確実に明白になるようにするためにメカニズムを含む必要があります。
The AAA server is a trusted entity. When keying material is present at all, it establishes keying material with the peer and distributes keying material to the authenticator using the AAA protocol. It is trusted to only distribute keying material to the authenticator that was established with the peer, and it is trusted to provide that keying material to no other parties. In many systems, keying material established by the EAP peer and EAP server are combined with publicly available data to derive other keys. The AAA server is trusted to refrain from deriving these same keys even though it has access to the secret values that are needed to do so.
AAAサーバは信じられた実体です。 材料を合わせるのが全く存在しているとき、それは、同輩と共に合わせることの材料を確立して、AAAプロトコルを使用することで合わせることの材料を固有識別文字に分配します。 合わせることの材料を固有識別文字に分配するだけであるために、それが同輩と共に確証されて、どんな相手にも材料を合わせないことでそれを提供すると信じられるのが信じられます。 多くのシステムでは、EAP同輩によって確立された材料を合わせて、EAPサーバは、他のキーを引き出すために公的に利用可能なデータに結合されます。 AAAサーバが、そうするのに必要である秘密の値に近づく手段を持っていますが、これらの同じキーを引き出すのを控えると信じられます。
The authenticator is also a trusted party. The authenticator is trusted not to distribute keying material provided by the AAA 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 this document, confirming that keys used to protect data are to be known only by the peer and authenticator.
また、固有識別文字は信じられたパーティーです。 サーバがAAAでいかなる他のもパーティーへ行くなら、固有識別文字が合わせることの材料を分配しないと信じられます。 固有識別文字が追加合わせることの材料を誘導するのに主要な派生機能を使用するなら、固有識別文字が同輩にもかかわらず、他のパーティーがないのにおいて知られている適切なパーティーだけに材料を合わせながら派生を分配すると信じられます。 このアプローチが使用されているとき、結果として起こるかぎ管理システムが本書では原則のすべてに会うのを保証するために注意しなければなりません、データを保護するのに使用されるキーが単に同輩と固有識別文字によって知られていることになっていると確認して。
EAP is used to authenticate the peer to the AAA/EAP server. Following successful authentication, the AAA/EAP server authorizes the peer. In many situations, this is accomplished by sending keying material to the authenticator and the peer in separate protocol
EAPは、AAA/EAPサーバに同輩を認証するのに使用されます。うまくいっている認証に続いて、AAA/EAPサーバは同輩に権限を与えます。 多くの状況で、これは、別々のプロトコルで固有識別文字と同輩に材料を合わせながら発信することによって、達成されます。
Housley & Aboba Best Current Practice [Page 14] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[14ページ]RFC4962指導
messages. The authenticator is not directly authenticated to the peer. Rather, the peer determines that the authenticator has been authorized by the AAA/EAP server by confirming that the authenticator has the same AAA/EAP server-provided keying material. In some systems, explicit authenticator and peer mutual authentication is possible. This is desirable since it greatly improves accountability.
メッセージ。 固有識別文字は直接同輩に認証されません。 むしろ、同輩は、固有識別文字で同じAAA/EAPのサーバで提供された合わせるのが物質的になると確認することによって固有識別文字がAAA/EAPサーバによって認可されたと決心しています。 いくつかのシステム、明白な固有識別文字、および同輩では、互いの認証は可能です。 責任を大いに改良するので、これは望ましいです。
When MIB modules are developed for AAA protocols or EAP methods, these MIB modules might include managed objects for keying material. The existence of managed objects associated with keying material offers an additional avenue for key compromise if these objects include the keying material itself. Therefore, these MIB modules MUST NOT include objects for private keys or symmetric keys. However, these MIB modules MAY include management objects that expose names and context associated with keys, and they MAY provide a means to delete keys.
MIBモジュールがAAAプロトコルかEAPメソッドのために開発されるとき、これらのMIBモジュールは材料を合わせるための管理オブジェクトを含むかもしれません。 これらのオブジェクトが合わせることの材料自体を含んでいるなら、材料を合わせると関連している管理オブジェクトの存在は主要な感染のために追加大通りを提供します。 したがって、これらのMIBモジュールは秘密鍵のためのオブジェクトか対称鍵を含んではいけません。 しかしながら、これらのMIBモジュールはキーに関連している名前と文脈を暴露する管理オブジェクトを含むかもしれません、そして、それらはキーを削除する手段を提供するかもしれません。
6. Normative References
6. 引用規格
[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月。
7. Informative References
7. 有益な参照
[802.1X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2004,
December 2004.
地方とメトロポリタンエリアネットワークの[802.1X]IEEE規格: ポートは2004年12月にNetwork Access Control、IEEE Std 802.1X-2004を基礎づけました。
[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, July
2004.
[802.11i]米国電気電子技術者学会、「システムの間のテレコミュニケーションと情報交換--LAN/男性決められた一定の要求--パート11の規格に補ってください」 ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様: 「警備の強化のための仕様」、IEEE 802.11i、2004年7月。
[802.16e] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems -- LAN/MAN Specific
Requirements - 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 Operation in Licensed Bands", Draft, IEEE
802.16e/D8, May 2005.
[802.16e]米国電気電子技術者学会、「システムの間のテレコミュニケーションと情報交換--LAN/男性決められた一定の要求--パート16の規格に補ってください」 「修理されてモバイルの広帯域のワイヤレス・アクセスシステムのための空気インタフェース--物理的で中型のアクセスコントロールのための修正は結合した修理されてモバイルの操作のために認可されたバンドで層にされます」、草稿、IEEE 802.16e/D8、2005年5月。
Housley & Aboba Best Current Practice [Page 15] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[15ページ]RFC4962指導
[AN] M. Abadi and R. Needham, "Prudent Engineering Practice for
Cryptographic Protocols", Proc. IEEE Computer Society
Symposium on Research in Security and Privacy, May 1994.
[AN]M.AbadiとR.ニーダム、「暗号のプロトコルのための慎重なエンジニアリング方式」、Proc。 1994年5月のセキュリティとプライバシーにおける研究に関するIEEEコンピュータ社会シンポジウム。
[B] Brewin, B., "LEAP attack tool author says he wants to
alert users to risks", Computerworld, October 17, 2003.
[B]Brewin、B.、「LEAP攻撃ツール作者は、リスクにユーザの注意を喚起したがっていると言う」Computerworld、2003年10月17日。
[BM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos
authentication system", Proceedings of the 1991 Winter
USENIX Conference, pp. 253-267, 1991.
[BM] BellovinとS.とM.メリット、「ケルベロス認証システムの限界」、1991年のWinter USENIXコンファレンスのProceedings、ページ 253-267, 1991.
[DDNN39.2] DCA DDN Program Management Office, "MILNET TAC Access
Control", Defense Data Network Newsletter, DDN News 39,
Special Issue, 26 Apr 1985, <http://www.isi.edu/
in-notes/museum/ddn-news/ddn-news.n39.2>.
[DDNN39.2]DCA DDN Program管理事務所、「MILNET TACはコントロールにアクセスします」、Defense Data Networkニュースレター、DDN News39、Special Issue、1985年4月26日、<http://www.isi.edu/注意している/ddn博物館/ニュース/ddn-news.n39.2>。
[DLS] Dole, B., Lodin, S. and E. Spafford, "Misplaced trust:
Kerberos 4 session keys", Proceedings of the Internet
Society Network and Distributed System Security Symposium,
pp. 60-70, March 1997.
[DLS] ドール、B.、Lodin、S.、およびE.Spafford、「置き違えられて、以下を信じてください」 「ケルベロス4セッションキー」、インターネット協会NetworkとDistributed System Security SymposiumのProceedings、ページ 60-70と、1997年3月。
[DS] D. Denning and G. Sacco. "Timestamps in key distributed
protocols", Communication of the ACM, 24(8):533--535,
1981.
[DS] D.デニングとG.サッコ。 533--535、「主要な分配されたプロトコルのタイムスタンプ」、ACM、24(8)のCommunication:1981。
[FIPS46] Federal Information Processing Standards Publication (FIPS
PUB) 46, Data Encryption Standard, 1977 January 15.
データ暗号化規格、1977年の15年1月[FIPS46]連邦政府の情報処理規格公表(FIPSパブ)46日。
[H] Housley, R., "Key Management in AAA", Presentation to the
AAA WG at IETF 56, March 2003, <http://www.ietf.org/
proceedings/03mar/slides/aaa-5/index.html>.
[H]Housley、R.、「AAAにおけるKey Management」、IETF56、2003年3月、<http://www.ietf.org/議事/03mar/スライド/aaa-5/index.html>のAAA WGへのPresentation。
[L] G. Lowe. "An attack on the Needham-Schroeder public key
authentication protocol", Information Processing Letters,
56(3):131--136, November 1995.
[L] G.ロウ。 「ニーダム-シュローダー公開鍵認証プロトコルに対する攻撃」、情報Processing Letters、56(3): 131--136と、1995年11月。
[M] Meadows, C., "Analysis of the Internet Key Exchange
Protocol using the NRL Protocol Analyser", Proceedings of
the 1999 IEEE Symposium on Security & Privacy, Oakland,
CA, USA, IEEE Computer Society, May 1999,
<http://chacs.nrl.navy.mil/publications/CHACS/1999/
1999meadows-IEEE99.pdf>.
[M] 草地、C.、「NRLプロトコル分析器を使用するインターネット・キー・エクスチェンジプロトコルの分析」(セキュリティとプライバシーにおける1999年のIEEEシンポジウムの議事、オークランド(カリフォルニア)(米国)IEEEコンピュータ社会)は1999、<http://chacs.nrl.navy.mil/刊行物/CHACS/1999/ 1999meadows-IEEE99.pdf>がそうするかもしれません。
[NS] R. Needham and M. Schroeder. "Using encryption for
authentication in large networks of computers",
Communications of the ACM, 21(12), December 1978.
[ナノ秒] R.ニーダムとM.シュローダー。 「認証にコンピュータの大きいネットワークに暗号化を使用します」、ACM、21(12)、1978年12月のCommunications。
Housley & Aboba Best Current Practice [Page 16] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[16ページ]RFC4962指導
[RFC0927] Anderson, B.A., "TACACS user identification Telnet
option", RFC 927, December 1984.
[RFC0927] アンダーソン、学士、「TACACSユーザ登録名Telnetオプション」、RFC927、1984年12月。
[RFC1334] Lloyd, B. and B. Simpson, "PPP Authentication Protocols",
RFC 1334, October 1992, Obsoleted by RFC 1994.
[RFC1334] RFC1334(1992年10月)は、RFC1994でロイドとB.とB.シンプソン、「ppp認証プロトコル」と時代遅れにしました。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, July 1993.
[RFC1492]Finseth、1993年7月のC.、「時々TACACSと呼ばれるアクセス制御プロトコル」RFC1492
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968,
June 1996.
G.、「ppp暗号化プロトコル(ECP)」、RFC1968 1996年6月の[RFC1968]マイヤー。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
1998年の[RFC2284]BlunkとL.とJ.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption
Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2419]SklowerとK.とG.マイヤー、「ppp DES暗号化プロトコル、バージョン2(2回DESE)」、RFC2419 1998年9月。
[RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol
(3DESE)", RFC 2420, September 1998.
K.、「ppp三重のDES暗号化プロトコル(3DESE)」、RFC2420 1998年9月の[RFC2420]Hummert。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC
2433, October 1998.
[RFC2433] ゾルンとG.とS.コッブ、「マイクロソフトpppやつ拡大」、RFC2433、1998年10月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2548] ゾルン、G.、「マイクロソフトのベンダー特有の半径属性」、RFC2548、1999年3月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, July 1999.
[RFC2637] Hamzeh、K.、祭服、G.、Verthein、W.、Taarud、J.、少し、w.、およびG.ゾルン、「二地点間トンネリングプロトコル(PPTP)」、RFC2637(1999年7月)。
[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月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
2759, January 2000.
[RFC2759] ゾルン、G.、「マイクロソフトpppやつ拡大、バージョン2インチ、RFC2759、2000年1月。」
Housley & Aboba Best Current Practice [Page 17] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[17ページ]RFC4962指導
[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月)。
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model", RFC
2881, July 2000.
[RFC2881] ミットンとD.とM.用務員、「ネットワークアクセス・サーバー要件次世代(NASREQNG)NASはモデル化する」RFC2881、2000年7月。
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001.
[RFC3078] 祭服とG.とG.ゾルン、「マイクロソフトの二地点間暗号化(MPPE)プロトコル」、RFC3078、2001年3月。
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-
Point Encryption (MPPE)", RFC 3079, March 2001.
[RFC3079] ゾルン、G.、「マイクロソフトPointからポイントへのEncryption(MPPE)との使用のためにキーズを引き出す」RFC3079、2001年3月。
[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月)。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC3748]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strength for Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC
3766, April 2004.
[RFC3766] OrmanとH.とP.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、2004年4月。
[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月)。
[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日
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[SM1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's
Point-to-Point Tunneling Protocol", Proceedings of the 5th
ACM Conference on Communications and Computer Security,
ACM Press, November 1998.
[SM1]シュナイアー、B.、およびマッジ、「マイクロソフトの二地点間トンネリングの暗号文解読術は議定書を作ります」、5の番目ものの議事。コミュニケーションとコンピュータセキュリティに関するACMコンファレンス、ACMプレス(1998年11月)。
[SM2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP
Authentication Extensions (MS-CHAPv2)", CQRE 99,
Springer-Verlag, 1999, pp. 192-203.
[SM2] シュナイアーとB.とマッジ、「マイクロソフトのPPTP認証拡張子(MS-CHAPv2)の暗号文解読術」、CQRE99、Springer-Verlag、1999、ページ 192-203.
Housley & Aboba Best Current Practice [Page 18] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[18ページ]RFC4962指導
[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がそうするかもしれません。
[W] Wu, T., "A Real-World Analysis of Kerberos Password
Security", Proceedings of the 1999 ISOC Network and
Distributed System Security Symposium,
<http://www.isoc.org/isoc/conferences/ndss/99/
proceedings/papers/wu.pdf>.
[W] ウー、T.、「ケルベロスパスワードセキュリティの本当の世界分析」、1999ISOC NetworkとDistributed System Security SymposiumのProceedings(<http://www.isoc.org/isoc/会議/ndss/99/議事/書類/wu.pdf>)。
Housley & Aboba Best Current Practice [Page 19] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[19ページ]RFC4962指導
Appendix: AAA Key Management History
付録: AAA Key Management歴史
Protocols for Authentication, Authorization, and Accounting (AAA) were originally developed to support deployments of Network Access Servers (NASes). In the ARPAnet, the Terminal Access Controller (TAC) provided a means for "dumb terminals" to access the network, and the TACACS [RFC0927][RFC1492] AAA protocol was designed by BBN under contract to the Defense Data Network Program Management Office (DDN PMO) for this environment. [RFC1492] documents a later version of TACACS, not the original version that was widely deployed in ARPAnet and MILNET [DDNN39.2].
Authentication、Authorization、およびAccounting(AAA)のためのプロトコルは、元々、Network Access Servers(NASes)の展開をサポートするために開発されました。 ARPAnetに、Terminal Access Controller(TAC)は「ダム端末」がネットワークにアクセスする手段を供給しました、そして、TACACS[RFC0927][RFC1492]AAAプロトコルはこの環境のためにBBNによって契約に基づきDefense Data Network Program管理事務所(DDN PMO)に設計されました。 [RFC1492]はARPAnetとMILNET[DDNN39.2]で広く配布されたオリジナルバージョンではなく、TACACSの後のバージョンを記録します。
Later, additional AAA protocols were developed to support deployments of NASes providing access to the Internet via PPP [RFC1661]. In deployments supporting more than a modest number of users, it became impractical for each NAS to contain its own list of users and associated credentials. As a result, additional AAA protocols were developed, including RADIUS [RFC2865] and Diameter [RFC3588]. These protocols enabled a central AAA server to authenticate users requesting network access, as well as providing authorization and accounting.
その後、追加AAAプロトコルは、PPP[RFC1661]を通してインターネットへのアクセスを提供するNASesの展開をサポートするために開発されました。 1以上の穏やかな番号のユーザをサポートする展開では、各NASがそれ自身のユーザーズ・リストと関連資格証明書を含むのは非実用的になりました。 その結果、RADIUS[RFC2865]とDiameter[RFC3588]を含んでいて、追加AAAプロトコルは開発されました。 これらのプロトコルは、主要なAAAサーバが承認と会計を提供することと同様にネットワークアクセスを要求するユーザを認証するのを可能にしました。
While PPP [RFC1661] originally supported only PAP [RFC1334] and CHAP [RFC1661] authentication, the limitations of these authentication mechanisms became apparent. For example, both PAP and CHAP are unilateral authentication schemes supporting only authentication of the PPP peer to the NAS. Since PAP is a cleartext password scheme, it is vulnerable to snooping by an attacker with access to the conversation between the PPP peer and NAS. In addition, the use of PAP creates vulnerabilities within RADIUS as described in Section 4.3 of [RFC3579]. As a result, use of PAP is deprecated. While CHAP, a challenge-response scheme based on MD5, offers better security than cleartext passwords, it does not provide for mutual authentication, and CHAP is vulnerable to dictionary attack.
PPP[RFC1661]は、元々PAP[RFC1334]と唯一のCHAP[RFC1661]が認証であるとサポートしましたが、これらの認証機構の限界は明らかになりました。 例えば、PAPとCHAPの両方がPPP同輩の認証だけをNASにサポートする一方的な認証体系です。 PAPがcleartextパスワード体系であるので、それはPPP同輩とNASとの会話へのアクセスで攻撃者で詮索するのに被害を受け易いです。 さらに、PAPの使用は[RFC3579]のセクション4.3で説明されるようにRADIUSの中で脆弱性を作成します。 その結果、PAPの使用は推奨しないです。 CHAP(MD5に基づくチャレンジレスポンス体系)がcleartextパスワードより良いセキュリティを提供している間、互いの認証に備えません、そして、CHAPは辞書攻撃に被害を受け易いです。
With the addition of the Encryption Control Protocol (ECP) to PPP [RFC1968] as well as the definition of PPP ciphersuites in [RFC2419], [RFC2420], and [RFC3078], the need arose to provide keying material for use with link layer ciphersuites. As with user authentication, provisioning of static keys on each NAS did not scale well.
[RFC2419]、[RFC2420]、および[RFC3078]とのPPP ciphersuitesの定義と同様にPPP[RFC1968]へのEncryption Controlプロトコル(ECP)の追加で、必要性は、使用のための材料を合わせるのをリンクレイヤciphersuitesを提供するために起こりました。 ユーザー認証のように、各NASの静的なキーの食糧を供給することはよく比例しませんでした。
Additional vendor-specific PPP authentication protocols such as MS-CHAP [RFC2433] and MS-CHAPv2 [RFC2759] were developed to provide mutual authentication as well as key derivation [RFC3079] for use with negotiated ciphersuites, and they were subsequently adapted for use with PPP-based VPNs [RFC2637]. As with PAP and CHAP, flaws were subsequently found in these new mechanisms [SM1][SM2].
さん-CHAP[RFC2433]やMS-CHAPv2[RFC2759]などの追加ベンダー特有のPPP認証プロトコルは使用のための主要な派生[RFC3079]と同様に互いの認証を交渉されたciphersuitesに供給するために開発されました、そして、それらは次に、PPPベースのVPNs[RFC2637]との使用のために適合させられました。 PAPとCHAPのように、欠点は次に、これらの新しいメカニズム[SM1][SM2]で見つけられました。
Housley & Aboba Best Current Practice [Page 20] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[20ページ]RFC4962指導
Even though PPP provided for negotiation of authentication algorithms, addressing the vulnerabilities found in authentication mechanisms still proved painful, since new code needed to be deployed on PPP peers as well as on the AAA server. In order to enable more rapid deployment of new authentication mechanisms, as well as fixes for vulnerabilities found in existing methods, the Extensible Authentication Protocol (EAP) [RFC3748] was developed, along with support for centralized authentication via RADIUS/EAP [RFC3579].
PPPは認証アルゴリズムの交渉に備えましたが、認証機構で見つけられた脆弱性を扱うのは苦痛であるとまだ判明していました; 以来、新法は、PPP同輩の上と、そして、AAAサーバの上で配布される必要がありました。拡張認証プロトコル(EAP)RFC3748は新しい認証機構の、より急速な展開、および既存の方法で見つけられた脆弱性のためのフィックスを可能にするために開発されました、RADIUS/EAP RFC3579を通した集結された認証のサポートと共に。
By enabling "pass through" authentication on the NAS, EAP enabled deployment of new authentication methods or updates to existing methods by revising code only on the EAP peer and AAA server. The initial authentication mechanisms defined in [RFC2284] (MD5- Challenge, One-Time Password (OTP), and Generic Token Card (GTC)) only supported unilateral authentication, and these mechanisms do not support key derivation. Subsequent authentication methods such as EAP-TLS [RFC2716] supported mutual authentication and key derivation.
NASで「通り抜けてください」という認証を可能にすることによって、EAPはEAP同輩とAAAサーバだけのコードを改訂することによって、新しい認証方法の展開を可能にするか、またはメソッドを存在するのにアップデートします。初期の認証機構は[RFC2284]で一方的な認証であるとサポートされただけであった(One-時間のMD5挑戦、Password(OTP)、およびGeneric Token Card(GTC))を定義しました、そして、これらのメカニズムは主要な派生をサポートしません。 EAP-TLS[RFC2716]などのその後の認証方法は互いの認証と主要な派生をサポートしました。
In order to support the provisioning of dynamic keying material for link layer ciphersuites in an environment supporting centralized authentication, a mechanism was needed for the transport of keying material between the AAA server and NAS. Vendor-specific RADIUS attributes were developed for this purpose [RFC2548]. Vulnerabilities were subsequently found in the key wrap technique, as described in Section 4.3 of [RFC3579].
リンクレイヤciphersuitesのために集結された認証をサポートする環境で材料を合わせる動力の食糧を供給することをサポートするために、メカニズムがAAAサーバとNASの間の合わせることの材料の輸送に必要でした。 ベンダー特有のRADIUS属性はこのために[RFC2548]開発されました。 脆弱性は次に、[RFC3579]のセクション4.3で説明されるように主要な包装のテクニックで見つけられました。
In theory, public key authentication mechanisms such as EAP-TLS are capable of supporting mutual authentication and key derivation between the EAP peer and NAS without requiring AAA key distribution. However, in practice, such pure two-party schemes are rarely deployed. Operation of a centralized AAA server significantly reduces the effort required to deploy certificates to NASes, and even though an AAA server may not be required for key derivation and possibly authentication, its participation is required for service authorization and accounting.
理論上、AAAの主要な分配を必要としないで、EAP-TLSなどの公開鍵認証機構はEAP同輩とNASの間の互いの認証と主要な派生をサポートすることができます。 しかしながら、実際には、そのような純粋な2パーティーの体系はめったに配布されません。 集結されたAAAサーバの操作はNASesに証明書を配布するのに必要である取り組みをかなり減少させます、そして、AAAサーバは主要な派生とことによると認証に必要でないかもしれませんが、参加がサービス承認と会計で必要です。
"Pass-through" authentication and AAA key distribution has retained popularity even in the face of rapid improvements in processor and memory capabilities. In addition to producing NAS devices of increased capability for enterprise and carrier customers, implementers have also produced low-cost/high-volume NAS devices such as 802.11 Access Points, causing the resources available on an average NAS to increase more slowly than Moore's law. Despite widespread support for certificate handling and sophisticated key derivation mechanisms such as IKEv1 [RFC2409] within host operating systems, these security capabilities are rarely deployed on low-end NASes and clients.
「通じて、通り」認証とAAAの主要な分配はプロセッサでの急速な改良とメモリ能力に直面してさえ人気を保有しました。 また、企業とキャリヤー顧客のために増強された能力のNASデバイスを生産することに加えて、implementersは802.11Access Pointsなどの安価の/大容量NASデバイスを生産しました、平均したNASで利用可能なリソースがムーアの法則よりゆっくり増加することを引き起こして。 ホスト・オペレーティング・システムの中の証明書取り扱いの広範囲のサポートとIKEv1[RFC2409]などの精巧な主要な派生メカニズムにもかかわらず、これらのセキュリティ能力はローエンドNASesとクライアントの上でめったに配布されません。
Housley & Aboba Best Current Practice [Page 21] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[21ページ]RFC4962指導
Even on more capable NASes, such as VPN servers, centralized authentication and AAA key management has proven popular. For example, one of the major limitations of IKEv1 [RFC2409] was the lack of integration with EAP and AAA, requiring proprietary extensions to enable use of IPsec VPNs by organizations deploying password or authentication tokens. These limitations were addressed in IKEv2 [RFC4306], which while handling key derivation solely between the VPN client and server, supports EAP methods for user authentication. In order to enable cryptographic binding of EAP user authentication to keys derived within the IKEv2 exchange, the transport of EAP-derived keys within AAA is required where the selected EAP method supports key derivation.
VPNサーバなどの、よりできるNASesでさえ、集結された認証とAAAかぎ管理はポピュラーであると判明しました。 例えば、パスワードか認証がトークンであると配布する組織によるIPsec VPNsの使用を可能にするために独占拡大を必要として、IKEv1[RFC2409]の主要な限界の1つはEAPとAAAとの統合の不足でした。 これらの制限は[RFC4306](唯一VPNクライアントとサーバの間の取り扱いキー派生をゆったり過ごす)がユーザー認証のためにEAPメソッドであるとサポートするIKEv2で扱われました。 IKEv2交換の中で引き出されたキーにEAPユーザー認証の暗号の結合を可能にするために、AAAの中のEAPによって派生させられたキーの輸送が選択されたEAPメソッドが主要な派生をサポートするところで必要です。
Acknowledgments
承認
Many thanks to James Kempf, Sam Hartman, and Joe Salowey for their quality review and encouragement.
彼らの上質のレビューと奨励のためにジェームス・ケンフ、サム・ハートマン、およびジョーSaloweyをありがとうございます。
Thanks to the IETF AAA Working Group and the IETF EAP Working Group for their review and comment. The document is greatly improved by their contribution.
彼らのレビューとコメントをIETF AAA作業部会とIETF EAP作業部会をありがとうございます。 ドキュメントは彼らの貢献で大いに改良されます。
Authors' Addresses
作者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Phone: +1 703-435-1775 Fax: +1 703-435-1274
ラッセルHousley不寝番セキュリティ、LLC918春の小山Driveヴァージニア20170ハーンドン(米国)メール: housley@vigilsec.com 電話: +1 703-435-1775Fax: +1 703-435-1274
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: bernarda@microsoft.com Phone: +1 425-706-6605 Fax: +1 425-936-7329
ワシントン98052レッドモンド(米国)がメールされるバーナードAbobaマイクロソフト社1マイクロソフト方法: bernarda@microsoft.com 電話: +1 425-706-6605Fax: +1 425-936-7329
Housley & Aboba Best Current Practice [Page 22] RFC 4962 Guidance for AAA Key Management July 2007
管理2007年7月に主要なAAAのためのHousley&Abobaの最も良い現在の習慣[22ページ]RFC4962指導
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Housley & Aboba Best Current Practice [Page 23]
Housley&Abobaの最も良い現在の習慣[23ページ]
一覧
スポンサーリンク
