dnsop(Domain Name System Operations) W. Wijngaards インターネットドラフト O. Kolkman 想定する状態: 標準化過程(Standards Track) NLnet Labs 有効期限: 2010年12月31日 2010年6月29日 DNSSECのトラストアンカー履歴サービス draft-ietf-dnsop-dnssec-trust-history-02 要旨 トラストアンカーを保持するDNSバリデータが長期間オフライン状態にある場合、 アンカー鍵のロールオーバーに失敗し、旧いトラストアンカーのまま取り残される。 履歴サービスは、バリデータが旧いDNSKEY RRsetを問合わせると、現在までの ロールオーバーの履歴を得られるものである。 要求に関する用語 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しな いものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することがで きる(MAY)"、"任意である(OPTIONAL)"は、[RFC2119]に記述されているとお りに解釈するものとする。 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 31, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Wijngaards & Kolkman Expires December 31, 2010 [Page 1] Internet-Draft Trust History Service June 2010 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. はじめに 本文書は、DNSバリデータ用の履歴サービスを定義する。ここで、DNSバリデータ とは、DNSSEC[RFC4034]の検証を行うリゾルバのコンポーネントで、短く バリデータと表記されることもある。 オフライン状態にあったか、または(緊急の)ロールオーバーを見落とした バリデータは、このサービスを使用することで、現行のトラストアンカーに 再設定することができる。本文書で新たに定義するリソースレコード(RR)の TALINK RRは旧いDNSKEY群を互いにリンクするもので、バリデータは 旧いDNSKEY RRsetを使用して、最新のアンカー鍵への更新の履歴を再構成する ことができる(セクション3参照)。TALINK RRでリンクされた旧いDNSKEYの一覧は、 DNSKEYの更新を行うゾーンで公開されなければならないというわけではなく、 任意のDNSドメインで公開可能である。トラストアンカーの履歴を提供する組織を 履歴プロバイダと呼ぶ。履歴プロバイダの選択は、バリデータ管理者が行う。 おそらくはゾーン管理者が提供する、TALINK RRが記述されたヒントファイルに 基づく方式になるだろう。 セクション2は背景と仕組み・使用法を提供する。トラストアンカーを含む ゾーンデータの公開者(以下"公開者"と表記する)および利用者の視点から、 破棄ビット(revocation bit)およびSEPビットを設定したアンカー鍵の使用法を 提示する。 バリデータが履歴を構築して最新のアンカー鍵に再設定し直すアルゴリズムの 詳細はセクション4で与えられる。このアルゴリズムはセクション3で定義する TALINK RRを使用する。セクション5は、履歴プロバイダが特定ゾーンで公開された DNSKEYデータを取得し、アンカー鍵の履歴を公開するアルゴリズムを記述する。 2. サービスの動機付けと解説 バリデータが提供するDNSSECのサービスには、二通りの見方がある。 公開者の立場から見たバリデータのサービスは、バリデータが受信したデータと 公開者から送信されたものとが同一であることを保証するものと言える。つまり、 この立場から見たバリデータのサービスとは、公開データの完全性保証サービス である。公開者は(検証がなされる限り)データが誰にも改ざんされていないと 確信できる。改ざんがあれば検知されるからである。したがって、この完全性 保証は、公開者が何者かを誤った場所に誘導していると見られることを防ぐもの である。 利用者の立場から見たバリデータのサービスは、ネットワークから得たデータを 信頼できる根拠を提供するものと言える。この視点から見ると、バリデータとは 利用者が受信したデータを受理すべきかどうかを主張するものである。 Wijngaards & Kolkman Expires December 31, 2010 [Page 2] Internet-Draft Trust History Service June 2010 これは公開者の視点から見た姿とは微妙に異なる。利用者にとって重要な ことは、利用者が閲覧しないデータが安全かどうかではなく、利用者が現在利用 しているデータが安全かどうかだからである。バリデータが提供する検証は、 利用者が誤った場所に誘導されることを防ぐものである。 この二つの微妙に異なるサービスの見え方により、運用上のゴールも微妙に 異なるものになる。公開者は、アンカー鍵のロールオーバーを制御することに より、公開データの安全性を維持したい。一方で、利用者は利用するデータが 正しいことを保証する最善の手段を望んでいる。 バリデータが保持するトラストアンカーの1つがロールオーバーされる際に 当該バリデータがオフラインだった場合、新しいトラストアンカーを必要とする 応答を検証できなくなる。公開者の立場からは、この事態は容認可能である。 バリデータが誤ったデータを利用者に提供しないということを公開者は依然として 確信できるからである。しかし利用者の立場からは、この事態は当該ゾーンの 機能停止に等しい。 公開者は、アンカー鍵のロールオーバーを実行するために、ある条件下では 新旧連続した一連のアンカー鍵を使用しているので([RFC5011参照])、その新旧の 履歴を使用することで、バリデータが利用者向けサービスを中断しても、 新しいトラストアンカーを得るために既存のプロトコル外の仕組みを使用する 必要をなくすことができる。これにより、検証データ利用者が感じるサービス品質が 向上し、DNSSECがDNSデータ利用者に対して利便性を提供する機会を増大させる。 この仕組みをDNSKEY RRの履歴の一部を再現する双方向連結リストで実現する。 バリデータはこの連結リストを使用して、何らかの理由で生じたアンカー鍵更新の 遅れを取り戻すことができる。このアプローチは、[RFC5011]方式のロールオーバー 履歴を事後に再現するものと考えることもできる。 2.1. 破棄されたアンカー鍵を使用することに関する考慮点 RFC 5011のプロトコルでは、公開者がロールオーバーしたアンカー鍵はREVOKED (破棄された)と判定される。この時点で、公開者はアンカー鍵を破棄したと 考えるが、バリデータはまだそれを検知していないか、またはアンカー鍵が破棄 されたと判定していない。RFC 5011規定のプロトコルでは、バリデータは定期的に アンカー鍵を調査するので、アンカー鍵が破棄されればそれを検知できる。 しかしアンカー鍵の調査ができなければ、アンカー鍵が破棄されても検知する ことはできない。つまり、履歴を使用してロールオーバーを再現する時点で、 利用者のバリデータは多数のアンカー鍵の破棄を見落していたことになる。 ゴールは正しいアンカー鍵およびそのアンカー鍵に至るまでの破棄の履歴を 取得することである。 それらのアンカー鍵が公開者によってずっと以前にREVOKEDと見なされていたと しても、利用者のバリデータにとってはそれらの鍵がREVOKEDになったというのは 新しい情報である。 Wijngaards & Kolkman Expires December 31, 2010 [Page 3] Internet-Draft Trust History Service June 2010 アンカー鍵の破棄履歴を一覧で保存することにより、利用者のバリデータが 何らかの理由で定期的調査ができず、破棄の告知を見落としたアンカー鍵の 情報を取得できるようになる。 これはREVOKEDとなったアンカー鍵の利用法として許容される。公開者は そのようなアンカー鍵の存在を告知する。バリデータは検証の後、それらを REVOKEDと判定する。この検証処理の序盤では、破棄履歴を過去に遡る。 これは、どのアンカー鍵を信用しているか露呈することを回避するためである。 これは、バリデータが既に破棄されたアンカー鍵による旧い署名を使用して、 履歴を構築し、検証することを意味する。 その結果、以下のようなことがあり得る。公開者がアンカー鍵をREVOKEDと判定 しても、鍵の破棄を見落とした利用者のバリデータは依然としてそのアンカー鍵を 使い続ける。公開者の立場からは、それらのアンカー鍵は破棄されており、 トラストアンカー履歴リスト(historical key list)に保存されているものである。 利用者の立場からは、アンカー鍵の破棄はその時点で検知できていない。 アンカー鍵の履歴検索アルゴリズムは、旧アンカー鍵が破棄されたことが 観測された場合に新しいアンカー鍵を取得するという状態変更を提供するものに 過ぎない。 2.2. SEPビットを必要とする動機付け SEPビットはKSKを他の鍵と区別するために使用する。SEPビットは[RFC3757]で 定義されたもので、[RFC5011]ではトラストアンカーを明示するために使用して いる。本文書で規定するプロトコルは、トラストアンカー履歴サービスに 使用するDNSKEYにSEPビットを設定するように要求する。この理由は、履歴に 保存されるアンカー鍵セットを少量に保ちたいからである。 3. TALINKリソースレコード DNSリソースレコードのタイプTALINK(10進の58)は、DNSKEY RR双方向連結リストの 要素を互いに結びつけるものである。 RDATA部は2つのドメイン名で構成される。1つ目の名前は開始点または連結リストの 前要素の名前である。2つ目の名前は終端点または連結リストの次要素の名前 である。空ラベル'.'は連結リストの終端点を表現するために使用される。 表記形式は2つのドメイン名を並べたものである。ワイヤーフォーマットも 2つのドメイン名を圧縮せずに並べたものである。したがってタイプは [RFC3597]にしたがって処理することができる。メモリ資源の少ないホストでも 一貫性検査(consistency check)ができるように、リストは双方向連結リスト とする。 ゾーン頂点で使用されるTALINKはリストの終端点を保持する。連結リストを 構成するTALINKは前要素および次要素を保持する。これらのTALINKは使用法 (開始点またはリストの結合)で区別される。双方向連結リストは循環しない。 検索は最も旧い要素に到達した時点で終了するからである。 Wijngaards & Kolkman Expires December 31, 2010 [Page 4] Internet-Draft Trust History Service June 2010 4. トラストアンカー履歴の検索 本セクションでは、バリデータの保持するトラストアンカーと、ゾーン所有者が 公開するDNSKEYとの間で同期ずれを起こした場合に、バリデータがそれを検知し、 解決するために使用するアルゴリズムを提示する。アルゴリズムは、TALINK RR タイプを使用して履歴プロバイダが公開する様々な旧いDNSKEYをリンクし、 バリデータが保持する同期ずれしたトラストアンカーから現在トラストアンカーと なっているDNSKEYまで到達できるようにする。TALINK RRタイプはセクション3で 定義される。 以下に示すアルゴリズムが失敗した場合、トラストアンカー履歴は構築できない ので、新しいトラストアンカーは他の仕組みを使用して再設定する必要がある。 第1段階: バリデータは対象ゾーンに対してDNSKEYの検索を実行する。この検索は、 バリデータが初めに行うDNSKEY検索、つまり現在使用されているDNSKEY RRsetの 中にバリデータが使用中のトラストアンカーと一致するものがあるかを検証する 処理に似ている。バリデータが保持するトラストアンカーでDNSKEY RRsetを検証 できた(訳注: RRsetに含まれるDNSKEYがバリデータのトラストアンカーと一致 した)場合、当該トラストアンカーは同期ずれしていない。検証できない場合、 DNSKEY RRsetが第1段階の処理結果として保存される。アルゴリズムはこの後、 このDNSKEY RRsetに至る双方向連結リスト構築に成功するか、トラストポイント を削除するか、失敗するかのどれかとなる。 全ネームサーバ(ゾーンの権威サーバ、バリデータがフルリゾルバ(反復検索を 行うリゾルバ)でない場合は上流のフルリゾルバの対応キャッシュ)を検査して、 各サーバが保持するDNSKEY RRsetが同じであることを確認すべき(SHOULD) である。署名鍵のロールオーバーが進行中で、全ネームサーバがまだ同期して いない場合、DNSKEY RRsetはサーバによって異なる可能性がある。この場合、 旧いDNSKEY RRsetで新しいものを署名しているはずなので、署名を調査する ことで新しいDNSKEY RRsetを取得することができる。新旧のDNSKEY RRsetが 互いに署名しあっている場合、他のDNSKEY RRsetで検証可能な最新のRRSIGを 保持するDNSKEY RRsetを採用する。この比較においては、検証された(複数の) 署名の有効期間開始時刻・終了時刻の中間値の平均を使用すること(ここで RFC 1982 規定のシリアル番号計算に関して、全署名の有効期間開始時刻・ 終了時刻の差は 2^(SERIAL_BITS-1) 以内に収まるという前提を置いている)。 新旧DNSKEY RRsetは存在するが、どちらも相手に署名していない場合、 DNSKEY RRset更新の認証ができないので、履歴検索は失敗する。 第2段階: トラストアンカー履歴の双方向連結リストの終端点を取得する。 QTYPEをTALINKに、またQNAMEはトラストアンカーを更新したい特定の ドメイン名を指定し、そのドメイン情報を提供する履歴プロバイダに対して 問合わせを実行する。 第3段階: TALINKの双方向連結リストとして提供されるトラストアンカー履歴 リストを過去に遡る。具体的に、取得した前DNSKEY RRsetが次要素のDNSKEY RRsetを適切に署名しているか検証する。この検証処理は[RFC4034]記載の ものと同じだが、RRSIGの有効期間終了時刻は無視する。また、所有者名は 検証を行う対象ゾーン名に置き換える。次DNSKEY RRsetに署名するDNSKEY RRsetの1つにはSEPビットが設定されていなければならない(MUST)。 Wijngaards & Kolkman Expires December 31, 2010 [Page 5] Internet-Draft Trust History Service June 2010 有効な当該署名の有効期間開始時刻・終了時刻の中間値は、リストの次要素と なっているDNSKEY RRsetのそれよりも古くなければならない(MUST)。複数の 署名を検証する場合には平均値を使用する(シリアル番号計算に関して、 全署名の有効期間開始時刻・終了時刻の差は 2^(SERIAL_BITS-1) 以内に収まる という前提を置く)。その後連結リストの前要素および次要素を取得するために タイプTALINKの問合わせを発行する。 この段階で、SEPビットを設定されたDNSKEYに全てREVOKEフラグが設定されて いる場合、処理を継続するが、暫定結果はトラストポイントの削除となる。 [RFC5011]のセクション5を参照のこと。 この段階で、SEPビットを設定されたDNSKEYが全て未知のアルゴリズムを使用 している場合、処理を継続(双方向連結リストを遡る)し、次の時点(双方向 連結リストを1つ遡った時点)で検証可能な署名が未知のアルゴリズム使用の DNSKEY RRsetに対応付けられているかを確認すること。検証が失敗した場合、 失敗という暫定結果を得た状態で処理を継続する。検証が成功した場合、 トラストポイント削除という暫定結果を得た状態で処理を継続する。つまり、 未知のアルゴリズムを使用するDNSKEY RRsetは、失敗という暫定結果を得た 状態で読み飛ばされる。未知のアルゴリズムの最も旧いDNSKEY RRsetが既知の アルゴリズムで署名されている場所に到達するまでは、バリデータは未知の アルゴリズムの署名が有効か判断できないためである。既知のアルゴリズムに よる署名に到達できた場合、暫定結果はトラストポイント削除に変更され、 既知のDNSKEY(訳注: バリデータの保持するトラストアンカー)に到達するまで 第3段階が継続される。 第4段階: バリデータが現在保持するトラストアンカーでDNSKEY RRsetを検証 できたならば、アルゴリズムは終了である。バリデータは結果を安定した状態で 記録すべき(SHOULD)である。以後、バリデータは新しいトラストアンカーを 検証に使用する([RFC5011]を使用している場合、状態をVALIDとする)。 5. トラストアンカー履歴の検索プログラム 外部の履歴検索プログラムにより、対象ゾーンのDNSKEY RRsetを定期的に調査する ことができる。その場合、RRSIGの有効期限の変更や、SEPフラグの設定されて いない署名鍵の変更は無視する。新たにDNSKEY RRsetおよびRRSIG RRsetを取得 した場合、レコードの所有者名を履歴プロバイダの公開場所の名前へと変更する。 それらの新しいRRsetを、連結リストの最終要素となるようにしたTALINKレコードと ともに公開する。更に、最初の名前と最後の名前を広報するTALINKを更新する。 これをロールオーバーに組み込む場合、DNSKEY RRsetは履歴に保存され、TALINKは ロールオーバー処理で新しい鍵が使用される際に更新されることになる。 この段階がTALINKと新しい旧アンカー鍵を広報する機会である。 署名ツールはトラストアンカー履歴をサポート可能である。トラストアンカー 履歴に保存されるアンカー鍵はSEPビットが設定されている必要があるだけである。 旧い署名ツールを使用するには、旧RRSIGを別のファイルに移動する。 TALINKおよびDNSKEYレコードを含むゾーンに署名する。その後旧RRSIGを結果に 加える。このような形式でゾーン署名を行うことで、署名ツールやサーバ ソフトウェアを変更する必要がなくなる。 Wijngaards & Kolkman Expires December 31, 2010 [Page 6] Internet-Draft Trust History Service June 2010 6. 例示 本例示では、"example.net"ゾーンのトラストアンカー履歴を"example.com"名前 空間で公開している。DNSKEYおよびRRSIGのRDATA部は簡潔にするため省略した。 これらはexample.netのデータをコピー&ペーストしたものである。 $ORIGIN example.com. example.com. TALINK h0.example.com. h2.example.com. h0 TALINK . h1.example.com. h0 DNSKEY ... h0 RRSIG ... h1 TALINK h0.example.com. h2.example.com. h1 DNSKEY ... h1 RRSIG ... h2 TALINK h1.example.com. . h2 DNSKEY ... h2 RRSIG ... example.netゾーンは、ここに示した所有者名example.comのTALINKをexample.net ゾーンの頂点で公開することで、example.comが履歴プロバイダだと広報することが できる。その場合、example.comゾーンでは、所有者名example.comのTALINKは 必要なくなる。 7. 展開 トラストアンカー履歴はゾーン頂点のTALINK RRで広報される。これらは、 順次検索可能な別の履歴提供リソースを参照する。ゾーン頂点のTALINKは、 トラストアンカー履歴リストの最初および最後の名前を含む。 アンカー鍵のリストは永久に増え続ける。大半のバリデータは最新のアンカー鍵 を持つので、リストが大きくなっても処理時間は大して変わらない。バリデータが 使用しなくなったトラストアンカーは履歴の公開も不要となる。リストを短く保つ ため、あまりにも旧くなったアンカー鍵エントリは省略することができる。 バリデータはアンカー鍵をどの程度の期間信用するかを決定できる。ゾーン 管理者からの推奨値をゾーンのトラストアンカーに設定することもできるし、 アルゴリズムや鍵長に基づく推奨値を使用することもできる(例えば[NIST800-57] 参照)。履歴に含まれるアンカー鍵がその期間よりも長い間更新されていなかった ことが判明した場合、その時点でトラストアンカー履歴検索は失敗し、トラスト ポイントは削除されたと見なしてよい。これは、各バリデータには独自の セキュリティポリシーに基づいた判断があり、トラストアンカーの更新に失敗した 場合には何らかの対応を取れることを想定している。そのようなポリシーを 持たない場合、または他の採り得る選択肢がDNSSECの使用停止になってしまう 場合、以下のアプローチを使用することもできる。 Wijngaards & Kolkman Expires December 31, 2010 [Page 7] Internet-Draft Trust History Service June 2010 一般に、旧いアンカー鍵でも、鍵長の短いアンカー鍵でも、DNSSECが使えない (セキュリティが保たれない)よりマシだという判断は可能である。その場合、 バリデータはアンカー鍵を旧すぎるとは見なさないようにする。また、アンカー 鍵が容易に漏洩する状態になった場合は、履歴検索アルゴリズムは安全でない アンカー鍵更新の仕組みになる。履歴プロバイダは、バリデータが安全でない アンカー鍵更新についても実行できるよう、漏洩した鍵も提供すべき(SHOULD) である。アンカー鍵が容易に漏洩しない状況であれば、それは充分なセキュリティを 提供しているので、履歴検索アルゴリズムを使用して最新のアンカー鍵を取得 できる。おそらくは、アンカー鍵更新後、結果は安定した状態で記録され、 以後クライアントは安全になる。したがって、目をつぶって決断すべきだろう。 バリデータ運用者は、DNSSEC機能をあきらめるか、ゾーンへの接続性を失うか、 "思い込みのセキュリティはセキュリティが無いよりも悪い"という意見なども 考慮して、これらの設定を選択することができる。 履歴検索は自動で使用可能である。その場合、トラストアンカー履歴はアンカー 鍵がロールオーバーされる都度使用されるので、履歴へのポーリングは行われない。 最後の検索結果が正常で、また入手したアンカー鍵を次の履歴検索で使用することが できる場合に履歴検索の実行を不要とするため、トラストアンカー履歴検索の 結果を安定した状態で記録すべき(SHOULD)である。 バリデータが対象ゾーンに対して[RFC5011]も使用している場合、トラスト アンカー履歴検索アルゴリズムは、[RFC5011]アルゴリズムが調査できなかった ために失敗した場合にだけ実行されるべき(SHOULD)である。これは[RFC5011]の 調査が最後に成功してから30日以上経過した場合が当てはまる。 新しいアンカー鍵が広報されている場合、履歴検索アルゴリズムが起動するのは、 鍵追加保留期間内に実行された2回の調査が失敗し、また鍵追加保留期間後にも 調査が成功しなかった場合である。したがって、最後に調査が成功した時刻を 安定した状態で記録しなければならない(MUST)。 ごくまれにしか行われない可能性のある履歴検索をテストするために、以下に 示す事柄が実装されるべき(SHOULD)である。テストにおいては、特定のアンカー鍵 セット、最後に成功した履歴検索時刻、テスト用履歴プロバイダをシステムに 提供できるようにし、手動で履歴検索を実行できるようにすべきである。 テスト用履歴プロバイダは、テスト用の過去履歴を生成し、アクセスできる ようにすべきである。 8. セキュリティに関する考慮点 履歴プロバイダは旧いデータのコピーしか提供しない。旧アンカー鍵データが 改ざんまたは隠ぺいされると、履歴検索アルゴリズムは第3段階で検証エラーが 生じるので失敗する。履歴プロバイダまたは敵対的中間者(MIMA: Man in the Middle Adversary)が(例えば窃盗、暗号解読、その他の手段により)オリジナルの 秘密鍵を使用できる場合、アルゴリズムが失敗することなく履歴を改ざん可能 である。以下では、MIMAに関する考慮点のみを検討し、履歴プロバイダは信頼 できると想定する。 Wijngaards & Kolkman Expires December 31, 2010 [Page 8] Internet-Draft Trust History Service June 2010 第2段階または第3段階で検索されるデータをMIMAが偽造した場合、具体的に TALINKおよびDNSKEYデータを偽造した場合、履歴を改ざん可能である。 しかし、履歴を構築して到達すべきDNSKEY RRset(トラストアンカー)は第1段階で 既に固定されている。第2段階または第3段階のアルゴリズムを妨害しようと 試みたとしても、誰にも気づかれないまま最終的に得られるDNSKEY RRsetを 別のものに置き換えることはできない。 最終的に到達すべきトラストアンカー鍵セットを変更するためには、第1段階の データを偽造し、バリデータが保持するトラストアンカー(またはこれより新しい 旧アンカー鍵)が漏洩していなければならない。このような偽造を特定の攻撃対象に 限定して行うというのでない限り、第1段階のデータを偽造すると極めてわかり やすいものとなる。ほとんどの偽造データを受信したバリデータは最新のトラスト アンカーを保持しているので、偽造DNSKEYを含むゾーンのデータに対しては検証 エラーが返される。したがって、MIMAはトラストアンカーを更新しようとしている バリデータを攻撃対象にしなくてはならない。しかし、バリデータは第2段階に 至るまでトラストアンカー履歴検索を実行しているとは告知しないので、MIMAは 攻撃対象のバリデータを選択することができない。 第2段階および第3段階でデータを偽造し、漏洩した(旧い)鍵と組み合わせると、 ダウングレード攻撃が可能となる。第2段階および第3段階で偽造したトラスト ポイント削除またはアルゴリズムのロールオーバーを履歴に挿入し、改ざんする ことが可能である。これにより、現在のトラストアンカー偽造の露呈(前段落 参照)を回避し、"Insecure"な状態にダウングレードさせる。 最後に、履歴プロバイダが公開している鍵の1つが漏洩した場合を考える。 履歴検索アルゴリズムの第1段階で何者かが偽造を行い、漏洩した鍵への履歴を 構築した場合、もちろんそこには鍵の破棄は含まれないまま漏洩した鍵への履歴が 作られる。したがって、履歴プロバイダがそのようなアンカー鍵を公開している 履歴から削除することは有用ではない。この対処を行っても、攻撃対象外の バリデータが履歴検索に失敗するようになるだけである。有用な対応は、別の 手段でバリデータを更新することだろう。 [RFC5011]方式のロールオーバーでは、アンカー鍵は使用後に破棄される。 履歴プロバイダを使用する場合、履歴の追跡や検索を行うために、 そのような鍵を使用すべき(SHOULD)である。バリデータが記録・保持する トラストアンカー鍵と、最終版として保存する現在のアンカー鍵は、破棄されて いる場合には信頼してはならない(MUST NOT) バリデータ運用者が[RFC5011]を使用せずにトラストアンカー履歴を使用する ことを選択した場合、トラストアンカーは鍵追加保留期間で保護されない。 これにより生じる危険もある。タイムアウト無しで即時のロールオーバーを 行う場合、(秘密鍵が漏洩すると)濫用につながる可能性がある。そのような濫用の 結果、保存された履歴検索結果がセキュリティ侵害される可能性がある。 運用者に通知を行うとともに監査証跡を残すために、アンカー鍵の変更を記録する ことが有用だろう。 Wijngaards & Kolkman Expires December 31, 2010 [Page 9] Internet-Draft Trust History Service June 2010 KSKに対する制御が対象ゾーンのアンカー鍵セットの変更に必要であることを 確認するために、SEPビットを検査する。 現在のアンカー鍵セットの署名の有効期間開始時刻・終了時刻を取得するために 履歴検索アルゴリズムを使用することができる。MIMAは履歴を短縮し、時間を それに合わせて調整することはできるが、アルゴリズムはこの実行を困難にし、 他者に気づきやすくさせようとするものである。 MIMAがバリデータの時間に影響を与えられる場合、時計を進めることに利点は ないが、時計を戻すと旧いDNSSECデータおよび署名を使用した再生攻撃が可能と なる。この脆弱性はDNSSECそのものにも存在する。 9. IANAに関する考慮点 RFC 5395記載の専門家の審査を経て、リソースレコードタイプTALINKが 定義された。そのRRタイプ番号は10進の58である。 10. Acknowledgments Thanks to the people who provided review and suggestions, Peter Koch, Andrew Sullivan, Joe Abley, George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil, Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and Matthijs Mekking. 11. References 11.1. Informative References [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendations for Key Management", NIST SP 800-57, March 2007. [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. 11.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. Wijngaards & Kolkman Expires December 31, 2010 [Page 10] Internet-Draft Trust History Service June 2010 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. Authors' Addresses Wouter Wijngaards NLnet Labs Science Park 140 Amsterdam 1098 XG The Netherlands EMail: wouter@nlnetlabs.nl Olaf Kolkman NLnet Labs Science Park 140 Amsterdam 1098 XG The Netherlands EMail: olaf@nlnetlabs.nl Wijngaards & Kolkman Expires December 31, 2010 [Page 11]