ネットワークワーキンググループ M. StJohns Request for Comments: 5011 Independent 分類: 標準化過程(Standards Track) 2007年9月 DNSセキュリティ拡張(DNSSEC)におけるトラストアンカーの自動更新 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 要旨 本文書は、権限認証を行った上でDNSSECの"トラストアンカー"を自動的に 更新する手法を記述する。本手法は、トラストポイントに存在するN個の鍵の うち、N-1個の鍵が漏洩(key compromise)した状況でも正常な状態に回復させる ことができる。本手法は、現在使用しているトラストアンカーによって確立された 信頼に基づき、まず別のトラストアンカーをDNS名前空間の同じ階層の場所に 追加し、最終的に既存のトラストアンカーを置き換えることができるものである。 この仕組みはリゾルバ運用管理に関する作業を変更する必要がある(名前解決 処理の変更は必要としない)。またDNSKEYレコードに1ビットのフラグを追加する 必要がある。 StJohns Standards Track [Page 1] RFC 5011 Trust Anchor Update September 2007 目次 1. はじめに ........................................................2 1.1. 準拠度合に関する表記 ......................................3 2. 運用の方法論 ....................................................3 2.1. 鍵の破棄 ...................................................4 2.2. 鍵追加の保留 ...............................................4 2.3. 能動的な鍵の更新 ...........................................5 2.4. リゾルバのパラメータ .......................................6 2.4.1. 鍵追加保留期間 ......................................6 2.4.2. 鍵削除保留期間 ......................................6 2.4.3. トラストポイントごとの最小トラストアンカー数 ........6 3. DNSKEY RDATAワイヤフォーマットの変更 ............................6 4. 状態表 ..........................................................6 4.1. イベント ...................................................7 4.2. 状態 .......................................................7 5. トラストポイントの削除 ..........................................8 6. 運用シナリオ(情報提供) ..........................................9 6.1. トラストアンカーの追加 .....................................9 6.2. トラストアンカーの削除 .....................................9 6.3. 鍵のロールオーバー ........................................10 6.4. アクティブ鍵の漏洩時の対応 ................................10 6.5. スタンバイ鍵の漏洩時の対応 ................................10 6.6. トラストポイントの削除 ....................................10 7. IANAに関する考慮点 .............................................11 8. セキュリティに関する考慮点 .....................................11 8.1. 鍵所有権と鍵受領ポリシー ..................................11 8.2. 複数鍵の漏洩 ..............................................12 8.3. 動的な更新 ................................................12 9. Normative References ...........................................12 10. Informative References ........................................12 1. はじめに DNSSECセキュリティ拡張(DNSSEC)[RFC4033][RFC4034][RFC4035]が普及してきた 過程と現状を考察し、コミュニティは次のような認識を持つに至った。 現実にはDNSツリー内に1つのまとまった署名空間ができるわけではなく、 署名空間の島々ができ、それぞれが特定の場所("トラストポイント")を 起点とすることになる。これらの署名空間の島はトラストポイント名で 特定され、最低1つの関連する公開鍵によって検証される。 本文書では、トラストポイント名に関連する特定の鍵を"トラストアンカー"と 呼ぶ。1つのトラストポイントは、複数のトラストアンカーを持つことができる。 DNSSEC対応リゾルバがDNSSECで保護された階層(DNSツリー)の枝にある 情報を検証するためには、その枝で使用できるトラストアンカーを 知らなければならない。またトラストポイントは複数のトラストアンカーを 持つ場合がある。現行の規則では、DNSSECで保護されたデータから既知の トラストアンカーのいずれかに至る信頼の連鎖が存在すれば、そのデータは "Secure(検証成功：信頼度高)"であると見なされる。 StJohns Standards Track [Page 2] RFC 5011 Trust Anchor Update September 2007 鍵が本来あるべき場所に無いことによる署名の空白が存在することにより、 おそらくはDNSSECのサブツリーが乱立することが予想される。その場合、 リゾルバは自分の役目を遂行するために、文字通り数千ものトラストアンカーの 知識が必要になる(未署名の".COM"を考えてみればよい)。リゾルバ運用者に これらの情報を人手で設定するよう求めると問題が生じるだろう。ましてや、 任意のトラストアンカーについて、鍵の置き換え/更新で必要な作業を要求すれば 問題は更に大きくなるだろう。本文書で記述する仕組みはリゾルバにおける トラストアンカーの初期設定には役立たないが、トラストポイントにおける 鍵の置き換え/ロールオーバーをより実際的なものにするはずである。 上述の通り、本文書は、任意のトラストポイントにおいて、リゾルバがほぼ 人手による介入なしにトラストアンカーを更新する手法を記述する。 人手による介入が必要となるような例外的事例(例えば複数の鍵の漏洩)の 議論もするが、そのような事例は極めて稀である。本文書は、リゾルバに おけるトラストアンカーの初期設定に関する一般的な問題については議論しない。 1.1. 準拠度合に関する表記 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しな いものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することができ る(MAY)"、"任意である(OPTIONAL)"は、BCP 14、[RFC 2119]に記述されてい るとおりに解釈するものとする。 2. 　運用の方法論 本方式の一般概念は、DNS階層中のあるトラストポイントにおいて、既存の トラストアンカーを使用して新しいトラストアンカーを認証できるという ものである。ゾーン管理者が新しいSEP鍵(SEPビットを設定したDNSKEY。 [RFC4034]のセクション2.1.1参照)をトラストポイントのDNSKEY RRsetに 追加する場合、そのRRsetが既存のトラストアンカーによって検証できるならば、 リゾルバは新しい鍵をそのトラストポイントの有効なトラストアンカーとして 追加することができる。 このアプローチには軽減すべき幾つかの問題がある。例えば、既存の鍵の1つが 漏洩すると、攻撃者は彼らが生成したデータを"有効な"ものとして追加できて しまう可能性がある。これは、鍵が漏洩する、しないに関わらず、既存の鍵を 破棄する方法が必要であることを意味している。他の例として、漏洩した 1つの鍵を用いて、攻撃者が新しい鍵を追加し、他の既存の鍵全てを 破棄することを防ぐ必要がある。 StJohns Standards Track [Page 3] RFC 5011 Trust Anchor Update September 2007 2.1. 鍵の破棄 2つのトラストアンカー 鍵Aと鍵Bがある場合において、鍵Bが漏洩した場合を 考える。特定の破棄ビット(revocation bit)が無い場合、鍵Aを含まないトラスト ポイントの鍵セットを鍵Bで署名してリゾルバに送りつけることで、鍵Aを無効化 できてしまう可能性がある。この問題を解決するため、DNSKEYを破棄するには そのDNSKEYと対の秘密鍵の知識が必要となるような仕組みを追加する。 自己署名RRsetに含まれる鍵のREVOKEビット(セクション7参照)が"1"に 設定されている場合、リゾルバはその鍵が破棄されたとみなす。 リゾルバが鍵のREVOKEビットの設定を確認した場合、破棄事実を検証するために その鍵で署名されたDNSKEY RRsetへのRRSIGを検証するため以外のいかなる 目的にもその鍵を使用してはならず、トラストアンカーとして使用したり、 他の目的に使用してはならない(MUST NOT)。後述する"追加"操作と異なり、 リゾルバが有効な破棄通知を受理したならば、鍵の破棄は直ちに行われ、 また永続的なものとなる。 自己署名RRsetとは、DNSKEY RRsetと対応するRRSIGレコードが存在する 場合に、DNSKEY RRsetが含むDNSKEYによってRRSIGレコードが検証できる ものを指す。これは特殊なDNSKEY RRsetというわけではなく、DNSKEY RRsetの 検証要件を表現する用語の一つに過ぎない。 注：REVOKEビットが設定されたDNSKEYは、ビットが設定されていない場合と 異なるフィンガープリントを持つ。(訳注: DSレコードはDNSKEYのフィンガー プリントを保持するので)このことは、DNSKEYと親ゾーンに存在するDSレコードの 対応付け[RFC3755]に影響する。また(訳注: リゾルバが設定で持つトラスト アンカーはDNSKEYのフィンガープリントなので)トラストポイントを 構築するためにリゾルバが使用するフィンガープリントに影響する。 先に示した例では、攻撃者は鍵Bの秘密鍵を知っているので鍵Bを破棄できる 可能性があるが、鍵Aを破棄することはできない。 2.2. 鍵追加の保留 2つのトラストアンカー 鍵Aと鍵Bがある場合において、鍵Bが漏洩した場合を 考える。その場合、攻撃者は新しいトラストアンカー 鍵Cを生成・追加し (DNSKEY RRsetに鍵Cを追加し、鍵Bで署名すればよい)、その後に漏洩した鍵Bを 無効化できてしまう可能性がある。この状況では、攻撃者とゾーン管理者の 双方がゾーンデータに署名でき、リゾルバはそれらの署名を有効なものとして 扱うことになる。 この問題を完全に解決するものではないが、影響を軽減するために、新しい トラストアンカーの追加に関して保留(hold-down)期間を追加する。 トラストポイントにある検証済みDNSKEY RRsetの中に新しいSEP鍵が あるのをリゾルバが確認した場合、リゾルバは受理保留タイマー (acceptance timer)を起動し、そのRRsetに署名を行っている全ての鍵を 記憶する。 StJohns Standards Track [Page 4] RFC 5011 Trust Anchor Update September 2007 その後、リゾルバがその新しい鍵を含まないが有効な署名を持つ DNSKEY RRsetを確認したならば、リゾルバは新しい鍵の受理処理を中止し、 受理保留タイマーをリセットする。また、新しい鍵の検証に使用した既存の 鍵全てが受理保留タイマー終了前に破棄された場合、リゾルバは受理処理を 中止し、受理保留タイマーをリセットする。 受理保留タイマーが満了したならば、リゾルバは、次回、新しい鍵を 検証可能なRRsetとともに確認した時点で、その鍵をトラストアンカーとして 追加する。受理保留タイマーが満了し、かつ、受理保留期間後に新しい鍵を含む DNSKEY RRsetを取得し検証するまでは、リゾルバはその新しい鍵をトラスト アンカーとみなしてはならない(MUST NOT)。 注: リゾルバは、鍵を一旦トラストアンカーとして受理したならば、 上に述べた手順にしたがって明示的に鍵が廃棄されるまでは、その鍵を 有効なトラストアンカーとみなし続けなければならない(MUST)。 先の例では、鍵Bを破棄するとともに新しい鍵Dを追加し、DNSKEY RRsetを 鍵Aおよび鍵Bの双方で署名することにより、ゾーン管理者は鍵Bの漏洩から 正常な状態に回復させることができる。 この手法が問題を完全には解決できない理由は、DNSが持つ分散特性に関係して いる。リゾルバは自分が確認した情報しか持たない。漏洩した鍵を保持する 執念深い攻撃者がいた場合、本物のゾーンから送出された「本物の」データを 遮断し、(例の場合ならば鍵Bだけで署名するなどして)データを差し替える ことで、特定の単一リゾルバに対して鍵の漏洩があったことを気づかせない ようにすることができるかもしれない。しかし、鍵が漏洩しているという 現在の状況が悪化するわけではない。 2.3. 能動的な鍵の更新 リゾルバが、特定のトラストポイントから自動的に鍵を取得して更新するように 設定されている場合、トラストポイントへの問合わせ(つまりDNSKEY RRsetと 関連するRRSIGレコードの検索)間隔は、15日またはDNSKEY RRsetのTTLの半分 またはRRSIGの署名有効期限までの残り時間の半分のうち最小の期間内に1度より 多く、1時間に1度より少ない頻度でなければならない(MUST)。 RRSIGの署名有効期限までの残り時間とは、RRSIGが最後に検索されてから RRSIGの署名有効期間終了時刻までの時間である。つまり、 問合せ間隔 = MAX(1時間, MIN(15日, 1/2*DNSKEYのTTL, 1/2*RRSIG署名有効期限までの残り時間)) である。 問合わせが失敗した場合、リゾルバは成功するまで問合わせを繰り返さなければ ならない(MUST)。その頻度は1時間に1度より少ない頻度で、1日または DNSKEY RRsetのTTLの10%またはRRSIGの署名有効期限までの残り時間の10% のうち最小となる期間に1度よりは多くなければならない(MUST)。つまり、 問合せ間隔 = MAX(1時間, MIN(1日, 1/10*DNSKEYのTTL, 1/10*RRSIG署名有効期限までの残り時間))である。 StJohns Standards Track [Page 5] RFC 5011 Trust Anchor Update September 2007 2.4. リゾルバのパラメータ 2.4.1. 鍵追加保留期間 鍵追加保留期間は、30日またはトラストポイントのDNSKEY RRsetが新しい鍵を 含むことを初めに認識した際のDNSKEY RRsetのTTLの残り時間のうちの長い方 とする。こうすることにより、リゾルバが新しい鍵を受理する前に、新しい鍵を 含むDNSKEY RRsetの検証が少なくとも2回行われなければならない(MUST)ことが 保証される。 2.4.2. 鍵削除保留期間 鍵削除保留期間は30日とする。これは単なる鍵管理データベースの管理パラメータ である。廃棄された鍵の情報をデータベースから削除しようとして失敗しても 本プロトコルのセキュリティに悪影響を与えることはないが、データベースが 廃棄された情報で溢れることになるだろう。 2.4.3. トラストポイントごとの最小トラストアンカー数 本プロトコルに準拠するリゾルバは、トラストポイントごとに少なくとも 5つのSEP鍵を扱うことができなければならない(MUST)。 3. DNSKEY RDATAワイヤフォーマットの変更 DNSKEYレコードのフラグフィールドの8ビット目を"REVOKE"フラグとする。 このビットが"1"に設定された鍵によって署名されたRRSIG(DNSKEY)を 確認した場合、リゾルバはその鍵の破棄の検証を除く全ての目的について その鍵は永続的に無効であるとみなさなければならない(MUST)。 4. 状態表 理解すべき最も重要なことは、トラストポイントに存在する鍵がリゾルバから どのように見えるかということである。以下の状態表は、鍵の生成から廃棄までの 間の様々な時点の見え方を示したものである。状態表は本仕様の規定である。 鍵の初期状態は"Start"である。様々なイベントが発生する毎に、リゾルバから見た 鍵の状態が変化する。 リゾルバから見たトラストポイントの鍵の状態を以下に示す。左の列は現在 の状態を示す。先頭行は次に遷移する状態を示す。行と列が交差する枠内に、 現在の状態から次の状態に遷移する原因となるイベントを示す。 StJohns Standards Track [Page 6] RFC 5011 Trust Anchor Update September 2007 次の状態 -------------------------------------------------- 現在の状態 |Start |AddPend |Valid |Missing|Revoked|Removed| ------------------------------------------------------------- |Start | |NewKey | | | | | ------------------------------------------------------------- |AddPend |KeyRem | |AddTime| | | | ------------------------------------------------------------- |Valid | | | |KeyRem |Revbit | | ------------------------------------------------------------- |Missing | | |KeyPres| |Revbit | | ------------------------------------------------------------- |Revoked | | | | | |RemTime| ------------------------------------------------------------- |Removed | | | | | | | ------------------------------------------------------------- 　　状態表 4.1. イベント NewKey リゾルバが新しいSEP鍵を含む有効なDNSKEY RRsetを確認した。 新しい鍵は、"鍵追加保留期間"の間RRset内に存在した後で、その鍵が 存在するトラストポイントの新しいトラストアンカーになる。 KeyPres 当該鍵が有効なDNSKEY RRsetに復帰した。 KeyRem リゾルバが当該鍵を含まない有効なDNSKEY RRsetを確認した。 AddTime 当該鍵が少なくとも"鍵追加保留期間"の間、有効なDNSKEY RRset に存在し続けた。 RemTime 破棄された鍵がトラストポイントのDNSKEY RRsetに存在しなくなって から充分な時間が経過し、リゾルバから削除してよい状態になった。 RevBit トラストアンカーのDNSKEY RRsetにREVOKEビットが設定された鍵が 存在し、その鍵で署名されたDNSKEY RRsetへのRRSIGが存在する。 4.2. 状態 Start 当該鍵はまだリゾルバにトラストアンカーとして認識されていない。 ゾーンサーバ上に存在していてもしていなくてもよいが、リゾルバに 確認されていないか、確認されたが最新のDNSKEY RRsetには 含まれていなかった(例えばKeyRemイベント)。 StJohns Standards Track [Page 7] RFC 5011 Trust Anchor Update September 2007 AddPend 当該鍵に"SEP"ビットが設定されており、有効なDNSKEY RRsetに 含まれていることがリゾルバに確認された。現在は当該鍵をトラスト アンカーとして使用できるようになるまでの鍵追加保留期間内である。 Valid 当該鍵が最初に確認された時点から鍵追加保留期間の間、有効なDNSKEY RRsetに含まれ続けていることがリゾルバに確認された。当該鍵は 鍵追加保留期間後にRRsetの検証に使用できる有効なものとなる。 明確化のための説明: 当該鍵を含むDNSKEY RRsetがリゾルバ上に 継続的に存在する必要はない(例えばTTLが経過してキャッシュから 削除されることもある)。ただし、既存のトラストアンカーを検証する ためDNSKEY RRsetを確認・検証する際には、当該鍵がRRset内に 存在していなければならない(MUST)。さもなければ"KeyRem"イベントが 発生する。 Missing これは異常な状態である。当該鍵はトラストアンカーとして有効な 状態を維持しているにも関わらず、リゾルバが最近検証した DNSKEY RRsetに当該鍵が含まれていないことが確認されている。ゾーン管理者は 鍵を削除する前にREVOKEビットを用いるはずなので、異常な状態である。 Revoked DNSKEY RRsetがREVOKEビットが"1"に設定された当該鍵を含み、 同じ鍵でRRSIG(DNSKEY)が署名されていることをリゾルバが確認 したならば、この状態に遷移する。一旦この状態に遷移した後は 当該鍵はトラストアンカーとして永続的に無効であるとみなさなければ ならない。 Removed 充分長い鍵削除保留期間が経過した後、当該鍵に関する情報を リゾルバから削除することができる。この状態の鍵を有効なトラスト アンカーとみなしてはならない(MUST NOT)。 (注：以前使用した鍵を再利用するのは良くない運用である。その点を 除けば、この状態は概ね "Start" 状態と同じである。 この状態は、リゾルバが古い鍵を最早管理しなくてよくなるまでの 保留状態と考えてほしい) 5. トラストポイントの削除 トラストアンカーが全て破棄されたトラストポイントは削除されたものと みなし、そのトラストポイントの設定はなかったものとする。 上位に他のトラストポイントが設定されていない場合、リゾルバは、削除された トラストポイント以下のデータを"Insecure(未署名状況検出：信頼度低)"として 扱う。上位に他のトラストポイントが設定されている場合、削除されたトラスト ポイント以下のデータは、上位のトラストポイントに応じて評価される。 設定されているトラストポイントの下位に別のトラストポイントが存在する場合、 上位のトラストポイントから下位のトラストポイントまでの信頼の連鎖が 有効であるなら、下位のトラストポイントを180日後にリゾルバから削除しても よい(MAY)。下位のトラストポイントを削除するかどうかは管理者が個別に 判断することである。下位のトラストポイントを削除した場合、そのゾーンの 検証は上位のトラストポイントからの信頼の連鎖に依存する。 StJohns Standards Track [Page 8] RFC 5011 Trust Anchor Update September 2007 6. 運用シナリオ(情報提供) 運用モデルとして推奨するのは、トラストポイントごとにアクティブ鍵と スタンバイ鍵を1つずつ持つ、というものである。アクティブ鍵はDNSKEY RRsetの 署名に使用する。スタンバイ鍵は通常DNSKEY RRsetに署名を行わないが、 トラストポイントのDNSKEY RRsetがスタンバイ鍵で署名されたのを確認した場合、 リゾルバはこれをトラストアンカーとして扱う。 スタンバイ鍵は実際の署名に使用しないので、対の秘密鍵に対して、頻繁に 使用しなければならない鍵に対してはほぼ不可能な付加的保護(例えば金庫に保管 する、複数グループに分散するなど)を行うことができる(し、すべきである)。 概念上、スタンバイ鍵はアクティブ鍵よりも漏洩しにくいものであるべきだが、 それは本文書で扱わない運用事項に依存している。 6.1. トラストアンカーの追加 既存のトラストアンカーを鍵Aとする。 1. 新しい鍵ペアを生成する。 2. 生成した鍵ペア(の公開鍵を含む)DNSKEYレコードを生成し、SEPビットと 署名鍵(ZSKまたはKSK)ビットを設定する。 3. 生成したDNSKEYレコードをDNSKEY RRsetに追加する。 4. 既存のトラストアンカーである鍵A "だけ"を使用してDNSKEY RRsetに 署名する。 5. それぞれのリゾルバのキャッシュ期間が終了し、新しいDNSKEY RRsetと その署名をリゾルバが検索してくるのを待つ。 6. セクション2およびセクション4に示した状態表と更新アルゴリズムに沿って 新しいトラストアンカーがリゾルバに行き渡る。 6.2. トラストアンカーの削除 既存のトラストアンカーを鍵Aと鍵Bとし、鍵Aを破棄したい場合を考える。 StJohns Standards Track [Page 9] RFC 5011 Trust Anchor Update September 2007 1. 鍵AのDNSKEYレコードにREVOKEビットを設定する。 2. DNSKEY RRsetに鍵Aと鍵Bで署名する。この時点で鍵Aは破棄される。 ゾーン管理者は、破棄した鍵Aを少なくとも鍵削除保留期間内は DNSKEY RRsetに含めるべきだが、その後はDNSKEY RRsetから削除してよい。 6.3. 鍵のロールオーバー 既存のトラストアンカーを鍵Aと鍵Bとする。鍵Aはアクティブ鍵である(つまり、 DNSKEY RRsetに署名している)。鍵Bはスタンバイ鍵である(つまり、 DNSKEY RRsetにある有効なトラストアンカーであるが、DNSKEY RRsetに署名 していない)。 1. 新しい鍵ペア(鍵C)を生成する。 2. 鍵CをDNSKEY RRsetに追加する。 3. 鍵AのREVOKEビットを設定する。 4. DNSKEY RRsetに鍵Aと鍵Bで署名する。 鍵Aはこの時点で破棄される。鍵Bはこの時点でアクティブ鍵となり、鍵Cは 鍵追加保留期間後にスタンバイ鍵となる。ゾーン管理者は、破棄した鍵Aを少なく とも鍵削除保留期間内はDNSKEY RRsetに含めるべきだが、その後はDNSKEY RRsetから削除してよい。 6.4. アクティブ鍵の漏洩時の対応 鍵Aをアクティブ鍵とすると、上述の鍵のロールオーバー(セクション6.3)と 同じ手順となる。 6.5. スタンバイ鍵の漏洩時の対応 上述の鍵のロールオーバー(セクション6.3)の場合と同じ前提、鍵の名称を 使用する。 1. 新しい鍵ペア(鍵C)を生成する。 2. 鍵CをDNSKEY RRsetに追加する。 3. 鍵BのREVOKEビットを設定する。 4. DNSKEY RRsetに鍵Aと鍵Bで署名する。 鍵Bはこの時点で破棄される。鍵Aはアクティブ鍵のまま、鍵Cは鍵追加保留期間後 にスタンバイ鍵となる。鍵削除保留期間内は鍵BをDNSKEY RRsetに含めるべきで ある。 6.6. トラストポイントの削除 他に設定のあるトラストポイントの下位のトラストポイント(例えば.comに対する example.com)を削除するには、若干のデータ取り回しが必要になる。 具体的な手順は以下のとおりである。 StJohns Standards Track [Page 10] RFC 5011 Trust Anchor Update September 2007 1. 下位ゾーンの新しいDNSKEYレコードとDSレコードを生成し、新しい DSレコードを既存の鍵に対応する古いDSレコードとあわせて親ゾーンに 登録する。 2. それらのDSレコードが親ゾーンで公開された後に、新しいDNSKEYを DNSKEY RRsetに追加し、同時に古い鍵を全て破棄し、破棄した全ての鍵と 新しく追加した鍵でDNSKEY RRsetに署名する。 3. 30日後、破棄された古い鍵の公開を停止し、古い鍵に対応する親ゾーンの DSレコードを削除する。 上位への信頼の連鎖を持つ新しい鍵の追加と古い鍵の破棄を同時に行うことに より、新しい鍵がトラストアンカーとしてリゾルバに追加されるのを防いでいる。 また、古い鍵のDSレコードを親ゾーンに登録することで、その下位ゾーンが (トラストポイントが削除されたため)Insecureとなるか、(上位ゾーンへの 信頼の連鎖がないため)Bogus(検証失敗：信頼禁止)となるような競合状態に 陥るのを防いでいる。 7. IANAに関する考慮点 IANAはREVOKEビット(8)をDNSKEYレコードのフラグフィールド([RFC4034] セクション7参照)に割り当てた。 8. セキュリティに関する考慮点 本プロトコルに固有ではないトラストアンカーのロールオーバーの セキュリティに関する考慮点については、[RFC4986]に議論がある。 8.1. 鍵所有権と鍵受理ポリシー ゾーン管理者が鍵の生成と配布に責任を持つ一方で、それらの鍵をゾーンを 認証する情報として受け入れるかどうかはリゾルバ管理者の決定事項であることに 注意すべきである。これは、現在信頼しているトラストアンカーに基づいて トラストアンカーの更新を行うかどうかもリゾルバ管理者の決定事項である ことを意味する。 リゾルバ管理者(やリゾルバ実装者)は、本仕様に基づく鍵更新の許可・禁止 をトラストポイントごとに選択してもよい(MAY)。鍵の自動更新を禁止する場合、 人手またはネットワークを使用しない方法(out-of-band)による鍵更新の 仕組みを確立する必要があるが、それらは本文書の対象外である。 StJohns Standards Track [Page 11] RFC 5011 Trust Anchor Update September 2007 8.2. 複数の鍵の漏洩 有効なトラストアンカーが少なくとも1つ漏洩していなければ、本方式を 用いて正常な状態に回復させることができる。例えば3つの鍵が存在する場合、 2つの鍵が漏洩しても正常な状態に回復させることができる。 ゾーン管理者は、ゾーンのトラストアンカーとして幾つ有効なアクティブ鍵を 持つのが適正かについて個別に決定し、また漏洩を検知した際の回復手順を 用意しておくべきである。トラストポイントの全てのトラストアンカーが 漏洩した場合、全リゾルバにおいて人手またはネットワークを使用しない 方法による鍵の更新が必要となる。 8.3. 動的な更新 ネットワークを介して(in-band)やりとりされる鍵情報に基づいてリゾルバに トラストアンカーの更新を許可することは、人手による処理に比べれば 潜在的に安全ではない。しかし、DNSの持つ性質、トラストアンカーの漏洩時に 更新が必要となるリゾルバの数、DNSに標準的管理手法が存在しないことなどを 考えれば、本仕様のアプローチによって現状以下になることはない。 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. 10. Informative References [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, "Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover", RFC 4986, August 2007. StJohns Standards Track [Page 12] RFC 5011 Trust Anchor Update September 2007 Author's Address Michael StJohns Independent EMail: mstjohns@comcast.net StJohns Standards Track [Page 13] RFC 5011 Trust Anchor Update September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. StJohns Standards Track [Page 14]