ネットワークワーキンググループ B. Wellington Request for Comments: 3008 Nominum 更新: 2535 2000年11月 分類: 標準化過程 ドメインネームシステムセキュリティ(DNSSEC)署名権限 この文書の位置づけ この文書は、インターネットコミュニティのためにインターネット標準化過程 プロトコルを規定するとともに、改善のための議論や提案を求めるものである。 このプロトコルの標準化の段階と状態については、「Internet Official Protocol Standards」(STD 1)の最新版を参照されたい。この文書の配布は制 限されない。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要約 この文書では、ドメインネームシステムセキュリティ(DNSSEC)署名権限のモデ ルの改訂を提案する。改訂されたモデルは、初期の文書を明確にすることと、 安全な解決プロセスの単純化のために補足的制約を追加することを目的に設計 された。これは特に、レコードセットに署名するための鍵の認可に影響する。 この文書で使用されるキーワード「しなければならない(MUST)」、「してはな らない(MUST NOT)」、「要求されている(REQUIRED)」、「するものとする (SHALL)」、「しないものとする(SHALL NOT)」、「するほうがよい(SHOULD)」、 「しないほうがよい(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「して もよい(MAY)」、「選択できる(OPTIONAL)」は、RFC 2119 [RFC2119]の記述に したがい解釈される。 1 - はじめに この文書は、DNSSEC署名(SIG)レコードに対する補足的制約を定義するもので、 これは関連データに署名するためのそれらの権限に関係する。目的は、安全な リゾルバが従う標準ポリシーを確立することであり、このポリシーはローカル 規則により強化できる。この文書は[RFC2535]に基づくもので、そのセクション 2.3.6を更新する。 最も重要な変更は、安全なゾーン内ではゾーン鍵によりゾーンデータに署名す ることが必要になった点である。 DNSシステム[RFC1034、RFC1035]とDNSセキュリティ拡張[RFC2535]に精通して いることが、この文書では前提とされている。 Wellington Standards Track [Page 1] RFC 3008 DNSSEC Signing Authority November 2000 2 - SIGレコード SIGレコードは通常、RRsetと関連づけられ、そのRRsetを「カバーする」(すな わち、そのRRsetの真正性(authenticity)と完全性を証明する)。これを「デー タSIG」と呼ぶ。注意を要する点は、複数のSIGレコードが1つのRRsetをカバー することがあり、同じ検査プロセスをそれらのSIGレコード一つ一つについて繰 り返す必要があることである。データSIGの中には「必須(material)」(すなわ ち、DNSSEC対応リゾルバと関係がある)とみなされるものと、「無関係 (immaterial)」または「DNSSEC外」(DNSSEC検査と関係がない)とみなされるも のがある。無関係なSIGは、アプリケーションによって定義された役割を果たす ことができる。どのRRsetとも結び付けられないSIGレコードが存在することが あり、これらも無関係とみなされる。どのSIGが必須かは、検査プロセスによっ て決定される。あるSIGが無関係であることが判明した場合は、他の検査は必要 なくなる。 SIGは、トランザクションセキュリティに使用することもできる。この場合は、 「カバーされるタイプ」(type covered)フィールドが0のSIGレコードがメッセ ージに付加され、メッセージの完全性の保護に使用される。これをSIG(0)と呼 ぶ[RFC2535、RFC2931]。 以下のセクションで、SIGレコードの全フィールドについて要件を定義する。こ の署名をDNSSEC対応リゾルバが処理するようにするためには、これらの要件が 満足されなければならない。これらの要件が一つでも満足されないと、SIGの処 理を続けることはできない。その他に、あるKEYがこのSIGを生成したことが確 認された場合は、それが満足しなければならない要件がある。 2.1 - カバーされるタイプ データSIGについては、カバーされるタイプは、関連づけられたRRset中のデー タのタイプと同じでなければならない。SIG(0)については、カバーされるタイ プは0でなければならない。 2.2 - アルゴリズム番号 SIGに指定されたアルゴリズムは、クライアントによって識別されなければなら ず、また、定義されたSIG rdataフォーマットを持つアルゴリズムでなければな らない。 2.3 - ラベル [RFC2535のセクション4.1.3]に明記されているように、ラベルの数はSIG所有者 名中のラベルの数と同じかそれより少なくなければならない。 2.4 - オリジナルTTL TTLを中間サーバによって増加することはできないため、オリジナルTTLはSIGレ コード自体のTTLと同じかそれより大きくなければならない。このフィールド は、SIG(0)レコードについては無視できる。 Wellington Standards Track [Page 2] RFC 3008 DNSSEC Signing Authority November 2000 2.5 - 署名の終了と開始 検査時の現在時刻は、開始時刻と終了時刻で決まる有効期間の範囲内でなけれ ばならない。 2.6 - 鍵タグ 鍵タグフィールドに関する制約はないが、今後のアルゴリズムによって制約が 課されることはあり得る。 2.7 - 署名者名 データSIGの署名者名フィールドには、そのデータと署名とが属するゾーンの 名前が入らなければならない。SIGが必須とみなされる場合は、署名者名、鍵 タグ、アルゴリズムの組み合わせでゾーン鍵が識別されなければならない。唯 一の例外は、ゾーンの頂点にあるSIG KEYの署名者名フィールドには、KEYセッ トにそれ自体の署名が付いている場合以外は、親ゾーンの名前が入っているほ うがよい点である。この文書では、DNSSEC検査について標準ポリシーを定義す る。この標準ポリシーは、ローカルポリシーによって無効にされることがある。 SIG(0)レコードの署名者フィールドについては、制約はない。このSIG(0)が処 理される場合は、署名者名、鍵タグ、アルゴリズムの組み合わせで鍵が識別さ れなければならない。 2.8 - 署名 署名フィールドについては、制約はない。署名はある時点で検証されるが、検 証に先立って署名を検査する必要はない。ただし、今後のアルゴリズムによっ て制約が課される場合は、この限りでない。 3 - 署名KEYレコード 署名とそのフィールドの検査が済むと、その後(ただし、その署名が検証される 前)、リゾルバはSIG中の署名者名フィールド、鍵タグフィールド、アルゴリズ ムフィールドと合致するKEYを見つけようとする。見つからない場合は、その SIGを検証することはできず、そのSIGは無関係とみなされる。KEYが見つかった 場合に、そのSIGが必須とみなされて認可される場合は、KEYレコードのいくつ かのフィールドは特定の値を持たなければならない。複数のKEYがある場合は、 どのKEYが署名を生成したかは検証を実行しないと分からないため、それらのす べてに対し以下のチェックが実行される。 Wellington Standards Track [Page 3] RFC 3008 DNSSEC Signing Authority November 2000 3.1 - タイプフラグ 署名KEYレコードは、00または01のフラグ値を持たなければならない(認証は許 可、秘匿性(confidentiality)はオプション)[RFC2535のセクション3.1.2]。 DNSSECリゾルバは、データの認証を許可された鍵によって生成された署名だけ を信頼しなければならない。 3.2 - 名前フラグ このフィールドの解釈は、データSIGとSIG(0)レコードとでかなり異なる。 3.2.1 - データSIG SIGレコードがRRsetをカバーする場合は、関連づけられたKEYの名前タイプは 01(ゾーン)でなければならない[RFC2535のセクション3.1.2]。これは、RFC 2535のセクション2.3.6の更新である。リゾルバによって実行されるDNSSEC検査 プロセスは、ローカルポリシーに規定されている場合以外は、ゾーン鍵でない 鍵をすべて無視しなければならない。 RFC 2535は、必須のDNSSEC署名の生成をホスト鍵とユーザー鍵に許可している が、この主な理由は、オンラインゾーン鍵がなくても動的更新を実行できるよ うにすることである。すなわち、プライベート鍵をオンラインサーバに保存す ることを回避することである。しかし、オンライン署名鍵(online signing key)を回避するという目的は、NXTやSOAセットに署名するのにこれらが必要な ため、達成できない[RFC3007]。これらのオンラインゾーン鍵は、どんな着信デ ータにも署名できる。オンライン鍵を持たないという目的をなくせば、必須の 署名の生成をホスト鍵とユーザー鍵に許可する理由はなくなる。 必須の署名をゾーン鍵に制限すれば、検査プロセスは簡単になる。検証チェー ンの長さは、名前のラベルの深さで制限される。鍵の権限は明確に定義され、 データに署名する正規の権限が鍵にあるかを判定するための複雑になる可能性 がある決定を、リゾルバが行う必要はない。 ホスト/ユーザー鍵によって生成される必須の署名を許可しても、柔軟性は向上 しない。プライマリゾーンサーバに対する更新要求を認証する能力をユーザー とホストが持っている限り、ゾーン鍵による署名で、データの完全性を世界全 体に対し十分に保護できる。 3.2.2 - SIG(0) SIGレコードがメッセージを保護するSIG(0)である場合は、関連づけられたKEY の名前タイプは00(ユーザー)または10(ホスト/エンティティ)であるほうがよ い。トランザクションはゾーンでなくホストかユーザーによって開始されるた め、ゾーン鍵はSIG(0)レコードを生成しないほうがよい。 Wellington Standards Track [Page 4] RFC 3008 DNSSEC Signing Authority November 2000 クライアントは、ユーザーによってかまたはホストに代わって明示的に実行さ れるため、クライアントによって生成されるSIG(0)の名前タイプはユーザーか ホストであるほうがよい。ネームサーバはホストと関連づけられ、ネームサー バによるSIG(0)の使用は特定のゾーンと関連づけられないため、ネームサーバ によって生成されるSIG(0)の名前タイプはホストであるほうがよい。 3.3 - 署名組織フラグ この文書は、署名組織フィールドに値を割り当てないし、値が存在することも 要求しない。 3.4 - プロトコル 署名KEYレコードは、3(DNSSEC)または255(ALL)のプロトコル値を持たなければ ならない。鍵がDNSSECとの使用を指定されていない場合は、DNSSECリゾルバは それが生成するどの署名も信頼してはならない。 3.5 - アルゴリズム番号 アルゴリズムフィールドは、生成されたSIGレコードのものと同一でなければな らず、また、SIGレコード中のアルゴリズム値に関する要件をすべて満足しなけ ればならない。 4 - セキュリティに関する検討 この文書は、DNSSEC対応リゾルバについて標準的な指針を定義するものである。 徹底的なセキュリティ分析をDNSSECに対し行う場合に、これが必要になる。 特に、この文書は補足的な制約をSIGレコードに課すもので、リゾルバがこれを 検査しないと、署名がDNSSECの信頼に値するとみなすことはできない。これに よってプロトコルは単純化され、より堅牢で、セキュリティコミュニティによ る精査に耐え得るものとなる。 5 - 謝辞 著書は、レビューや有益なコメントを提供してくださった次の方々(アルファベ ット順)に感謝の意を表する。 Olafur Gudmundsson Ed Lewis Wellington Standards Track [Page 5] RFC 3008 DNSSEC Signing Authority November 2000 6 - 参考文献 [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000. [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. 7 - 著者の連絡先 Brian Wellington Nominum, Inc. 950 Charter Street Redwood City, CA 94063 Phone: +1 650 381 6022 EMail: Brian.Wellington@nominum.com Wellington Standards Track [Page 6] RFC 3008 DNSSEC Signing Authority November 2000 9 - 著作権表示の全文 Copyright (C) The Internet Society (2000). 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. 謝辞 RFCエディターの職務に対する助成金は、現時点ではInternet Societyによって 提供されている。 Wellington Standards Track [Page 7] RFC3008-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/