Network Working Group D. Eastlake
Request for Comments: 2541 IBM
Category: Informational March 1999
DNS Security Operational Considerations
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.
著作権（C）インターネット協会（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は、暗号技術に基づいています。これらの技術の強度の必要な部分は、鍵と署名生成、寿命、サイズ、およびストレージの運用面に細心の注意です。また、特別な注意がハイレベルのゾーンのセキュリティ、特にルートゾーンに支払わなければなりません。この文書では、KEYと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.
この文書では、[RFC 2535] KEYとSIGリソースレコードで生成、寿命、サイズ、および使用のためのDNSの暗号鍵と署名のストレージの運用考慮事項について説明します。特に注意がハイレベルゾーンとルートゾーンに支払われます。
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日です。多くの場合、多少日以上のキーの有効期間は、合理的であるかもしれません。
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.
ほとんどのスキームでは、より大きな鍵はより安全ですが遅いです。加えて、より大きなキーは、キーと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パワーと概ね変わります。したがって1280ビットモジュラスに640ビットモジュラスからつもりはわずか4倍検証時間を増加させるが、900 ^ 2上により鍵を壊すの仕事率を増加させることができます。
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ビット、その小さなモジュラスの使用、すなわち、n個のRSAモジュラスを使用して暗号化システムの輸出を許可しているので、弱い考慮しなければなりません。）
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 RRを追加し、そのアルゴリズムとサブゾーンのための実際のKEYのRRが設けられていないサブゾーン/アルゴリズムの非キータイプKEY RRを追加することによって、ゾーンに認証を追加するために実行することができます。その後、拡張ファイルは、ネットワークゾーンのプライマリサーバマシンに、おそらくスニーカーネットによって、転送することができます。
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のシーケンスに署名しますロールアウトされる有効期間。ルートゾーンは、メタルートや他のルート秘密鍵（s）は自分自身の両方の下にSIGのRRによって署名されたメタルートと現在の正規ルートキー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.
メタルート鍵の保管や使用中の最大限のセキュリティが不可欠です。正確な技術は、このドキュメントの範囲を超えて使用する注意事項です。理由は、その特別な位置に、それは時間のような1015年に年の長期間同じメタルート鍵を続行するのが最善かもしれません。
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]イーストレイク、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性の要件"、RFC 1750、1994年12月。
[RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC 2065]イーストレイク、D.およびC.カウフマン、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2065、1997年1月。
[RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC 2137]イーストレイク、D.は、RFC 2137、1997年4月、 "ドメインネームシステム動的な更新を固定します"。
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC 2535]イーストレイク、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.イーストレイク3位IBM 65 Shindeganヒルロード、RR＃1カーメル、NY 10512
Phone: +1-914-276-2668(h) +1-914-784-7913(w) Fax: +1-914-784-3833(w) EMail: dee3@us.ibm.com
電話番号：+ 1-914-276-2668（H）+ 1-914-784-7913（W）ファックス：+ 1-914-784-3833（W）メール：dee3@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。