この文書はRFC4025の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                      M. Richardson
Request for Comments: 4025                                           SSW
Category: Standards Track                                   February 2005


           A Method for Storing IPsec Keying Material in DNS
           IPsec鍵材料をDNSにしまっておく方法

Status of This Memo
この文書の状態


   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD
   1)の現在の版を参照してください。このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (2005).

Abstract
概要

   This document describes a new resource record for the Domain Name
   System (DNS).  This record may be used to store public keys for use
   in IP security (IPsec) systems.  The record also includes provisions
   for indicating what system should be contacted when an IPsec tunnel
   is established with the entity in question.
   この文書はドメインネームシステム(DNS)のために新しい資源レコード
   を記述します。このレコードはIPセキュリティ(IPsec)システムで
   公開鍵保存に使われるかもしれません。レコードは、IPsecトンネルが
   エンティティで設立される時、どのシステムに連絡を取るべきかを示す情報
   を含みます。

   This record replaces the functionality of the sub-type #4 of the KEY
   Resource Record, which has been obsoleted by RFC 3445.
   このレコードは鍵資源レコードのサブタイプ#4の機能の置換えで、そして
   #4はRFC3445によって時代遅れにされました。

Table of Contents
目次


   1.  Introduction
   1.  はじめに
       1.1.  Overview
       1.1.  概観
       1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
       1.2.  DNSアドレスから名前への変換の使用(IN-ADDR.ARPAとIP6.ARPA)
       1.3.  Usage Criteria
       1.3.  使用法基準
   2.  Storage Formats
   2.  貯蔵フォーマット
       2.1.  IPSECKEY RDATA Format
       2.1.  IPSECKEY資源データフォーマット
       2.2.  RDATA Format - Precedence
       2.2.  資源データフォーマット−優先
       2.3.  RDATA Format - Gateway Type
       2.3.  資源データフォーマット−ゲートウェイタイプ
       2.4.  RDATA Format - Algorithm Type
       2.4.  資源データフォーマット−アルゴリズムタイプ
       2.5.  RDATA Format - Gateway
       2.5.  資源データフォーマット−ゲートウェイ
       2.6.  RDATA Format - Public Keys
       2.6.  資源データフォーマット−公開鍵
   3.  Presentation Formats
   3.  表示フォーマット
       3.1.  Representation of IPSECKEY RRs
       3.1.  IPSECKEY資源レコードの表示
       3.2.  Examples
       3.2.  例
   4.  Security Considerations
   4.  セキュリティの考察
       4.1.  Active Attacks Against Unsecured IPSECKEY Resource Records
       4.1.  非安全なIPSECKEY資源レコードに対する能動的攻撃
             4.1.1.  Active Attacks Against IPSECKEY Keying Materials
             4.1.1.  IPSECKEY鍵材料に対する能動的攻撃
             4.1.2.  Active Attacks Against IPSECKEY Gateway Material
             4.1.2.  IPSECKEYゲートウェイ材料に対しての能動的攻撃
   5.  IANA Considerations
   5.  IANA考慮
   6.  Acknowledgements
   6.  謝辞
   7.  References
   7.  参考文献
       7.1.  Normative References
       7.1.  参照する参考文献

       7.2.  Informative References
       7.2.  有益な参考文献
   Author's Address
   著者のアドレス
   Full Copyright Statement
   著作権表示全文


1.  Introduction
1.  はじめに

   Suppose a host wishes (or is required by policy) to establish an
   IPsec tunnel with some remote entity on the network prior to allowing
   normal communication to take place.  In many cases, this end system
   will be able to determine the DNS name for the remote entity (either
   by having the DNS name given explicitly, by performing a DNS PTR
   query for a particular IP address, or through some other means, e.g.,
   by extracting the DNS portion of a "user@FQDN" name for a remote
   entity).  In these cases, the host will need to obtain a public key
   to authenticate the remote entity, and may also need some guidance
   about whether it should contact the entity directly or use another
   node as a gateway to the target entity.  The IPSECKEY RR provides a
   mechanism for storing such information.
   ホストがあるネットワーク上の遠隔エンティティと標準的な通信を行う前に
   IPsecトンネルを確立したいと望む(あるいはポリシで必要がある)と
   考えてください。多くの場合、この末端システムは遠隔エンティティのため
   にDNS名を決定することが可能であるでしょう(DNS名が明示的に与え
   られるあるいは、特定のIPアドレスのDNS PTR問合せを行うことで、
   あるいは何か他の手段を通して、例えば遠隔のエンティティの"user@FQDN"名
   のDNS部を抜き出す事で)。これらの場合、ホストは遠隔のエンティティ
   を認証するために公開鍵を得る必要があるでしょう、そして、直接エンティ
   ティと通信するか、あるいは目標エンティティへのゲートウェイとして他の
   ノードを用いるべきかのある助言を必要とするかもしれません。IPSECKEY資
   源レコードはこのような情報を保管する機構を供給します。

   The type number for the IPSECKEY RR is 45.
   IPSECKEY資源レコードのタイプ番号は45です。

   This record replaces the functionality of the sub-type #4 of the KEY
   Resource Record, which has been obsoleted by RFC 3445 [11].
   このレコードは鍵資源レコードのサブタイプ#4の機能の置換えで、#4は
   RFC3445[11]によって時代遅れにされました。

1.1.  Overview
1.1.  概観

   The IPSECKEY resource record (RR) is used to publish a public key
   that is to be associated with a Domain Name System (DNS) [1] name for
   use with the IPsec protocol suite.  This can be the public key of a
   host, network, or application (in the case of per-port keying).
   IPSECKEY資源レコード(RR)はIPsecプロトコル群でドメインネーム
   システム[1]と結びつけられる公開鍵を公開するために使われます。これはホ
   ストやネットワークやアプリケーション(ポート毎の暗号鍵の場合)の公開
   鍵であり得ます。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].
   この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
   NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
   RFC2119[3]で記述されたように解釈されるはずです。

1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
1.2.  DNSアドレスから名前への変換の使用(IN-ADDR.ARPAとIP6.ARPA)

   Often a security gateway will only have access to the IP address of
   the node with which communication is desired and will not know any
   other name for the target node.  Because of this, frequently the best
   way of looking up IPSECKEY RRs will be by using the IP address as an
   index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or
   IP6.ARPA for IPv6).
   しばしばセキュリティゲートウェイが、通信が望まれているノードのIPア
   ドレスにアクセスを持つだけで、そして目標ノードの他の名前を知らないで
   しょう。このため、しばしばIPSECKEY資源レコードを探す最も良い仕方は逆
   変換木(IPv4のIN-ADDR.ARPAあるいはIPv6のIP6.ARPA)でIPアド
   レスをインデックスとして用いることであるでしょう。

   The lookup is done in the fashion usual for PTR records.  The IP
   address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
   with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
   followed.
   検索はPTRレコードの通常の方法でされます。IPアドレスのオクテット
   (IPv4)あるいはニブル(=4ビット)(IPv6)が逆順にされ、適
   切な接尾辞を付けて検索されます。CNAMEやDNAMEが見いだしたら従わなくて
   はなりません(MUST)。

   Note: even when the IPsec function is contained in the end-host,
   often only the application will know the forward name used.  Although
   the case where the application knows the forward name is common, the
   user could easily have typed in a literal IP address.  This storage
   mechanism does not preclude using the forward name when it is
   available but does not require it.
   メモ:IPsec機能がエンドホストにある時でも、しばしばアプリケーショ
   ンが使われた前方の名前を知るだけでしょう。アプリケーションが前方の名
   前を知っている場合が普通であるけれども、ユーザは容易にIPアドレスを
   直接タイプすることができます。この貯蔵機構は、利用可能であれば前方の
   名前を使うことを妨げず、しかし必須にはしません。

1.3.  Usage Criteria
1.3.  使用法基準

   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
   [8] unless some other means of authenticating the IPSECKEY resource
   record is available.
   IPSECKEY資源レコードは、何か他のIPSECKEY資源レコードを認証する手段が
   利用可能ではないなら、DNSSEC[8]と共に使われるべきです(SHOULD)。

   It is expected that there will often be multiple IPSECKEY resource
   records at the same name.  This will be due to the presence of
   multiple gateways and a need to roll over keys.
   同じ名前に多数のIPSECKEY資源レコードがしばしばあると思われます。これ
   は多数のゲートウェイの存在と鍵を切替える必要のためであるでしょう。

   This resource record is class independent.
   この資源レコードはクラスに依存しません。

2.  Storage Formats
2.  貯蔵フォーマット

2.1.  IPSECKEY RDATA Format
2.1.  IPSECKEY資源データフォーマット

   The RDATA for an IPSECKEY RR consists of a precedence value, a
   gateway type, a public key, algorithm type, and an optional gateway
   address.
   IPSECKEY資源レコードの資源データは優先値とゲートウェイタイプと公開鍵
   とアルゴリズムタイプと任意設定のゲートウェイアドレスから成り立ちます。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  precedence   | gateway type  |  algorithm  |     gateway     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
      ~                            gateway                            ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               /
      /                          public key                           /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

2.2.  RDATA Format - Precedence
2.2.  資源データフォーマット−優先

   This is an 8-bit precedence for this record.  It is interpreted in
   the same way as the PREFERENCE field described in section 3.3.9 of
   RFC 1035 [2].
   これはこのレコードの8ビットの優先値です。これはRFC1035[2]の
   3.3.9章で記述した優先フィールドと同じように解釈されます。

   Gateways listed in IPSECKEY records with lower precedence are to be
   attempted first.  Where there is a tie in precedence, the order
   should be non-deterministic.
   より低い優先値のIPSECKEYレコードのゲートウェイが最初に試みられるはず
   です。優先値が同じ場合順序は非決定論的です。

2.3.  RDATA Format - Gateway Type
2.3.  資源データフォーマット−ゲートウェイタイプ

   The gateway type field indicates the format of the information that
   is stored in the gateway field.
   ゲートウェイタイプフィールドはゲートウェイフィールドに保管される情
   報のフォーマットを示します。

   The following values are defined:
   次の値が定義されます:
   0  No gateway is present.
   0  ゲートウェイが存在していません。
   1  A 4-byte IPv4 address is present.
   1  4バイトのIPv4アドレスが存在しています。
   2  A 16-byte IPv6 address is present.
   2  16バイトのIPv6アドレスが存在しています。
   3  A wire-encoded domain name is present.  The wire-encoded format is
      self-describing, so the length is implicit.  The domain name MUST
      NOT be compressed.  (See Section 3.3 of RFC 1035 [2].)
   3  ワイヤコード化されたドメイン名が存在しています。ワイヤコードフォー
      マットは自己記述で、長さは暗黙指定です。ドメイン名は圧縮されてはな
      りません(MUST NOT)。(RFC1035[2]の3.3章を見てください。)

2.4.  RDATA Format - Algorithm Type
2.4.  資源データフォーマット−アルゴリズムタイプ

   The algorithm type field identifies the public key's cryptographic
   algorithm and determines the format of the public key field.
   アルゴリズムタイプフィールドは公開鍵の暗号のアルゴリズムを識別して、
   そして公開鍵フィールドのフォーマットを決定します。

   A value of 0 indicates that no key is present.
   0の価値が鍵が存在していないことを示します。

   The following values are defined:
   次の値が定義されます:
   1  A DSA key is present, in the format defined in RFC 2536 [9].
   1  RFC2536[9]で定義されたフォーマットで、DSA鍵が存在し
      ています。
   2  A RSA key is present, in the format defined in RFC 3110 [10].
   2  RFC3110[10]で定義されたフォーマットで、RSA鍵が存在
      しています。

2.5.  RDATA Format - Gateway
2.5.  資源データフォーマット−ゲートウェイ

   The gateway field indicates a gateway to which an IPsec tunnel may be
   created in order to reach the entity named by this resource record.
   ゲートウェイフィールドは、この資源レコードによって名指されたエンティ
   ティに接続するために作られるかもしれないIPsecトンネルのゲート
   ウェイを示します。

   There are three formats:
   3つのフォーマットがあります:

   A 32-bit IPv4 address is present in the gateway field.  The data
   portion is an IPv4 address as described in section 3.4.1 of RFC 1035
   [2].  This is a 32-bit number in network byte order.
   32ビットのIPv4アドレスがゲートウェイフィールドで存在しています。
   データ部は、RFC1035[2]の3.4.1章で記述されるように、IPv4
   アドレスです。これはネットワークバイト順で32ビットの数です。

   A 128-bit IPv6 address is present in the gateway field.  The data
   portion is an IPv6 address as described in section 2.2 of RFC 3596
   [12].  This is a 128-bit number in network byte order.
   128ビットのIPv6アドレスがゲートウェイフィールドで存在しています。
   データ部は、RFC3596[12]の2.2章で記述されるように、IPv6ア
   ドレスです。これはネットワークバイト順で128ビットの数です。

   The gateway field is a normal wire-encoded domain name, as described
   in section 3.3 of RFC 1035 [2].  Compression MUST NOT be used.
   ゲートウェイフィールドは、RFC1035[2]の3.3章で記述されるよう
   に、標準的なワイヤコード化されたドメイン名です。圧縮が使われてはなり
   ません(MUST NOT)。

2.6.  RDATA Format - Public Keys
2.6.  資源データフォーマット−公開鍵

   Both the public key types defined in this document (RSA and DSA)
   inherit their public key formats from the corresponding KEY RR
   formats.  Specifically, the public key field contains the
   algorithm-specific portion of the KEY RR RDATA, which is all the KEY
   RR DATA after the first four octets.  This is the same portion of the
   KEY RR that must be specified by documents that define a DNSSEC
   algorithm.  Those documents also specify a message digest to be used
   for generation of SIG RRs; that specification is not relevant for
   IPSECKEY RRs.
   この文書で定義された両方の公開鍵タイプ(RSAとDSA)は対応する鍵
   資源レコードフォーマットの公開鍵フォーマットを継承します。特に、公開
   鍵フィールドは鍵資源レコード資源データの、最初の4つのオクテットの後
   のすべてであるアルゴリズム特定の部分を含みます。これはDNSSECア
   ルゴリズムを定義する文書で指定されなくてはならない鍵資源レコードの同
   じ部分です。それらの文書は同じく署名資源レコード生成に使われるメッセー
   ジダイジェストを指定します;その仕様はIPSECKEY資源レコードで適切では
   ありません。

   Future algorithms, if they are to be used by both DNSSEC (in the KEY
   RR) and IPSECKEY, are likely to use the same public key encodings in
   both records.  Unless otherwise specified, the IPSECKEY public key
   field will contain the algorithm-specific portion of the KEY RR RDATA
   for the corresponding algorithm.  The algorithm must still be
   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
   (which might be different from the DNSSEC algorithm number) must be
   assigned to it.
   将来のアルゴリズムは、もしDNSSEC(鍵資源レコードで)とIPSECKEY
   の両方で使われるなら、両方のレコードで同じ公開鍵コーディングを使う可
   能性が高いです。特に指定されないなら、 IPSECKEY公開鍵フィールドは対応
   するアルゴリズムの鍵資源レコード資源データのアルゴリズム特定の部分を
   含んでいるでしょう。アルゴリズムはIPSECKEYで使用するためには指定され
   なくてはなりません、そして(DNSSECアルゴリズム番号と異なっるか
   もしれない)IPSECKEYアルゴリズムタイプ番号がそれに割り当てられなくて
   はなりません。

   The DSA key format is defined in RFC 2536 [9]
   DSA鍵フォーマットはRFC2536[9]で定義されます。

   The RSA key format is defined in RFC 3110 [10], with the following
   changes:
   RSA鍵フォーマットはRFC3110[10]で定義され、次の変更がありま
   す:

   The earlier definition of RSA/MD5 in RFC 2065 [4] limited the
   exponent and modulus to 2552 bits in length.  RFC 3110 extended that
   limit to 4096 bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no
   length limit on RSA public keys, other than the 65535 octet limit
   imposed by the two-octet length encoding.  This length extension is
   applicable only to IPSECKEY; it is not applicable to KEY RRs.
   RFC2065[4]でのRSA/MD5の前の定義は、指数とモジュロの長
   さを2552ビットに制限しました。RFC3110がRSA/SHA1の
   鍵の限界を4096ビットに拡張しました。IPSECKEY資源レコードは2オク
   テットの長さコーディングによって課された65535のオクテットの限界
   以外、RSA公開鍵に長さ限度を課しません。この長さの拡張はIPSECKEYに
   だけ適用できます;それは鍵資源レコードに適用できません。

3.  Presentation Formats
3.  表示フォーマット

3.1.  Representation of IPSECKEY RRs
3.1.  IPSECKEY資源レコードの表示

   IPSECKEY RRs may appear in a zone data master file.  The precedence,
   gateway type, algorithm, and gateway fields are REQUIRED.  The base64
   encoded public key block is OPTIONAL; if it is not present, the
   public key field of the resource record MUST be construed to be zero
   octets in length.
   IPSECKEY資源レコードはゾーンデータマスターファイルに現われるかもしれ
   ません。優先値とゲートウェイタイプとアルゴリズムとゲートウェイフィー
   ルドが必要です(REQUIRED)。ベース64でコード化された公開鍵ブロックの
   存在は任意です(OPTIONAL);もし存在していないなら資源レコードの公開鍵
   フィールドは長がゼロオクテットであると解釈されなくてはなりません(MUST)。

   The algorithm field is an unsigned integer.  No mnemonics are
   defined.
   アルゴリズムフィールドは符号なしの整数です。覚え易い名称が定義されま
   せん。

   If no gateway is to be indicated, then the gateway type field MUST be
   zero, and the gateway field MUST be "."
   もしゲートウェイがないなら、ゲートウェイタイプフィールドはゼロで(MUST)、
   ゲートウェイフィールドは"."に違いありません(MUST)。

   The Public Key field is represented as a Base64 encoding of the
   Public Key.  Whitespace is allowed within the Base64 text.  For a
   definition of Base64 encoding, see RFC 3548 [6], Section 5.2.
   公開鍵フィールドは公開鍵のベース64コーディングとして描かれます。空
   白スペースがベース64テキストの中で許されます。ベース64コーディン
   グの定義はRFC3548[6]の5.2章を見てください。

   The general presentation for the record is as follows:
   一般的なレコードの表示は次の通りです:

   IN     IPSECKEY ( precedence gateway-type algorithm
                     gateway base64-encoded-public-key )

3.2.  Examples
3.2.  例

   An example of a node, 192.0.2.38, that will accept IPsec tunnels on
   its own behalf.
   自分自身のIPsecトンネルを受け入れるノード192.0.2.38の例。

   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
                    192.0.2.38
                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )

   An example of a node, 192.0.2.38, that has published its key only.
   その鍵のみを公開したノード192.0.2.38の例。

   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
                    .
                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )

   An example of a node, 192.0.2.38, that has delegated authority to the
   node 192.0.2.3.
   ノード192.0.2.38に委任された権限を持つノード192.0.2.3.の例。

   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
                    192.0.2.3
                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )

   An example of a node, 192.0.1.38 that has delegated authority to the
   node with the identity "mygateway.example.com".
   識別子"mygateway.example.com"のノードに委任された権限を持っているノー
   ド192.0.1.38の例。

   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
                    mygateway.example.com.
                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )

   An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
   delegated authority to the node 2001:0DB8:c000:0200:2::1
   ノード2001:0DB8:c000:0200:2::1に委任された権限を持つノード
   2001:0DB8:0200:1:210:f3ff:fe03:4d0の例。

   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
                    2001:0DB8:0:8002::2000:1
                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )

4.  Security Considerations
4.  セキュリティの考察

   This entire memo pertains to the provision of public keying material
   for use by key management protocols such as ISAKMP/IKE (RFC 2407)
   [7].
   この文書全体がISAKMP/IKE(RFC2407)[7]のような鍵管理プロトコル
   の使用する公開鍵材料の準備に関係があります。

   The IPSECKEY resource record contains information that SHOULD be
   communicated to the end client in an integral fashion; i.e., free
   from modification.  The form of this channel is up to the consumer of
   the data; there must be a trust relationship between the end consumer
   of this resource record and the server.  This relationship may be
   end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another
   secure source, a secure local channel on the host, or some
   combination of the above.
   IPSECKEY資源レコードは確実に、すなわち無修正で、エンドクライアントに
   伝達されるべき(SHOULD)情報を含んでいます。このチャネルの形式はデータ
   の消費者次第です;この資源レコードのエンド消費者とサーバ間の信頼関係
   があるに違いありません。この関係はエンドエンドDNSSEC検証、他の
   安全なソースへのTSIGあるいはSIG(0)チャネル、ホストの安全な
   ローカルチャネル、あるいは上記の組合せかもしれません。

   The keying material provided by the IPSECKEY resource record is not
   sensitive to passive attacks.  The keying material may be freely
   disclosed to any party without any impact on the security properties
   of the resulting IPsec session.  IPsec and IKE provide defense
   against both active and passive attacks.
   IPSECKEY資源レコードによって供給された鍵材料は受動的な攻撃に敏感では
   ありません。鍵材料は結果として生じるIPsecセッションのセキュリティ
   特性に影響無く任意の第三者にでも自由に明らかにされるかもしれません。
   IPsecとIKEは共に能動的や受動的な攻撃に対して防衛を供給します。

   Any derivative specification that makes use of this resource record
   MUST carefully document its trust model and why the trust model of
   DNSSEC is appropriate, if that is the secure channel used.
   この資源レコードを利用する派生的な仕様書は、慎重にその信頼モデルと、
   もしDNSSECが使われる安全なチャネルであるならDNSSECの信頼
   モデルが適切である理由を、文書化しなくてはなりません(MUST)。

   An active attack on the DNS that caused the wrong IP address to be
   retrieved (via forged address), and therefore the wrong QNAME to be
   queried, would also result in a man-in-the-middle attack.  This
   situation is independent of whether the IPSECKEY RR is used.
   DNSへの能動的な攻撃は、(偽造されたアドレスによって)間違ったIP
   アドレスを得て、そしてそれ故に問合せで間違ったQNAMEを得て、中間者攻撃
   をもたらすでしょう。この状態は、IPSECKEY資源レコードが使われるかと関
   係ありません。

4.1.  Active Attacks Against Unsecured IPSECKEY Resource Records
4.1.  非安全なIPSECKEY資源レコードに対する能動的攻撃

   This section deals with active attacks against the DNS.  These
   attacks require that DNS requests and responses be intercepted and
   changed.  DNSSEC is designed to defend against attacks of this kind.
   This section deals with the situation in which DNSSEC is not
   available.  This is not the recommended deployment scenario.
   この章はDNSに対する能動的な攻撃を扱います。これらの攻撃はDNS要
   請と応答を途中で捕えらえて変えることを要求します。DNSSECはこの
   種類の攻撃から守るよう意図されます。この章はDNSSECが利用可能で
   はない状態を扱います。これは推薦された展開の筋書きではありません。

4.1.1.  Active Attacks Against IPSECKEY Keying Materials
4.1.1.  IPSECKEY鍵材料に対する能動的攻撃

   The first kind of active attack is when the attacker replaces the
   keying material with either a key under its control or with garbage.
   能動的攻撃の最初の種類は攻撃者が鍵材料を制御下にある鍵あるいは無意味
   な加地と取り替えるものです。

   The gateway field is either untouched or is null.  The IKE
   negotiation will therefore occur with the original end-system.  For
   this attack to succeed, the attacker must perform a man-in-the-middle
   attack on the IKE negotiation.  This attack requires that the
   attacker be able to intercept and modify packets on the forwarding
   path for the IKE and data packets.
   ゲートウェイフィールドは無変更かあるいは空です。従ってIKE交渉はオ
   リジナルの末端システムで起こるでしょう。この攻撃が成功するために、攻
   撃者はIKE交渉に対する中間者攻撃を行わなくてはなりません。この攻撃
   は攻撃者がIKEとデータパケットの転送パスのパケットを捕獲して修正す
   ることが可能であることを要求します。

   If the attacker is not able to perform this man-in-the-middle attack
   on the IKE negotiation, then a denial of service will result, as the
   IKE negotiation will fail.
   もし攻撃者がこのIKE交渉に対する中間者攻撃を行うことが可能ではない
   なら、IKE交渉が失敗してサービス妨害が結果的に発生するでしょう。

   If the attacker is not only able to mount active attacks against DNS
   but also in a position to perform a man-in-the-middle attack on IKE
   and IPsec negotiations, then the attacker will be able to compromise
   the resulting IPsec channel.  Note that an attacker must be able to
   perform active DNS attacks on both sides of the IKE negotiation for
   this to succeed.
   もし攻撃者がDNSに対して能動的な攻撃を開始することが可能であるだけ
   ではなくIKEとIPsec交渉に対する中間者攻撃を行う立場にあるなら、
   攻撃者は結果として生じるIPsecチャネルを危険にすることが可能であ
   るでしょう。攻撃者がこれが成功させるためにIKE交渉の両側に対する能
   動的なDNS攻撃を行うことができなければならないことに注意してくださ
   い。

4.1.2.  Active Attacks Against IPSECKEY Gateway Material
4.1.2.  IPSECKEYゲートウェイ材料に対しての能動的攻撃

   The second kind of active attack is one in which the attacker
   replaces the gateway address to point to a node under the attacker's
   control.  The attacker then either replaces the public key or removes
   it.  If the public key were removed, then the attacker could provide
   an accurate public key of its own in a second record.
   能動的攻撃の2番目の種類は攻撃者が攻撃者の制御の下のノードを指し示す
   ためにゲートウェイアドレスを置き換えるものです。攻撃者はそれから公開
   鍵を置き換えるか削除します。もし公開鍵が削除されたなら、攻撃者は2番
   目のレコードで自分自身の正確な公開鍵を供給できます。

   This second form creates a simple man-in-the-middle attacks since the
   attacker can then create a second tunnel to the real destination.
   Note that, as before, this requires that the attacker also mount an
   active attack against the responder.
   この2番目の書式は、攻撃者が本当の宛先に2番目のトンネルを作ることが
   できるので、単純な中間者攻撃を作ります。前と同じように、これは攻撃者
   が応答者に対して同じく能動的な攻撃を開始することを要求することに注意
   しててください。

   Note that the man-in-the-middle cannot just forward cleartext packets
   to the original destination.  While the destination may be willing to
   speak in the clear, replying to the original sender, the sender will
   already have created a policy expecting ciphertext.  Thus, the
   attacker will need to intercept traffic in both directions.  In some
   cases, the attacker may be able to accomplish the full intercept by
   use of Network Address/Port Translation (NAT/NAPT) technology.
   中間者攻撃は平文パケットを元の目的地に転送することができないことに注
   意してください。宛先が平文での会話を期待していても、本来の送り主への
   答で、送り主はすでに暗号文を期待するポリシを作ってしまっているでしょ
   う。それで、攻撃者は両方向のトラフィックを途中で捕える必要があるで
   しょう。ある場合に、攻撃者はネットワークアドレス/ポート翻訳(NAT
   /NAPT)技術の使用によって完全な妨害を達成することが可能であるか
   もしれません。

   This attack is easier than the first one because the attacker does
   NOT need to be on the end-to-end forwarding path.  The attacker need
   only be able to modify DNS replies.  This can be done by packet
   modification, by various kinds of race attacks, or through methods
   that pollute DNS caches.
   この攻撃は、攻撃者がエンドエンド転送パス上にいる必要がないから、最初
   のより容易です。攻撃者はただDNS応答を修正することが可能である必要
   があるだけです。これは、種々の種類の競合攻撃やDNSキャッシュを汚染
   する方法による、パケット修正によって可能です。

   If the end-to-end integrity of the IPSECKEY RR is suspect, the end
   client MUST restrict its use of the IPSECKEY RR to cases where the RR
   owner name matches the content of the gateway field.  As the RR owner
   name is assumed when the gateway field is null, a null gateway field
   is considered a match.
   もしIPSECKEY資源レコードのエンドエンド完全性が疑わしいなら、エンドク
   ライアントはそのIPSECKEY資源レコードの使用を資源レコード所有者名がゲー
   トウェイフィールドの内容と一致する場合に制限しなくてはなりません(MUST)。
   ゲートウェイフィールドが空である時、資源レコード所有者名が空のゲート
   ウェイフィールドと一致すると思われます。

   Thus, any records obtained under unverified conditions (e.g., no
   DNSSEC or trusted path to source) that have a non-null gateway field
   MUST be ignored.
   それで、検証されていない状態(DNSSECがないかソースへの信頼パス
   がない)の得られたレコードで、非ヌルゲートウェイがあるものは無視しな
   くてはなりません(MUST)。

   This restriction eliminates attacks against the gateway field, which
   are considered much easier, as the attack does not need to be on the
   forwarding path.
   この制限はゲートウェイフィールドに対して攻撃を排除し、そしてこの攻撃
   は攻撃者が転送パス上にいる必要がないからずっとより容易であると思われ
   ます。

   In the case of an IPSECKEY RR with a value of three in its gateway
   type field, the gateway field contains a domain name.  The subsequent
   query required to translate that name into an IP address or IPSECKEY
   RR will also be subject to man-in-the-middle attacks.  If the
   end-to-end integrity of this second query is suspect, then the
   provisions above also apply.  The IPSECKEY RR MUST be ignored
   whenever the resulting gateway does not match the QNAME of the
   original IPSECKEY RR query.

   ゲートウェイタイプフィールドが3の値であるIPSECKEY資源レコードの場合、
   ゲートウェイフィールドはドメイン名を含んでいます。その名前をIPアド
   レスあるいはIPSECKEY資源レコードに変換するように要求された次の問合せ
   は同じく中間者攻撃の適用を受けるでしょう。もしこの2番目の質問のエン
   ドエンド完全性が疑わしいなら、上の条項は同じく適用されます。IPSECKEY
   資源レコードは、結果として発生するゲートウェイが元のIPSECKEY資源レコー
   ドの質問のQNAMEと一致しない時はいつでも、無視されなくてはなりません
   (MUST)。

5.  IANA Considerations
5.  IANA考慮

   This document updates the IANA Registry for DNS Resource Record Types
   by assigning type 45 to the IPSECKEY record.
   この文書はIPSECKEYレコードにタイプ45を割り当てることによってDNS
   資源レコードタイプのIANA登記所を更新します。

   This document creates two new IANA registries, both specific to the
   IPSECKEY Resource Record:
   この書類は、IPSECKEY資源レコードに固有の、2つの新しいIANA登記所
   を作ります:
 
   This document creates an IANA registry for the algorithm type field.
   この文書はアルゴリズムタイプフィールドのためにIANA登記所を作ります。

   Values 0, 1, and 2 are defined in Section 2.4.  Algorithm numbers 3
   through 255 can be assigned by IETF Consensus (see RFC 2434 [5]).
   価0と1と2が2.4章で定義されます。アルゴリズム3から255までの
   番号がIETF合意によって割り当てられることができます
   (RFC2434[5]参照)。

   This document creates an IANA registry for the gateway type field.
   この文書はゲートウェイタイプフィールドのIANA登記所を作ります。

   Values 0, 1, 2, and 3 are defined in Section 2.3.  Gateway type
   numbers 4 through 255 can be assigned by Standards Action (see RFC
   2434 [5]).
   価0と1と2と3が2.3章で定義されます。ゲートウェイタイプ4から
   255までの数が標準化行動によって割り当てできます
   (RFC2434[5]参照)。

6.  Acknowledgements
6.  謝辞

   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
   Austein, and Olafur Gudmundsson, who reviewed this document
   carefully.  Additional thanks to Olafur Gurmundsson for a reference
   implementation.
   慎重にこの文書を再検討したPaul HoffmanとSam WeilerとJean-Jacques
   PuigとRob AusteinとOlafur Gudmundssonに感謝します。参照実装に関して
   Olafur Gurmundssonに追加で感謝します。

7.  References
7.  参考文献

7.1.  Normative References
7.1.  参照する参考文献


   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security
        Extensions", RFC 2065, January 1997.

   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
        RFC 3548, July 2003.

7.2.  Informative References
7.2.  有益な参考文献

   [7]  Piper, D., "The Internet IP Security Domain of Interpretation
        for ISAKMP", RFC 2407, November 1998.

   [8]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [9]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System
        (DNS)", RFC 2536, March 1999.

   [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
        Name System (DNS)", RFC 3110, May 2001.

   [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
        Record (RR)", RFC 3445, December 2002.

   [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
        Extensions to Support IP Version 6", RFC 3596, October 2003.

Author's Address
著者のアドレス

   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7
   CA

   EMail: mcr@sandelman.ottawa.on.ca
   URI:   http://www.sandelman.ottawa.on.ca/


Full Copyright Statement
著作権表示全文

   Copyright (C) The Internet Society (2005).
   著作権(C)インターネット学会(2005)。

   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.
   この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして
   この中に明らかにされる以外は著者がすべての権利を維持します。

   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 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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.
   この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンライン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.
   IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So