ネットワークワーキンググループ D. Eastlake, 3rd Request for Comments: 2930 Motorola 分類: 標準トラック 2000年9月 DNSにおける秘密鍵の確立 (TKEY RR) 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準トラック プロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については「Internet Official Protocol Standards」(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要旨 [RFC2845]は、共有秘密鍵を使用することにより、トランザクション署名 (TSIG: Transaction Signature)リソースレコード(RR)を通してDomain Name System(DNS)の照会と応答を認証する手段を提供する。しかし、RFC2845は そのような秘密鍵の設定について、手動による交換以外のメカニズムを提供 していない。本文書はDNSリゾルバとサーバ間で共有秘密鍵を確立するために、 多くの異なるモードで使用可能なトランザクション鍵(TKEY: Transaction Key) RRについて記述する。 謝辞 以下の方(アルファベット順)のコメントとアイデアが本文書に取り入れられて おり、深く感謝するものである。 Olafur Gudmundsson (TIS) Stuart Kwan (Microsoft) Ed Lewis (TIS) Erik Nordmark (SUN) Brian Wellington (Nominum) Eastlake Standards Track [Page 1] RFC 2930 The DNS TKEY RR September 2000 目次 1. はじめに......................................................2 1.1 内容の概観..................................................3 2. TKEYリソースレコード..........................................4 2.1 Nameフィールド..............................................4 2.2 TTLフィールド...............................................5 2.3 Algorithmフィールド.........................................5 2.4 InceptionフィールドとExpirationフィールド...................5 2.5 Modeフィールド..............................................5 2.6 Errorフィールド.............................................6 2.7 Key SizeフィールドとDataフィールド..........................6 2.8 Other SizeフィールドとOther Dataフィールド..................6 3. TKEYに関する一般的な考察......................................7 4. リゾルバからの照会を介した鍵交換方式..........................8 4.1 Diffie-Hellman鍵交換方式による鍵処理のための照会............8 4.2 TKEY削除のための照会........................................9 4.3 GSS-API確立のための照会....................................10 4.4 サーバ割り当て方式による鍵処理のための照会.................10 4.5 リゾルバ割り当て方式による鍵処理のための照会...............11 5. サーバによるTKEYの自動的包含処理.............................12 5.1 サーバによる自動的鍵削除処理...............................12 6. 暗号化の方式.................................................12 7. IANAに関する考察.............................................13 8. セキュリティに関する考察.....................................13 参考文献........................................................14 著者の連絡先....................................................15 著作権表示の全文................................................16 1. はじめに Domain Name System (DNS)は階層構造を持つ、分散型で可用性の高いデータ ベースであり、ドメイン名とアドレスの双方向マッピング、電子メールの ルーティング、その他の情報提供のために使用される[RFC1034, 1035]。 DNSは公開鍵によるセキュリティ機能と動的更新機能を提供するために拡張が なされてきている[RFC2535, RFC2136]。本文書は、これらのRFCを熟知して いることを前提とする。 [RFC2845]は、共有秘密鍵を使用することにより、TSIGリソースレコード(RR)を 通してDNSメッセージを効率的に認証する手段を提供するが、そのような秘密鍵 の設定について、手動による交換以外のメカニズムを提供していない。本文書は DNSリゾルバとサーバ間でそのような共有秘密鍵を確立、削除するために、 多くの異なるモードで使用可能なTKEY RRを規定する。 Eastlake Standards Track [Page 2] RFC 2930 The DNS TKEY RR September 2000 TKEYによって確立された鍵処理素材とそれを使用するTSIGは、DNSサーバまたは リゾルバと関連付けられることに注意してもらいたい。これらはゾーンには 関連付けられない。これらは照会と応答を認証するために使用される場合が あるが、ゾーンベースのDNSデータの生成元もしくは拒否の認証[RFC2535]は 提供しない。 あるモードのTKEYは、一部の国への輸出入に影響する可能性がある暗号化を 実行する。本文書で規定される中で、この影響を受けるモードは、サーバ 割り当てモードとリゾルバ割り当てモードである。 本文書における「しなければならない(MUST)」、「してはならない(MUST NOT)」、 「要求される(REQUIRED)」、「するものとする(SHALL)」、「しないものとする (SHALL NOT)」、「すべきである(SHOULD)」、「すべきではない(SHOULD NOT)」、 「推奨される(RECOMMENDED)」、「してもよい(MAY)」、「任意である(OPTIONAL)」 というキーワードは、RFC 2119に記述される通りに解釈するものとする。 ここで、あらゆる場合において「リゾルバ」という語は、フルゾーン転送照会、 差分ゾーン転送照会、再帰的な照会の転送等のサーバ機能の一部を含む。 1.1 内容の概観 この後のセクション2では、TKEY RRを規定し、その構成フィールドの説明と 考察を提供する。 セクション3では、TKEYの運用に関する基本原則を説明する。 セクション4では、タイプTKEYのRRに対する、Query OPCODE(訳注: OPCODE=0の こと)を持つDNSリクエストを通じた鍵の合意と削除について説明する。 この方法は、現在定義されている全てのTKEYモードに適用できる。ただし、 幾つかの場合において直観的に「照会」と呼ばれるものではないことがある。 セクション5では、現在鍵削除のためだけに使用されている、サーバが応答に TKEY RRを自動的に包含する処理について説明する。 セクション6では秘密鍵情報を転送するための暗号化方式について説明する。 本文書では、この暗号化方式はサーバ割り当てモードとリゾルバ割り当てモード のためだけに使用される。 セクション7では、TKEYモードの割り当てにおけるIANAに関する考察を扱う。 最後に、セクション8で、必要なセキュリティに関する考察を提供する。 Eastlake Standards Track [Page 3] RFC 2930 The DNS TKEY RR September 2000 2. TKEYリソース レコード TKEYリソース レコード(RR)は、以下のような構造を持つ。RRタイプコードは 249である。 フィールド タイプ 説明 ----- ---- ------- NAME domain 下の説明を参照 TTYPE u_int16_t TKEY = 249 CLASS u_int16_t 無視される。255 (ANY)であるべきである TTL u_int32_t 無視される。0であるべきである RDLEN u_int16_t RDATAのサイズ RDATA: Algorithm: domain Inception: u_int32_t Expiration: u_int32_t Mode: u_int16_t Error: u_int16_t Key Size: u_int16_t Key Data: octet-stream Other Size: u_int16_t Other Data: octet-stream 本仕様では未定義 2.1 Nameフィールド Nameフィールドは、鍵の名前付けに関するものである。その意味は、後の セクションで説明するように、モードと状況にとって幾分異なる。 全てのDNSサーバまたはリゾルバでは、全ての鍵名のために、1オクテット長 文字列のみの鍵処理素材が設定される。サーバにおいて、既に存在する名前に 対して他の鍵処理素材のセットを確立しようとする試みに対してはBADNAME エラーが返される。 ルート以外の名前が照会に存在するTKEYでは、TKEY RR名はリゾルバの中で ローカルに一意であり、ワイヤエンコーディングで128オクテット長より短く、 鍵と鍵合意セッションのどちらか、あるいは両方を識別する助けとなるために、 リゾルバにとって意味のあるドメイン名であるべきである。照会に対する 応答にTKEYが存在する場合、TKEY RR名はグローバルに一意な、サーバに 割り当てられたドメイン名になるべきである。 妥当な鍵の名前付け方法は次のようになる。 ルートを所有者名(owner name)とした照会の結果として鍵が生成された場合、 サーバは擬似乱数[RFC1750]ラベルにサーバのドメイン名を付加することに より、鍵名となるべきグローバルに一意なドメイン名を作成するべきである。 例えば、89n3mDgX072pp.server1.example.com. のようになる。 Eastlake Standards Track [Page 4] RFC 2930 The DNS TKEY RR September 2000 新しい擬似乱数の生成を毎回行うことによって、著しい計算負荷ないしは 乱数の均一性の消失につながる場合には、DNSサーバ起動時に生成される 固定擬似乱数名にシリアル番号プレフィックスを追加し、 1001.89n3mDgX072pp.server1.example.com.のようにすることができる。 ルート以外の名前、例えば789.resolver.example.netへの照会への結果と して鍵が生成される場合、その名前とサーバ名を連結した名前を鍵名として 使用する。例えば、789.resolver.example.net.server1.example.com. の ようになる。 2.2 TTLフィールド TTLフィールドは、TKEY RRでは意味がない。古いDNSの実装がTKEY RRを キャッシュしないように、常に0であるべきである。 2.3 Algorithmフィールド アルゴリズム名は、[RFC2845]と同様の意味を持つドメイン名形式である。 アルゴリズムは、TKEY RRの使用を合意した秘密鍵の鍵処理素材が、アルゴ リズム固有の鍵を導出するために、実際にどのように使用されるのかを決定 する。 2.4 Inception(有効期間開始)フィールドとExpiration(有効期間終了)フィールド 有効期間開始時刻と有効時間終了時刻は、1970年1月1日(GMT)の始まりから 経過したうるう秒を無視した秒数を循環計算[RFC1982]し、2の32乗を法とした 値として扱われる。これらのフィールドが意味を持つDNSリゾルバとDNSサーバ 間のメッセージにおいて、これらのフィールドは求められた鍵処理素材に対する リクエストされた有効期間か、または提供された鍵処理素材の有効期間を指定 するかのどちらかである。 TKEY RRの有効期間開始時刻と終了時刻について異なる解釈が生じることを 避けるため、これらの情報を交換するリゾルバとサーバは、時刻について同じ 見解を持たなければならない。これを行う一つの方法としてNTPプロトコル [RFC2030]が挙げられるが、この方法またはこの目的で使用される他の時刻同期 処理は安全に行われなければならない。 2.5 Modeフィールド Modeフィールドは、鍵合意もしくはTKEY DNSメッセージの目的に関する一般的な 枠組みを指定する。本仕様をサポートするサーバとリゾルバは、照会に対する Diffie-Hellman鍵合意モードと鍵削除モードを実装しなければならない。 他のモードは全て任意である。TKEYをサポートするサーバは、サポートして いないモードのTKEYリクエストを受信した場合、BADMODEエラーを返す。 Modeオクテットの以下の値は、定義済み、利用可能、または予約済みである。 Eastlake Standards Track [Page 5] RFC 2930 The DNS TKEY RR September 2000 値 説明 ----- ----------- 0 - 予約済み。セクション7参照 1 サーバ割り当て 2 Diffie-Hellman鍵交換方式 3 GSS-APIネゴシエーション 4 リゾルバ割り当て 5 鍵削除 6-65534 - 利用可能。セクション7参照 65535 - 予約済み。セクション7参照 2.6 Errorフィールド エラーコードフィールドは拡張RCODEである。以下の値が定義される。 値 説明 ----- ----------- 0 - エラーなし 1-15 非拡張RCODE 16 BADSIG (TSIG) 17 BADKEY (TSIG) 18 BADTIME (TSIG) 19 BADMODE 20 BADNAME 21 BADALG TKEYへの照会に対する応答において、TKEYのErrorフィールドが0以外である 場合、DNSヘッダのRCODEフィールドはエラーが無いことを示す。しかし、 TKEYが応答に自動的に包含される場合、TKEY RRとDNSヘッダのErrorフィールド は、互いに関連のない0以外のエラーコードを持つことがある。 2.7 Key SizeフィールドとDataフィールド 鍵のデータサイズフィールドは、ネットワークバイトオーダで記述された、 鍵交換データフィールドのサイズをオクテット単位で指定する符号なし (unsigned)16ビットの整数である。このデータの意味はモードによって異なる。 2.8 Other SizeフィールドとOther Dataフィールド Other SizeフィールドとOther Dataフィールドは本仕様では使用されないが、 将来の拡張で使用されるかもしれない。RDLENフィールドはOther Dataの 終わりまでのRDATAセクションのデータ長と等しくなければならない。 そうでない場合はRRは改竄されたとみなされ拒否される。 Eastlake Standards Track [Page 6] RFC 2930 The DNS TKEY RR September 2000 3. TKEYに関する一般的な考察 TKEYは、DNSに保存またはキャッシュされないメタRRであり、ゾーンファイル にも現れない。TKEYは、DNSリゾルバとサーバ間における共有秘密鍵情報の確立 と削除のために様々なモードをサポートする。このような共有鍵の確立には、 両端で状態が維持されていることが求められる。また、状態を維持するための リソース確保には双方の合意を必要とする場合がある。そのような状態を提供 する意思がない場合、サーバはTKEYを使用するための試行に対して、NOTIMP もしくはREFUSEDなどのエラーを返さなければならない。リゾルバは自由に受信 したTKEY RRを無視することができる。 TKEYを使用して生成された共有秘密鍵の鍵処理素材は、平文のオクテット シーケンスである。どのようなTSIGアルゴリズムにおいても、TKEYを通して 交換されたこの共有秘密鍵の鍵処理素材が実際に使用される方法はアルゴリズム に依存するものであり、アルゴリズムに関連して定義される。例えば、 TKEYによって合意された共有秘密鍵の鍵処理素材が、HMAC-MD5アルゴリズム または他のHMACアルゴリズムでどのように使用されるかについては、[RFC2104] を参照してもらいたい。 DNSの照会、応答に複数のTKEY RRがあってはならない。 鍵処理データ、エラーコードその他の完全性を保護するために、GSS-APIを除き TKEYの応答は常にDNSトランザクション認証を持たなければならない。 この認証では、事前に確立された共有秘密鍵(TSIG)または公開鍵(SIG(0) [RFC2931])を使用しなければならず、検証される応答自体が提供する鍵を 使用してはならない。 TKEYへの照会は、GSS-APIとある状況下のサーバ割り当てモードを除いた、 全てのモードで認証されなければならない。特にサーバに割り当てられた鍵 への照会が、ある特権、例えば更新権限のようなものを明示するものである 場合、照会は偽造を避けるために認証されなければならない。しかし、鍵が トランザクションセキュリティのために使用されている場合、偽造は最悪の 場合サービス不能攻撃に結びつく。照会の認証は、利用可能であるならば 確立済の秘密鍵(TSIG)の証明書(authenticator)を使用するべきである。 そうでなければ、公開鍵(SIG(0))の署名が使用されなければならない。 照会自身が提供する鍵を使用してはならない。 要求されるTKEY認証がない場合、NOTAUTHエラーが返されなければならない。 リプレイ攻撃を回避するために、2の32乗秒(約136年)オーダ、またはその倍数 のオーダでリプレイが行われても、TKEYの応答または照会が有効にならないこと が必要である。これを実現するために、TKEYメッセージを認証する全てのTSIG RR またはSIG(0) RRで使用される鍵処理素材は、2の31乗-1秒(約68年)よりも長い 存続期間を持ってはならない。こうすることにより、リプレイを試行しても、 認証を行うTSIG RRまたはSIG(0) RRは鍵の有効期間が終了しており正当性が 検証されないため、リプレイは失敗する。 Eastlake Standards Track [Page 7] RFC 2930 The DNS TKEY RR September 2000 4. リゾルバからの照会を介した鍵交換方式 リゾルバとサーバがTSIGで使用する共有秘密鍵の鍵処理素材について合意 する1つの方法として、構文的にタイプTKEYへのDNS照会になっている、 リゾルバからのDNSリクエストを介するものが挙げられる。そのような照会 では、使用するモードを明示するために、付加情報部にTKEY RRが付随しな ければならず、また必要ならば他の情報が付随しなければならない。 タイプTKEYへの照会には再帰フラグが立てられるべきではないため、サーバは 受信したTKEYへの照会のヘッダに含まれる再帰ビットを無視してもよい。 4.1 Diffie-Hellman鍵交換方式による鍵処理のための照会 Diffie-Hellman (DH) 鍵交換方式は、二者が交換するメッセージで一切の 秘密を必要とせずに、何らかの共有秘密情報を導き出すことができる手段で ある[Schneier]。DNSにおけるDH公開鍵の保管[RFC2539]のために準備が行わ れている。 リゾルバは、タイプがTKEYであり、付加情報部の中にDiffie-Hellmanモードを 指定するTKEY RRと、リゾルバのDiffie-Hellman鍵を指定するKEY RRを持つ照会 を送信する。TKEY RRのAlgorithmフィールドには、リゾルバが使用を予定する 認証アルゴリズムが設定される。TKEYで提供される「鍵データ」は、同じDH鍵の ペアに対して常に同じ鍵処理素材が導出されることを避けるための、ランダムな [RFC1750]Nonce(訳注: 鍵の生成に使用する乱数)として使用される。 サーバの応答は、Diffie-HellmanモードのTKEYを回答部に含む。このTKEYで提供 される「鍵データ」は、同じDH鍵のペアに対して常に同じ鍵処理素材が導出 されることを避けるため、追加的なNonceとして使用される。TKEYのError フィールドが0以外である場合、照会は所定の理由により失敗している。 照会がDH KEYを含んでいなかった場合には、FORMERRが理由として与えられ、 照会が互換性のないDH KEYを含んでいた場合はBADKEYが理由として与えられる。 TKEYのErrorフィールドが0である場合、Diffie-HellmanのKEY RRを与えられた リゾルバは、それを付加情報部内で反復するべきであり、さらにサーバの Diffie-HellmanのKEY RRは応答の回答部に提示されるべきである。両者は共有 する同じ秘密の値を、使用するDiffie-Hellman (DH) 鍵のペアとTKEY RR内の データから計算することができる[Schneier]。(提供されるこれらのDH鍵は、 同じGeneratorとModulusを使用する)。TKEY RRのデータは以下のようにDHの 結果と混合される。 Eastlake Standards Track [Page 8] RFC 2930 The DNS TKEY RR September 2000 鍵処理素材 = XOR ( DHの値, MD5 ( 照会データ | DHの値) | MD5 ( サーバデータ | DHの値) ) ここで、XORは排他的論理和演算であり、「|」はバイトストリームの連結 である。XORの2つの被演算数のうち短いものは、左のバイト方向に端を揃え られ、もう一方の被演算数の長さにあうように0値で埋められたバイトが付け 加えられる。「DHの値」は、KEY RRから導き出されたDiffie-Hellmanの値 である。照会データとサーバデータは、TKEY RRのデータフィールドに入れ られて送信される値である。これら「照会データ」と「サーバデータ」の Nonceは、DHの値を末尾に追加され、MD5によってダイジェストを生成され、 その結果が連結され、DHの値との排他的論理和演算がなされる。 照会のTKEY RRに含まれる有効期間開始時刻と終了時刻は、鍵処理素材のために リクエストされたものである。応答のTKEY RRに含まれる有効期間開始時刻と 終了時刻は、サーバが鍵処理素材が有効であると見なす最長の期間である。 サーバは提示した期間の満了前に鍵の有効期限を終了してもよい。つまり、 これは保証ではない。 4.2 TKEY削除のための照会 TKEYを介して確立された鍵はソフトステート(訳注: 定期的な更新作業を必要と するということ)として扱われる。DNSトランザクションはリゾルバによって 開始されるため、後に他の鍵交換方式が必要になればそれを経なければならなく なるが、リゾルバは単に鍵を渡すだけで済ませることができる。同様に、 サーバは鍵を破棄することができるが、破棄した鍵を使用するTSIGを持った 照会を受理した際にはエラーという結果につながる。 リクエストにおける、有効期間の過ぎた鍵による信任の試行を回避するために、 サーバはリゾルバから削除すべき鍵名を持つTKEY RRに対する認証済削除 リクエストを受信したときには、その鍵を「破棄」する鍵削除(の機構)を 実装しなければならない。サーバはその名前を持つ鍵のレコードを持たない 場合、BADNAMEを返す。 鍵削除をするためのTKEYへの照会は認証されなければならない。 この認証は削除される鍵を使用するTSIG RRであってもよい。 照会側で割り当てられたDiffie-Hellman型の鍵に対しては、サーバはその鍵に 関連する全てのアクティブな状態を正確に「破棄」しなければならない。 サーバに割り当てられた鍵に対しては、サーバは単にこの鍵はもうクライアント には保持されていないとマークするだけでもよく、またその鍵を将来サーバ 割り当ての鍵処理素材への照会の応答として再度送信してもよい。 Eastlake Standards Track [Page 9] RFC 2930 The DNS TKEY RR September 2000 4.3 GSS-API確立のための照会 このモードは、完全な説明を行うために準備中の別の文書で説明される。 基本的に、リゾルバとサーバはGSS-APIモードを付加情報部において指定し、 GSS-APIトークンをTKEY RRのKey Data部で指定するTKEYへの照会、応答を 交換できる。 転送中のGSS-APIトークンデータの一部を暗号化する問題は全て、GSS-API レベルで処理される。更に、GSS-APIレベルは独自に認証を提供しているので、 このモードでのTKEYへの照会と応答は、TSIG RRもしくはSIG(0) RR[RFC2931] によって認証されてもよいが、そうする必要はない。 GSS-APIモードでは、TKEY RRに含まれる有効期間開始時刻と終了時刻は無視 される。 4.4 サーバ割り当て方式による鍵処理のための照会 任意により、サーバはリゾルバの鍵処理を割り当てることができる。これは リゾルバの公開鍵によって暗号化された状態でリゾルバに送信される。 暗号化法の説明については、セクション6を参照してもらいたい。 リゾルバは「サーバ割り当て」モードを指定するTKEY RRと、応答を暗号化 するために使用されるリゾルバのKEY RRが、両方とも付加情報部に付随した TKEYへの照会を送信する。TKEYのAlgorithmフィールドには、リゾルバが使用 を予定する認証アルゴリズムが設定される。リゾルバによる照会のTKEY RR内で 提供される全ての「Key Data」は、使用される鍵処理素材を導出するために、 サーバに生成された乱数[RFC1750]と強力に混合されることが推奨される。照会 の中に現れるKEY RRにSIG(KEY) RRが付随する必要はない。照会がTSIG RR [RFC2845]またはSIG(0)によってリゾルバに認証されていて、その認証が検証 されたならば、その照会で提供されるSIG(KEY)は全て無視されるべきである。 そのような照会に含まれるKEY RRはリゾルバに対応する名前を持つべきで あるが、必須であることは、それがリゾルバが対応する秘密鍵を持つ公開鍵 であり、したがってリゾルバが応答データを復号化できるということだけで ある。 サーバの応答は、サーバ割り当てモードのTKEY RRを回答部に含み、照会で 提供されたKEY RRを付加情報部に反復する。 応答において、TKEYのErrorフィールドが0である場合、応答のTKEY RRの 鍵データ部はサーバに割り当てられた鍵処理データになるものであり、 リゾルバに提供されたKEY RRに含まれる公開鍵によって暗号化されている。 この場合、回答部のTKEY RRの対象ドメイン名は、サーバに割り当てられた 鍵の名前になる。 Eastlake Standards Track [Page 10] RFC 2930 The DNS TKEY RR September 2000 応答におけるTKEYのErrorフィールドが0以外である場合、照会は所定の理由 により失敗している。照会が暗号鍵を指定していなかった場合、FORMERRが 理由として与えられる。 照会のTKEY RRに含まれる有効期間開始時刻と終了時刻は、鍵処理素材で必要と される。応答のTKEY RRに含まれる有効期間開始時刻と終了時刻は、サーバが 鍵処理素材が有効であると見なす最長の期間である。サーバは提示した期間の 満了前に鍵の有効期限を終了してもよい。つまり、これは保証ではない。 TSIGまたはSIG(0)を使用する方法か、SIG(KEY)を使用してリゾルバのKEYに 署名する方法によってその照会の認証を行うことにより、リゾルバのKEY RRは 認証されなければならない。そうでない場合、攻撃者は彼らが知っている 秘密鍵に対応するリゾルバのKEYを偽造することができ、それによって攻撃者は 有効な共有秘密鍵をサーバから入手することが可能になる可能性がある。 4.5 リゾルバ割り当て方式による鍵処理のための照会 任意により、サーバはリゾルバに割り当てられた鍵を受理することができる。 鍵処理素材は、セクション6で説明されるように、転送時の保護のためにサーバの 鍵によって暗号化されなければならない。 リゾルバは、暗号化された鍵処理素材を規定するTKEY RRと、データを暗号化 する際に使用されるサーバの公開鍵を指定するKEY RRが両方とも付加情報部に 含まれるTKEYへの照会を送信する。鍵の名前と鍵処理データは、送信リゾルバ によって完全に制御されるため、グローバルに一意な鍵名が使用されるべきで ある。使用されるKEY RRはサーバが対応する秘密鍵を持つものでなければ ならない。そうでなければ、鍵処理素材を復号化することができず、FORMERRが 返される。また、信頼されないサーバがKEY RRに対応する秘密鍵を持たない (正当なサーバ以外のサーバは秘密鍵を持たないことが望ましい)ことが重要 である。なぜなら、それを認めると、彼ら(正当なサーバ以外の秘密鍵保持者) は正当なサーバへのメッセージをキャプチャし、共有秘密鍵を学習し、有効な TSIGを偽造することが可能となるからである。 照会のTKEY RRに含まれる有効期間開始時刻と終了時刻は、照会側が意図する 鍵素材が有効であると見なす期間を与えるものである。サーバは、サーバが そのように長く状態を維持しないことを通知するために、より短い時間間隔を 返すことが可能であり、またどのような状態であっても、有効期間終了時刻 よりも前に鍵の有効期間を終了することができる。 このモードの照会はTSIGまたはSIG(0)によって認証されなければならない。 そうでない場合は、攻撃者はリゾルバに割り当てられたTKEYへの照会を偽造 することが可能となり、これによって攻撃者は、サーバに受理され、使用され、 正当と認められる共有秘密鍵を指定することが可能になる。 Eastlake Standards Track [Page 11] RFC 2930 The DNS TKEY RR September 2000 5. サーバによるTKEYの自動的包含処理 DNSサーバは、TKEY RRを付加情報として応答に自動的に含めてもよい。 これは、照会側がTKEYを理解し、更にこのオプションを実装していることを サーバが知っている場合にのみ行われるべきである。この技法は鍵を削除する ために使用することができ、また将来定義されるモードのために規定されて いる。この技法の欠点は、サーバがエラーまたは成功の表示を得る方法がない ことである。また、UDPの場合、DNSの応答がリゾルバに到達したかどうか すらも知る方法が存在しない。 5.1 サーバによる自動的鍵削除処理 サーバは任意により、応答の付加情報部に鍵名と鍵削除モードを指定する TKEY RRを自動的に含めることにより、秘密鍵を削除したことをクライアントに 通知することができる。このような応答は認証されるべきである。 認証がなされたならば、(応答で)与えられた名前の鍵は「削除」される。 削除するTKEY RRに含まれる有効期間開始時刻、終了時刻は無視される。 クライアントにおいて、受信に失敗したり、応答に含まれる付加情報を正確に 処理できない場合には、クライアントはサーバが既に破棄した鍵を使用する 可能性があり、その場合にはサーバからエラー表示を得る可能性がある。 サーバに割り当てられたDiffie-Hellman型の鍵に対しては、クライアントは その鍵に関連する全てのアクティブな状態を「破棄」しなければならない。 照会側で割り当てられた鍵に対しては、照会側は単にこの鍵はサーバには保持 されていないとマークするだけでもよく、照会側で割り当てられる鍵処理素材 を指定する将来の照会で再度送信してもよい。 6. 暗号化の方式 サーバ割り当てとリゾルバ割り当ての鍵合意モードでは、鍵処理素材は TKEY RRのKey Dataフィールド内に保存され、付随するKEY RRに含まれる公開鍵 で暗号化されて送信される[RFC2535]。このKEY RRでは、公開鍵と秘密鍵を 使用して、それぞれ暗号化と暗号化されたデータを復旧する復号化が可能な 公開鍵アルゴリズムが使用されなければならない。復号化処理では、データを 復号化するために対応する秘密鍵にアクセスがあるため、KEY RRは、復号化 するリゾルバ/サーバに対応した名前であるべきである。送信される秘密鍵の 鍵素材は一般にかなり短いものであり、通常256ビット未満である。これは 現代の鍵付ハッシュや対称アルゴリズムにより、非常に強力な保護でも短い 鍵素材で充分に提供できるためである。 KEY RRがRSAアルゴリズムを指定する場合、鍵処理素材はPKCS#1 [RFC2437]の RSAES-PKCS1-v1_5の記述どおりに暗号化される。 Eastlake Standards Track [Page 12] RFC 2930 The DNS TKEY RR September 2000 (送信される秘密鍵の鍵処理素材は、PKCS#1フォーマットで直接RSAにより 暗号化がなされることに注意してもらいたい。これらは他の対称(暗号)アルゴ リズムに「包含」されることはない)。可能性は低いが、鍵処理素材が選択 された1つのRSA係数の中に収まらない場合には、追加のRSA暗号ブロックが 含められる。各ブロックの長さは、指定されたRSA公開鍵から明らかになる。 また、RSAES-PKCS1-v1_5パディング処理は、暗号化されたデータのどの部分が 実際の鍵処理素材であり、どの部分がフォーマット処理したものか、あるいは 必要とされる最低8バイトの乱数[RFC1750]によるパディングであるかを明らかに する。 7. IANAに関する考察 このセクションは[RFC 2434]で説明されるとおりに解釈される。 Modeフィールド値0x0000および0xFFFFは予約済である。 Modeフィールド値0x0001から0x00FFまで、および0xFF00から0xFFFEまでは、 IETFの「Standards Action」(訳注: IESGに承認された標準トラックのRFCと なること)によってのみ割り当てられる。 Modeフィールド値0x0100から0x0FFFまで、および0xF0000から0xFEFFまでは、 「IESG approval」(訳注: IESGの承認が必要だが、リクエストはRFCになって いなくともよい)または「IETF consensus」(訳注: IESGに承認されたRFCで あること)によって割り当てられる。 Modeフィールド値0x1000から0xEFFFまでは、[RFC 2434]で定義される 「Specification Required」(訳注: RFCまたは他に容易に参照可能な不変の 文書の中で、異なる実装が相互接続するために充分な程度の情報が与えられる こと)に基づいて割り当てられる。 モード値は、その使用の状態が変更されても、変更されるべきではない。 例えば、仕様の提供に基づいて割り当てられたモード値は後になってその 使用の状態が標準トラックに変わったからといって変更されるべきではない。 以下の割り当てがここで文書化されている。 TKEYのRRタイプとして249 セクション2.5にリストされるTKEYモード1から5 セクション2.6にリストされる拡張RCODEエラー値19, 20, 21 8. セキュリティに関する考察 本仕様は全て、TSIG[RFC2845]をサポートするDNSクライアントとサーバ間に おける、安全な秘密共有鍵の確立に関するものである。 TKEYの使用を悪用したサービス不能攻撃からの保護に関する情報は提供され ない。 Eastlake Standards Track [Page 13] RFC 2930 The DNS TKEY RR September 2000 参考文献 [Schneier] Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996, John Wiley and Sons [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987. [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, September 1996. [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [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 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998. [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. Eastlake Standards Track [Page 14] RFC 2930 The DNS TKEY RR September 2000 [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, 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 508-261-4447 (w) EMail: Donald.Eastlake@motorola.com Eastlake Standards Track [Page 15] RFC 2930 The DNS TKEY RR 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 16] RFC2930-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/