この文書はRFC2541の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
安全なＤＮＳは暗号技術に基づいています。これらの技術の力の必要な部分
が鍵と署名生成と寿命と大きさと貯蔵の運用面の注意深い扱いです。加えて、
特別な注意が上位ゾーン、特にルートゾーンの安全に払われなくてはなりま
せん。この文書は鍵と署名ＤＮＳ資源レコードに関連した鍵と署名の運用面
を論じます。
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
概要
Acknowledgments
謝辞
1. Introduction
1. はじめに
2. Public/Private Key Generation
2. 公開／秘密鍵生成
3. Public/Private Key Lifetimes
3. 公開／秘密鍵寿命
4. Public/Private Key Size Considerations
4. 公開／秘密鍵の大きさの考察
4.1 RSA Key Sizes
4.1 ＲＳＡ鍵サイズ
4.2 DSS Key Sizes
4.2 ＤＳＳ鍵サイズ
5. Private Key Storage
5. 秘密鍵貯蔵場所
6. High Level Zones, The Root Zone, and The Meta-Root Key
6. 上位ゾーンと、ルートゾーンと、メタルート鍵
7. Security Considerations
7. セキュリティの考察
References
参考文献
Author's Address
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
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]使用するＤＮＳ暗号鍵と署名
のための、生成と寿命と大きさと貯蔵に対する運用上の考慮を記述します。
特定の注意が上位レベルゾーンとルートゾーンに払われます。
2. Public/Private Key Generation
2. 公開／秘密鍵生成
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.
長期の鍵がより価値がある標的を表し、そして短期鍵より長時間の攻撃の
適用を受けるであろうから、特に敏感です。長期鍵生成が空間によってあ
るいは、最小限、レベルが高い安全なハードウェアによって、ネットワー
クから隔離された方法でオフラインで起こることは強く推薦されています。
3. Public/Private Key Lifetimes
3. 公開／秘密鍵寿命
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.
公開鍵寿命がローカルなポリシーの問題であるが、これらの考慮は異常な状
況がないなら、長期鍵が４年以上の寿命を持つべきではないことを意味しま
す。実際、オフラインで慎重に保持される長期鍵の合理的なガイドラインは、
鍵を毎年変える意図で１３カ月の寿命です。処理セキュリティや同種のもの
で使われ、オンラインで保持される鍵の合理的な最大寿命は、それらが毎月
変更されるという意図で、３６日です。多くの場合、鍵寿命で１日以上は合
理的かもしれません。
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.
他方、公開鍵の寿命をあまりにも短くすると、再署名と、キャッシュ情報が
古くなるのに伴う新しい情報を検索により、極端な資源消費に導くことがあ
ります。インターネット環境で、ほとんどすべての公開鍵は３分以上の寿命
を持つべきで、これは異常状況での最大パケット遅延の妥当な見積もりです。
4. Public/Private Key Size Considerations
4. 公開／秘密鍵の大きさの考察
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.
ＤＮＳセキュリティ拡張で使用するための公開鍵サイズ選択には多くの要因
があります。不幸にも、これらの要因は通常すべて同じ方向を指すわけでは
ありません。ゾーン鍵の大きさの選択が一般にローカルな状態に依存してゾー
ン管理者によってされるべきです。
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.
たいていの計画で、より大きい鍵はより安全ですが、より遅いです。加えて、
より大きい鍵が鍵と署名資源レコードの大きさを増やします。これはＤＮＳ
のＵＤＰパケットの溢れの可能性を増やし、回答でより高いオーバーヘッド
のＴＣＰを使う確率を増やします。
4.1 RSA Key Sizes
4.1 ＲＳＡ鍵サイズ
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.
小さい公開指数の条件下で、ＭＤ５／ＲＡＳアルゴリズムの検証（最も一般
的演算）がおおよそモジュラス長の平方で変化するでしょう、署名がおおよ
そモジュラス長の立方で変化するでしょう、そして鍵生成（最も一般的でな
い演算）がモジュラス長の４乗で変化するでしょう。モジュラスを因数分解
して、そしてＲＡＳセキュリティを破るための現在の最も良いアルゴリズム
はモジュラス自身の１およそ.６乗で変化します。それで６４０ビットモジュ
ラスから１２８０ビットモジュラスにすると証明時間が４倍に増えるだけで
すが、鍵を壊すには２^９００倍以上の仕事を増やします。
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.)
推薦された最小ＲＳＡアルゴリズムモジュロサイズは著者が、今、安全であ
ると信る７０４ビットです。けれどもＤＮＳ木の上位ゾーンがセキュリティ
理由のためにより高い最小値、多分１０００ビット、を設定することを望む
かもしれません。（合衆国国家安全保障局が一般に最高５１２ビットのＲＳ
Ａモジュロを使う暗号の輸出を認めるので、これより小さいモジュロ、すな
わちｎを使う場合、弱いと思われなくてはなりません。）
For an RSA key used only to secure data and not to secure other keys,
704 bits should be adequate at this time.
他の鍵の安全性にではなく、安全なデータにだけ使うＲＡＳ鍵で、今、
７０４ビットが適切です。
4.2 DSS Key Sizes
4.2 ＤＳＳ鍵サイズ
DSS keys are probably roughly as strong as an RSA key of the same
length but DSS signatures are significantly smaller.
ＤＳＳ鍵は恐らくおよそ同じ長さのＲＳＡ鍵と比べて同じぐらい強いですが、
ＤＳＳ署名はかなり小さいです。
5. Private Key Storage
5. 秘密鍵貯蔵場所
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.
可能である場合は、ゾーン秘密鍵とゾーンファイル原本がオフラインでネッ
トワーク接続なしで物理的に安全なマシンに置かれて使われることが勧めら
れます。周期的に、アプリケーションが、署名とＮＸＴ資源レコードを加え
て、サブゾーンのそのアルゴリズムの真の鍵資源レコードが供給されないサ
ブゾーン／アルゴリズムの非鍵資源レコードを加えることで、ゾーン認証を
加えるために、走らせらることができます。それで拡張されたファイルは、
多分スニーカーネットで、ネットワークゾーンの主サーバマシンに、転送で
きます。
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]。少なくともＳＯＡとＮＸＴ鎖を更新することができる秘密鍵が
このような場合オンラインであるに違いありません。
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.
安全なリゾルバがある信頼されたオンライン公開鍵情報（あるいはこのよう
なリゾルバへの安全なパス）で構成を設定されなくてはなりません、でなけ
れば彼らは認証が不可能であるでしょう。オンラインであるが、この公開鍵
情報は守られなくてはなりません、そうでなければ、送られた偽ＤＮＳデー
タが正しいように見えるように改変できます。
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.
ホストあるいはユーザー鍵のような、非ゾーン秘密鍵が一般にＤＮＳ処理セ
キュリティのようなリアルタイム目的で使われるためオンラインにしておか
れなければなりません。
6. High Level Zones, The Root Zone, and The Meta-Root Key
6. 上位ゾーンと、ルートゾーンと、メタルート鍵
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.
ルートゾーンはすべてのゾーンの中で最も重大です。ルートゾーンのセキュ
リティを制御するか、あるいは危うくする誰かがすべてのそのルートゾーン
を使っているリゾルバの全部のＤＮＳ名前空間を制御します（ローカルに設
定されたリゾルバの場合でサブドメインの公開鍵を除外します）。それ故に、
最大の注意はルートゾーンを安全に保つ際にとられなくてはなりません。最
も強く、そして最も慎重に扱う鍵が使われるべきです。ルートゾーン秘密鍵
は常にオフラインにされるべきです。
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.
多くのリゾルバがＤＮＳデータへのアクセスとその認証をルートサーバから
開始するでしょう。世界中リゾルバの巨大な数を安全に更新することは非常
に難しいでしょう。それでもなお上記の３章のガイドラインはルートゾーン
秘密鍵が毎年、あるいはより頻繁に変えられて、そしてもしそれが静的に全
てのリゾルバに設定されるなら、変更時にすべてのリゾルバの更新が必要な
ことを示すでしょう。
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.
ＤＮＳ木の最高鍵の危険性を最小にするため、比較的頻繁なルートゾーンの
鍵の変更を許すために、めったに使われない「メタルート」の鍵があり、こ
れは鍵の正当な期間が重なる状況で、通常のルート鍵資源レコード集合の列
に署名します。ルートゾーンはメタルートを含み、そして署名レコードで署
名される現在の通常のルート鍵資源レコードが、メタルートと他のルート秘
密鍵それ自身で署名されます。
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.
メタルートの鍵の貯蔵と使用での最大のセキュリティは不可欠です。使用す
る厳密な用心テクニックはこの文書の範囲外です。その特別な立場のために、
１０から１５年のような長い一定期間の間の同じメタルート鍵の使用は最も
良いかもしれません。
7. Security Considerations
7. セキュリティの考察
The entirety of this document is concerned with operational
considerations of public/private key pair DNS Security.
この文書の全部はＤＮＳセキュリティの公開／秘密鍵対の運用上の考慮に関
係しています。
References
参考文献
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Requirements for Security", RFC 1750, December 1994.
[RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic
Update", RFC 2137, April 1997.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RSA FAQ] RSADSI Frequently Asked Questions periodic posting.
Author's Address
著者のアドレス
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 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.
著作権（Ｃ）インターネット学会（１９９９）。すべての権利は保留される。
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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。