ネットワークワーキンググループ D. Eastlake Request for Comments: 2541 IBM 分類: 情報提供 1999年3月 DNSセキュリティの運用に関する考察 本文書の位置づけ 本文書はインターネットコミュニティに対して情報を提供するものである。本文 書はいかなる種類のインターネット標準も規定していない。本文書の配布は制限 されない。 著作権表示 Copyright (C) The Internet Society (1999). All Rights Reserved. 要旨 安全なDNSは、暗号技術に基づいている。暗号技術の効果を保つためには、鍵 および署名の生成、存続期間、サイズ、保管等の運用面に対して注意をはらう ことが必要とされる。加えて、高位レベルのゾーンのセキュリティ、特にルート ゾーンのセキュリティには特別な注意が払われなければならない。本文書では、 KEYおよびSIG DNSリソースレコードで使用される鍵および署名について、これら の運用面を論じる。 謝辞 以下の方々(アルファベット順)の貢献と提案に深く感謝する。 John Gilmore Olafur Gudmundsson Charlie Kaufman Eastlake Informational [Page 1] RFC 2541 DNS Security Operational Considerations March 1999 目次 要旨.......................................................1 謝辞.......................................................1 1. はじめに................................................2 2. 公開鍵/秘密鍵の生成.....................................2 3. 公開鍵/秘密鍵の存続期間.................................2 4. 公開/秘密鍵のサイズに関する考察.........................3 4.1 RSA鍵のサイズ..........................................3 4.2 DSS鍵のサイズ..........................................4 5. 秘密鍵の保管............................................4 6. 高レベルゾーン、ルートゾーン、およびメタルート鍵........5 7. セキュリティに関する考察................................5 参考文献...................................................6 著者の連絡先...............................................6 著作権表示の全文...........................................7 1. はじめに 本文書では、KEYおよびSIGリソースレコード[RFC 2535]で使用されるDNS暗号鍵 および署名の生成、存続期間、サイズ、保管について、運用に関する考察を 述べる。高位レベルゾーンとルートゾーンについては特別な注意を払う。 2. 公開鍵/秘密鍵の作成 全ての鍵を慎重に生成することは、見過ごされる場合があるが、暗号で保護 されるシステムにおいて極めて重要な要素である。最長の鍵で使用される最も 強力なアルゴリズムであっても、攻撃者が解読によって鍵空間の網羅的探索を 可能にするのに充分な程度まで鍵空間を縮小可能な場合には役にたたない。 乱数鍵の生成についての技術的な提案は[RFC 1750]で説明される。 存続期間の長い鍵はより価値の高い対象を表すために特にセンシティブなもの であり、存続期間の短い鍵よりも長時間にわたって攻撃にさらされやすいもの である。鍵の生成はネットワークから物理的に隔離されたオフラインで実行 するか、高いレベルの安全性が確保された最小限のハードウェアで実行すること が強く推奨される。 3. 公開鍵/秘密鍵の存続期間 鍵は永続的に使用されるべきではない。鍵が長く使用されるほど、不注意、 事故、スパイ活動、または暗号解読により被害を受ける可能性は大きくなる。 Eastlake Informational [Page 2] RFC 2541 DNS Security Operational Considerations March 1999 更に、鍵のロールオーバーがまれにしか行われない場合、鍵を変更する時期が 来たときに誰もロールオーバーの方法や、ロールオーバー手続き中に発生する 運用上の問題などを覚えていないという危険性が高くなる。 公開鍵の存続時間はローカルなポリシーの問題だが、これらの事柄を考慮する と、特別な事情がない限り存続期間の長い鍵であっても4年を越える存続期間は 持つべきではない。実際、オフラインの状態に保たれ、注意深く保護されている 存続期間の長い鍵に対する適当な指針は、年に1度置き換える意図の下に存続 期間は13ヶ月である。トランザクションセキュリティなどに使用され、 オンラインの状態に置かれている鍵にとって適当な最長存続期間は、月に1度 またはそれ以上の頻度で置き換える意図の下に36日である。多くの場合、1日 程度の鍵存続期間が適当である。 一方で、存続期間が短すぎる公開鍵はキャッシュされた情報が古くなるため、 データの再署名と新しい情報の取り出しの際に過度のリソース消費をもたらす 可能性がある。インターネット環境では、ほとんど全ての公開鍵は3分以下の 存続期間を持つべきではない。これはたとえ正常でない状態であっても、 パケットの最大遅延時間として妥当な推測値である。 4. 公開鍵/秘密鍵のサイズに関する考察 DNSセキュリティ拡張で使用される公開鍵のサイズを選択する際には、多くの 要素が影響する。残念ながら、これらの要素は普通全て同じ方向を示すとは 限らない。ゾーン鍵のサイズの選択は、一般に、ローカルな条件に従って ゾーン管理者によって行われる。 ほとんどの暗号鍵機構では、より長い鍵の方が安全であるが、処理速度は 遅くなる。加えて、長い鍵はKEYおよびSIG RRのサイズを増加させる。 これはDNSのUDPパケットがオーバーフローする機会を増加させ、よりオーバー ヘッドの大きいTCPを応答で使用する必要性が高くなる。 4.1 RSA鍵のサイズ 与えられた公開指数が小さい場合、MD5/RSAアルゴリズムの検証処理(処理の 頻度が最も多い操作)時間は、係数の長さのほぼ2乗の割合で変化し、署名処理 時間は係数の長さの3乗の割合で変化し、鍵生成処理(処理の頻度が最も少ない 操作)時間は係数の長さの4乗の割合で変化する。現在最も優れたアルゴリズム による係数の因数分解とRSAセキュリティを破るための処理時間は、係数の値の ほぼ1.6乗の割合で変化する。したがって、640ビットの係数が1280ビットの 係数になった場合、検証時間は4倍に増えるだけであるが、鍵を破る処理量は 2^900倍以上に増加する。 Eastlake Informational [Page 3] RFC 2541 DNS Security Operational Considerations March 1999 RSAアルゴリズムにおいて、推奨される係数サイズの最小値は704ビットであり、 これが現時点で筆者に安全と思われるサイズである。しかし、DNSツリーの 高位レベルのゾーンでは、セキュリティ上の理由からより大きい最小値、 おそらくは1000ビットの係数を設定することが望まれる場合がある。(アメリカ 国家安全保障局は一般に512ビットまでのRSA係数を使用する暗号システムの 輸出を認めていることから、小さな係数(つまりn)を使用するということは、 暗号強度的に弱くなると考えなければならない)。 データを保護する目的にのみ使用され、他の鍵の保護には使用されない RSA鍵の場合、現時点では704ビットが適当である。 4.2 DSS鍵のサイズ DSS鍵は、おそらく同じ長さのRSA鍵とほぼ同程度に強い暗号強度を持つが、 DSS署名は大幅に小さなサイズになる。 5. 秘密鍵の保管 可能であれば、ゾーン秘密鍵とゾーンファイルのマスタコピーは、オフラインで ネットワークに接続していない、物理的に安全なマシン上にだけ保管し、その マシン上だけで使用することが推奨される。定期的にアプリケーションを実行し、 ゾーンに対してはSIGおよびNXT RRを追加し、KEY RRを持たないサブゾーン/アル ゴリズムに対してはタイプ「no key」のKEY RRを追加することにより、ゾーンに 認証を付加することができる。その後に認証情報が補強されたファイルは、 おそらくはスニーカーネット(訳注: 記録メディアを物理的に持ち運びするネット ワーク)によってネットワークに接続されたプライマリサーバマシンに転送する ことができる。 考え方としては、ネットワークからのデータ改竄の可能性を回避するために、 ネットワークへの一方通行な情報の流れを持つということである。ゾーンの マスタファイルをネットワーク上でオンライン状態で保管し、それを単に オフラインの署名者にまわしてまた元に戻すという循環を行うだけではこれは 実現されない。オンラインバージョンは、データが置かれているホストが 被害を受けた場合、依然として改竄の可能性がある。セキュリティを最大限に 高めるためには、ゾーンファイルのマスタコピーはネットワークから切り離す べきであり、安全に保護されていないネットワークを通した通信によって更新 すべきではない。 この方法は、ゾーンが安全な手法で動的に更新される場合[RFC 2137]には 可能ではない。少なくともSOAおよびNXTチェーンを更新できる秘密鍵は、 この場合オンラインでなければならない。 安全なリゾルバは、信頼されたオンライン公開鍵情報(またはそのような リゾルバへの安全なパス)を使用して設定される必要がある。そうでなければ リゾルバは認証を行うことができない。たとえオンラインの状態であっても、 この公開鍵情報は保護されなければならない。そうでなければ偽造された DNSデータが認証を得たものに見えるように公開鍵情報が変更される可能性がある。 Eastlake Informational [Page 4] RFC 2541 DNS Security Operational Considerations March 1999 ホスト鍵またはユーザー鍵等のゾーン秘密鍵以外のものは、DNSトラン ザクションセキュリティ等のリアルタイムな用途に使用するため、一般に オンラインの状態に置くことが必要である。 6. 高位レベルゾーン、ルートゾーンおよびメタルート鍵 一般に高位レベルのゾーンは低位レベルのゾーンよりもよりもセンシティブ である。ゾーンのセキュリティを制御する者あるいはセキュリティを破った 者は誰であれ、そのサブドメイン全てに対する権威を得る(リゾルバが ローカルにサブドメインの公開鍵を設定している場合を除く)からである。 したがって、高位レベルのゾーンとそこで使用される強い鍵に対しては特別な 注意を払うべきである。 ルートゾーンは全ゾーンの中で最も重要なものである。ルートゾーンの セキュリティを制御する者あるいはセキュリティを破った者は、そのルート ゾーンを使用する全てのリゾルバのDNS名前空間全体を制御できる(リゾルバが ローカルにサブドメインの公開鍵を設定している場合を除く)。したがって、 ルートゾーンの安全確保には最大限の注意を払われなければならない。最も 暗号強度が強く、最も慎重に扱われる鍵が使用されるべきである。ルート ゾーンの秘密鍵は常にオフラインで保管されるべきである。 多くのリゾルバは、DNSデータに対するアクセスと認証をルートサーバから 開始する。世界中にある膨大な数のリゾルバを安全に更新することは極めて 困難である。更に、先のセクション3の指針では、ルートゾーンの秘密鍵は 年に1度またはそれ以上の頻度で更新されることが暗に示唆されているが、 もし秘密鍵がリゾルバで静的に設定されている場合、秘密鍵変更時には 設定情報の更新をしなければならなくなる。 ルートゾーン鍵の比較的頻繁な変更を可能にし、更にDNSツリーの根本部分の 鍵の露出を最小限にするために、「メタルート」鍵の適用が考えられる。 この鍵はまれにしか使用されず、正規のルート鍵のRRsetシーケンスに ロールアウトされようとしている重複状態の有効期間を署名するだけのもの である。ルートゾーンは、メタルート鍵と正規に使用するルートの秘密鍵両方の SIG RRによって署名された、メタルート鍵と正規に使用するルート鍵のKEY RR を持つ。 メタルート鍵の保管と使用に際して、最上級のセキュリティは必須である。 使用される予防措置の厳密な方法は、本文書の範囲を超えるものである。 特別な位置付けにあることから、10年から15年といった時間に延長された周期で 同じメタルート鍵を存続させることが最善である可能性もある。 7. セキュリティに関する考察 本文書は、全て公開鍵/秘密鍵のペアによるDNSセキュリティの運用に関する 考察について扱ったものである。 Eastlake Informational [Page 5] RFC 2541 DNS Security Operational Considerations March 1999 参考文献 [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. 著者の連絡先 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 Eastlake Informational [Page 6] RFC 2541 DNS Security Operational Considerations March 1999 著作権表示の全文 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. Eastlake Informational [Page 7] RFC2541-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/