この文書は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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。