ネットワークワーキンググループ D. Eastlake 3rd Request for Comments: 2931 Motorola 更新: 2535 2000年9月 分類: 標準トラック DNSリクエストおよびトランザクションの署名( SIG(0) ) 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準トラック プロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については「Internet Official Protocol Standards」(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要旨 Domain Name System (DNS)の機能拡張は[RFC2535]で説明される。これは 暗号電子署名を利用して、セキュリティ対応リゾルバとアプリケーションに 対して、データ発信元およびトランザクションの完全性と認証を提供する ことができるものである。 実装の経験より、リクエストとトランザクションの署名レコード( SIG(0) )に 関しては、小規模だが相互運用性のない変更が必要であることが示唆されて いる。これらの変更点をここで文書化するものである。 謝辞 以下の方々(アルファベット順)の本文書への貢献と提案に深く感謝する。 Olafur Gudmundsson Ed Lewis Erik Nordmark Brian Wellington Eastlake Standards Track [Page 1] RFC 2931 DNS SIG(0) September 2000 目次 1. はじめに.......................................................2 2. SIG(0)の設計原理...............................................3 2.1 トランザクション認証..........................................3 2.2 リクエスト認証................................................3 2.3 鍵処理........................................................3 2.4 TSIGとSIG(0)の違い............................................4 3. SIG(0)リソースレコード.........................................4 3.1 リクエストSIGとトランザクションSIGの計算......................5 3.2 応答とSIG(0) RRの処理.........................................6 3.3 SIG(0)の存続期間と有効期間終了................................7 4. セキュリティに関する考察.......................................7 参考文献..........................................................7 著者の連絡先......................................................8 付録: SIG(0)に関するRFC 2535からの変更点..........................9 著作権表示の全文.................................................10 1. はじめに 本文書は、[RFC 2535]の一部に対して小規模ではあるが相互運用性のない 変更を加えるものであり、[RFC 2535]の内容を理解していることを前提と する。また、本文書は[RFC 2535]の追加の説明を含む。これらの変更は、 DNSリクエストおよびトランザクション/応答に電子署名をするために使用 されるSIGリソースレコード(RR)に関するものである。このリソースレコード は0のType Coveredフィールドを持つため、しばしばSIG(0)と呼ばれる。 変更は、TSIG[RFC 2845]と[RFC 2535]でSIG(0)に関する部分それぞれについて、 実装および試みられた実装の経験に基づいている。 更新される[RFC 2535]のセクションは、4.1.8.1全てと4.2および4.3の一部 である。KEYまたはNXT RR、もしくはデータ生成元とDNSデータの拒否認証に 関する処理については変更されない。 本文書における「しなければならない(MUST)」、｢してはならない(MUST NOT)｣、 ｢要求される(REQUIRED)｣、｢するものとする(SHALL)｣、｢しないものとする (SHALL NOT)｣、「すべきである(SHOULD)」、｢すべきではない(SHOULD NOT)｣、 「推奨される(RECOMMENDED)」、「してもよい(MAY)」、｢任意である(OPTIONAL)｣ というキーワードは、RFC 2119に記述される通りに解釈するものとする。 Eastlake Standards Track [Page 2] RFC 2931 DNS SIG(0) September 2000 2. SIG(0)の設計原理 SIG(0)は、DNSトランザクションおよびリクエストに対し、 [RFC 2535]で 規定される通常のSIG、KEY、NXT RRでは提供されない保護を提供する。 安全なDNSにおけるデータ送信元を認証するサービスは、データリソース レコード(RR)の保護か、あるいは保護されたデータリソースレコードが存在 しないメッセージを認証によって拒否するか、どちらかの機能を提供する。 これらのサービスは、グルー(glue)レコード、DNSリクエスト、リクエスト または応答のメッセージヘッダ、応答の全体的な完全性に対する保護は提供 しない。 2.1トランザクション認証 トランザクション認証とは、リクエスト送信者が少なくとも照会したサーバ からメッセージを受信したこと、受信したメッセージがその照会に対する 応答であることを信頼できるようにするものである。これは、任意により TSIG RR[RFC2845]か、SIG(0) RRのどちらかを応答の最後に追加することに より達成される。SIG(0) RRは、本文書で説明するように、サーバの応答と 対応するリゾルバの照会を結合したものに電子的に署名するものである。 2.2 リクエスト認証 リクエストはTSIGか、またはここで説明される特別なSIG(0) RRをリクエストの 最後に含めることで認証される。リクエストの認証は、動的更新の仕様以前の DNSサーバでは、何も機能を提供しない。わずかに残されたそのような古い 実装のDNSサーバでは、空でない付加情報部を持つリクエストに対してエラー 応答を生成するか、あるいはリクエストが無視される場合すらある。 しかしながら、動的更新リクエスト[RFC2136]、TKEYリクエスト[RFC2930]、 または認証を必要とする将来のリクエストを認証するため、リクエストの 署名用にこの構文が定義されている。 2.3 鍵処理 トランザクションセキュリティで使用される秘密鍵は、関係するゾーンでは なく、DNS応答メッセージを生成するホストに帰属する。リクエスト認証も、 ホストまたはリクエストを構成する他のエンティティの秘密鍵や、リクエスト によって影響を受けるゾーンの秘密鍵、あるいは確立が求められるリクエストの 権威によっては他の秘密鍵を必要とすることがある。対応する(1つ以上の) 公開鍵は、通常3(DNSSEC)または255(ANY)のプロトコルバイトを持つKEY RRと してDNSに保管され、検証のためにDNSから取り出される。 リクエストと応答は極めて変化しやすいため、メッセージ認証SIGをあらかじめ 計算しておくことができない。したがって、たとえばソフトウェアまたは直接 接続された機器によって、秘密鍵をオンラインにしておくことが必要となる。 Eastlake Standards Track [Page 3] RFC 2931 DNS SIG(0) September 2000 2.4 TSIGとSIG(0)の違い TSIGとSIG(0)には大きな違いがある。 TSIGはリクエスト側とサーバの両方にインストールされた秘密鍵を必要と するため、、そのような秘密鍵が存在するということは、TSIGを理解し、 また非常に高い確率で同じ鍵をインストールされている他のサーバが存在する ことを意味する。さらに、TSIGは計算コストが相対的に小さい鍵付きハッシュ 認証コードを使用する。そのため、通常はリクエストをTSIGで認証し、 対応するリクエストが認証された場合、応答もまたTSIGで認証される。 一方で、SIG(0)は公開鍵認証を利用する。公開鍵認証では、公開鍵はKEY RRと してDNSに保存され、秘密鍵は署名側に保存される。このようなKEY RRの存在は、 必ずしもSIG(0)の実装を意味しない。更に、SIG(0)は、最小限に抑えられる べき計算コストの高い公開鍵暗号化操作を必要とする。また、SIG(0)の検証 にはKEYに対応する鍵の入手と検証を必要とするが、これも計算コストが高く 処理時間がかかるものである。実際に、全てのリクエストについて応答前に SIG(0)を使用して検証を行うというポリシは、設定によっては致命的な状況を 導く場合がある。リクエストSIG(0)の認証のためにKEYを入手し検証するという 試みが、結果としてSIG(0)を伴う追加のリクエストにつながり、更にそれが SIG(0)を伴うリクエストにつながり、それが繰り返されるような状況である。 加えて、必要ない場合にリクエストのSIG(0)を省略すると、トランザクションに 要求される公開鍵処理の数は半分になる。 このような理由により、リクエストにおけるSIG(0)の使用は、リクエスト側が 必要な特権または識別情報を持つことを認証するために必要な場合のみにする べきである。応答におけるSIG(0)は、対応するリクエストのSIG(0)を必要と せず、それでもなおトランザクションの保護を提供する形で定義される。 他の応答については、サーバに認証されるか、リクエスト側の認証を必要と するかは、ローカルの設定オプションとするべきである。 3. SIG(0)リソース レコード SIGリソースレコード(RR)の構造とタイプ番号は、[RFC2535]セクション4.1に 示されている。しかし、セクション4.1.8.1の全てとSIG(0)に関連する セクション4.2および4.3の一部は、以下の説明によって置き換えられるとみなす べきである。SIG(0) RRに関して[RFC2535]と本文書に矛盾がある場合、本文書の 説明が優先されるべきである。 全てのトランザクションSIG(0)について、Signerフィールドは、送信元ホストの 名前でなければならず、また署名の計算に使用される秘密鍵に対応する公開鍵の 名前を持つKEY RRが存在しなければならない。(使用されるホストドメイン名は、 関連するKEYがそこに保存されている場合、ホストのIPアドレスの逆引き名と なる場合がある。) Eastlake Standards Track [Page 4] RFC 2931 DNS SIG(0) September 2000 全てのSIG(0) RRにおいて、所有者名(owner name)、クラス、TTL、オリジナルの TTLは意味を持たない。TTLフィールドは0にし、CLASSフィールドはANYにする べきである。データ量を節約するため、所有者名はルート(単一の0オクテット) にするべきである。応答に対するSIG(0)認証が求められる場合、そのSIG RRは、 応答に含めるための追加情報の中で最も高い優先度を持つと考えなければ ならない。メッセージの切り詰め処理なしではSIG(0) RRを追加することが できない場合、サーバはSIG(0)を含めることができるように、応答を変更 しなければならない。この応答は問い合わせ部とSIG(0)レコードのみから構成 され、TCビットが立てられ、RCODE 0 (NOERROR)を持つ。クライアントはこの 時点でTCPを使用してリトライを行うべきである。 3.1 リクエストSIGとトランザクションSIGの計算 DNSリクエストは、任意で1つのSIGを照会の付加情報部の最後に含めることに より、署名されることがある。このようなSIGは、0が指定された｢Type Covered｣ フィールドを持つことで識別される。署名は、前述のDNSリクエストメッセージ の、DNSヘッダは含むがUDP/IPヘッダは含まないものに対して、リクエストSIG(0) 追加のためにリクエストRR数が調整される前に行われる。 署名の計算は、以下の「データ」([RFC 2535]セクション4.1.8参照)を使用して 計算される。すなわち、(1)Signatureサブフィールド自身を全て省略した (フィールドに0を詰めるのではなく)SIGのRDATAセクション、(2)DNSヘッダは 含むがUDP/IPヘッダを含まないもので、SIG(0)追加のために応答RR数が調整 される前のDNS照会メッセージである。つまり、次のようになる。 data = RDATA | リクエスト - SIG(0) ここで、「|」は連結を意味し、RDATAは計算されるSIG(0)のRDATAから 署名自体を除いたものである。 リクエストの場合と同様に、SIG(0)は応答とその応答を生成したリクエストを 保護するために使用することができる。このようなトランザクション署名は 以下の「データ」を使用して計算される。すなわち、(1)署名そのものを省略 したSIGのRDATAセクション、(2)DNSヘッダは含むがUDP/IPヘッダは含まない、 応答を生成したDNS照会メッセージ全体、(3)DNSヘッダは含むがUDP/IPヘッダは 含まないDNS応答メッセージ全体で、SIG(0)追加のために応答RR数が調整される 前のものである。 Eastlake Standards Track [Page 5] RFC 2931 DNS SIG(0) September 2000 つまり、次のようになる。 data = RDATA | 照会全体 | 応答 - SIG(0) ここで、「|」は連結を意味し、RDATAは計算されるSIG(0)のRDATAから 署名自体を除いたものである。 リクエストを送信したリゾルバによって行われる、(ゾーン鍵ではなく、 サーバホスト鍵によって署名された)応答SIG(0)の検証は、以下の事柄を 明らかにする。すなわち、照会と応答が転送中に汚染されていないこと、 応答が意図した照会に対応するものであること、応答が照会されたサーバ からのものであることである。 TCP経由のDNSメッセージの場合、最初のデータパケットのSIG(0)は上述の 「データ」を使用して計算され、それ以降の各パケットのSIG(0)は次のように 計算される。 data = RDATA | DNSペイロード - SIG(0) | 前のパケット ここで「|」は連結であり、RDATAは上述のとおりである。前のパケットは DNSヘッダとSIG(0)を含むがTCP/IPヘッダを含まないDNSペイロードである。 TCPにおけるSIG(0)サポートは任意である。別の方法として、必要であれば、 TKEY[RFC2930]で鍵を設定した後にTSIGを使用してもよい。 更新、TKEY、または同様の特権付リクエストの認証のために必要である場合 を除き、サーバはリクエストSIG(0)をチェックすることを要求されない。 注: 要求と応答は単一のTSIGまたはSIG(0)のいずれかを持つことができるが、 TSIGとSIG(0)の両方を持つことはできない。 3.2 応答とSIG(0) RRの処理 SIG RRが応答の付加情報部の最後にあり、Type Coveredが0であれば、それは 応答と応答を生成した照会を対象とするトランザクション署名である。 TKEY応答ではこれがチェックされなければならず、チェックに失敗した場合、 使用中のTKEYに向けた他の指定が存在しなければ、メッセージは拒否される。 他の応答全てについては、これはチェックしてもよいという位置づけのもの であり、チェックが失敗した場合にはメッセージは拒否される。 応答のSIG(0)チェックが成功した場合でも、そのようなトランザクション 認証は、メッセージ内のいかなるデータRRについても、その正当性について 直接認証をするものではない。しかし、データRRが照会されたサーバから 送られたものであり、偽造がされていないことは認証する。 (ゾーン鍵か、またはその権威をゾーンまたは静的リゾルバ設定に対して トレーシングする鍵によって署名された正当なSIG(0)RRだけが、リゾルバの ポリシにしたがってデータRRを直接認証することができる。) Eastlake Standards Track [Page 6] RFC 2931 DNS SIG(0) September 2000 リゾルバまたはサーバがトランザクションSIG、リクエストSIGのどちらか あるいは両方を実装していない場合、これらのSIGはエラー無しで無視され なければならない。署名の包含処理は任意であり、処理を要求された先で 失敗したものとして扱われる。 3.3 SIG(0)の存続期間と有効期間終了 SIG(0)の有効期間開始時間と終了時間は、リプレイ攻撃を防ぐためのもの である。これらは、時間の範囲を形成するように設定され、範囲外の メッセージを無視できるようにするべきである。IPネットワークでは、 この時間の範囲は通常、過去に対しても未来に対しても5分以上拡大される べきではない。 4. セキュリティに関する考察 [RFC 2535]に示されるもの以外に追加の考察はない。 署名にSIG(0)有効期間開始時刻および終了時刻を含めることにより、 リプレイ攻撃への防御性は向上する。 5. IANAに関する考察 本文書によって新しいパラメータは作成されていないか、変数値が割り当て られることはない。 参考文献 [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, September 1996. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Signatures for DNS (TSIG)", RFC 2845, May 2000. [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC 2930, September 2000. Eastlake Standards Track [Page 7] RFC 2931 DNS SIG(0) September 2000 著者の連絡先 Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA Phone: +1-978-562-2827(h) +1-508-261-5434(w) Fax: +1 978-567-7941(h) +1-508-261-4447(w) EMail: Donald.Eastlake@motorola.com Eastlake Standards Track [Page 8] RFC 2931 DNS SIG(0) September 2000 付録: RFC 2535からのSIG(0)に関する変更点 TSIGとSIG(0)の違いを扱う説明文を追加した。 署名の有効期間開始時刻、終了時刻を保護し、リプレイ攻撃を防ぐために、 署名それ自体以外にSIG(0) RDATAを含めるために、SIG(0)が計算される素材と なるデータを変更した。TCPのためのSIG(0)を規定した。 SIG(0)の適切な有効期間開始時刻および終了時刻についての議論を追加した。 TSIGまたは1つ以上のSIG(0)のどちらかが存在できるが、両方は存在できない ことを示すために表現を追加した。 表現を明確にするために幾つかの部分を書き換えた。 Eastlake Standards Track [Page 9] RFC 2931 DNS SIG(0) September 2000 著作権表示の全文 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によって提供されて いる。 Eastlake Standards Track [Page 10] RFC2931-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/