RFC4025 ＩＰｓｅｃ鍵材料をＤＮＳにしまっておく方法

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

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

A Method for Storing IPsec Keying Material in 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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。

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.
この文書はドメインネームシステム（ＤＮＳ）のために新しい資源レコード
を記述します。このレコードはＩＰセキュリティ（ＩＰｓｅｃ）システムで
公開鍵保存に使われるかもしれません。レコードは、ＩＰｓｅｃトンネルが
エンティティで設立される時、どのシステムに連絡を取るべきかを示す情報
を含みます。

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

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. ＤＮＳアドレスから名前への変換の使用(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. ＩＡＮＡ考慮
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.
ホストがあるネットワーク上の遠隔エンティティと標準的な通信を行う前に
ＩＰｓｅｃトンネルを確立したいと望む（あるいはポリシで必要がある）と
考えてください。多くの場合、この末端システムは遠隔エンティティのため
にＤＮＳ名を決定することが可能であるでしょう（ＤＮＳ名が明示的に与え
られるあるいは、特定のＩＰアドレスのＤＮＳ ＰＴＲ問合せを行うことで、
あるいは何か他の手段を通して、例えば遠隔のエンティティの"user@FQDN"名
のＤＮＳ部を抜き出す事で）。これらの場合、ホストは遠隔のエンティティ
を認証するために公開鍵を得る必要があるでしょう、そして、直接エンティ
ティと通信するか、あるいは目標エンティティへのゲートウェイとして他の
ノードを用いるべきかのある助言を必要とするかもしれません。IPSECKEY資
源レコードはこのような情報を保管する機構を供給します。

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

This record replaces the functionality of the sub-type #4 of the KEY
Resource Record, which has been obsoleted by RFC 3445 [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資源レコード（ＲＲ）はＩＰｓｅｃプロトコル群でドメインネーム
システム[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"は
ＲＦＣ２１１９[3]で記述されたように解釈されるはずです。

1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
1.2. ＤＮＳアドレスから名前への変換の使用(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).
しばしばセキュリティゲートウェイが、通信が望まれているノードのＩＰア
ドレスにアクセスを持つだけで、そして目標ノードの他の名前を知らないで
しょう。このため、しばしばIPSECKEY資源レコードを探す最も良い仕方は逆
変換木（ＩＰｖ４のIN-ADDR.ARPAあるいはＩＰｖ６のIP6.ARPA）でＩＰアド
レスをインデックスとして用いることであるでしょう。

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レコードの通常の方法でされます。ＩＰアドレスのオクテット
（ＩＰｖ４）あるいはニブル（＝４ビット）（ＩＰｖ６）が逆順にされ、適
切な接尾辞を付けて検索されます。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.
メモ：ＩＰｓｅｃ機能がエンドホストにある時でも、しばしばアプリケーショ
ンが使われた前方の名前を知るだけでしょう。アプリケーションが前方の名
前を知っている場合が普通であるけれども、ユーザは容易にＩＰアドレスを
直接タイプすることができます。この貯蔵機構は、利用可能であれば前方の
名前を使うことを妨げず、しかし必須にはしません。

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資源レコードを認証する手段が
利用可能ではないなら、ＤＮＳＳＥＣ[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].
これはこのレコードの８ビットの優先値です。これはＲＦＣ１０３５[2]の
３.３.９章で記述した優先フィールドと同じように解釈されます。

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 ４バイトのＩＰｖ４アドレスが存在しています。
2 A 16-byte IPv6 address is present.
2 １６バイトのＩＰｖ６アドレスが存在しています。
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)。（ＲＦＣ１０３５[2]の３.３章を見てください。）

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.
０の価値が鍵が存在していないことを示します。

The following values are defined:
次の値が定義されます：
1 A DSA key is present, in the format defined in RFC 2536 [9].
1 ＲＦＣ２５３６[9]で定義されたフォーマットで、ＤＳＡ鍵が存在し
ています。
2 A RSA key is present, in the format defined in RFC 3110 [10].
2 ＲＦＣ３１１０[10]で定義されたフォーマットで、ＲＳＡ鍵が存在
しています。

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.
ゲートウェイフィールドは、この資源レコードによって名指されたエンティ
ティに接続するために作られるかもしれないＩＰｓｅｃトンネルのゲート
ウェイを示します。

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

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.
３２ビットのＩＰｖ４アドレスがゲートウェイフィールドで存在しています。
データ部は、ＲＦＣ１０３５[2]の３.４.１章で記述されるように、ＩＰｖ４
アドレスです。これはネットワークバイト順で３２ビットの数です。

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.
１２８ビットのＩＰｖ６アドレスがゲートウェイフィールドで存在しています。
データ部は、ＲＦＣ３５９６[12]の２.２章で記述されるように、ＩＰｖ６ア
ドレスです。これはネットワークバイト順で１２８ビットの数です。

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.
ゲートウェイフィールドは、ＲＦＣ１０３５[2]の３.３章で記述されるよう
に、標準的なワイヤコード化されたドメイン名です。圧縮が使われてはなり
ません(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.
この文書で定義された両方の公開鍵タイプ（ＲＳＡとＤＳＡ）は対応する鍵
資源レコードフォーマットの公開鍵フォーマットを継承します。特に、公開
鍵フィールドは鍵資源レコード資源データの、最初の４つのオクテットの後
のすべてであるアルゴリズム特定の部分を含みます。これはＤＮＳＳＥＣア
ルゴリズムを定義する文書で指定されなくてはならない鍵資源レコードの同
じ部分です。それらの文書は同じく署名資源レコード生成に使われるメッセー
ジダイジェストを指定します；その仕様は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.
将来のアルゴリズムは、もしＤＮＳＳＥＣ（鍵資源レコードで）とIPSECKEY
の両方で使われるなら、両方のレコードで同じ公開鍵コーディングを使う可
能性が高いです。特に指定されないなら、 IPSECKEY公開鍵フィールドは対応
するアルゴリズムの鍵資源レコード資源データのアルゴリズム特定の部分を
含んでいるでしょう。アルゴリズムはIPSECKEYで使用するためには指定され
なくてはなりません、そして（ＤＮＳＳＥＣアルゴリズム番号と異なっるか
もしれない）IPSECKEYアルゴリズムタイプ番号がそれに割り当てられなくて
はなりません。

The DSA key format is defined in RFC 2536 [9]
ＤＳＡ鍵フォーマットはＲＦＣ２５３６[9]で定義されます。

The RSA key format is defined in RFC 3110 [10], with the following
changes:
ＲＳＡ鍵フォーマットはＲＦＣ３１１０[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.
ＲＦＣ２０６５[4]でのＲＳＡ／ＭＤ５の前の定義は、指数とモジュロの長
さを２５５２ビットに制限しました。ＲＦＣ３１１０がＲＳＡ／ＳＨＡ１の
鍵の限界を４０９６ビットに拡張しました。IPSECKEY資源レコードは２オク
テットの長さコーディングによって課された６５５３５のオクテットの限界
以外、ＲＳＡ公開鍵に長さ限度を課しません。この長さの拡張は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)。ベース６４でコード化された公開鍵ブロックの
存在は任意です(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.
公開鍵フィールドは公開鍵のベース６４コーディングとして描かれます。空
白スペースがベース６４テキストの中で許されます。ベース６４コーディン
グの定義はＲＦＣ３５４８[6]の５.２章を見てください。

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.
自分自身のＩＰｓｅｃトンネルを受け入れるノード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（ＲＦＣ２４０７）[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)情報を含んでいます。このチャネルの形式はデータ
の消費者次第です；この資源レコードのエンド消費者とサーバ間の信頼関係
があるに違いありません。この関係はエンドエンドＤＮＳＳＥＣ検証、他の
安全なソースへのＴＳＩＧあるいはＳＩＧ（０）チャネル、ホストの安全な
ローカルチャネル、あるいは上記の組合せかもしれません。

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資源レコードによって供給された鍵材料は受動的な攻撃に敏感では
ありません。鍵材料は結果として生じるＩＰｓｅｃセッションのセキュリティ
特性に影響無く任意の第三者にでも自由に明らかにされるかもしれません。
ＩＰｓｅｃとＩＫＥは共に能動的や受動的な攻撃に対して防衛を供給します。

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.
この資源レコードを利用する派生的な仕様書は、慎重にその信頼モデルと、
もしＤＮＳＳＥＣが使われる安全なチャネルであるならＤＮＳＳＥＣの信頼
モデルが適切である理由を、文書化しなくてはなりません(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.
ＤＮＳへの能動的な攻撃は、（偽造されたアドレスによって）間違ったＩＰ
アドレスを得て、そしてそれ故に問合せで間違った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.
この章はＤＮＳに対する能動的な攻撃を扱います。これらの攻撃はＤＮＳ要
請と応答を途中で捕えらえて変えることを要求します。ＤＮＳＳＥＣはこの
種類の攻撃から守るよう意図されます。この章はＤＮＳＳＥＣが利用可能で
はない状態を扱います。これは推薦された展開の筋書きではありません。

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.
ゲートウェイフィールドは無変更かあるいは空です。従ってＩＫＥ交渉はオ
リジナルの末端システムで起こるでしょう。この攻撃が成功するために、攻
撃者はＩＫＥ交渉に対する中間者攻撃を行わなくてはなりません。この攻撃
は攻撃者がＩＫＥとデータパケットの転送パスのパケットを捕獲して修正す
ることが可能であることを要求します。

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.
もし攻撃者がこのＩＫＥ交渉に対する中間者攻撃を行うことが可能ではない
なら、ＩＫＥ交渉が失敗してサービス妨害が結果的に発生するでしょう。

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.
もし攻撃者がＤＮＳに対して能動的な攻撃を開始することが可能であるだけ
ではなくＩＫＥとＩＰｓｅｃ交渉に対する中間者攻撃を行う立場にあるなら、
攻撃者は結果として生じるＩＰｓｅｃチャネルを危険にすることが可能であ
るでしょう。攻撃者がこれが成功させるためにＩＫＥ交渉の両側に対する能
動的なＤＮＳ攻撃を行うことができなければならないことに注意してくださ
い。

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.
能動的攻撃の２番目の種類は攻撃者が攻撃者の制御の下のノードを指し示す
ためにゲートウェイアドレスを置き換えるものです。攻撃者はそれから公開
鍵を置き換えるか削除します。もし公開鍵が削除されたなら、攻撃者は２番
目のレコードで自分自身の正確な公開鍵を供給できます。

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.
この２番目の書式は、攻撃者が本当の宛先に２番目のトンネルを作ることが
できるので、単純な中間者攻撃を作ります。前と同じように、これは攻撃者
が応答者に対して同じく能動的な攻撃を開始することを要求することに注意
しててください。

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.
中間者攻撃は平文パケットを元の目的地に転送することができないことに注
意してください。宛先が平文での会話を期待していても、本来の送り主への
答で、送り主はすでに暗号文を期待するポリシを作ってしまっているでしょ
う。それで、攻撃者は両方向のトラフィックを途中で捕える必要があるで
しょう。ある場合に、攻撃者はネットワークアドレス／ポート翻訳（ＮＡＴ
／ＮＡＰＴ）技術の使用によって完全な妨害を達成することが可能であるか
もしれません。

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.
この攻撃は、攻撃者がエンドエンド転送パス上にいる必要がないから、最初
のより容易です。攻撃者はただＤＮＳ応答を修正することが可能である必要
があるだけです。これは、種々の種類の競合攻撃やＤＮＳキャッシュを汚染
する方法による、パケット修正によって可能です。

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.
それで、検証されていない状態（ＤＮＳＳＥＣがないかソースへの信頼パス
がない）の得られたレコードで、非ヌルゲートウェイがあるものは無視しな
くてはなりません(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.

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

5. IANA Considerations
5. ＩＡＮＡ考慮

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

This document creates two new IANA registries, both specific to the
IPSECKEY Resource Record:
この書類は、IPSECKEY資源レコードに固有の、２つの新しいＩＡＮＡ登記所
を作ります：

This document creates an IANA registry for the algorithm type field.
この文書はアルゴリズムタイプフィールドのためにＩＡＮＡ登記所を作ります。

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]).
価０と１と２が２.４章で定義されます。アルゴリズム３から２５５までの
番号がＩＥＴＦ合意によって割り当てられることができます
（ＲＦＣ２４３４［５］参照）。

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

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]).
価０と１と２と３が２.３章で定義されます。ゲートウェイタイプ４から
２５５までの数が標準化行動によって割り当てできます
（ＲＦＣ２４３４［５］参照）。

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
著作権表示全文

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 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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。

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

Acknowledgement
謝辞

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

Japanese translation by Ishida So