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)
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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）は、暗号アジリティの作業項目の正式な説明と対応するチャーターマイルストーンを準備するために、セキュリティエリア理事のメンバーによって頼まれました。セキュリティエリアディレクター（ラスHousley）の一つと協議した後、テキストは当初10月26日にRADEXT WGメーリングリストで提案された、2006以下がその提案をまとめたものです。
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つ以上の仕様を提案します。知られている欠陥は、メッセージダイジェスト機能のための代替アルゴリズムのネゴシエーションの問題、キーラップ機能、およびパスワード隠蔽機能が含まれます。また、暗号アルゴリズムを実装するために必須の少なくとも一つは、必要に応じて、これらの領域の各々に定義されます。
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.
この文書では、機能、性質、およびRADIUS暗号アジリティソリューションの制限について説明します。この文脈で使用される用語「暗号の敏捷性」を定義します。そして、この作品のための動機を提供します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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つまたは複数のMUSTのか、文はありませんMUSTを満たすために失敗した場合、RADIUS暗号アジリティソリューションは、この仕様に準拠していません。すべてのMUSTを満たす解は、SHOULD NOT、および文は「無条件に準拠した」と言われてはならないしなければなりません。すべてのMUSTを満たし、文はならず全てではないSHOULDまたはべきではありません要件は、「条件付き準拠した」と言われている。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は暗号アジリティソリューションの標準トラック出版のための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実装の特定の文脈において、暗号敏捷性は良好完全性に使用されるアルゴリズム保護し、RADIUSパケットを認証し、非表示にするなど、自動的にRADIUS交換に使用する暗号アルゴリズムを交渉するためにRADIUS実装の能力として定義することができますRADIUS属性。アクセス要求/応答、アカウンティング要求/応答、アシルCoA /切断 - 要求/応答、およびステータス・サーバー：この機能は、すべてのRADIUSメッセージの種類をカバーしています。暗号アルゴリズムのネゴシエーションは、トランスポート層として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.
RADIUSパケットは、[RFC2865]で定義されるように、アクセス要求[RFC2865]およびステータス・サーバ[RFC5997]以外のRADIUSパケットの認証フィールド内のMD5メッセージ完全性チェック（MIC）によって保護されています。 Message-Authenticatorアトリビュートは、認証と完全性RADIUSパケットを保護するために、HMAC-MD5を利用しています。
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のサポートは暗号化された属性をユーザーパスワードなどの値が、（また、「隠された」として知られている）[RFC2868]で定義され、トンネル・パスワード（（セクション5.2、[RFC2865]で定義されています）、セクション3.5）、およびそのようなMS-MPPE-SENDキー及び[RFC2548]で定義されたMS-MPPE-Recv関数キー属性（セクション2.4）のような様々なベンダー固有の属性、。一般的に言って、隠ぺいメカニズムは、MD5ダイジェストからキーストリームに基づいて、ストリーム暗号を使用しています。このメカニズムに対する攻撃は、「EAPのためのRADIUSサポート」[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:
[RFC6151]「MD5メッセージダイジェストとHMAC-MD5アルゴリズムのための更新されたセキュリティ上の考慮事項は、」MD5とHMAC-MD5アルゴリズムの使用のためのセキュリティの考慮事項について説明します。 MD5衝突における進歩はすぐにRADIUS共有シークレットのRADIUS不在の知識の範囲内で使用目的のために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.
RADIUS暗号アジリティ・ソリューションは、既存のRFCに記載の技術を利用することに限定されません。 IPsecの上RADIUSが既に「RADIUSとIPv6」のセクション5 [RFC3162]及び[RFC3579]のセクション4.2に記載されているので、この技術は、すでにそれを使用したい人に利用可能です。したがって、提案は、他の技術を利用することが期待されます。
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.
提案は、パケットごとの整合性/認証保護のための暗号アルゴリズムのネゴシエーションをサポートしなければなりません。提案はまた、すべてのRADIUSメッセージタイプのパケットごとのリプレイ保護をサポートしなければなりません。暗号アジリティソリューションは、強制的に実装定義された各機構のための暗号化アルゴリズムを指定しなければなりません。
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.
ソリューションは、機密性のために、いずれかの全体のRADIUSパケットの暗号化をサポートすることにより、または個々のRADIUS属性を暗号化することで、サポートを提供することを推奨しています。機密性をサポートする提案は、暗号化のための暗号アルゴリズムのネゴシエーションをサポートしなければなりません。
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.
個々のRADIUS属性の暗号化のサポートは、全体のRADIUSパケットの暗号化を提供するソリューションのためのオプションです。個々のRADIUS属性の暗号化を提供するソリューションは、既存の暗号化の機密性を向上させるためのサポートを提供するために必要とされる（時々、「隠された」という。）の属性だけでなく、現在は平文で送信されている（例えば、位置、属性など）の属性を暗号化します。
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は、RADIUS暗号アジリティ・ソリューションのための次の要件に翻訳追加のセキュリティ要件を、説明します。
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 solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) with respect to session keys negotiated between the RADIUS client and server.
RADIUS暗号アジリティソリューションは、RADIUSクライアントとサーバ間の使用のために新鮮なセッション鍵を生成する必要があります。他のセッションキーを発見する攻撃者を助けるから1つのセッションキーの開示を防ぐために、RADIUS暗号アジリティソリューションは、RADIUSクライアントとサーバとの間で交渉セッションキーに関して完全転送秘密（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サーバを有効にするためには、NASとRADIUS間の認証のための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暗号アジリティソリューションはまた、事前共有キーの資格情報をサポートする必要があります。事前共有キーの資格情報を使用している場合しかし、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.
後方互換性は、従来のRADIUSと暗号アジャイルRADIUS間の移行を容易にするために必要とされているが、従来の機構の使用は、従来、これらのメカニズムの妥協にのみ適切です。従来の機構が損なわれた後に下位互換性がもはや可能でないように、安全なアルゴリズムが使用されなければなりません。
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.
暗号敏捷性ソリューションは、アクセス要求、アクセスチャレンジ、アクセス拒否、アクセス-受け入れ、アカウンティング要求、会計・レスポンス、ステータス・サーバーとCoA /切断メッセージを含む、すべてのRADIUSパケットタイプに適用する必要があります。
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.
提案は、クライアント/サーバー操作や展開上の任意の固有に関する仮定、または制限を議論しなければならなくて、暗号アジャイルRADIUSにレガシーRADIUSからの展開の移行のための勧告を提供する必要があります。暗号スイートのネゴシエーション、レガシー相互運用性、および入札ダウン攻撃の可能性に関する問題は、これらの議論の中であるべきです。
"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）もありますし、RADIUS暗号アジリティソリューションを必要とするか否かを与えました。これは、AKMは、本質的に以下の点に基づいて、RADIUSのために必要ではなかったことが判明しました。
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.
入出力RFC 4107は、（N ^ 2）キーOを含むプロトコル用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セッション鍵鮮度の要件は、一回だけの交換に伴って事前共有キーを使用することによって、例えば、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.
しかし、同時に、このような完全転送秘密とNASとRADIUSサーバ間のキーの直接の輸送のためのサポートとして、4.2節で推奨機能はのみAKMを支援するソリューションによって提供されていることが認識されます。その結果、自動キー管理のためのサポートは、RADIUS暗号アジリティソリューションの中に推奨されます。
Also, automated key management is REQUIRED for RADIUS crypto-agility solutions that use cryptographic modes of operation that require frequent key changes.
また、自動化された鍵管理は頻繁にキーの変更を必要とする操作の暗号化モードを使用するRADIUS暗号アジリティ・ソリューションのために必要です。
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.
RADIUSプロトコルに対する攻撃の可能性は、[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.
バーナードAboba、メアリー・バーンズ、パシEronen、ダンRomascanu、ジョーSalowey、およびグレンツォルンを含むすべてのレビューと貢献のおかげで、。
[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]バーカー、E.およびA. Roginsky、 "トランジション：暗号アルゴリズムや鍵長の使用移行のための勧告"、NIST SP800-131A、2011年1月を。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[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。および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]ターナー、S.とL.チェン、 "MD5メッセージダイジェストと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.編、およびG.ウェーバー、 "RADIUS設計ガイドライン"、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]冬、S.及びM.マッコーリー、 "RADIUS / TLSとRADIUS / DTLSためNAIベースの動的ピア発見"、進歩、2011年7月に働いています。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]ソーン、G.、 "マイクロソフトのベンダー固有の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]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.、およびI. Goyret、RFC 2868、2000年6月 "RADIUSトンネルプロトコルサポートのための属性"。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、ゾルン、G.、およびD.ミットン、 "RADIUSと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.カルフーン、 "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）でリモート認証ダイヤルのStatus-Serverのパケットのプロトコル"、RFC 5997、2010年8月。
Author's Address
著者のアドレス
David B. Nelson (editor) Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 USA
デビッド・B・ネルソン（エディタ）Elbrysネットワークス株式会社282コーポレート・ドライブ、1号機ポーツマス、ニューハンプシャー03801 USA
EMail: d.b.nelson@comcast.net
メールアドレス：d.b.nelson@comcast.net