ネットワークワーキンググループ D. Eastlake 3rd Request for Comments: 3110 Motorola 廃止(Obsolete): 2537 2001年5月 分類: 標準化過程(Standards Track) DNSへのRSA/SHA-1 SIGおよびRSA KEYの導入 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、改善に向けた議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 要旨 本文書は、セクション3でRSA/SHA-1に対応したSIGリソースレコードの生成法を 記述する。またRFC 2537を完全に置き換えるために、セクション2で当該SIG RRに 対応するRSA KEY RRを生成する方法を記述する。 DNS (Domain Name Space)におけるRSA署名が "標準化への提唱" (Proposed Standard)に採用されてから、ハッシュ技術は進歩している。これらの進歩を SIG RRで利用できるようにするため、新しいDNS署名アルゴリズムを定義する。 過去に規定されたセキュリティ強度が弱い方式は廃止見込みとなる。 RSA KEY RRのアルゴリズム番号を新しいSIGアルゴリズムに対応するように 変更する。それ以外の変更をDNSSECに加えることはない。 Acknowledgements Material and comments from the following have been incorporated and are gratefully acknowledged: Olafur Gudmundsson The IESG Charlie Kaufman Steve Wang D. Eastlake 3rd Standards Track [Page 1] RFC 3110 RSA SIGs and KEYs in the DNS May 2001 目次 1. はじめに ...................................................... 2 2. KEYリソースレコードへのRSA公開鍵格納 .......................... 3 3. RSA/SHA-1によるSIGリソースレコード ............................ 3 4. パフォーマンスに関する考慮点 .................................. 4 5. IANAに関する考慮点 ............................................ 5 6. セキュリティに関する考慮点 .................................... 5 References........................................................ 5 Author's Address.................................................. 6 Full Copyright Statement.......................................... 7 1. はじめに DNS(Domain Name System)はグローバルで階層的に分散した、IPアドレスや メールサーバ、他の情報を管理するデータベースである[RFC 1034、1035等]。 DNSは拡張され、暗号鍵とデジタル署名が使用できるようになった[RFC 2535]。 その結果、DNSを安全に維持したり、安全な鍵配布手段として使用できるように なった。 本文書は、読者がRSAおよびSHA-1アルゴリズム[Schneier、FIP180]に精通 していることを前提とする。 RFC 2537は、RSA鍵とRSA/MD5による署名をDNSに保存する方法を記述している。 しかし、RFC 2537採択後、継続的な暗号研究により、RFC 2537で使用される MD5アルゴリズム[RFC1321]の脆弱性が明らかにされている。一方で、より大きな ハッシュを生成するSHA-1(Secure Hash Algorithm)[FIP180]が開発されている。 現在までに、SHA-1に関して充分な経験が蓄積されており、一般にMD5よりも 強力であると認識されている。現在、ほとんどの署名ゾーンは、このより強力な ハッシュをおそらく必要としない。しかし、ルート、多くのトップレベル ドメインと幾つかの第2レベルドメイン、第3レベルドメイン等の重要な ドメインは価値の高い攻撃対象であるから、より強力な方式と一般が認めるものを 提供しないことは怠慢だろう。更に、将来における暗号解読または コンピュータの処理速度の進歩のため、あらゆる場所でより強力なハッシュを 要求される可能性がある。加えて、SHA-1で要求される計算量はMD5よりも多いが、 RSAの係数を累乗する計算処理と比較すれば取るに足らないものである。 本文書は、セクション3でRSA/SHA-1によるSIG RRを生成する方法を記述し、 RFC 2537を完全に置き換えるため、セクション2 でRSA KEY RRを生成する 方法を記述する。 RSA/SHA-1の実装はDNSSECに必須(MANDATORY)である。RFC 2537記載の RSA/MD5によるSIG RRの生成は推奨されない(NOT RECOMMENDED)。 D. Eastlake 3rd Standards Track [Page 2] RFC 3110 RSA SIGs and KEYs in the DNS May 2001 本文書におけるキーワード"しなければならない(MUST)"、"要求される (REQUIRED)"、"すべきである(SHOULD)"、"推奨される(RECOMMENDED)"、 "推奨されない(NOT RECOMMENDED"、してもよい/することができる(MAY)" は、RFC 2119に記述されているとおりに解釈するものとする。 2. KEYリソースレコードへのRSA公開鍵格納 RSAの公開鍵をDNSに保存する場合、KEY RRにアルゴリズム番号 5[RFC2535]を 指定して格納する。以下に示すとおり、KEY RRのRDATA部はRSAアルゴリズム固有の 構造となる。 フィールド サイズ ---------- ------ 指数長(exponent length) 1または3オクテット(本文参照) 指数(exponent) "指数長"フィールドで指定された長さ モジュラス(modulus) 残りの領域 相互運用性を維持するため、指数フィールドとモジュラスフィールドは、 それぞれ4096ビット長に制限される。公開鍵の指数は可変長の符号なし (unsigned)整数である。公開鍵の指数のオクテット長は、1から255バイトの範囲に ある場合は1オクテットで表現され、255バイトより長い場合には、0で埋められた オクテットに、符号なしで長さを示す2オクテットが続く形によって表現される (訳注: したがって3オクテットになる)。公開鍵のモジュラスフィールドは 多倍精度の符号なし整数である。モジュラス長は、RDLENGTHと指数までの RDATAフィールドの長さから決定可能である。指数フィールドおよび モジュラスフィールドを値0のオクテットで開始することは禁止される。 注: RSA/SHA-1による署名を行うRSA KEY RRを使用する場合、(廃止された RFC 2537で規定したアルゴリズム番号ではなく)アルゴリズム番号 5を 使用しなければならない(MUST)。 注: この変更により、RSA KEY RRのアルゴリズム番号がRSA/SHA-1 SIGに 割り当てられた新しいアルゴリズム番号と同じになる。 3. RSA/SHA-1によるSIGリソースレコード RSA/SHA-1による署名をDNSに保存する場合、SIG RRにアルゴリズム番号 5を 指定して格納する。 RSA/SHA-1アルゴリズムを使用する場合、SIG RRのRDATAの署名部分は以下の ように計算される。署名対象データは[RFC 2535]の規定に従って決定される。 署名部分よりも前に格納されるSIG RR RDATAの各フィールドについては RFC 2535を参照のこと。 ハッシュ = SHA-1(署名対象データ) 署名 = ( 01 | FF* | 00 | プレフィックス | ハッシュ ) ** e (mod n) D. Eastlake 3rd Standards Track [Page 3] RFC 3110 RSA SIGs and KEYs in the DNS May 2001 ここで、SHA-1は[FIP180]で文書化されたメッセージダイジェストアルゴリズム であり、"|"は連結を表す。"e"は署名者(署名ツール)が使用する秘密鍵の指数で、 "n"は公開鍵のモジュラスである。01、FF、00は16進数で表記された固定値を持つ オクテットである。"プレフィックス"はPKCS1[RFC2437]で要求される ASN.1 BER SHA1アルゴリズム指定プレフィックスであり、以下のような ものである。 hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 このプレフィックスは、標準暗号ライブラリの使用を容易にするために 加えられる。FFオクテットは、累乗されている値がnの値よりも1オクテット 短くなる範囲で最大の回数を繰り返さなければならない(MUST)。 (上記の規定はPublic Key Cryptographic Standard #1 [RFC2437]の対応部分と 同一である。) 最上位ビットおよび最下位ビット(これは1になる)を含む"n"のサイズは、 512ビット以上4096ビット未満でなければならない(MUST)。"n"と"e"は公開鍵の 指数が小さくなるように選択されるべきである(SHOULD)。これらはプロトコルの 制限である。鍵長の議論についてはRFC 2541を参照のこと。 RSA/SHA-1アルゴリズムによる署名は、値0のオクテットで開始することを 許容している。 4. パフォーマンスに関する考慮点 一般的な署名生成速度は、RSAとDSA[RFC2536]でほぼ同じである。充分な前処理を 事前にしておけば、DSAはRSAよりも高速に署名を生成する。また、鍵の生成は DSAの方が高速である。しかし、DNSのデータ認証で使用するKEY RRでは、RSAの 公開鍵の指数に小さい値を選択するよう推奨されているので、DSAを使用する場合の 署名検証速度はRSAよりも1桁遅くなる。 公開鍵の指数が3であれば、署名検証に必要な労力を最小限に抑えられる。 秘匿性を提供する場合には、公開鍵の指数として3は脆弱である。指数3を使用する 3つの異なる鍵で暗号化された同じ内容のデータを収集することができれば、 中国人剰余定理[NETSEC]を使用することにより、オリジナルの平文を容易に 復元できるからである。しかし、鍵を認証目的でしか使用されないことが周知 されている場合、DNSSECはその事例なのだが、公開鍵の指数として3は容認できる ものである。しかし、将来のアプリケーションは、秘匿性を要求するアプリ ケーションのためにDNSによって配布された鍵を利用したいかもしれない。 他の用途に使用されるかもしれない鍵では、より保守的な指数の選択肢として 65537 (F4つまり4番目のフェルマー数)が考えられるだろう。 D. Eastlake 3rd Standards Track [Page 4] RFC 3110 RSA SIGs and KEYs in the DNS May 2001 現在のDNS実装は、主としてオーバヘッドを含めて512バイト未満となる小さな データの転送に最適化されている。大きいデータであっても正しく転送される だろうし、大きいデータを効率的に転送する取り組みも標準化されている [RFC2671]。しかし、少なくとも現時点においては、適切なセキュリティを 保てる範囲内でKEY RRsetを最小化するために、相応の努力をすることが 推奨される。署名ゾーンでは、データを認証するSIG RRが最低1つは返される ことに留意してもらいたい。 5. IANAに関する考慮点 DNSSECアルゴリズム番号5がRSA/SHA-1 SIG RRおよびRSA KEY RRに対して 割り当てられている。 6. セキュリティに関する考慮点 RFC 2535記載の一般的なセキュリティに関する考慮点の多くが当てはまる。 DNSから取得した鍵は、以下の条件が全て満たされなければ信用すべきではない。 (1)DNSSEC対応リゾルバから安全な手段で取得したか、ユーザが独自に検証を 行った。(2)DNSSEC対応リゾルバと、リゾルバから鍵を取得した手段または 独立して行った検証がユーザに許容可能なセキュリティポリシーに準拠している。 他の暗号アルゴリズムでも同様だが、鍵に必要とされる強度の評価は不可欠な もので、ローカルポリシーに依存する。特に重要なアプリケーションの実装者は、 使用アルゴリズムおよび鍵長の範囲について検討することを推奨する。 RFC 2541 "DNSSECの運用に関する考慮点(DNS Security Operational Considerations)" も参照してもらいたい。 References [FIP180] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-1, 17 Apr 1995. [NETSEC] Network Security: PRIVATE Communications in a PUBLIC World, Charlie Kaufman, Radia Perlman, & Mike Speciner, Prentice Hall Series in Computer Networking and Distributed Communications, 1995. [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. D. Eastlake 3rd Standards Track [Page 5] RFC 3110 RSA SIGs and KEYs in the DNS May 2001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999. [RFC2541] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [Schneier] Bruce Schneier, "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996, John Wiley and Sons, ISBN 0-471-11709-9. Author's Address Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-261-5434 (w) +1-508-634-2066 (h) Fax +1-508-261-4777 (w) EMail: Donald.Eastlake@motorola.com D. Eastlake 3rd Standards Track [Page 6] RFC 3110 RSA SIGs and KEYs in the DNS May 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. D. Eastlake 3rd Standards Track [Page 7]