[要約] RFC 2541は、DNSセキュリティの運用上の考慮事項に関するガイドラインです。このRFCの目的は、DNSインフラストラクチャのセキュリティを向上させるための実践的なアドバイスを提供することです。
Network Working Group D. Eastlake
Request for Comments: 2541 IBM
Category: Informational March 1999
DNS Security Operational Considerations
DNSセキュリティ運用上の考慮事項
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
Abstract
概要
Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records.
安全なDNSは、暗号化技術に基づいています。これらの技術の強さに必要な部分は、キーと署名の生成、寿命、サイズ、およびストレージの運用的側面に慎重に注意することです。さらに、高レベルのゾーン、特にルートゾーンのセキュリティに特別な注意を払う必要があります。このドキュメントでは、キーおよびSIG DNSのリソースレコードに関連して使用されるキーと署名のこれらの運用面について説明します。
Acknowledgments
謝辞
The contributions and suggestions of the following persons (in alphabetic order) are gratefully acknowledged:
次の人の貢献と提案（アルファベット順）に感謝されています。
John Gilmore Olafur Gudmundsson Charlie Kaufman
ジョン・ギルモア・オラファー・グドムンドソン・チャーリー・カウフマン
Table of Contents
目次
Abstract...................................................1
Acknowledgments............................................1
1. Introduction............................................2
2. Public/Private Key Generation...........................2
3. Public/Private Key Lifetimes............................2
4. Public/Private Key Size Considerations..................3
4.1 RSA Key Sizes..........................................3
4.2 DSS Key Sizes..........................................4
5. Private Key Storage.....................................4
6. High Level Zones, The Root Zone, and The Meta-Root Key..5
7. Security Considerations.................................5
References.................................................6
Author's Address...........................................6
Full Copyright Statement...................................7
This document describes operational considerations for the generation, lifetime, size, and storage of DNS cryptographic keys and signatures for use in the KEY and SIG resource records [RFC 2535]. Particular attention is paid to high level zones and the root zone.
このドキュメントでは、キーおよびSIGリソースレコードで使用するDNS暗号化キーと署名の生成、寿命、サイズ、および保存に関する運用上の考慮事項について説明します[RFC 2535]。高レベルゾーンとルートゾーンに特に注意が払われています。
Careful generation of all keys is a sometimes overlooked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Technical suggestions for the generation of random keys will be found in [RFC 1750].
すべてのキーを慎重に生成することは、暗号化されたシステムでは見落とされがちですが絶対に不可欠な要素です。最長のキーで使用される最強のアルゴリズムは、敵が可能性のあるキー空間のサイズを縮小して徹底的に検索できるように十分に推測できる場合でも、まだ役に立ちません。ランダムキーの生成に関する技術的な提案は、[RFC 1750]にあります。
Long term keys are particularly sensitive as they will represent a more valuable target and be subject to attack for a longer time than short period keys. It is strongly recommended that long term key generation occur off-line in a manner isolated from the network via an air gap or, at a minimum, high level secure hardware.
長期キーは、より価値のあるターゲットを表し、短期間のキーよりも長い時間攻撃を受ける可能性があるため、特に敏感です。エアギャップを介してネットワークから分離された方法または少なくとも高レベルの安全なハードウェアを介して、長期的なキー生成がオフラインで発生することを強くお勧めします。
No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Furthermore, if
キーを永遠に使用する必要はありません。キーが長く使用されているほど、不注意、事故、スパイ、または暗号化によって侵害される可能性が高くなります。さらに、場合
key rollover is a rare event, there is an increased risk that, when the time does come to change the key, no one at the site will remember how to do it or operational problems will have developed in the key rollover procedures.
キーロールオーバーはまれなイベントであり、キーを変更する時が来たときに、サイトの誰もそれを行う方法を覚えていないか、キーロールオーバー手順で運用上の問題が発生したリスクが高くなります。
While public key lifetime is a matter of local policy, these considerations imply that, unless there are extraordinary circumstances, no long term key should have a lifetime significantly over four years. In fact, a reasonable guideline for long term keys that are kept off-line and carefully guarded is a 13 month lifetime with the intent that they be replaced every year. A reasonable maximum lifetime for keys that are used for transaction security or the like and are kept on line is 36 days with the intent that they be replaced monthly or more often. In many cases, a key lifetime of somewhat over a day may be reasonable.
公開キーの寿命は地域の政策の問題ですが、これらの考慮事項は、並外れた状況がない限り、長期的な鍵は4年間で有意な寿命を持つべきではないことを意味します。実際、オフラインで慎重に保護されている長期キーの合理的なガイドラインは、毎年交換されることを意図した13か月の寿命です。トランザクションセキュリティなどに使用され、オンラインに保たれているキーの合理的な最大寿命は、毎月またはより頻繁に交換することを目的として36日間です。多くの場合、1日をやや過ごす重要な寿命は合理的かもしれません。
On the other hand, public keys with too short a lifetime can lead to excessive resource consumption in re-signing data and retrieving fresh information because cached information becomes stale. In the Internet environment, almost all public keys should have lifetimes no shorter than three minutes, which is a reasonable estimate of maximum packet delay even in unusual circumstances.
一方、一生が短すぎるパブリックキーは、キャッシュされた情報が古くなっているため、データの再署名と新鮮な情報の取得において過度のリソース消費につながる可能性があります。インターネット環境では、ほとんどすべてのパブリックキーが3分以内に寿命をかける必要があります。これは、異常な状況であっても、最大のパケット遅延の合理的な推定です。
There are a number of factors that effect public key size choice for use in the DNS security extension. Unfortunately, these factors usually do not all point in the same direction. Choice of zone key size should generally be made by the zone administrator depending on their local conditions.
DNSセキュリティエクステンションで使用する公開キーサイズの選択に影響を与える多くの要因があります。残念ながら、これらの要因は通常、すべてが同じ方向に向かっているわけではありません。通常、ゾーンキーサイズの選択は、ローカルの条件に応じて、ゾーン管理者が通常行う必要があります。
For most schemes, larger keys are more secure but slower. In addition, larger keys increase the size of the KEY and SIG RRs. This increases the chance of DNS UDP packet overflow and the possible necessity for using higher overhead TCP in responses.
ほとんどのスキームでは、より大きなキーはより安全ですが遅いです。さらに、キーを大きくすると、キーRRとSIG RRのサイズが増加します。これにより、DNS UDPパケットオーバーフローの可能性と、応答でより高いオーバーヘッドTCPを使用するための必要性が高まります。
Given a small public exponent, verification (the most common operation) for the MD5/RSA algorithm will vary roughly with the square of the modulus length, signing will vary with the cube of the modulus length, and key generation (the least common operation) will vary with the fourth power of the modulus length. The current best algorithms for factoring a modulus and breaking RSA security vary roughly with the 1.6 power of the modulus itself. Thus going from a 640 bit modulus to a 1280 bit modulus only increases the verification time by a factor of 4 but may increase the work factor of breaking the key by over 2^900.
わずかな公開指数を考えると、MD5/RSAアルゴリズムの検証（最も一般的な操作）は、弾性率の長さの正方形によって大まかに異なり、署名は弾性率の立方体とキー生成（最も一般的な操作）によって異なります。弾性率の4番目のパワーによって異なります。弾性率を考慮し、RSAセキュリティを破壊するための現在の最良のアルゴリズムは、モジュラス自体の1.6パワーによって大まかに異なります。したがって、640ビット弾性率から1280ビットモジュラスに移動すると、検証時間が4倍になるだけですが、キーを2^900以上に壊す作業係数が増加する可能性があります。
The recommended minimum RSA algorithm modulus size is 704 bits which is believed by the author to be secure at this time. But high level zones in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.)
推奨される最小RSAアルゴリズムモジュラスサイズは704ビットで、著者は現時点で安全であると考えられています。しかし、DNSツリーの高レベルゾーンは、セキュリティ上の理由から、より高い最小、おそらく1000ビットを設定したい場合があります。（米国国家安全保障局は一般に、最大512ビットのRSAモジュラスを使用して暗号化システムの輸出を許可しているため、その小さなモジュラス、つまりNを使用することは弱いと見なされなければなりません。）
For an RSA key used only to secure data and not to secure other keys, 704 bits should be adequate at this time.
データを保護するためにのみ使用され、他のキーを保護しないために使用されるRSAキーの場合、704ビットが適切である必要があります。
DSS keys are probably roughly as strong as an RSA key of the same length but DSS signatures are significantly smaller.
DSSキーは、おそらく同じ長さのRSAキーとほぼ同じくらい強力ですが、DSS署名は大幅に小さくなります。
It is recommended that, where possible, zone private keys and the zone file master copy be kept and used in off-line, non-network connected, physically secure machines only. Periodically an application can be run to add authentication to a zone by adding SIG and NXT RRs and adding no-key type KEY RRs for subzones/algorithms where a real KEY RR for the subzone with that algorithm is not provided. Then the augmented file can be transferred, perhaps by sneaker-net, to the networked zone primary server machine.
可能であれば、ゾーンプライベートキーとゾーンファイルマスターコピーを保持し、オフライン、ネットワーク非接続、物理的に安全なマシンのみで使用することをお勧めします。定期的にアプリケーションを実行して、SIGとNXT RRSを追加し、そのアルゴリズムを備えたサブゾーンの実際のキーRRが提供されていないサブゾーン/アルゴリズムのキータイプのキーRRSを追加することにより、ゾーンに認証を追加できます。その後、拡張ファイルは、おそらくスニーカーネットによって、ネットワークゾーンプライマリサーバーマシンに転送できます。
The idea is to have a one way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off net and should not be updated based on an unsecured network mediated communication.
アイデアは、ネットワークからの改ざんの可能性を回避するために、ネットワークへの一方向の情報フローを持つことです。ゾーンマスターファイルをネットワーク上にオンラインに保ち、オフラインの署名者を介して単純にサイクリングしてもこれは行われません。オンラインバージョンは、ホストが存在する場合でも改ざんされる可能性があります。最大のセキュリティのために、ゾーンファイルのマスターコピーはネットから外れている必要があり、無担保ネットワーク媒介通信に基づいて更新しないでください。
This is not possible if the zone is to be dynamically updated securely [RFC 2137]. At least a private key capable of updating the SOA and NXT chain must be on line in that case.
これは、ゾーンを安全に動的に更新する場合は不可能です[RFC 2137]。少なくともSOAおよびNXTチェーンを更新できる秘密鍵は、その場合はオンラインでなければなりません。
Secure resolvers must be configured with some trusted on-line public key information (or a secure path to such a resolver) or they will be unable to authenticate. Although on line, this public key information must be protected or it could be altered so that spoofed DNS data would appear authentic.
セキュアリゾルバーは、信頼できるオンラインの公開情報（またはそのようなリゾルバーへの安全なパス）で構成する必要があります。そうしないと、認証できません。オンラインでは、この公開キー情報を保護する必要があります。そうしないと、スプーフィングされたDNSデータが本物に見えるように変更する必要があります。
Non-zone private keys, such as host or user keys, generally have to be kept on line to be used for real-time purposes such as DNS transaction security.
ホストやユーザーキーなどのゾーン以外のプライベートキーは、通常、DNSトランザクションセキュリティなどのリアルタイム目的で使用するためにオンラインに保つ必要があります。
Higher level zones are generally more sensitive than lower level zones. Anyone controlling or breaking the security of a zone thereby obtains authority over all of its subdomains (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, extra care should be taken with high level zones and strong keys used.
一般に、より高いレベルゾーンは、低レベルのゾーンよりも感度が高くなります。それにより、ゾーンのセキュリティを制御または破壊する人は、すべてのサブドメインに対する権限を取得します（サブドメインの公開鍵をローカルで構成したリゾルバーの場合を除く）。したがって、高レベルのゾーンと強力なキーを使用して、特別な注意を払う必要があります。
The root zone is the most critical of all zones. Someone controlling or compromising the security of the root zone would control the entire DNS name space of all resolvers using that root zone (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, the utmost care must be taken in the securing of the root zone. The strongest and most carefully handled keys should be used. The root zone private key should always be kept off line.
ルートゾーンは、すべてのゾーンにとって最も重要です。ルートゾーンのセキュリティを制御または侵害する人は、そのルートゾーンを使用してすべてのリゾルバーのDNS名スペース全体を制御します（サブドメインの公開キーをローカルで構成したリゾルバーの場合を除く）。したがって、ルートゾーンの保護に最大限の注意を払う必要があります。最も強力で最も慎重に処理されたキーを使用する必要があります。ルートゾーンの秘密キーは、常に路線から離れておく必要があります。
Many resolvers will start at a root server for their access to and authentication of DNS data. Securely updating an enormous population of resolvers around the world will be extremely difficult. Yet the guidelines in section 3 above would imply that the root zone private key be changed annually or more often and if it were staticly configured at all these resolvers, it would have to be updated when changed.
多くのリゾルバーは、DNSデータへのアクセスと認証のためにルートサーバーで開始されます。世界中の抵抗力の膨大な人口を安全に更新することは非常に困難です。しかし、上記のセクション3のガイドラインは、ルートゾーンの秘密キーを毎年または頻繁に変更することを意味し、これらすべてのリゾルバーで静的に構成されている場合、変更時に更新する必要があります。
To permit relatively frequent change to the root zone key yet minimize exposure of the ultimate key of the DNS tree, there will be a "meta-root" key used very rarely and then only to sign a sequence of regular root key RRsets with overlapping time validity periods that are to be rolled out. The root zone contains the meta-root and current regular root KEY RR(s) signed by SIG RRs under both the meta-root and other root private key(s) themselves.
ルートゾーンキーに比較的頻繁に変更を可能にしながら、DNSツリーの究極のキーの露出を最小限に抑えるために、非常にまれに使用される「メタルート」キーがあり、重複する時間のある通常のルートキーrrsetのシーケンスに署名するだけです。展開される妥当性期間。ルートゾーンには、メタルートと他のルート秘密キーの両方の下でSIG RRSによって署名されたメタルートと現在の通常のルートキーRRが含まれています。
The utmost security in the storage and use of the meta-root key is essential. The exact techniques are precautions to be used are beyond the scope of this document. Because of its special position, it may be best to continue with the same meta-root key for an extended period of time such as ten to fifteen years.
メタルートキーのストレージと使用の最大のセキュリティが不可欠です。正確な手法は使用する予防策です。このドキュメントの範囲を超えています。特別なポジションのため、10年から15年など、同じメタルートキーを長期間続けることが最善かもしれません。
The entirety of this document is concerned with operational considerations of public/private key pair DNS Security.
このドキュメント全体は、パブリック/プライベートキーペアDNSセキュリティの運用上の考慮事項に関係しています。
References
参考文献
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Requirements for Security", RFC 1750, December 1994.
[RFC 1750] Eastlake、D.、Crocker、S。and J. Schiller、「セキュリティのランダム性要件」、RFC 1750、1994年12月。
[RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC 2065] Eastlake、D。およびC. Kaufman、「ドメイン名システムセキュリティ拡張機能」、RFC 2065、1997年1月。
[RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC 2137] Eastlake、D。、「Secure Domain Name System Dynamic Update」、RFC 2137、1997年4月。
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC 2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RSA FAQ] RSADSI Frequently Asked Questions periodic posting.
[RSA FAQ] rsadsiはよく尋ねます。
Author's Address
著者の連絡先
Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road, RR #1 Carmel, NY 10512
ドナルドE.イーストレイク3rd IBM 65 Shindegan Hill Road、RR＃1カーメル、ニューヨーク10512
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明するか、その実装を支援する派生作品は、いかなる種類の制限なしに、準備、コピー、公開、配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。