[要約] RFC 4962は、AAAキー管理の認証、認可、会計に関するガイダンスを提供するものであり、セキュリティの向上とネットワークリソースの効果的な管理を目的としています。
Network Working Group R. Housley
Request for Comments: 4962 Vigil Security
BCP: 132 B. Aboba
Category: Best Current Practice Microsoft
July 2007
Guidance for Authentication, Authorization, and Accounting (AAA) Key Management
認証、承認、会計（AAA）鍵管理のためのガイダンス
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.
このドキュメントは、インターネットコミュニティのためのインターネットの最良の現在の慣行を指定し、改善のための議論と提案を要求します。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）IETF Trust（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.
この資料は、認証、承認、および会計（AAA）鍵管理プロトコルの設計者へのガイダンスを提供します。ガイダンスは、AAA鍵管理プロトコルを含むシステムやソリューションの設計者にも役立ちます。フィールド内の専門家による安全で長期的な鍵管理アルゴリズムとプロトコルの設計の複雑さと困難性を考えると、それに基づく独自の鍵管理アルゴリズムとプロトコルを設計するためのIETFワーキンググループにはほぼ確実に不適切です。認証、承認、および会計（AAA）プロトコル。この文書のガイドラインは、IETF RFCとして出版物を要求する文書に適用されます。さらに、これらのガイドラインは、AAA鍵管理を指定する他の標準開発組織（SDO）に役立ちます。
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
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ワーキンググループにはほぼ確実に不適切です。認証、承認および会計（AAA）プロトコル。これらのガイドラインは、IETF RFCとして出版物を要求する文書に適用されます。さらに、これらのガイドラインは、拡張認証プロトコル（EAP）[RFC3748]、リモート認証ダイヤルインユーザサービス（RADIUS）などのプロトコルのIETF仕様に依存するAAA鍵管理を指定する他の標準開発組織（SDO）に役立ちます。RFC2865]、および直径[RFC3588]。
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月、IETF 56 AAAワーキンググループセッションで、Russ Housleyは「AAAの鍵管理」[H]に関するプレゼンテーションを行いました。その発表は、この文書に含まれている要件の大多数を確立しました。過去3年間で、この要件のコレクションは「ホウレー基準」として知られています。
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].
この文書に記載されている場合は、この文書に記載されている場合は、必要ではなく、必ずしてはいけません。
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".
AAA鍵管理の提案は、必要とされている、またはステートメントのうちの1つ以上を満たすことができない場合は、この仕様に準拠していません。すべての必要が満たされていて、ステートメントを満たすべきではなく、声明が「無条件に準拠している」と言われてはならないAAA鍵管理提案。すべてを満足する必要があり、文を満たす必要があり、必要とされていないが、要件が必要ではなく、必要ではありませんが、「条件付き準拠」と言われています。
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]は、第三者への開示なしに、AAAサーバからAAAクライアントへのEAPキーイング材料をAAAクライアントに配信できるようにします。したがって、鍵の機密性は、直径[RFC3588]を実装することを必須です。ただし、主要な機密性は使用に必須ではありません。
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プロトコルには、半径[RFC2865]と直径[RFC3588]があります。
Authenticator The party initiating EAP authentication. The term authenticator is used in [802.1X], and authenticator has the same meaning in this document.
Authenticator EAP認証を開始するパーティー。Authenticatorという用語は[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].
バックエンド認証サーバーバックエンド認証サーバーは、認証者に認証サービスを提供するエンティティです。この用語は[802.1x]でも使用されています。
CHAP Challenge Handshake Authentication Protocol; a one-way challenge/response authentication protocol defined in [RFC1994].
CHAPチャレンジハンドシェイク認証プロトコル。[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 Serverピアを使用して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).
キーを別の対称暗号鍵の暗号化を包みます。暗号化に使用されるアルゴリズムは、キーラップアルゴリズムまたはキー暗号化アルゴリズムと呼ばれます。暗号化プロセスで使用されているキーは、キー暗号化キー（KEK）と呼ばれます。
PAP Password Authentication Protocol; a deprecated cleartext password PPP authentication protocol, originally defined in [RFC1334].
PAPパスワード認証プロトコル。RFC1334で最初に定義されている非推奨のクリアテキストパスワードPPP認証プロトコル。
Party A party is a processing entity that can be identified as a single role in a protocol.
パーティのパーティーは、プロトコル内の単一の役割として識別できる処理エンティティです。
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.
[RFC1661]で定義されているPPPポイントツーポイントプロトコルは、マルチプロトコルシリアルデータリンクをサポートしています。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].
セキュアアソシエーションプロトコルEAPおよび/またはAAAの交換から派生したセキュリティアソシエーションを管理するためのプロトコル。このプロトコルは、Symmetricキーとキーを使用するコンテキストを含むセキュリティアソシエーションを確立します。セキュアアソシエーションプロトコルの例は、[802.11i]内に定義されている4方向ハンドシェイクです。
Session Keys Keying material used to protect data exchanged after authentication has successfully completed, using the negotiated 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].
ネットワークアクセスサーバー（NAS）ユーザーがネットワークへのアクセスサービスを提供する装置。サービスは、[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.
4ウェイハンドシェイク[802.11i]で定義されているセキュアアソシエーションプロトコルは、2つのパーティでペアワイズマスターキーの相互所有を確認し、グループキーを配布します。
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年の開発プロトコルを最初に定義し、1978年[NS]に掲載された主要管理プロトコルを最初に定義したことから始めて、主要管理プロトコル開発の履歴を悩ませます。1981年[DS]に欠陥と修正が出版され、1994年に修正が壊れました[AN]。1995年には、1981年/ 1994年の号の影響を受けない地域で、オリジナルの1978年版に新しい欠陥が見つかりました。これらの欠陥の全てが盲目的に明らかだったが、それでも誰もそれらを早く発見した。オリジナルのプロトコルは、それが証明書を雇用するために修正された場合、どちらがまだ発明されていなければ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およびIEEE 802などの他の規格開発組織（SDO）によって開発された規格に組み込まれています。セキュリティ特性を理解して、よく研究されている暗号化アルゴリズムが使用されています。それが今日雇用されている多様なプロトコル環境におけるAAAベースの鍵管理のセキュリティ特性を十分に理解するためには、より多くの学術研究が必要です。そのような研究結果がない場合、音のセキュリティ工学の原則に基づく実用的なガイダンスが必要です。
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.
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.
AAAの履歴は、CHAP、MS-CHAPV1 [SM1]、MS-CHAPV2 [SM2]、Kerberos [W] [BM] [DLS]などの認証メカニズムに欠陥が見つかったため、アルゴリズム独立性の重要性を強調しています。b]。残念なことに、RADIUS [RFC2865]は、既知の欠陥を持ち、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 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.
EAPは新しい方法で使用されています。IEP内のEAPのサポートをインターネットキー交換プロトコルバージョン2（IKEV2）と、EAPに基づく堅牢な無線LANセキュリティの標準化[802.11i]の標準化は2つの例です。EAPは、IEEE 802.16e [802.16e]とIETF PANAワーキンググループでも提案されています。AAAベースの鍵管理は、IETFおよびIEEE 802などの他の規格開発組織（SDO）によって開発された規格に組み込まれています。セキュリティ特性を理解して、よく研究されている暗号化アルゴリズムが使用されています。それが今日雇用されている多様なプロトコル環境における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は1つのエンドツーエンド認証メカニズムを選択します。[RFC3748]で定義されているメカニズムは、一方的な認証をサポートしており、相互認証やキーの派生をサポートしていません。その結果、これらのメカニズムは、無線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ピアとサーバーです。オーセンティケータは、その特定の役割に必要なキーイング資料のみを取得します。他の当事者は、どのキーイング資料に直接アクセスすることもできません。しかしながら、他の当事者は、次のセクションで定義された要件が満たされている限り、このキーイング材料から派生したキーを特定の目的で受け取ることができる。
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鍵管理の全体的な目標は、キー導出をピア・オーセンティケーターによって使用できない状況で暗号化キーイング材料を提供することです。オーセンティケータは、必要とされる可能性があるさまざまな認証メカニズムを実装するために必要なリソースを欠いているため、またはそれが別々の鍵管理会話に従事することが望ましくないため、オーセンティケータは不可能かもしれません。
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つが定義されている場合、安全なアソシエーションプロトコルでアルゴリズム独立性が必要です。これは通常、プロトコル内のアルゴリズム識別子とパラメータを含み、プロトコル仕様のアルゴリズム要件を指定することによって実現されます。非常に望ましいが、鍵導出機能（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.
アルゴリズムの独立性を保存しながら、セッションキーは強くて新鮮でなければなりません。各セッションは独立したセッションキーに値します。長い再生カウンタ（つまり、「折り返し」が「折り返さない」とは、同じセッションキーを使用して同じカウンタ値を複数回使用することがないことを確認するために、フレッシュキーが必要です。
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メソッドは最小の同等のキー強度を満たすキーの生成を許可しなければなりません。BCP 86 [RFC3766]適切な鍵サイズに関するアドバイスを提供します。国立標準技術研究所（NIST）には、[SP800-57]の適切な鍵サイズに関するアドバイスも提供しています。
A fresh cryptographic key is one that is generated specifically for the intended use. In this situation, a secure association protocol is used to establish session keys. The AAA protocol and EAP method MUST ensure that the keying material supplied as an input to session key derivation is fresh, and the secure association protocol MUST generate a separate session key for each session, even if the keying material provided by EAP is cached. A cached key persists after the authentication exchange has completed. For the AAA/EAP server, key caching can happen when state is kept on the server. For the NAS or client, key caching can happen when the NAS or client does not destroy keying material immediately following the derivation of session keys.
新鮮な暗号鍵は、意図された用途に特に発生したものです。この状況では、セキュアアソシエーションプロトコルを使用してセッションキーを確立します。AAAプロトコルとEAPメソッドは、Session Key導出への入力として提供されているキーイングマテリアルが新しいものであり、EAPによって提供されたキーイングマテリアルがキャッシュされていても、セキュアアソシエーションプロトコルは各セッションに対して別のセッションキーを生成する必要があります。認証Exchangeが完了した後、キャッシュされたキーが持続します。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.
セッションキーは互いに依存してはいけません。複数のセッションキーは、通常はNonceと呼ばれ、各セッションキーが新鮮であることを確認するために使用される限り、高レベルの共有秘密から派生することがあります。セッションキーを生成するために使用されるメカニズムは、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、およびセキュアアソシエーションプロトコルの交換など、再生保護されている必要があります。再生保護により、プロトコルメッセージ受信者は、前の正規の対話中に記録されたメッセージを破棄し、それが現在のダイアログに属しているかのように提示されたメッセージを廃棄できます。
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鍵管理プロトコルの各当事者は、通信する他の当事者に認証されなければなりません。認証メカニズムは、認証プロセスで使用される秘密値の機密性を維持する必要があります。
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.
セキュアアソシエーションプロトコルを使用してセッションキーを確立すると、セキュアアソシエーションプロトコルに関連する当事者は、セッションキーを使用する下位プロトコル環境では意味があるIDを使用して識別する必要があります。この状況では、オーセンティケータとピアは、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]および直径[RFC3588]などのAAAプロトコルは、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オーセンティケータを含む場合、「基地局ID」は関係ありません。EAPメソッドの会話は、EAPピアとEAPサーバーの間で行われます。また、多くの基地局は同じオーセンティケータアイデンティティを共有することができます。オーセンティケータIDは、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.
ピアとオーセンティケータの承認を実行する必要があります。これらのエンティティは、それを開示することなく、適切なキーイング材料の所有を実証する必要があります。承認は、ピアが新しいオーセンティケータと関連付けられているときはいつでも必要です。許可検査では特権攻撃の標高を防ぎ、不正なオーセンティケータが検出されます。
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.
承認は、ピア、NAS、バックエンド認証サーバーの間で同期されるべきです。AAA鍵管理プロトコルの交換が完了すると、これらの当事者はすべて、他の当事者に関連した認可の一般的な見方を保持する必要があります。
In addition to authenticating all parties, key management protocols need to demonstrate that the parties are authorized to possess keying material. Note that proof of possession of keying material does not necessarily prove authorization to hold that keying material. For example, within an IEEE 802.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キーイングマテリアルを持っていることを示しています。しかしながら、それ自体では、この保有証明は、その認証者がそのキーイング資料を所有するためにオーセンティケータが認証されたことを証明していない。 AAAプロキシが存在するセクション4.3.7のRFC 3579に記載されているように、AAAチェーン内の各リンクが偽装に対するチェックを実現しない限り、ある認証者が別の認証者に偽装することが可能です。これらのチェックを開いても、オーセンティケータは依然としてピアとバックエンド認証サーバとは異なる識別情報を請求することがあります。セクション7.15のRFC 3748に記載されているように、Authenticatorの主張が一貫性で正しいことを確認できるように、チャネルバインディングが必要です。
Keying material confidentiality and integrity
キーインズ材の機密性と完全性
While preserving algorithm independence, confidentiality and integrity of all keying material MUST be maintained.
アルゴリズムの独立性を保存しながら、すべてのキーイング材料の機密性と完全性を維持する必要があります。
Confirm ciphersuite selection
暗号石場の選択を確認してください
The selection of the "best" ciphersuite SHOULD be securely confirmed. The mechanism SHOULD detect attempted roll-back attacks.
「最善」の暗号石場の選択を確実に確認する必要があります。このメカニズムは、ロールバック攻撃の試みを検出する必要があります。
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鍵管理プロポーザルでは、特にキーキャッシングがサポートされている場合には、ロバストなキー命名方式が必要です。キー名は、キーのキーが参照されているすべての当事者には明らかであるように、プロトコル内のキーを参照する方法を提供します。名前を付けられないオブジェクトは管理できません。すべてのキーは一意に名前が付けられている必要があり、キー名は直接または間接的にキーイングを開示してはいけません。キー名がキーイングマテリアルに基づいていない場合は、キー値の検索を支援するために使用できないことを確認できます。
Prevent the Domino effect
Dominoの効果を防ぎます
Compromise of a single peer MUST NOT compromise keying material held by any other peer within the system, including session keys and long-term keys. Likewise, compromise of a single authenticator MUST NOT compromise keying material held by any other authenticator within the system. In the context of a key 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つの意味が強調表示に値する。第1に、キーイング材料の範囲は、そのキーイング材料を保持する当事者と通信するすべての当事者によって定義され理解されなければならない。第二に、キー階層内のキーイング資料を保持する当事者は、キー階層内の他の分岐に関連付けられている締約国とそのキーイングマテリアルを共有してはいけません。
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 キーイング材料の予想される寿命。子キーの有効期間は、キー階層内の親の有効期間より大きくしないでください。
Any party with legitimate access to keying material can determine its context. In addition, the protocol MUST ensure that all parties with legitimate access to keying material have the same context for the keying material. This requires that the parties are properly identified and authenticated, so that all of the parties that have access to the keying material can be determined.
キーイングマテリアルへの正当なアクセス権を持つ任意の当事者はその文脈を決定することができます。さらに、このプロトコルは、キーイング材料への正当なアクセス権を持つすべての当事者が、キーイング材料について同じ文脈を有することを確実にしなければならない。これは、当事者が正しく識別され認証されていることを必要とし、その結果、キーイング材料にアクセスできるすべての当事者を決定することができる。
The context will include the peer and NAS identities in more than one form. One (or more) name form is needed to identify these parties in the authentication exchange and the AAA protocol. Another name form may be needed to identify these parties within the lower layer that will employ the session key.
コンテキストには、複数のフォームにピアアイデンティティとNAS IDが含まれます。認証ExchangeおよびAAAプロトコルでこれらの当事者を識別するためには、1（またはそれ以上）の名前フォームが必要です。セッションキーを採用する下位レイヤ内のこれらの当事者を識別するためには、別の名前のフォームが必要になることがあります。
Acceptable solutions SHOULD meet all of these requirements.
許容できるソリューションは、これらすべての要件を満たすべきです。
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:
ピア認証が制限されている場合、ピアは制限を認識してください。さもなければ、ピアは誤って制限を回避しようとするかもしれません。たとえば、IEEE 802.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 キーイングマテリアルが特定のIEEE 802.11 SSIDでのみ使用できるSSIDの制限事項。
o Called-Station-ID restrictions, where the keying material can only be used with a single IEEE 802.11 BSSID; and
o キーイングを単一のIEEE 802.11 BSSIDでのみ使用できるようにすることができるSTAST-IDの制限事項。そして
o Calling-Station-ID restrictions, where the keying material can only be used with a single peer IEEE 802 MAC address.
o キーイングのあるマッキング802 MACアドレスでのみ使用できる呼び出し先IDの制限事項。
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鍵管理プロトコル内の複数のパーティーが同じホストに存在することができます。たとえば、EAPオーセンティケーターとAAAクライアントは同じエンティティに存在すると予想されます。コロケーションは、単一の固有のオーセンティケーターIDをオーセンティケータによってAAAサーバとEAPピアへのオーセンティケータに送信することができます。両面での同じアイデンティティを使用すると、ピアサーバとAAAサーバはオーセンティケータがその識別情報で一致していることを確認することができ、潜在的な偽装攻撃を回避することができます。AuthenticatorとAAAクライアントがセロッションされていない場合は、AuthenticatorとAAAクライアントのIDが異なりますが、キースコープは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 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.
EAPは、PeerをAAA / EAPサーバーに認証するために使用されます。認証が成功した後、AAA / EAPサーバーはピアを承認します。多くの状況では、これはキーイングマテリアルをオーセンティケータとピアに別々のプロトコルメッセージで送信することによって達成されます。オーセンティケータはピアに直接認証されません。むしろ、ピアは、オーセンティケータが同じ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モジュールにはキーイングアップ用の管理対象オブジェクトが含まれます。Keying Materialに関連する管理対象オブジェクトの存在は、これらのオブジェクトがキーイング資料自体を含む場合、重要な妥協案を提供します。したがって、これらのMIBモジュールは、秘密鍵や対称鍵のオブジェクトを含めてはなりません。ただし、これらのMIBモジュールは、キーに関連付けられている名前とコンテキストを公開する管理オブジェクトを含み、それらはキーを削除するための手段を提供してもよい。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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規格：Port Based Network Access Control、IEEE STD 802.1X-2004、2004年12月。
[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 / MAN特有の要件 - 第11報：無線LANメディアアクセス制御（MAC）および物理層（PHY）仕様：仕様セキュリティ強化のために、2004年7月、IEEE 802.11i。
[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 / MAN特有の要件 - 第16号：固定およびモバイルブロードバンド無線アクセスシステムのためのエアインターフェース - 物理的および中程度の修正2005年5月2005年5月2005年5月、ライセンスバンドにおける固定およびモバイル操作の組み合わせのためのアクセス制御層。
[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. Needham、「暗号プロトコルの慎重なエンジニアリング練習」、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 Attack Tool Author」は、2003年10月17日、ComputerWorld、Risksに警告することを望んでいると述べています。
[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.M.Merrit、「Kerberos認証システムの制限」、1991年のWinter Usenix Conference、PP。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プログラム管理オフィス、「Milnet TACアクセス制御」、ディフェンスデータネットワークニュースレター、DDNニュース39、特集、1985年4月26日、<http://www.isi.edu /館内/博物館/ddn-news/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] DOLE、B.、Lodin、S.およびE. Spafford、「不足している信託：Kerberos 4セッション鍵」、インターネット社会ネットワークの議事録、および分散システムセキュリティシンポジウム、PP。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. DenningおよびG.Sacco。「キー分散プロトコルのタイムスタンプ」、ACM、24（8）：533-535,1981の通信。
[FIPS46] Federal Information Processing Standards Publication (FIPS PUB) 46, Data Encryption Standard, 1977 January 15.
[FIPS46]連邦情報処理規格（FIPS PUB）46、データ暗号化規格、1977年1月15日。
[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の主な管理」、2003年3月、2003年3月、<http：//www.ietf.org/議事録/ 03mar /スライド/ aaa-5 / index。HTML>。
[L] G. Lowe. "An attack on the Needham-Schroeder public key authentication protocol", Information Processing Letters, 56(3):131--136, November 1995.
[L] G.ローエ。「Needham-Schroeder公開鍵認証プロトコルへの攻撃」、情報処理文字、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シンポジウムのセキュリティ＆プライバシー、Oakland、CA、アメリカ、IEEEコンピュータ社会、<http：//chacs.nrl.navy.mil/publications/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.
[NS] R. NeedhamとM. Schroeder。「大規模ネットワークでの認証のための暗号化の使用」、ACM、21（12）、1978年12月の通信。
[RFC0927] Anderson, B.A., "TACACS user identification Telnet option", RFC 927, December 1984.
[RFC0927] Anderson、B.A.「TACACSユーザー識別Telnetオプション」、RFC 927、1984年12月。
[RFC1334] Lloyd, B. and B. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992, Obsoleted by RFC 1994.
[RFC1334] Lloyd、B.およびB.Simpson、RFC 1334、1992年10月、RFC 1994によって廃止された。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.
[RFC1492] Finseth、C、「TACACSと呼ばれるアクセス制御プロトコル」、RFC 1492、1993年7月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] SimpSon、W.、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996.
[RFC1968] Meyer、G.、「PPP暗号化プロトコル（ECP）」、RFC 1968、1996年6月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994] Simpson、W.、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284] Blunk、L.およびJ.Vollbrecht、「PPP Extensible Authentication Protocol（EAP）」、RFC 2284、1998年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D.およびD. Carrel、「インターネット鍵交換（IKE）」、RFC 2409、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.Meyer、「PPP DES暗号化プロトコル、バージョン2（Dese-Bis）」、RFC 2419、1998年9月。
[RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[RFC2420] Hummert、K.、「PPP Triple-Des暗号化プロトコル（3DESE）」、RFC 2420、1998年9月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433] Zorn、G.およびS. COBB、「Microsoft PPP CHAP Extensions」、RFC 2433、1998年10月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G.、「マイクロソフトベンダー固有のRADIUS属性」、RFC 2548、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.、Pall、G.、Verthein、W.、Taarud、J.、Little、W.、G. Zorn、「ポイントツーポイントトンネリングプロトコル（PPTP）」、RFC 2637、7月1999年。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716] Aboba、B.およびD. Simon、「PPP EAP TLS認証プロトコル」、RFC 2716、1999年10月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759] Zorn、G.、「Microsoft PPP CHAP Extensions、バージョン2」、RFC 2759、2000年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C、Willens、S.、Rubens、A.、およびW.Simpson、「ユーザーサービスのリモート認証ダイヤル（RADIUS）」、RFC 2865、2000年6月。
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[RFC2881] Mitton、D.およびM.ビーズル、「ネットワークアクセスサーバーの要求次世代（NASREQNG）NASモデル」、RFC 2881、2000年7月。
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) Protocol", RFC 3078, March 2001.
[RFC3078] Pall、G.およびG. Zorn、「Microsoft Point-to-Point Encryption（MPPE）プロトコル」、RFC 3078、2001年3月。
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001.
[RFC3079] Zorn、G。、「Microsoft Point-to-Point Encryption（MPPE）」、RFC 3079、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.Calhoun、「RADIUS（リモート認証ダイヤルインユーザーサービス）拡張認証プロトコル（EAP）のサポート、2003年9月、RFC 3579。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G.、J.Arkko、「Diameter Base Protocol」、RFC 3588、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.、Carlson、J.、H. Levkowetz、「拡張認証プロトコル（EAP）」、RFC 3748、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. Hoffman、「対称鍵の交換に使用される公開鍵の強さの決定」、BCP 86、RFC 3766、2004年4月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017] Stanley、D.、Walker、J.、B. Aboba、「無線LANの拡張認証プロトコル（EAP）方法要件」、RFC 4017、2005年3月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、ED。、HILER、T.、およびG. Zorn、「直径拡張認証プロトコル（EAP）アプリケーション」、RFC 4072、2005年8月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C、ED。、「インターネット鍵交換（IKEV2）プロトコル」、2005年12月、RFC 4306。
[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] Schneier、B.およびMudge、「マイクロソフトのポイントツーポイントトンネリングプロトコルの暗号解読」、第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] Schneier、B.およびMUDGE、「MicrosoftのPPTP認証拡張（MS-CHAPV2）の暗号化（MS-CHAPV2）」、CQRE 99、Springer-Verlag、1999、PP.192-203。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
[SP800-57]国立標準技術研究所、「鍵管理のための勧告」、特別発表800-57、2006年5月。
[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] WU、T.、「Kerberosパスワードセキュリティの実際の分析」、1999年のISOCネットワークおよび分散システムセキュリティシンポジウム、<http://www.isoc.org/isoc/conferences/ndss/99/議事録/論文/ wu.pdf>。
Appendix: AAA Key Management History
付録：AAA鍵管理履歴の履歴
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].
認証、承認、および会計（AAA）のためのプロトコルは、もともとネットワークアクセスサーバーの展開（NAS）の展開をサポートするために開発されました。ARPANETでは、端末アクセスコントローラ（TAC）はネットワークにアクセスするための「ダム端末」の手段を提供し、TACACS [RFC0927] [RFC1492] AAAプロトコルは、防衛データネットワークプログラム管理局に契約後のBBNによって設計されました（この環境のためのDDN PMO）。[RFC1492] ArpAnetとMilnet [DDNN39.2]に広く展開されていたオリジナルバージョンではなく、後のバージョンのTACACを文書化してください。
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.
その後、PPP [RFC1661]を介してインターネットへのアクセスを提供するナースの展開をサポートするために追加のAAAプロトコルが開発されました。適度なユーザー以上のユーザーをサポートする展開では、NASごとに独自のユーザーのリストと関連資格情報を含むように非実用化されました。その結果、RADIUS [RFC2865]と直径[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の両方が、NASへのPPPピアの認証のみをサポートする一方的な認証方式です。PAPはClearText Password Schemeであるため、PPPピアとNASの間の会話にアクセスすることで、攻撃者によるスヌーピングに脆弱です。さらに、PAPの使用は[RFC3579]のセクション4.3で説明されているように半径内の脆弱性を生み出します。その結果、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の定義だけでなく、暗号化制御プロトコル（ECP）を追加した場合、リンク層で使用するためのキーイング材料を提供する必要があります。暗号スイートユーザー認証と同様に、各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].
MS-CHAP [RFC2433]やMS-CHAPV2 [RFC2759]などの追加のベンダー固有のPPP認証プロトコルは、交渉された暗号スイートで使用するための鍵派生[RFC3079]を提供するために開発されました。PPPベースのVPNS [RFC2637]。PAPやCHAPと同様に、これらの新しいメカニズム[SM1] [SM2]には、欠陥が見つかった。
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サーバ上でPPPピアに展開される必要があるため、依然として痛いことが証明されています。新しい認証メカニズムのより迅速な展開を可能にするために、既存のメソッドで見つかった脆弱性の修正を可能にするために、拡張認証プロトコル（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]で定義されている初期認証メカニズム（MD5チャレンジ、ワンタイムパスワード（OTP）、および一般的なトークンカード（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].
集中認証をサポートする環境におけるリンク層暗号スイートのための動的キーイング材料のプロビジョニングをサポートするために、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.
理論的には、EAP-TLSなどの公開鍵認証メカニズムは、AAA鍵配布を必要とせずにEAPピアとNAS間の相互認証と鍵導出をサポートすることができます。ただし、実際には、そのような純粋な2版スキームはめったに展開されません。集中型の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デバイスの製造に加えて、実装者は802.11アクセスポイントなどの低コスト/大量のNASデバイスを生産し、ムーアの法律よりもゆっくりと増加するために平均的なNASで入手可能なリソースを生み出しています。ホストオペレーティングシステム内のIKEV1 [RFC2409]などの証明書処理と洗練された鍵導出メカニズムの広範なサポートにもかかわらず、これらのセキュリティ機能はローエンドのナースとクライアントに展開されていません。
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サーバーなどのより有能なナースでも、集中認証とAAA鍵管理は一般に実証されています。たとえば、IKEV1 [RFC2409]の主な制限の1つは、EAPとAAAとの統合が不足していました。これらの制限はIKEv2 [RFC4306]でアドレス指定されており、VPNクライアントとサーバーの間で鍵導出を処理しながら、ユーザー認証のためのEAPメソッドをサポートしています。EAPユーザー認証の暗号化バインディングをIKEv2 Exchange内で導出されたキーへの暗号化バインドを有効にするには、選択したEAPメソッドがキー導出をサポートする場合には、AAA内のEAP派生キーのトランスポートが必要です。
Acknowledgments
謝辞
Many thanks to James Kempf, Sam Hartman, and Joe Salowey for their quality review and encouragement.
James Kempf、Sam Hartman、およびJoe 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.
Review and Commentの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
Russell Ousley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA Eメール：housley@vigilsec.com電話番号703-435-1775 FAX：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
Bernard Aboba Microsoft Corporation 1つのMicrosoft Way Redmond、WA 98052 USAメール：bernarda@microsoft.com電話番号：1 425-706-6605ファックス：1 425-936-7329
Full Copyright Statement
完全著作権宣言
Copyright (C) The IETF Trust (2007).
著作権（c）IETF Trust（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.
この文書は、BCP 78に含まれている権利、ライセンス、制限の対象となり、その中に述べた場合を除き、著者らはすべての権利を保持しています。
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は、IETFを取りません。利用可能です。そのような権利を特定するためにそれが独立した努力をしたことを表していません。RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
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.
IETF事務局へのIETF事務局と利用可能なライセンスの保証のコピー、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。IETFオンラインIPRリポジトリからhttp://www.ietf.org/ipr。
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エディタ機能のための資金は、現在インターネット社会によって提供されています。