ネットワークワーキンググループ D. EastLake Request for Comments: 2536 IBM 分類: 標準化過程(Standards Track) 1999年3月 DNSのKEY、SIGレコードへのDSAアルゴリズムの導入 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、改善に向けた議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 要旨 DNSに米政府標準のDSA(Digital Signature Algorithm)の鍵と署名を保存する 標準的な方式を記述する。本方式ではDNSのKEY、SIGリソースレコードを 使用する。 目次 要旨 ......................................................1 1. はじめに ...............................................1 2. KEYリソースレコードのDSA対応 ...........................2 3. SIGリソースレコードのDSA対応 ...........................3 4. パフォーマンスに関する考慮点 ...........................3 5. セキュリティに関する考慮点 .............................4 6. IANAに関する考慮点 .....................................4 References.................................................5 Author's Address...........................................5 Full Copyright Statement...................................6 1. はじめに DNS(Domain Name System)はグローバルで階層的に分散した、IPアドレスや メールサーバ、他の情報を管理するデータベースである。DNSは拡張され、 暗号鍵とデジタル署名が使用できるようになった[RFC 2535]。その結果、 DNSを安全に維持したり、安全な鍵配布手段として使用できるようになった。 Eastlake Standards Track [Page 1] RFC 2536 DSA in the DNS March 1999 本文書は、DNSに米政府標準のDSAの鍵と署名を保存する方法を記述する。 読者はDSAに精通していることを前提とする[Schneier]。DSAの実装はDNSSECに 必須である。 2. KEYリソースレコードのDSA対応 DSAの公開鍵をDNSに保存する場合、KEY RRにアルゴリズム番号 3[RFC 2535]を 指定して格納する。後に示すとおり、KEY RRのRDATA部はDSAアルゴリズム固有の 構造となる。これらのフィールドのQからYがDSAのKEY RRの"公開鍵"部分である。 鍵の有効期間に関する情報をKEY RRは保持しない。しかし、KEY RRを含む ドメイン名(ゾーン)において、(1つ以上の)KEY RRに署名し認証する(1つ以上の) SIG RRが鍵の有効期間を明示する。 フィールド サイズ --------- ------- T 1 オクテット Q 20 オクテット P 64 + T*8 オクテット G 64 + T*8 オクテット Y 64 + T*8 オクテット [FIPS 186]および[Schneier]に記述されるように、Tは鍵長に関するパラメータで、 0 <= T <= 8 となるように選択される。(アルゴリズム番号3でTのオクテット長が 8より大きいものは将来のために予約されており、RDATA部の残りは異なる フォーマットになる可能性がある)。Qは鍵生成時に選択される素数で、 2**159 < Q < 2**160 の範囲にある。したがってQは常に20オクテットであり、 他の全フィールドと同様に"ビッグエンディアン"ネットワークオーダで格納 される。P、G、YはFIPS 186鍵生成アルゴリズム[Schneier]により直接計算される。 Pは 2**(511+64T) < P < 2**(512+64T) の範囲内になるので、オクテット長は 64 + 8*T となる。GとYはそれぞれPの剰余値だからPと同じオクテット長以下に なるので、Pと同じオクテット長が確保される。 鍵生成処理中に、1 <= X <= Q-1 となる乱数 X を生成しなければならない。 Xは秘密鍵で、公開鍵生成の最終段階で Y を以下のように計算する際に使用 される。 Y = G**X mod P Eastlake Standards Track [Page 2] RFC 2536 DSA in the DNS March 1999 3. SIGリソースレコードのDSA対応 SIG RRでDSAを使用する場合に署名部分が格納されるRDATA部を出現順に以下に 示す。署名部分よりも前に格納されるSIG RR RDATAの各フィールドについては [RFC 2535]を参照のこと。 フィールド サイズ --------- ------- T 1 オクテット R 20 オクテット S 20 オクテット 署名対象データは[RFC 2535]の規定に従って決定される。その後、[FIPS 186]の 規定に従い、以下の処理が行われる。ここでQ、P、G、Yは公開鍵生成時に使用 したものと同じである [Schneier]。 (1)ハッシュ = SHA-1(署名対象データ) (2)0 < K < Q となるような乱数Kを生成する。 (3)R = ( G**K mod P ) mod Q (4)S = ( K**(-1) * (ハッシュ + X*R) ) mod Q Qが160ビットなので、RおよびSが20オクテットを越えることはない。 したがって、RおよびSにこの大きさの領域を割り当てる。 Tは公開鍵からコピーされる。Tは理論上SIGレコードでは必要ないのだが、後に 記述するように、 T > 8 なるTをDSAの拡張バージョンまたは別のアルゴリズムに 対応するための逃げ道として使用できるようにTを残している。 4. パフォーマンスに関する考慮点 一般的な署名生成速度は、RSA[RFC 2537]とDSAでほぼ同じである。充分な前処理を 事前にしておけば、DSAはRSAよりも高速に署名を生成する。また、鍵の生成は DSAの方が高速である。しかし、DNSのデータ認証で使用するKEY RRでは、RSAの 公開鍵の指数(public exponent)に小さい値を選択するよう推奨されているので、 DSAを使用する場合の署名検証速度はRSAよりも1桁遅くなる。 現在のDNS実装は、主としてオーバヘッドを含めて512バイト未満となる小さな データの転送に最適化されている。大きいデータであっても正しく転送される だろうし、大きいデータを効率的に転送する取り組みも行われている。しかし、 少なくとも現時点においては、適切なセキュリティを保てる範囲内で DNSKEY RRsetを最小化するために、相応の努力をすることが推奨される。 署名ゾーンでは、データを認証するSIG RRが最低1つは返されることに留意 してもらいたい。 Eastlake Standards Track [Page 3] RFC 2536 DSA in the DNS March 1999 5. セキュリティに関する考慮点 [RFC 2535]記載の一般的なセキュリティに関する考慮点の多くが当てはまる。 DNSから取得した鍵は、以下の条件が全て満たされなければ信用すべきではない。 (1)DNSSEC対応リゾルバから安全な手段で取得したか、ユーザが独自に検証を 行った。(2)DNSSEC対応リゾルバと、リゾルバから鍵を取得した手段または 独立して行った検証がユーザに許容可能なセキュリティポリシーに準拠している。 他の暗号アルゴリズムでも同様だが、鍵に必要とされる強度の評価は不可欠な もので、ローカルポリシーに依存する。 現在のDSA標準では、鍵長の上限値は1024ビット(T = 8)になっているが、 これはDSAの安全性を限定することになるかもしれない。特に重要な アプリケーションの実装者は、使用アルゴリズムおよび鍵長の範囲について 検討することを推奨する。 DSAは高品質な乱数を頻繁に生成できることを前提としている。ガイドラインに ついては[RFC 1750]を参照のこと。DSAは、乱数を使用せず操作された数を使用 すると、非常に広帯域の秘密通信が可能になるように設計されている。 最近の研究成果については[Schneier]を参照のこと。わずか2つのDSA署名から DSA秘密鍵が漏洩することが例証されている。DSAは高品質な乱数の生成も含めた 信頼性の高い実装が使用されている場合に限り安全を提供する。 6. IANAに関する考慮点 本文書で未定義のパラメータTの値とその意味を割り当てるには、IETF標準化活動が 必要である。現在未割り当ての値は、将来拡張されたDSS標準に対応するために 使用することを意図している。 Eastlake Standards Track [Page 4] RFC 2536 DSA in the DNS March 1999 References [FIPS 186] U.S. Federal Information Processing Standard: Digital Signature Standard. [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999. [Schneier] Schneier, B., "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996. 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 Eastlake Standards Track [Page 5] RFC 2536 DSA in the DNS March 1999 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. Eastlake Standards Track [Page 6]