[要約] RFC 6421は、Remote Authentication Dial-In User Service (RADIUS) プロトコルの暗号化アジリティ要件に関する文書です。このRFCの目的は、RADIUSプロトコルが将来の暗号技術の変化に柔軟に対応できるようにするための要件を定義することです。これは、新しい暗号化アルゴリズムへの移行を容易にし、古いもしくは脆弱な暗号化手法に依存することのリスクを減らすことを目指しています。利用場面としては、RADIUSを使用する認証、認可、およびアカウンティング(AAA)サービスのセキュリティを強化する際に参照されます。関連するRFCには、RADIUSプロトコルを定義するRFC 2865や、RADIUSの拡張を定義するRFC 2869などがあります。
Internet Engineering Task Force (IETF) D. Nelson, Ed.
Request for Comments: 6421 Elbrys Networks, Inc.
Category: Informational November 2011
ISSN: 2070-1721
Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)
リモート認証のための暗号能力要件ダイヤルインユーザーサービス（RADIUS）
Abstract
概要
This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS).
このメモでは、リモート認証ダイヤルインユーザーサービス（RADIUS）のための暗号能力ソリューションの要件について説明しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6421.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6421で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................2
1.1. General ....................................................2
1.2. Requirements Language ......................................3
1.3. Publication Process ........................................3
2. A Working Definition of Crypto-Agility ..........................4
3. The Current State of RADIUS Security ............................5
4. The Requirements ................................................5
4.1. Overall Solution Approach ..................................5
4.2. Security Services ..........................................6
4.3. Backwards Compatibility ....................................7
4.4. Interoperability and Change Control ........................9
4.5. Scope of Work ..............................................9
4.6. Applicability of Automated Key Management Requirements .....9
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
At the IETF 66 meeting, the RADIUS Extensions (RADEXT) Working Group (WG) was asked by members of the Security Area Directorate to prepare a formal description of a crypto-agility work item and corresponding charter milestones. After consultation with one of the Security Area Directors (Russ Housley), text was initially proposed on the RADEXT WG mailing list on October 26, 2006. The following summarizes that proposal:
IETF 66会議では、RADIUS拡張機能（Radext）ワーキンググループ（WG）は、セキュリティエリア局のメンバーから、暗号性能力のワークアイテムと対応するチャーターマイルストーンの正式な説明を準備するよう求められました。セキュリティエリアディレクター（Russ Housley）の1人と協議した後、2006年10月26日のRadext WGメーリングリストで最初にテキストが提案されました。以下は、その提案をまとめたものです。
The RADEXT WG will review the security requirements for crypto-agility in IETF protocols, and identify the deficiencies of the existing RADIUS protocol specifications against these requirements. Specific attention will be paid to RFC 4962 [RFC4962].
Radext WGは、IETFプロトコルにおける暗号性のセキュリティ要件を確認し、これらの要件に対して既存のRADIUSプロトコル仕様の欠陥を特定します。RFC 4962 [RFC4962]に特に注意が払われます。
The RADEXT WG will propose one or more specifications to remediate any identified deficiencies in the crypto-agility properties of the RADIUS protocol. The known deficiencies include the issue of negotiation of substitute algorithms for the message digest functions, the key-wrap functions, and the password-hiding function. Additionally, at least one mandatory to implement cryptographic algorithm will be defined in each of these areas, as required.
Radext WGは、RADIUSプロトコルの暗号性特性の特定された欠陥を修復するための1つ以上の仕様を提案します。既知の欠陥には、メッセージダイジェスト関数の代替アルゴリズムの交渉の問題、キーWRAP関数、およびパスワードハイディング関数が含まれます。さらに、必要に応じて、これらの各領域で暗号化アルゴリズムを実装するために少なくとも1つの必須の必須です。
This document describes the features, properties, and limitations of RADIUS crypto-agility solutions; defines the term "crypto-agility" as used in this context; and provides the motivations for this work.
このドキュメントでは、半径の暗号能力ソリューションの機能、特性、および制限について説明します。このコンテキストで使用されている「暗号性」という用語を定義します。この作業の動機を提供します。
The requirements defined in this memo have been developed based on email messages posted to the RADEXT WG mailing list, which may be found in the archives of that list. The purpose of framing the requirements in this memo is to formalize and archive them for future reference and to bring them explicitly to the attention of the IESG and the IETF community as we proceed with this work.
このメモで定義されている要件は、Radext WGメーリングリストに投稿された電子メールメッセージに基づいて開発されています。これは、そのリストのアーカイブにあります。このメモの要件をフレーミングする目的は、将来の参照のためにそれらを正式化およびアーカイブし、この作業を進める際にIESGとIETFコミュニティの注意に明示的に導くことです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
A RADIUS crypto-agility solution is not compliant with this specification if it fails to satisfy one or more of the MUST or MUST NOT statements. A solution 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つ以上の必須声明を満たすことができない場合、または声明を満たしていない場合、この仕様に準拠していません。すべてのマストを満たす、声明を満たす、必須、すべきではない、そしてすべきではないソリューションは、「無条件に準拠している」と言われています。すべての必要性を満たす必要があり、声明を満たしていないものは、すべての要件を必要とするかどうかではなく、「条件付きで準拠」であると言われているものではありません。
RADIUS [RFC2865] is a widely deployed protocol that has attained Draft Standard status based on multiple independent interoperable implementations. Therefore, it is desirable that a high level of interoperability be maintained for crypto-agility solutions.
RADIUS [RFC2865]は、複数の独立した相互運用可能な実装に基づいてドラフト標準ステータスを達成した広く展開されたプロトコルです。したがって、暗号能力ソリューションでは、高いレベルの相互運用性を維持することが望ましいです。
To ensure that crypto-agility solutions published on the standards track are well specified and interoperable, the RADEXT WG has adopted a two phase process for standards-track publication of crypto-agility solutions.
Radext WGは、標準トラックで公開されている暗号能力ソリューションがよく指定され、相互運用可能であることを確認するために、Crypto-Agility Solutionsの標準トラック公開の2つのフェーズプロセスを採用しています。
In the initial phase, crypto-agility solutions adopted by the working group will be published as Experimental. These documents should contain a description of the implementations and experimental deployments in progress as well as an evaluation of the proposal against the requirements described in this document.
初期段階では、ワーキンググループが採用した暗号能力ソリューションが実験として公開されます。これらのドキュメントには、このドキュメントに記載されている要件に対する提案の評価と同様に、実装と実験的展開の説明と実験的展開の説明が含まれている必要があります。
The working group will then select proposals to advance on the standards track. Criteria to be used include evaluation of the proposal against the requirements, summary of the experimental deployment experience, and evidence of multiple interoperable implementations.
ワーキンググループは、標準トラックで前進する提案を選択します。使用する基準には、要件に対する提案の評価、実験的展開の経験の概要、および複数の相互運用可能な実装の証拠が含まれます。
Crypto-agility is the ability of a protocol to adapt to evolving cryptography and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to fielded implementations. It may provide for the dynamic negotiation and installation of cryptographic algorithms within protocol implementations (think of Dynamic-Link Libraries (DLL)).
暗号性は、進化する暗号化およびセキュリティ要件に適応するプロトコルの能力です。これには、フィールド化された実装を大幅に中断することなく、暗号化アルゴリズムを更新できるようにするモジュラーメカニズムの提供が含まれる場合があります。プロトコル実装内の暗号化アルゴリズムの動的な交渉とインストールを提供する場合があります（動的リンクライブラリ（DLL）を考えてください）。
In the specific context of the RADIUS protocol and RADIUS implementations, crypto-agility may be better defined as the ability of RADIUS implementations to automatically negotiate cryptographic algorithms for use in RADIUS exchanges, including the algorithms used to integrity protect and authenticate RADIUS packets and to hide RADIUS attributes. This capability covers all RADIUS message types: Access-Request/Response, Accounting-Request/Response, CoA/Disconnect-Request/Response, and Status-Server. Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer.
RADIUSプロトコルとRADIUS実装の特定のコンテキストでは、Crypto-agility性は、RADIUS交換で使用されるラジアス交換で使用するための暗号化アルゴリズムを自動的に交渉する能力として、RADIUSパケットを保護および認証するために使用されるアルゴリズムを含む、隠して隠すためのRADIUS実装の能力としてよりよく定義される場合があります。RADIUS属性。この機能は、すべてのRADIUSメッセージタイプをカバーします：アクセスリクエスト/応答、アカウンティングレクエスト/応答、COA/切断 - レクエスト/応答、およびステータスサーバー。暗号化アルゴリズムの交渉は、RADIUSプロトコル内、または輸送層などの下層層内で発生する場合があります。
Proposals MUST NOT introduce generic new capability negotiation features into the RADIUS protocol or require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC6158], Section 3.1 and Appendix A.4. A proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC6158], Section 2.3. Issues of backward compatibility are described in more detail in Section 4.3.
提案は、一般的な新しい機能交渉機能をRADIUSプロトコルに導入したり、「RADIUS設計ガイドライン」[RFC6158]、セクション3.1、および付録A. 4で定義されているように、RADIUS動作モデルの変更を必要としないでください。提案は、暗号性の問題に焦点を当てる必要があります。たとえば、提案は新しい属性形式を必要としないでください。[RFC6158]、セクション2.3で提供されるガイダンスと互換性があるはずです。後方互換性の問題については、セクション4.3で詳しく説明します。
RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC) within the Authenticator field of RADIUS packets other than Access-Request [RFC2865] and Status-Server [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets.
[RFC2865]で定義されているRADIUSパケットは、Access-Request [RFC2865]およびStatus-Server [RFC5997]以外のRADIUSパケットの認証フィールド内のMD5メッセージ整合性チェック（MIC）によって保護されています。Message-Authenticator属性は、HMAC-MD5を利用して、RADIUSパケットを認証および整合性保護します。
While RADIUS does not support confidentiality of entire packets, various RADIUS attributes support encrypted (also known as "hidden") values, including User-Password (defined in [RFC2865], Section 5.2), Tunnel-Password (defined in [RFC2868], Section 3.5), and various Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes (defined in [RFC2548], Section 2.4). Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Attacks against this mechanism are described in "RADIUS Support for EAP" [RFC3579], Section 4.3.4.
RADIUSはパケット全体の機密性をサポートしていませんが、さまざまなRADIUS属性は、ユーザーパスワード（[RFC2865]で定義されている」、セクション5.2で定義）、トンネルパスワード（[RFC2868]で定義されています。セクション3.5）、およびMS-MPPEセンドキーやMS-MPPE-RECV-KEY属性（[RFC2548]、セクション2.4で定義）などのさまざまなベンダー固有の属性。一般的に言えば、隠れメカニズムは、MD5ダイジェストのキーストリームに基づいてストリーム暗号を使用します。このメカニズムに対する攻撃は、「EAPの半径サポート」[RFC3579]、セクション4.3.4で説明されています。
"Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5 collisions do not immediately compromise the use of MD5 or HMAC-MD5 for the purposes used within RADIUS absent knowledge of the RADIUS shared secret, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. As noted in [RFC6151], Section 2:
「MD5 Message-DigestおよびHMAC-MD5アルゴリズムの更新されたセキュリティ上の考慮事項」[RFC6151]は、MD5およびHMAC-MD5アルゴリズムの使用に関するセキュリティ上の考慮事項について説明しています。MD5衝突の進歩は、半径の共有秘密の知識がないために半径内で使用される目的のためにMD5またはHMAC-MD5の使用をすぐに妥協するものではありませんが、MD5の基本的な暗号化の仮定の妥協に向けた進歩は、MD5の使用量が非難されました。さまざまなアプリケーション。[RFC6151]に記載されているように、セクション2：
MD5 is no longer acceptable where collision resistance is required such as digital signatures. It is not urgent to stop using MD5 in other ways, such as HMAC-MD5; however, since MD5 must not be used for digital signatures, new protocol designs should not employ HMAC-MD5.
MD5は、デジタル署名などの衝突抵抗が必要な場合、もはや受け入れられません。HMAC-MD5など、MD5の使用を他の方法で停止することは緊急ではありません。ただし、MD5はデジタル署名に使用してはならないため、新しいプロトコル設計ではHMAC-MD5を使用してはなりません。
RADIUS crypto-agility solutions are not restricted to utilizing technology described in existing RFCs. Since RADIUS over IPsec is already described in Section 5 of "RADIUS and IPv6" [RFC3162] and Section 4.2 of [RFC3579], this technique is already available to those who wish to use it. Therefore, it is expected that proposals will utilize other techniques.
半径の暗号能力ソリューションは、既存のRFCに記載されている技術を利用することに限定されていません。IPSEC上の半径は「RADIUSおよびIPV6」[RFC3162]および[RFC3579]のセクション4.2のセクション5ですでに説明されているため、この手法はそれを使用したい人がすでに利用できます。したがって、提案は他の手法を利用することが期待されています。
Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. Proposals also MUST support per-packet replay protection for all RADIUS message types. Crypto-agility solutions MUST specify mandatory-to-implement cryptographic algorithms for each defined mechanism.
提案は、パケットごとの整合性/認証保護のための暗号化アルゴリズムの交渉をサポートする必要があります。また、提案は、すべての半径メッセージタイプのパケットごとのリプレイ保護をサポートする必要があります。暗号能力ソリューションは、定義された各メカニズムの必須の暗号化アルゴリズムを指定する必要があります。
Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g., in the event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding-down attacks. In analyzing the resilience of a crypto-agility solution, it can be assumed that RADIUS requesters and responders can be configured to require the use of new secure algorithms in the event of a compromise of existing cryptographic algorithms or the legacy RADIUS shared secret.
暗号能力ソリューションは、RADIUS実装で利用されている既存の暗号化アルゴリズムがセキュリティをほとんどまたはまったく提供するのに十分な弱いことが示されている場合でも、セキュリティの妥協を避ける必要があります（例えば、レガシーRADIUS共有秘密の妥協の場合）。これには、入札ダウン攻撃に対する保護が含まれます。暗号能力ソリューションの回復力を分析する際に、既存の暗号アルゴリズムまたはレガシーRADIUS共有秘密の妥協がある場合に、新しい安全なアルゴリズムの使用を要求するようにRADIUSリクエスト担当者とレスポンダーを設定できると想定できます。
Guidance on acceptable algorithms can be found in [NIST-SP800-131A]. It is RECOMMENDED that mandatory-to-implement cryptographic algorithms be chosen from among those classified as "Acceptable" with no known deprecation date from within this or successor documents.
許容可能なアルゴリズムに関するガイダンスは、[nist-sp800-131a]に記載されています。このまたは後継者文書内から既知の非推奨日がない場合、「許容可能」として分類されたものの中から、義務的な暗号化された暗号化アルゴリズムを選択することをお勧めします。
It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption.
ソリューションは、半径パケット全体の暗号化をサポートするか、個々の半径属性を暗号化することにより、機密性をサポートすることをお勧めします。機密性をサポートする提案は、暗号化のための暗号化アルゴリズムの交渉をサポートする必要があります。
Support for encryption of individual RADIUS attributes is OPTIONAL for solutions that provide encryption of entire RADIUS packets. Solutions providing for encryption of individual RADIUS attributes are REQUIRED to provide support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext.
個々の半径属性の暗号化のサポートは、半径パケット全体の暗号化を提供するソリューションでオプションです。個々の半径属性の暗号化を提供するソリューションは、現在クリアテキストで送信されている既存の暗号化（「隠された」と呼ばれる）属性（「隠された」と呼ばれる）属性（「隠された」と呼ばれる）属性の機密性を改善するためのサポートを提供するために必要です。
In addition to the goals referred to above, [RFC4962] Section 3 describes additional security requirements, which translate into the following requirements for RADIUS crypto-agility solutions:
上記の目標に加えて、[RFC4962]セクション3では、半径の暗号能力ソリューションの次の要件につながる追加のセキュリティ要件について説明します。
Strong, fresh session keys:
強力で新鮮なセッションキー：
RADIUS crypto-agility solutions are REQUIRED to generate fresh session keys for use between the RADIUS client and server. In order to prevent the disclosure of one session key from aiding an attacker in discovering other session keys, RADIUS crypto-agility
RADIUSクライアントとサーバー間で使用するための新しいセッションキーを生成するには、RADIUS Crypto-Agilityソリューションが必要です。あるセッションキーの開示を防ぐために、攻撃者が他のセッションキーを発見するのを支援することを防ぐために、Radius Crypto-Agility
solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) with respect to session keys negotiated between the RADIUS client and server.
RADIUSクライアントとサーバーの間で交渉されたセッションキーに関して、Perfect Forward Secrecy（PFS）をサポートするためのソリューションが推奨されます。
Limit key scope:
キースコープを制限します：
In order to enable a Network Access Server (NAS) and RADIUS server to exchange confidential information such as keying material without disclosure to third parties, it is RECOMMENDED that a RADIUS crypto-agility solution support X.509 certificates for authentication between the NAS and RADIUS server. Manual configuration or automated discovery mechanisms such as NAI-based Dynamic Peer Discovery [RADYN] can be used to enable direct NAS-RADIUS server communications. Support for end-to-end confidentiality of RADIUS attributes is OPTIONAL.
ネットワークアクセスサーバー（NAS）とRADIUSサーバーが第三者に開示せずにキーイング素材などの機密情報を交換できるようにするために、RADIUS Crypto-Agilityソリューションは、NASとRADIUS間の認証のためのX.509証明書をサポートすることをお勧めしますサーバ。NAIベースのダイナミックピアディスカバリー[RADYN]などの手動構成または自動発見メカニズムを使用して、直接的なNAS-Radiusサーバー通信を可能にすることができます。RADIUS属性のエンドツーエンドの機密性のサポートはオプションです。
For compatibility with existing operations, RADIUS crypto-agility solutions SHOULD also support pre-shared key credentials. However, support for direct communications between the NAS and RADIUS server is OPTIONAL when pre-shared key credentials are used.
既存の操作との互換性のために、RADIUS Crypto-Agility Solutionsは、事前に共有される主要な資格情報もサポートする必要があります。ただし、NASとRADIUSサーバー間の直接通信のサポートは、事前に共有される主要な資格情報を使用する場合にオプションです。
Solutions MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both crypto-agility and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms).
ソリューションは、既存のRADIUS実装との後方互換性を実証する必要があります。つまり、暗号性とレガシーメカニズムの両方をサポートする実装は、レガシーRADIUSクライアントとサーバー（レガシーメカニズムを使用）と話すことができなければなりません。
While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy mechanisms have been compromised, secure algorithms MUST be used so that backward compatibility is no longer possible.
レガシー半径と暗号アジャイル半径の間の遷移を容易にするには、後方互換性が必要ですが、レガシーメカニズムの使用は、それらのメカニズムの妥協の前にのみ適切です。レガシーメカニズムが損なわれた後、後方互換性が不可能になるように、安全なアルゴリズムを使用する必要があります。
Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. Prior to receipt of a response, a requester will not know what algorithms are supported by the responder. Therefore, while a RADIUS request can provide a list of supported cryptographic algorithms that can be selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within an initial request will need to be predetermined.
RADIUSは要求/応答プロトコルであるため、単一のRADIUS交換内で暗号化アルゴリズムを交渉する機能は本質的に制限されています。応答を受信する前に、要求者は、レスポンダーによってどのアルゴリズムがサポートされているかを知りません。したがって、RADIUS要求は、応答内で使用するために選択できるサポートされている暗号化アルゴリズムのリストを提供できますが、応答を受信する前に、初期リクエスト内でセキュリティサービスを提供するために使用される暗号化アルゴリズムは事前に決定する必要があります。
In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms was well as with attributes providing security services
リクエストをレガシーと暗号アジャイルの実装の両方によって処理できるようにするために、セキュリティサービスを提供する属性と同様に、レガシーアルゴリズムでリクエストを保護できます。
using more secure algorithms. This approach allows a RADIUS packet to be processed by legacy implementations as well as by crypto-agile implementations, and it does not result in additional response delays. If this technique is used, credentials used with legacy algorithms MUST be cryptographically independent of the credentials used with the more secure algorithms, so that compromise of the legacy credentials does not result in compromise of the credentials used with more secure algorithms.
より安全なアルゴリズムを使用します。このアプローチにより、RADIUSパケットをレガシーの実装と暗号アジャイルの実装によって処理することができ、追加の応答遅延は発生しません。この手法を使用する場合、レガシーアルゴリズムで使用される資格情報は、より安全なアルゴリズムで使用される資格情報とは独立している必要があります。そのため、レガシー資格情報の妥協は、より安全なアルゴリズムで使用される資格情報の妥協をもたらさないようにします。
In this approach to backward compatibility, legacy mechanisms are initially used in requests sent between crypto-agile implementations. However, if the responder indicates support for crypto-agility, future requests can use more secure mechanisms. Note that if a responder is upgraded and then subsequently needs to be downgraded (e.g., due to bugs), this could result in requesters being unable to communicate with the downgraded responder unless a mechanism is provided to configure the requester to re-enable use of legacy algorithms.
後方互換性へのこのアプローチでは、暗号化アジャイルの実装間で送信された要求で最初にレガシーメカニズムが使用されます。ただし、応答者が暗号性のサポートを示している場合、将来のリクエストはより安全なメカニズムを使用できます。レスポンダーがアップグレードされ、その後ダウングレードする必要がある場合（例えば、バグのため）、リクエスターが格下げされたレスポンダーと通信できない可能性があることに注意してください。レガシーアルゴリズム。
Probing techniques can be used to avoid the use of legacy algorithms in requests sent between crypto-agile implementations. For example, an initial request can omit use of legacy mechanisms. If a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure mechanisms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy mechanisms in future requests. Note that if a requester is upgraded and then subsequently needs to be downgraded (e.g., due to bugs), this could result in the requester being unable to interpret responses, unless a mechanism is provided to configure the responder to re-enable use of legacy algorithms.
プロービング手法は、暗号アジャイルの実装間で送信されるリクエストでレガシーアルゴリズムの使用を回避するために使用できます。たとえば、最初のリクエストでは、レガシーメカニズムの使用を省略できます。応答が受信された場合、受信者は暗号アジャイルであると想定でき、その受信者への将来のリクエストは安全なメカニズムを利用できます。同様に、レスポンダーは、要求者が暗号能力をサポートし、将来の要求でレガシーメカニズムの使用を禁止できると想定できます。リクエスターがアップグレードされ、その後ダウングレードする必要がある場合（例えば、バグのため）、レガシーの再度電位使用に応答者を構成するメカニズムが提供されない限り、リクエスタが応答を解釈できない可能性があることに注意してください。アルゴリズム。
If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre-configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy mechanisms.
応答が受信されていない場合、暗号性（事前構成や暗号アジャイル応答の以前の受信など）に対する応答者のサポートを示す情報がない場合、レガシーメカニズムを利用して新しい要求を作成できます。
Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests can be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. Therefore, probing techniques can delay initial communication between crypto-agile requesters and legacy responders. This can be addressed by upgrading the responders (e.g., RADIUS servers) first.
クリプトアピリティをサポートしていないレガシーの実装は、エラーを返すのではなく、レガシーアルゴリズムによって保護されていない要求を静かに破棄するため、パケット能力のサポートの欠如やその他の障害条件を区別するために、繰り返し要求が必要になる場合があります。したがって、調査手法は、暗号アジャイルリクエスターとレガシーレスポンダーの間の初期通信を遅らせる可能性があります。これは、最初にレスポンダー（RADIUSサーバーなど）をアップグレードすることで対処できます。
Proposals MUST indicate a willingness to cede change control to the IETF.
提案は、変更制御をIETFに譲渡する意欲を示す必要があります。
Crypto-agility solutions MUST be interoperable between independent implementations based purely on the information provided in the specification.
暗号能力ソリューションは、仕様で提供される情報に純粋に基づいて、独立した実装間で相互運用可能でなければなりません。
Crypto-agility solutions MUST apply to all RADIUS packet types, including Access-Request, Access-Challenge, Access-Reject, Access-Accept, Accounting-Request, Accounting-Response, Status-Server and CoA/Disconnect messages.
Crypto-agilityソリューションは、アクセスリケスト、アクセスチャレンジ、アクセス - リジェクト、アクセスアセプト、アカウンティングリケスト、会計応答、ステータスサーバー、COA/切断メッセージなど、すべての半径パケットタイプに適用する必要があります。
Since it is expected that the work will occur purely within RADIUS or in the transport, message data exchanged with Diameter SHOULD NOT be affected.
作業は純粋に半径内または輸送内で発生すると予想されるため、直径と交換されるメッセージデータに影響を受けるべきではありません。
Proposals MUST discuss any inherent assumptions about, or limitations on, client/server operations or deployment and SHOULD provide recommendations for transition of deployments from legacy RADIUS to crypto-agile RADIUS. Issues regarding cipher-suite negotiation, legacy interoperability, and the potential for bidding-down attacks SHOULD be among these discussions.
提案は、クライアント/サーバーの操作または展開に関する固有の仮定または制限を議論する必要があり、レガシー半径から暗号アジャイル半径への展開の移行に関する推奨事項を提供する必要があります。Cipher-Suiteの交渉、レガシーの相互運用性、および入札ダウン攻撃の可能性に関する問題は、これらの議論の中にあるべきです。
"Guidelines for Cryptographic Key Management" [RFC4107] provides guidelines for when automated key management is necessary. Consideration was given as to whether or not RFC 4107 would require a RADIUS crypto-agility solution to feature Automated Key Management (AKM). It was determined that AKM was not inherently required for RADIUS based on the following points:
「暗号化キー管理のガイドライン」[RFC4107]は、自動化されたキー管理が必要なときのガイドラインを提供します。RFC 4107に自動化されたキー管理（AKM）を特徴とするために、RFC 4107が半径暗号能力ソリューションを必要とするかどうかについて考慮されました。AKMは、次のポイントに基づいて半径に本質的に必要ではないと判断されました。
o RFC 4107 requires AKM for protocols that involve O(n^2) keys. This does not apply to RADIUS deployments, which require O(n) keys.
o RFC 4107には、O（n^2）キーを含むプロトコルにAKMが必要です。これは、O（n）キーが必要なRADIUS展開には適用されません。
o Requirements for session key freshness can be met without AKM, for example, by utilizing a pre-shared key along with an exchange of nonces.
o セッションキーの要件は、たとえば、非首位のキーを使用してNoncesの交換を使用することにより、AKMなしでは満たすことができます。
o RADIUS does not require the encryption of large amounts of data in a short time.
o RADIUSは、短時間で大量のデータの暗号化を必要としません。
o Organizations already have operational practices to manage existing RADIUS shared secrets to address key changes required as a result of personnel changes.
o 組織はすでに、人事の変更の結果として必要な重要な変更に対処するために、既存のRADIUS共有秘密を管理するための運用慣行を既に持っています。
o The crypto-agility solution can avoid the use of cryptographic modes of operation, such as a counter mode cipher, that require frequent key changes.
o 暗号能力ソリューションは、頻繁に重要な変更を必要とするカウンターモード暗号などの暗号化モードの動作モードの使用を回避できます。
However, at the same time, it is recognized that features recommended in Section 4.2 such as support for perfect forward secrecy and direct transport of keys between a NAS and RADIUS server can only be provided by a solution supporting AKM. As a result, support for Automated Key Management is RECOMMENDED within a RADIUS crypto-agility solution.
ただし、同時に、AKMをサポートするソリューションによってのみ提供されると、NASとRADIUSサーバー間のキーの直接輸送など、セクション4.2で推奨される機能がAKMをサポートするソリューションによってのみ提供できることが認識されています。その結果、自動化されたキー管理のサポートが、半径の暗号性能力ソリューション内で推奨されます。
Also, automated key management is REQUIRED for RADIUS crypto-agility solutions that use cryptographic modes of operation that require frequent key changes.
また、頻繁な主要な変更を必要とする暗号化モードの操作モードを使用する半径の暗号性能力ソリューションには、自動化された主要管理が必要です。
Potential attacks against the RADIUS protocol are described in [RFC3579], Section 4.1, and details of known exploits as well as potential mitigations are discussed in [RFC3579], Section 4.3.
半径プロトコルに対する潜在的な攻撃は、[RFC3579]、セクション4.1、および既知のエクスプロイトの詳細と潜在的な緩和の詳細について、[RFC3579]、セクション4.3で説明されています。
This specification describes the requirements for new cryptographic protection mechanisms, including the modular selection of algorithms and modes. Therefore, all the subject matter of this memo is related to security.
この仕様では、アルゴリズムとモードのモジュラー選択を含む、新しい暗号保護メカニズムの要件について説明します。したがって、このメモのすべての主題はセキュリティに関連しています。
Thanks to all the reviewers and contributors, including Bernard Aboba, Mary Barnes, Pasi Eronen, Dan Romascanu, Joe Salowey, and Glen Zorn.
バーナード・アボバ、メアリー・バーンズ、パシ・エロネン、ダン・ロマスカヌ、ジョー・サロウィー、グレン・ゾーンなど、すべてのレビュアーと貢献者に感謝します。
[NIST-SP800-131A] Barker, E. and A. Roginsky, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", NIST SP-800-131A, January 2011.
[NIST-SP800-131A] Barker、E。およびA. Roginsky、「遷移：暗号化アルゴリズムとキー長の使用の遷移に関する推奨」、NIST SP-800-131A、2011年1月。
[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月。
[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月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号化キー管理のためのガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley、R。and B. Aboba、「認証、認可、会計（AAA）主要管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151] Turner、S。およびL. Chen、「MD5 Message-DigestおよびHMAC-MD5アルゴリズムのセキュリティ上の考慮事項を更新しました」、RFC 6151、2011年3月。
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[RFC6158] Dekok、A.、ed。、およびG. Weber、「Radius Design Guidelines」、BCP 158、RFC 6158、2011年3月。
[RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", Work in Progress, July 2011.
[Radyn] Winter、S。and M. McCauley、「NAIベースのDynamic Peer Discovery for Radius/TLSおよびRADIUS/DTLS」、2011年7月の作業。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G。、「Microsoft Vendor固有のRADIUS属性」、RFC 2548、1999年3月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートのRadius属性」、RFC 2868、2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and IPv6」、RFC 3162、2001年8月。
[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）のサポート」、RFC 3579、2003年9月。
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, August 2010.
[RFC5997] Dekok、A。、「リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルでのステータスサーバーパケットの使用」、RFC 5997、2010年8月。
Author's Address
著者の連絡先
David B. Nelson (editor) Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 USA
David B. Nelson（編集者）Elbrys Networks、Inc。282 Corporate Drive、Unit 1 Portsmouth、NH 03801 USA
EMail: d.b.nelson@comcast.net