ネットワークワーキンググループ P. Vixie Request for Comments: 2845 ISC 分類: 標準トラック O. Gudmundsson 更新: 1035 NAI Labs D. Eastlake 3rd Motorola B. Wellington Nominum 2000年5月 DNSにおける秘密鍵のトランザクション認証(TSIG) 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準トラック プロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については「Internet Official Protocol Standards」(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要旨 このプロトコルは、共有秘密鍵と一方向ハッシュ関数を使用してトラン ザクションレベルの認証を可能にするものである。このプロトコルは承認済 クライアントからの動的更新を認証したり、承認済再帰的ネームサーバからの 応答を認証することに使用することができる。 ここまでに共有秘密鍵を配布するための準備はなされていないので、安全かつ 自動的に鍵配布を行えるメカニズムが利用可能になるまで、ネットワーク管理者 はスニーカーネット(訳注: 記録メディアを物理的に持ち運びするネットワーク) のようなアウトオブバンド(訳注: 正規に使用するネットワーク以外)のメカ ニズムを使用して、静的にネームサーバとクライアントを設定することが求め られる。 1 - はじめに 1.1 Domain Name System (DNS) [RFC1034, RFC1035]は、複製される階層的 分散データベースシステムであり、名前とアドレスの変換やメール処理の情報 などインターネット運用の基礎となる情報を提供する。DNSは最近になって、 データ生成元の認証や公開鍵の配布を可能にするように拡張が行われた [RFC2535]。これらは全て公開鍵暗号と公開鍵に基づく電子署名に基づくもの である。実際上、この形式のセキュリティでは、一般に大規模な鍵のローカル キャッシュと、ローカルに設定された信頼済の鍵に対する複数の鍵および 署名による認証のトレーシングが必要になる。 Vixie, et al. Standards Track [Page 1] RFC 2845 DNS TSIG May 2000 1.2 [RFC2535]で規定される機構の問題は、一般のDNS実装がキャッシュを 持たない単純な「スタブ」リゾルバを含むことである。このようなリゾルバは、 通常別のホスト上のキャッシュ機能付のDNSサーバに依存する。これらの スタブリゾルバが、[RFC2535]で規定される一般的な認証を実行することは 現実的ではなく、これらのリゾルバがそのようなサービスを提供するために、 キャッシュ機能付DNSサーバに依存するのは当然である。この作業を安全に行う ために、照会、応答時に安全な通信をすることが必要となる。[RFC2535]は これをサポートするために公開鍵によるトランザクション署名を提供している が、この種の署名は生成のための計算コストが非常に高い。一般にこれらの 署名は同一の複雑な公開鍵ロジックが必要であり、スタブリゾルバにおける 処理は現実的ではない。本文書はメッセージ認証コード(MAC)、特にHMAC-MD5 (鍵付ハッシュ関数)の使用法を規定し、ポイントツーポイントの認証とトラン ザクションの完全性チェックに対して効果的な手段を提供する。 1.3 もう1つ、[RFC2535]で規定される公開鍵に基づくメカニズムを、そのまま 使用することが現実的でないものとして、[RFC2136]で規定される動的更新 リクエストの認証が挙げられる。[RFC2535]はリクエスト署名を提供しているが、 この署名はトランザクション署名のように、計算コストの高い公開鍵暗号と 複雑な認証ロジックを必要とする。「Secure Domain Name System Dynamic Update」([RFC2137])では、動的に更新されるゾーンで異なる鍵がどのように 使用されるかについて記述している。本文書で規定する、秘密鍵に基づくMACは、 DNSの更新リクエストの認証やトランザクション応答の認証に使用することが でき、[RFC2137]で規定されるプロトコルに処理の軽い別の選択肢を提供する ものである。 1.4 このメカニズムの更に進んだ使用法として、ゾーン転送の保護が挙げら れる。この場合、扱われるデータは、送信される全グルー(glue)レコードを 含むゾーン転送全体になる。[RFC2535]で説明されるプロトコルでは、SIG(0) (トランザクション署名)が使用されない限り、グルーレコードと未署名レコード は保護されない。 1.5 本文書で提案する認証メカニズムは、2つのエンティティの間に信頼関係を 確立するために共有秘密鍵を使用する。これらの鍵は、意図された関係者の1つ であるかのような第三者なりすまし(偽造MAC)を防ぐために、公開鍵における 秘密鍵と同様な方法によって保護されなければならない。クライアントと ローカルサーバ間におけるシンプルで効果的な認証を提供するために緊急の 需要があり、本提案はその需要に対するものである。他の多くのサーバと通信を 行うサーバの一般的サーバ間認証に本提案を使用するのは適当ではない。 共有鍵の数が二乗の割合で増加するため、鍵管理が困難になるからである。 しかし、数台の再帰的サーバとしか通信しない、多くのホスト上のリゾルバには 適当である。 Vixie, et al. Standards Track [Page 2] RFC 2845 DNS TSIG May 2000 1.6 間接的キャッシュリゾルバとして機能するサーバ、通常は「フォワーダ」 として使用されるサーバは、事前に設定された「上位の」サーバと通信を行う 際に、トランザクションベースの認証を使用することがある。DNS秘密鍵を使用 した認証の他の用途や、秘密鍵を自動的に配布可能なシステムについては、 将来別の文書で提案される可能性がある。 1.7 新規割り当て番号 RRTYPE = TSIG (250) ERROR = 0..15 (DNS RCODE) ERROR = 16 (BADSIG) ERROR = 17 (BADKEY) ERROR = 18 (BADTIME) 1.8 本文書における「しなければならない(MUST)」、「要求される(REQUIRED)」、 「すべきである(SHOULD)」、「推奨される(RECOMMENDED)」、「してもよい(MAY)」 というキーワードは[RFC2119]に記述されているとおりに解釈するものとする。 2 - TSIG RRのフォーマット 2.1 TSIG RRタイプ 秘密鍵による認証を実現するために、ニーモニックがTSIG、タイプコードが250 の新しいRRタイプを使用する。TSIGはメタRRであり、キャッシュされてはなら ない。TSIG RRは、共有秘密鍵を持つDNSエンティティ間で認証のために使用さ れる。TSIG RRは特定のDNSトランザクションを扱うために動的に計算されるもの であり、通常の意味でのDNS RRとは異なるものである。 2.2 TSIGの計算 TSIG RRは1つのDNSリクエスト/応答と関連付けられるため、保管または再送信を 行うことに意味はない。したがって、TSIG RRは1つのDNSメッセージを認証する ために1度使用されたならば破棄される。本文書で規定される唯一のメッセージ ダイジェストアルゴリズムは「HMAC-MD5」([RFC1321]、[RFC2104]を参照)である。 ｢HMAC-MD5｣アルゴリズムは、相互接続性を実現するために必須のものである。 他のアルゴリズムについては後日規定することができる。新しいアルゴリズムの 名前と定義は、IANAに登録されなければならない。TSIGレコード内のマルチ オクテットな整数は全てネットワークバイトオーダで送信される ([RFC1035 2.3.2]参照)。 Vixie, et al. Standards Track [Page 3] RFC 2845 DNS TSIG May 2000 2.3 レコードのフォーマット NAME ドメイン名の構文で使用される鍵の名前。名前は2台のホスト名を反映する べきであり、またこの2台のホストがある特定の時刻に共有する可能性が ある鍵の集合の中で、特定の鍵を一意に識別すべきである。ホスト A.site.exampleとB.example.netが鍵を共有する場合、可能性のある鍵の 名前は、.A.site.example、.B.example.net、 .A.site.example.B.example.net等になる。相互に通信するホストの ペアの集合の中で、一つ以上の鍵が同時に使用可能であるべきである。 名前は通信するホスト間で意味がありさえすればよいが、上記のような 意味のあるニーモニック名が強く推奨される。 鍵の名前は、その名前が指し示す鍵のローカルインデックスとして使用 されることがあるので、グローバルに一意であることが推奨される。 そのような状況では、鍵は2台のホスト間で共有されるだけであり、実際 には名前は2台の間だけで意味を持ちさえすればよい。しかし、鍵の名前は ニーモニックとし、リゾルバのホスト名、サーバのホスト名を順に結合 したものにすることが推奨される。 TYPE TSIG (250: Transaction SIGnature) CLASS ANY TTL 0 RdLen (変数) RDATA フィールド名 データ タイプ 説明 ----------------------------------------------------------------- Algorithm Name domain-name ドメイン名の構文における アルゴリズムの名前 Time Signed u_int48_t 1-Jan-70 UTC以降の秒数 Fudge u_int16_t Time Signedで許可された エラーの秒数 MAC Size u_int16_t MACのオクテット数 MAC octet stream Algorithm Nameで定義される Original ID u_int16_t オリジナルのメッセージID Error u_int16_t TSIG処理を行うために拡張された RCODE Other Len u_int16_t Other Dataのデータ長をオクテット で表したもの Other Data octet stream Error == BADTIMEの場合を除き空 Vixie, et al. Standards Track [Page 4] RFC 2845 DNS TSIG May 2000 2.4 例 NAME HOST.EXAMPLE. TYPE TSIG CLASS ANY TTL 0 RdLen 適宜 RDATA フィールド名 内容 ------------------------------------- Algorithm Name SAMPLE-ALG.EXAMPLE. Time Signed 853804800 Fudge 300 MAC Size 適宜 MAC 適宜 Original ID 適宜 Error 0 (NOERROR) Other Len 0 Other Data 空 3 - プロトコルの処理 3.1 送信メッセージにTSIGを追加する効果 送信メッセージが一旦作成された後に、鍵付きメッセージダイジェスト処理が 実行される。得られたメッセージダイジェストは、付加情報部に追加される TSIGに格納される(これを反映するため、ARCOUNTがインクレメントされる)。 メッセージの切り詰め処理無しではTSIGレコードを追加できない場合、サーバは TSIGを含むことができるように応答を修正しなければならない。この応答は 問い合わせ部とTSIGレコードのみから構成され、TCビットがセットされ、 RCODE 0(NOERROR)となっているものである。クライアントは、この時点で ([RFC1035 4.2.2]の記述にしたがい)TCPを使用してリクエストをリトライ するべきである。 3.2 受信メッセージに対するTSIG処理 受信メッセージがTSIGレコードを含む場合、付加情報部の最後のレコードで なければならない。複数のTSIGレコードは許可されない。TSIGレコードが他の 場所にある場合、パケットは破棄されるため、RCODE 1 (FORMERR)を持つ応答が 返されなければならない。正しく配置されたTSIG RRを持つメッセージを受信 したら、直ちにTSIG RRは安全な場所にコピーされ、DNSメッセージから削除 され、DNSメッセージヘッダのARCOUNTがデクレメントされる。 Vixie, et al. Standards Track [Page 5] RFC 2845 DNS TSIG May 2000 この時点で鍵付きメッセージダイジェスト処理が実行される。受信側でアルゴ リズム名または鍵名が不明である場合、あるいはメッセージダイジェストが一致 しない場合にはDNSメッセージ全体が破棄されなければならない。メッセージが 照会である場合には、RCODE 9(NOTAUTH)でTSIG ERROR 17(BADKEY)または TSIG ERROR 16(BADSIG)を持つ応答を発信者に送り返さなければならない。 このメッセージに署名できる鍵がない場合、署名無しで送られなければならない (MACサイズ=0であり、MACが空)。運用スタッフに対して、セキュリティ事件の 可能性がある事象が現在起きつつあることを警告するために、システム運用 ログへのメッセージを生成するべきである。この種類のイベントのロギングが システムへのサービス不能攻撃への手段にならないことを保証するために 注意が払われるべきである。 3.3 TSIGの計算で使用される時間の値 ダイジェストされたデータは、リプレイ攻撃からの保護のために、2つのタイマ値 をTSIGヘッダに含む。この処理が行われない場合、攻撃者は「Time Signed」 フィールドと「Fudge」フィールドを更新して、新しいメッセージに見せかけた 古いメッセージを繰り返し使用することが可能となる。このデータは 「TSIGタイマ」と名づけられており、ダイジェストの計算をするために 「ワイヤフォーマット」で呼び出される。その順序は初めがTime Signedであり、 次がFudgeである。例えば: フィールド名 値 ワイヤフォーマット 意味 -------------------------------------------------------------------------- Time Signed 853804800 00 00 32 e4 07 00 1997年1月21日火曜日00:00:00 Fudge 300 01 2C 5分 3.4 TSIGの変数と範囲 TSIGレコードの内容を生成または検証する場合、ネットワークバイトオーダ またはワイヤフォーマットで適宜以下のデータがダイジェストされる。 3.4.1 DNS メッセージ ワイヤフォーマットによる完全なDNSメッセージ全体は、TSIG RRが付加情報部に 追加される前であり、TSIG RRを含めるためにDNSメッセージヘッダのARCOUNT フィールドの値がインクレメントされる前のものである。メッセージIDが オリジナルのメッセージIDと異なる場合、オリジナルメッセージIDはその メッセージIDに置き換えられる。このような状況は例えば動的更新の要求を 転送する際に発生する場合がある。 Vixie, et al. Standards Track [Page 6] RFC 2845 DNS TSIG May 2000 3.4.2 TSIG変数 ソース フィールド名 説明 ----------------------------------------------------------------------- TSIG RR NAME 正規のワイヤフォーマットによる鍵名 TSIG RR CLASS (現在の仕様では常に ANY) TSIG RR TTL (現在の仕様では常に 0) TSIG RDATA Algorithm Name 正規のワイヤフォーマットによる TSIG RDATA Time Signed ネットワークバイトオーダによる TSIG RDATA Fudge ネットワークバイトオーダによる TSIG RDATA Error ネットワークバイトオーダによる TSIG RDATA Other Len ネットワークバイトオーダによる TSIG RDATA Other Data 転送されたものと同一 RR RDLENとRDATA MAC Lengthは、MAC生成前に既知である保証がないため、 ハッシュには含まれない。 Original IDフィールドは、すでにDNSヘッダにおいてメッセージIDに置き換え られハッシュされているため、このセクションには含まれない。 ラベルタイプ毎に、明確にラベルを表現する手法を規定した「正規のワイヤ フォーマット」が定義されなければならない。ラベルタイプ00は[RFC2535]で 定義されており、ラベルタイプ01は[RFC2673]で定義されている。00および01 以外のラベルタイプの使用は、本仕様では定義されない。 3.4.3 リクエストMAC 応答に含まれるMACを生成する場合、リクエストMACがダイジェストに含まれて いなければならない。リクエストのMACはワイヤフォーマットでダイジェスト され、以下のフィールドを含む。 フィールド タイプ 説明 ------------------------------------------------------------- MAC Length u_int16_t ネットワークバイトオーダーによる MAC Data octet stream 転送されたものと同一 3.5 パディング ダイジェストされた構成要素は、フィールド間パディングのない連続的な オクテットストリームとしてハッシュ関数に送られる。 Vixie, et al. Standards Track [Page 7] RFC 2845 DNS TSIG May 2000 4 - プロトコルの詳細 4.1 リクエストに対するTSIG生成 クライアントはメッセージダイジェスト処理を実行し、TSIGレコードを 付加情報部に追加し、サーバにリクエストを転送する。クライアントは応答を 待つ間、リクエストから取得したメッセージダイジェストを保管しなければ ならない。リクエストのダイジェストの構成要素は以下のとおりである。 DNSメッセージ(リクエスト) TSIG変数(リクエスト) 古いネームサーバには空でない付加情報部を持つリクエストを受理しないものが あることであることに注意してもらいたい。クライアントは、TSIGをサポートし、 幾つかの秘密鍵をそのクライアントと共有していることがわかっているサーバに のみ署名付のトランザクションを試みるべきである。したがって、これは実際 には問題にはならない。 4.2 応答のTSIG サーバが署名付リクエストへの応答を生成すると、同じアルゴリズムと鍵を 使用してその応答に署名を行う。サーバは未署名のリクエストに対して署名付 応答を生成してはならない。ダイジェストの構成要素は以下のとおりである。 リクエストMAC DNSメッセージ(応答) TSIG変数(応答) 4.3 TSIGエラー返信時におけるTSIG サーバが鍵またはMACに関連するエラーを検出した場合、サーバは未署名 (MACサイズ＝0でMACが空)のエラーメッセージを返信するべきである。TSIGの 有効期間に関するエラーが検出された場合、サーバは署名付エラーメッセージを 返信すべきである。ダイジェストの構成要素は以下のとおりである。 リクエストMAC (リクエストMACが有効である場合) DNSメッセージ (応答) TSIG変数 (応答) リクエストがこのダイジェストに含まれない場合がある理由は、クライアントに よるエラーの検証を可能にするためである。エラーがTSIGエラーでない場合に は[4.2]で規定されているとおりの応答が生成されなければならない。 Vixie, et al. Standards Track [Page 8] RFC 2845 DNS TSIG May 2000 4.4 TCP接続時のTSIG DNSのTCPセッションは、複数のDNSエンベロープを含むことができる。これは 例えばゾーン転送で普通に使われるものである。そのような接続において、 TSIGの使用はコネクションをハイジャックから保護することを可能とし、 データの完全性を提供する。TSIGは最初と最後のDNSエンベロープに含まれ なければならない。任意で中間のエンベロープにTSIGを配置することもできる。 全エンベロープにTSIGを含めることはコスト的に高くつくが、少なくとも エンベロープ100個毎にTSIGが配置されなければならない。最初のエンベロープ は標準的な応答として処理され、続くメッセージは以下のダイジェストの構成 要素を持つ。 前のダイジェスト (実行中) DNSメッセージ (最後のTSIG以降の未署名メッセージ全て) TSIGタイマ (現在のメッセージ) これにより、セッションが変更されたときにクライアントは素早くそれを検出 することができるようになる。この時点で接続をクローズし、リトライを行う ことができる。クライアントのTSIG検証が失敗した場合、クライアントは接続を クローズしなければならない。クライアントがTSIGレコードを(先に規定した とおりの)充分な頻度で受信できない場合、接続はハイジャックされたと想定し、 コネクションをクローズすべきである。クライアントは、この接続クローズ 作業を他の(種類の)転送が中断された場合と同じ方法で行うべきである(ただし 正確な動作は規定されていない)。 4.5 サーバにおけるTSIGのチェック メッセージ受信後直ちにサーバはTSIG RRが存在するかどうかをチェックする。 TSIG RRが存在する場合、サーバは応答にTSIG RRを含めて返すことが求め られる。サーバは以下のチェックをKEYチェック, TIMEチェック, MACチェックの 順番で実行しなければならない。 4.5.1 鍵(KEY)チェックとエラー処理 非転送サーバがクライアントによって使用される鍵を理解しない場合、サーバは RCODE 9(NOTAUTH)とTSIG ERROR 17(BADKEY)を含むエラー応答を生成しなければ ならない。この応答は[4.3]で規定されるとおり未署名でなければならない。 サーバはエラーを記録するべきである。 4.5.2 時間(TIME)チェックとエラー処理 サーバ時間がリクエストで指定される時間間隔(これはTime SignedとFudgeの差 になる)を越える場合、サーバはRCODE 9(NOTAUTH)とTSIG ERROR 18(BADTIME)を 含むエラー応答を生成しなければならない。また、サーバは鍵によって生成 されたメッセージに含まれる最新のTime Signed値をキャッシュすべきである。 そしてキャッシュ後に受信したメッセージがキャッシュした値よりも以前の Time Signed値を持つ場合には、BADTIMEを返すべきである。BADTIMEエラーを 示す応答は、リクエストと同じ鍵によって署名されなければならない。 Vixie, et al. Standards Track [Page 9] RFC 2845 DNS TSIG May 2000 クライアントの現在時刻はTime Signedフィールドに、サーバの現在時刻 (u_unt48_t)はOther Dataフィールドに含まれなければならず、Other Len フィールドは6でなければならない。これは、BADTIMEエラーを含むメッセージの 検証を行う際に、他のBADTIMEエラーによる失敗をすることなく検証ができる ようにするためのものである。署名されるデータは[4.3]において規定される。 サーバはエラーを記録するべきである。 4.5.3 MACチェックとエラー処理 TSIGの検証に失敗した場合、サーバは[4.3]で規定されるとおり、RCODE 9 (NOTAUTH)とTSIG ERROR 16(BADSIG)を含むエラー応答を生成しなければなら ない。この応答は[4.3]で規定されるように未署名でなければならない。 サーバはエラーを記録するべきである。 4.6 クライアントによる応答の処理 クライアントがサーバから応答を受信し、TSIGを確認する場合、はじめに TSIG RRが応答に含まれるかどうかをチェックする。TSIG RRが存在しなければ、 応答はフォーマットエラーとして扱われ、破棄される。次にクライアントは TSIGを展開し、ARCOUNTを調整し、サーバと同じ方法で署名付のダイジェストを 計算する。TSIGが有効でない場合、RCODEが9(NOTAUTH)でない限り、応答は破棄 されなければならない。RCODE 9である場合、[4.3]で規定されているとおり、 クライアントは応答がTSIGエラー応答であるかのように検証を試みるべきで ある。未署名のTSIGレコードや検証に失敗するTSIGレコードを含むメッセージは 受理可能な応答と考えるべきではない。クライアントはエラーを記録し、 リクエストがタイムアウトするまで署名付の応答を待つべきである。 4.6.1 鍵(KEY)エラーの処理 応答のRCODEが9(NOTAUTH)であり、応答のTSIGが有効であり、TSIGの鍵が リクエストで使用されたものと異なる場合、KEYエラーとなる。クライアントは サーバによって指定された鍵を使用してリトライをしてもよい。サーバは リクエストに署名されたものと異なる鍵で応答に署名してはならないため、 このようなことは決して起こらない。 4.6.2 時間(TIME)エラーの処理 応答のRCODEが9(NOTAUTH)でTSIG ERRORが18(BADTIME)であるか、現在時刻が TSIGレコードで指定された範囲にあたらない場合、TIMEエラーとなる。 これはクライアントとサーバの時計が同期していないことを示すものである。 この場合、クライアントはこのイベントを記録すべきである。DNSリゾルバは BADTIMEエラーに基づいてクライアントの時計を調整してはならない。 しかしOther Dataフィールドにあるサーバの時刻は記録されるべきである。 Vixie, et al. Standards Track [Page 10] RFC 2845 DNS TSIG May 2000 4.6.3 MACエラーの処理 応答のRCODEが9(NOTAUTH)でTSIG ERRORが16(BADSIG)である場合、MACエラー である。クライアントは新しいリクエストIDでリクエストのリトライをしても よいが、異なる共有鍵があるならば、その使用を試みるほうが望ましい。 クライアントは各鍵について、幾つのMACエラーが発生したかの追跡記録を 保存するべきである。クライアントはこのイベントを記録するべきである。 4.7 転送サーバに関する特別な考察 DNSメッセージの転送サーバとして機能するサーバは、TSIGレコードが存在 するかをチェックするべきである。TSIGの名前がサーバと生成者が共有する 秘密鍵の名前と異なる場合、サーバはTSIGを含めてメッセージを変更せずに 転送しなければならない。TSIGの名前がサーバと生成者が共有する鍵の名前と 同じである場合、サーバはTSIGを処理しなければならない。TSIGが全ての チェックを通過した場合、転送サーバはそれが可能であるならばサーバ自身の TSIGを含めた上で、送信先もしくは次の転送サーバに転送しなければならない。 送信先までに何らトランザクションセキュリティを利用することができず、 応答のADフラグ([RFC2535]参照)が立てられている場合、転送サーバは応答に TSIGを付加する前にADフラグをクリアしなければならない。 5 - 共有秘密鍵 5.1 秘密鍵は非常に機密性の高い情報であり、秘密鍵を保管する全てのホスト において、保護するために利用できるあらゆる措置が取られるべきである。 一般に、このようなホストは物理的に保護される必要がある。もしマルチユーザ マシンであるならば、非特権ユーザが鍵処理素材にアクセスできないように 細心の注意が払われるべきである。リゾルバはしばしば非特権で動作する。 これはホストの全ユーザがリゾルバに使用される設定データは何でも閲覧 できることを意味する。 5.2 ネームサーバは通常特権で動作する。これは、その設定データは動作 ホストの全ユーザに閲覧できる必要が無いことを意味する。このため、 トランザクションベースの認証を実装するホストはおそらく「スタブリゾルバ」、 ローカルキャッシュおよび転送ネームサーバとして設定されるべきである。 これは[RFC2136]に関する特別な問題をもたらす。そうでなければゾーンの 権威あるネームサーバとのみ通信するためのクライアントに依存する。 5.3 強い乱数共有秘密鍵の使用はTSIGのセキュリティに不可欠である。 この問題についての議論は[RFC1750]を参照のこと。秘密鍵は少なくとも 署名付メッセージダイジェストと同じくらいの鍵長であるべきである。 すなわち、HMAC-MD5ならば16バイト、HMAC-SHA1ならば20バイトである。 Vixie, et al. Standards Track [Page 11] RFC 2845 DNS TSIG May 2000 6 - セキュリティに関する考察 6.1 ここで規定されるアプローチは、[RFC2535]で規定される署名よりも計算 コストが非常に少ないものである。共有秘密鍵が破られない限り、ローカルな ネームサーバからユーザリゾルバまでの最終ホップのための強い認証が提供 される。 6.2 秘密鍵は定期的に変更されるべきである。クライアントホストが被害を 受けた場合、サーバはそのクライアントに知られている全ての秘密鍵の使用を 中止するべきである。可能であれば、秘密鍵は全て暗号化された形態で保管 されるべきである。秘密鍵はどんなネットワーク上も平文のままでは決して 転送されるべきではない。本文書は秘密鍵を配布する方法に関する問題は 扱っていない。秘密鍵は決して2つより多くのエンティティによって共有される べきではない。 6.3 このメカニズムはソースデータを認証せず、幾つかの秘密鍵を共有する 2つのパーティ間のデータ転送のみが認証される。オリジナルのソースデータは 被害を受けたゾーンマスタから送られてくるかもしれないし、あるいは本物の ゾーンマスタから幾つかの「キャッシング転送サーバ」を通過する間に汚染 されるかもしれない。しかし、サーバが正確に全ての[RFC2535]セキュリティ チェックを実行すれば、クライアントはセキュリティチェックされたデータ のみを利用できるようになる。 6.4 大きすぎるFudge値は、サーバをリプレイ攻撃にさらすかもしれない。 小さすぎるFudge値は、マシンの時間が同期されていない場合や予期しない ネットワークの遅延が生じた場合に処理の失敗を引き起こすことがある。 多くの場合に推奨される値は300秒である。 7 - IANAに関する考察 IANAはセクション2.3で定義されている「Algorithm Names」として使用される アルゴリズム名のレジストリを作成し、保守することが求められる。初期値は 「HMAC-MD5.SIG-ALG.REG.INT」であるべきである。アルゴリズム名はドメイン名 構文でエンコードされた文字列である。異なるアルゴリズムの名前がDNS名 として比較される際に一意でなければならないこと以外の構造は必要とされない。 すなわち、比較は大文字小文字の区別はされない。上に記した初期値は ドメイン名ではないことに注意してもらいたい。したがって、DNSに登録された 名前である必要はないということである。新しいアルゴリズムは、RFC2434で 定義されるIETF Consensus(訳注: この場合は新しいアルゴリズムがIESGに 承認されたRFCになること)ポリシによって割り当てられる。アルゴリズム名 HMAC-MD5.SIG-ALG.REG.INTは歴史的理由により、FQDNのようになっている。 将来のアルゴリズム名は単純な(つまり単一構成要素の)名前になることが期待 される Vixie, et al. Standards Track [Page 12] RFC 2845 DNS TSIG May 2000 IANAはセクション2.3で定義されている「Error」値のために使用される 「TSIG Error値」のレジストリを作成し、保守することが求められる。 初期値はセクション1.7で定義されているものになるべきである。TSIGの Errorフィールドで使用される新しいエラーコードは、RFC2434で定義される IETF Consensus(訳注: IESGに承認されたRFCとして文書化されること)ポリシに よって割り当てられる。 8 - 参考文献 [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 1034, November 1987. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1995. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5: Keyed-MD5 for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic Updates in the Domain Name System", RFC 2136, April 1997. [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999. Vixie, et al. Standards Track [Page 13] RFC 2845 DNS TSIG May 2000 9 - 著者の連絡先 Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 Phone: +1 650 779 7001 EMail: vixie@isc.org Olafur Gudmundsson NAI Labs 3060 Washington Road, Route 97 Glenwood, MD 21738 Phone: +1 443 259 2389 EMail: ogud@tislabs.com Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA Phone: +1 508 261 5434 EMail: dee3@torque.pothole.com Brian Wellington Nominum, Inc. 950 Charter Street Redwood City, CA 94063 Phone: +1 650 779 6022 EMail: Brian.Wellington@nominum.com Vixie, et al. Standards Track [Page 14] RFC 2845 DNS TSIG May 2000 10 著作権表示の全文 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によって提供されて いる。 Vixie, et al. Standards Track [Page 15] RFC2845-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/