[要約] RFC 2230は、DNSのための鍵交換委任レコードに関する規格です。このRFCの目的は、DNSセキュリティの向上と、鍵交換プロセスの効率化を図ることです。
Network Working Group R. Atkinson
Request for Comments: 2230 NRL
Category: Informational November 1997
Key Exchange Delegation Record for the DNS
DNSのキー交換委任レコード
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
ABSTRACT
概要
This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. It can be used with several security services. For example, a system seeking to use IP Security [RFC-1825, RFC-1826, RFC-1827] to protect IP packets for a given destination can use this mechanism to determine the set of authorised remote key exchanger systems for that destination.
このノートでは、1つのノードが2番目のノードのキー交換器として機能するための承認が委任され、セキュアDNSを介して利用可能になるメカニズムについて説明します。このメカニズムは、セキュアDNSでのみ使用することを目的としています。複数のセキュリティサービスで使用できます。たとえば、IPセキュリティ[RFC-1825、RFC-1826、RFC-1827]を使用して特定の宛先のIPパケットを保護しようとするシステムは、このメカニズムを使用して、その宛先の許可されたリモートキーエクスチェンジャーシステムのセットを決定できます。
The Domain Name System (DNS) is the standard way that Internet nodes locate information about addresses, mail exchangers, and other data relating to remote Internet nodes. [RFC-1035, RFC-1034] More recently, Eastlake and Kaufman have defined standards-track security extensions to the DNS. [RFC-2065] These security extensions can be used to authenticate signed DNS data records and can also be used to store signed public keys in the DNS.
ドメインネームシステム（DNS）は、インターネットノードがアドレス、メールエクスチェンジャ、およびリモートインターネットノードに関連するその他のデータに関する情報を見つける標準的な方法です。 [RFC-1035、RFC-1034]最近では、EastlakeとKaufmanがDNSに対する標準トラックのセキュリティ拡張を定義しています。 [RFC-2065]これらのセキュリティ拡張機能は、署名されたDNSデータレコードを認証するために使用でき、署名された公開鍵をDNSに格納するためにも使用できます。
The KX record is useful in providing an authenticatible method of delegating authorisation for one node to provide key exchange services on behalf of one or more, possibly different, nodes. This note specifies the syntax and semantics of the KX record, which is currently in limited deployment in certain IP-based networks. The reader is assumed to be familiar with the basics of DNS, including familiarity with [RFC-1035, RFC-1034]. This document is not on the IETF standards-track and does not specify any level of standard. This document merely provides information for the Internet community.
KXレコードは、1つまたは複数の、場合によっては異なるノードに代わってキー交換サービスを提供するために、1つのノードに認証を委任する認証可能な方法を提供するのに役立ちます。この注記では、KXレコードの構文とセマンティクスを指定します。これは、現在、特定のIPベースのネットワークでの展開が制限されています。読者は、[RFC-1035、RFC-1034]に精通していることを含め、DNSの基本に精通していることを前提としています。このドキュメントは、IETF標準化過程にありませんし、標準のレベルを指定しません。このドキュメントは、インターネットコミュニティに情報を提供するだけです。
This document relies upon the concept of "identity domination". This concept might be new to the reader and so is explained in this section. The subject of endpoint naming for security associations has historically been somewhat contentious. This document takes no position on what forms of identity should be used. In a network, there are several forms of identity that are possible.
このドキュメントは、「アイデンティティの支配」の概念に依存しています。この概念は読者にとって新しいものである可能性があるため、このセクションで説明します。セキュリティアソシエーションのエンドポイントの命名については、これまで幾分論争がありました。このドキュメントでは、どのような形式のIDを使用する必要があるかについては触れていません。ネットワークでは、いくつかの形式のIDが可能です。
For example, IP Security has defined notions of identity that include: IP Address, IP Address Range, Connection ID, Fully-Qualified Domain Name (FQDN), and User with Fully Qualified Domain Name (USER FQDN).
たとえば、IPセキュリティでは、IPアドレス、IPアドレス範囲、接続ID、完全修飾ドメイン名（FQDN）、完全修飾ドメイン名を持つユーザー（USER FQDN）などのIDの概念を定義しています。
A USER FQDN identity dominates a FQDN identity. A FQDN identity in turn dominates an IP Address identity. Similarly, a Connection ID dominates an IP Address identity. An IP Address Range dominates each IP Address identity for each IP address within that IP address range. Also, for completeness, an IP Address identity is considered to dominate itself.
USER FQDN IDはFQDN IDを支配します。次に、FQDN IDがIPアドレスIDを支配します。同様に、接続IDはIPアドレスIDを支配します。 IPアドレス範囲は、そのIPアドレス範囲内の各IPアドレスの各IPアドレスIDを支配します。また、完全を期すために、IPアドレスIDはそれ自体を支配していると見なされます。
This document specifies a new kind of DNS Resource Record (RR), known as the Key Exchanger (KX) record. A Key Exchanger Record has the mnemonic "KX" and the type code of 36. Each KX record is associated with a fully-qualified domain name. The KX record is modeled on the MX record described in [Part86]. Any given domain, subdomain, or host entry in the DNS might have a KX record.
このドキュメントでは、Key Exchanger（KX）レコードと呼ばれる新しい種類のDNSリソースレコード（RR）を指定します。 Key Exchanger Recordには、ニーモニック「KX」とタイプコード36があります。各KXレコードは、完全修飾ドメイン名に関連付けられています。 KXレコードは、[Part86]で説明されているMXレコードをモデルにしています。 DNSの特定のドメイン、サブドメイン、またはホストエントリには、KXレコードが含まれる場合があります。
In these two examples, let S be the originating node and let D be the destination node. S2 is another node on the same subnet as S. D2 is another node on the same subnet as D. R1 and R2 are IPsec-capable routers. The path from S to D goes via first R1 and later R2. The return path from D to S goes via first R2 and later R1.
これらの2つの例では、Sを発信元ノード、Dを宛先ノードとします。 S2はSと同じサブネット上の別のノードです。D2はDと同じサブネット上の別のノードです。R1とR2はIPsec対応ルーターです。 SからDへのパスは、最初のR1とその後のR2を経由します。 DからSへの戻りパスは、最初のR2とその後のR1を経由します。
IETF-standard IP Security uses unidirectional Security Associations [RFC-1825]. Therefore, a typical IP session will use a pair of related Security Associations, one in each direction. The examples below talk about how to setup an example Security Association, but in practice a pair of matched Security Associations will normally be used.
IETF標準のIPセキュリティは、単方向のセキュリティアソシエーションを使用します[RFC-1825]。したがって、一般的なIPセッションでは、関連するセキュリティアソシエーションのペアを各方向に1つずつ使用します。以下の例では、サンプルのセキュリティアソシエーションのセットアップ方法について説明していますが、実際には、通常、一致するセキュリティアソシエーションのペアが使用されます。
If neither S nor D implements IPsec, security can still be provided between R1 and R2 by building a secure tunnel. This can use either AH or ESP.
SもDもIPsecを実装していない場合でも、安全なトンネルを構築することにより、R1とR2の間にセキュリティを提供できます。これはAHまたはESPのいずれかを使用できます。
S ---+ +----D
| |
+- R1 -----[zero or more routers]-------R2-+
| |
S2---+ +----D2
Figure 1: Network Diagram for Subnet-to-Subnet Example
図1：サブネット間の例のネットワーク図
In this example, R1 makes the policy decision to provide the IPsec service for traffic from R1 destined for R2. Once R1 has decided that the packet from S to D should be protected, it performs a secure DNS lookup for the records associated with domain D. If R1 only knows the IP address for D, then a secure reverse DNS lookup will be necessary to determine the domain D, before that forward secure DNS lookup for records associated with domain D. If these DNS records of domain D include a KX record for the IPsec service, then R1 knows which set of nodes are authorised key exchanger nodes for the destination D.
この例では、R1はR1からR2宛てのトラフィックにIPsecサービスを提供するというポリシー決定を行います。 R1は、SからDへのパケットを保護する必要があると判断すると、ドメインDに関連付けられたレコードに対して安全なDNSルックアップを実行します。R1がDのIPアドレスのみを知っている場合は、安全な逆DNSルックアップが必要です。ドメインD、その前にドメインDに関連付けられたレコードの安全なDNSルックアップを転送します。ドメインDのこれらのDNSレコードにIPsecサービスのKXレコードが含まれている場合、R1はどのセットのノードが宛先Dの承認されたキー交換ノードであるかを認識しています。
In this example, let there be at least one KX record for D and let the most preferred KX record for D point at R2. R1 then selects a key exchanger (in this example, R2) for D from the list obtained from the secure DNS. Then R1 initiates a key management session with that key exchanger (in this example, R2) to setup an IPsec Security Association between R1 and D. In this example, R1 knows (either by seeing an outbound packet arriving from S destined to D or via other methods) that S will be sending traffic to D. In this example R1's policy requires that traffic from S to D should be segregated at least on a host-to-host basis, so R1 desires an IPsec Security Association with source identity that dominates S, proxy identity that dominates R1, and destination identity that dominates R2.
この例では、Dの少なくとも1つのKXレコードがあり、Dの最も好ましいKXレコードがR2をポイントしているとします。次に、R1は、安全なDNSから取得したリストからDのキー交換器（この例ではR2）を選択します。次に、R1はそのキーエクスチェンジャー（この例ではR2）とのキー管理セッションを開始して、R1とDの間のIPsecセキュリティアソシエーションをセットアップします。この例では、R1は（SからD宛てに送信されたアウトバウンドパケットを見るか、または他の方法）SがDにトラフィックを送信することになります。この例では、R1のポリシーでは、SからDへのトラフィックを少なくともホスト間で分離する必要があるため、R1は、支配的なソースIDを持つIPsecセキュリティアソシエーションを望んでいます。 S、R1を支配するプロキシID、およびR2を支配する宛先ID。
In turn, R2 is able to authenticate the delegation of Key Exchanger authorisation for target S to R1 by making an authenticated forward DNS lookup for KX records associated with S and verifying that at least one such record points to R1. The identity S is typically given to R2 as part of the key management process between R1 and R2.
次に、R2は、Sに関連付けられたKXレコードの認証済みDNSルックアップを実行し、少なくとも1つのそのようなレコードがR1をポイントしていることを確認することにより、ターゲットSのR1へのキーエクスチェンジャー承認の委任を認証できます。 ID Sは通常、R1とR2の間の鍵管理プロセスの一部としてR2に与えられます。
If D initially only knows the IP address of S, then it will need to perform a secure reverse DNS lookup to obtain the fully-qualified domain name for S prior to that secure forward DNS lookup.
Dが最初にSのIPアドレスしかわかっていない場合は、安全なDNS逆引き参照を実行して、安全な正引きDNS参照の前にSの完全修飾ドメイン名を取得する必要があります。
If R2 does not receive an authenticated DNS response indicating that R1 is an authorised key exchanger for S, then D will not accept the SA negotiation from R1 on behalf of identity S.
R2が、R1がSの許可された鍵交換者であることを示す認証済みDNS応答を受信しない場合、DはID Sに代わってR1からのSAネゴシエーションを受け入れません。
If the proposed IPsec Security Association is acceptable to both R1 and R2, each of which might have separate policies, then they create that IPsec Security Association via Key Management.
提案されたIPsecセキュリティアソシエーションがR1とR2の両方に受け入れ可能であり、それぞれに個別のポリシーがある場合、キー管理を介してそのIPsecセキュリティアソシエーションを作成します。
Note that for unicast traffic, Key Management will typically also setup a separate (but related) IPsec Security Association for the return traffic. That return IPsec Security Association will have equivalent identities. In this example, that return IPsec Security Association will have a source identity that dominates D, a proxy identity that dominates R2, and a destination identity that dominates R1.
ユニキャストトラフィックの場合、キー管理では通常、リターントラフィック用に別の（ただし関連する）IPsecセキュリティアソシエーションもセットアップされます。その戻りIPsecセキュリティアソシエーションは同等のIDを持ちます。この例では、返されるIPsecセキュリティアソシエーションには、Dを支配するソースID、R2を支配するプロキシID、およびR1を支配する宛先IDがあります。
Once the IPsec Security Association has been created, then R1 uses it to protect traffic from S destined for D via a secure tunnel that originates at R1 and terminates at R2. For the case of unicast, R2 will use the return IPsec Security Association to protect traffic from D destined for S via a secure tunnel that originates at R2 and terminates at R1.
IPsecセキュリティアソシエーションが作成されると、R1はそれを使用して、R1で始まりR2で終わる安全なトンネルを介してD宛てのSからのトラフィックを保護します。ユニキャストの場合、R2はリターンIPsecセキュリティアソシエーションを使用して、R2で始まり、R1で終わる安全なトンネルを介して、S宛てのトラフィックをDから保護します。
Consider the case where D and R1 implement IPsec, but S does not implement IPsec, which is an interesting variation on the previous example. This example is shown in Figure 2 below.
DとR1がIPsecを実装しているが、SはIPsecを実装していない場合を考えてみましょう。これは、前の例の興味深いバリエーションです。この例を下の図2に示します。
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
Figure 2: Network Diagram for Subnet-to-Host Example
図2：サブネットからホストへの例のネットワーク図
In this example, R1 makes the policy decision that IP Security is needed for the packet travelling from S to D. Then, R1 performs the secure DNS lookup for D and determines that D is its own key exchanger, either from the existence of a KX record for D pointing to D or from an authenticated DNS response indicating that no KX record exists for D. If R1 does not initially know the domain name of D, then prior to the above forward secure DNS lookup, R1 performs a secure reverse DNS lookup on the IP address of D to determine the fully-qualified domain name for that IP address. R1 then initiates key management with D to create an IPsec Security Association on behalf of S.
この例では、R1はSからDに移動するパケットにIPセキュリティが必要であるというポリシーの決定を行います。次に、R1はDの安全なDNSルックアップを実行し、KXの存在から、Dが独自のキー交換器であると判断しますDを指すDのレコード、またはDのKXレコードが存在しないことを示す認証済みDNS応答からのレコード。R1が最初にDのドメイン名を認識していない場合、上記の安全な前方DNSルックアップの前に、R1は安全な逆DNSルックアップを実行します。 DのIPアドレスで、そのIPアドレスの完全修飾ドメイン名を決定します。次に、R1はDを使用してキー管理を開始し、Sに代わってIPsecセキュリティアソシエーションを作成します。
In turn, D can verify that R1 is authorised to create an IPsec Security Association on behalf of S by performing a DNS KX record lookup for target S. R1 usually provides identity S to D via key management. If D only has the IP address of S, then D will need to perform a secure reverse lookup on the IP address of S to determine domain name S prior to the secure forward DNS lookup on S to locate the KX records for S.
次に、Dは、ターゲットSに対してDNS KXレコードルックアップを実行することにより、R1がSに代わってIPsecセキュリティアソシエーションを作成することを承認されていることを確認できます。R1は通常、キー管理を介してSからDにIDを提供します。 DがSのIPアドレスしか持っていない場合、DはSのKXレコードを見つけるためにSでセキュアなDNSルックアップを行う前に、SのIPアドレスでセキュアな逆ルックアップを実行してドメイン名Sを決定する必要があります。
If D does not receive an authenticated DNS response indicating that R1 is an authorised key exchanger for S, then D will not accept the SA negotiation from R1 on behalf of identity S.
Dが、R1がSの許可されたキー交換者であることを示す認証済みDNS応答を受信しない場合、DはアイデンティティSに代わってR1からのSAネゴシエーションを受け入れません。
If the IPsec Security Association is successfully established between R1 and D, that IPsec Security Association has a source identity that dominates S's IP address, a proxy identity that dominates R1's IP address, and a destination identity that dominates D's IP address.
IPsecセキュリティアソシエーションがR1とDの間で正常に確立された場合、そのIPsecセキュリティアソシエーションには、SのIPアドレスを支配するソースID、R1のIPアドレスを支配するプロキシID、およびDのIPアドレスを支配する宛先IDがあります。
Finally, R1 begins providing the security service for packets from S that transit R1 destined for D. When D receives such packets, D examines the SA information during IPsec input processing and sees that R1's address is listed as valid proxy address for that SA and that S is the source address for that SA. Hence, D knows at input processing time that R1 is authorised to provide security on behalf of S. Therefore packets coming from R1 with valid IP security that claim to be from S are trusted by D to have really come from S.
最後に、R1は、D宛てのR1を通過するSからのパケットにセキュリティサービスの提供を開始します。Dがそのようなパケットを受信すると、DはIPsec入力処理中にSA情報を調べ、R1のアドレスがそのSAの有効なプロキシアドレスとしてリストされていることを確認します。 SはそのSAの送信元アドレスです。したがって、Dは入力処理時に、R1がSに代わってセキュリティを提供することを許可されていることを知っています。したがって、Sからのものであると主張する有効なIPセキュリティを備えたR1からのパケットは、Dによって本当にSからのものであると信頼されます。
Now consider the above case from D's perspective (i.e. where D is sending IP packets to S). This variant is sometimes known as the Mobile Host or "roadwarrier" case. The same basic concepts apply, but the details are covered here in hope of improved clarity.
次に、Dの観点から上記のケースを検討します（つまり、DがIPパケットをSに送信する場合）。この変種は、モバイルホストまたは「ロードウォーリア」ケースと呼ばれることもあります。基本的な概念は同じですが、わかりやすくするために、ここで詳細を説明します。
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
Figure 3: Network Diagram for Host-to-Subnet Example
図3：ホストからサブネットへの例のネットワーク図
In this example, D makes the policy decision that IP Security is needed for the packets from D to S. Then D performs the secure DNS lookup for S and discovers that a KX record for S exists and points at R1. If D only has the IP address of S, then it performs a secure reverse DNS lookup on the IP address of S prior to the forward secure DNS lookup for S.
この例では、DはDからSへのパケットにIPセキュリティが必要であるというポリシー決定を行います。次に、DはSのセキュアDNSルックアップを実行し、SのKXレコードが存在し、R1をポイントしていることを検出します。 DのIPアドレスがSのみの場合、DはSのフォワードセキュアDNSルックアップの前に、SのIPアドレスでセキュアな逆DNSルックアップを実行します。
D then initiates key management with R1, where R1 is acting on behalf of S, to create an appropriate Security Association. Because D is acting as its own key exchanger, R1 does not need to perform a secure DNS lookup for KX records associated with D.
次に、DはR1を使用してキー管理を開始し、R1はSの代わりに動作して、適切なセキュリティアソシエーションを作成します。 Dは独自のキーエクスチェンジャーとして機能しているため、R1はDに関連付けられたKXレコードの安全なDNSルックアップを実行する必要はありません。
D and R1 then create an appropriate IPsec Security Security Association. This IPsec Security Association is setup as a secure tunnel with a source identity that dominates D's IP Address and a destination identity that dominates R1's IP Address. Because D performs IPsec for itself, no proxy identity is needed in this IPsec Security Association. If the proxy identity is non-null in this situation, then the proxy identity must dominate D's IP Address.
DとR1は、適切なIPsecセキュリティセキュリティアソシエーションを作成します。このIPsecセキュリティアソシエーションは、DのIPアドレスを支配するソースIDとR1のIPアドレスを支配する宛先IDを持つ安全なトンネルとしてセットアップされます。 Dは自身でIPsecを実行するため、このIPsecセキュリティアソシエーションではプロキシIDは必要ありません。この状況でプロキシIDがnull以外の場合、プロキシIDはDのIPアドレスを支配する必要があります。
Finally, D sends secured IP packets to R1. R1 receives those packets, provides IPsec input processing (including appropriate inner/outer IP address validation), and forwards valid packets along to S.
最後に、Dは保護されたIPパケットをR1に送信します。 R1はこれらのパケットを受信し、IPsec入力処理（適切な内部/外部IPアドレス検証を含む）を提供し、有効なパケットをSに転送します。
This mechanism can be extended for use with other services as well. To give some insight into other possible uses, this section discusses use of KX records in environments using a Key Distribution Center (KDC), such as Kerberos [KN93], and a possible use of KX records in conjunction with mobile nodes accessing the network via a dialup service.
このメカニズムは、他のサービスでも使用できるように拡張できます。このセクションでは、他の可能な使用法について洞察を与えるために、Kerberos [KN93]などのキー配布センター（KDC）を使用する環境でのKXレコードの使用法と、経由でネットワークにアクセスするモバイルノードと組み合わせたKXレコードの使用法について説明します。ダイアルアップサービス。
This example considers the situation of a destination node implementing IPsec that can only obtain its Security Association information from a Key Distribution Center (KDC). Let the KDC implement both the KDC protocol and also a non-KDC key management protocol (e.g. ISAKMP). In such a case, each client node of the KDC might have its own KX record pointing at the KDC so that nodes not implementing the KDC protocol can still create Security Associations with each of the client nodes of the KDC.
この例では、キー配布センター（KDC）からのみセキュリティアソシエーション情報を取得できるIPsecを実装する宛先ノードの状況を検討します。 KDCにKDCプロトコルと非KDCキー管理プロトコル（ISAKMPなど）の両方を実装させます。このような場合、KDCの各クライアントノードは、KDCをポイントする独自のKXレコードを持っている可能性があるため、KDCプロトコルを実装していないノードでも、KDCの各クライアントノードとのセキュリティアソシエーションを作成できます。
In the event the session initiator were not using the KDC but the session target was an IPsec node that only used the KDC, the initiator would find the KX record for the target pointing at the KDC. Then, the external key management exchange (e.g. ISAKMP) would be between the initiator and the KDC. Then the KDC would distribute the IPsec SA to the KDC-only IPsec node using the KDC. The IPsec traffic itself could travel directly between the initiator and the destination node.
セッションイニシエーターがKDCを使用していないが、セッションターゲットがKDCのみを使用するIPsecノードである場合、イニシエーターはKDCを指すターゲットのKXレコードを見つけます。次に、外部キー管理交換（ISAKMPなど）がイニシエーターとKDCの間で行われます。次に、KDCはKDCを使用してIPsec SAをKDCのみのIPsecノードに配布します。 IPsecトラフィック自体は、イニシエーターと宛先ノードの間を直接移動できます。
In the event the initiator node could only use the KDC and the target were not using the KDC, the initiator would send its request for a key to the KDC. The KDC would then initiate an external key management exchange (e.g. ISAKMP) with a node that the target's KX record(s) pointed to, on behalf of the initiator node.
イニシエーターノードがKDCのみを使用でき、ターゲットがKDCを使用していない場合、イニシエーターはキーの要求をKDCに送信します。次に、KDCは、イニシエーターノードの代わりに、ターゲットのKXレコードがポイントしたノードとの外部キー管理交換（ISAKMPなど）を開始します。
The target node could verify that the KDC were allowed to proxy for the initiator node by looking up the KX records for the initiator node and finding a KX record for the initiator that listed the KDC.
ターゲット・ノードは、イニシエーター・ノードのKXレコードを検索し、KDCをリストしたイニシエーターのKXレコードを見つけることにより、KDCがイニシエーター・ノードのプロキシーを許可されていることを確認できます。
Then the external key exchange would be performed between the KDC and the target node. Then the KDC would distribute the resulting IPsec Security Association to the initiator. Again, IPsec traffic itself could travel directly between the initiator and the destination.
次に、外部キー交換がKDCとターゲットノード間で実行されます。次に、KDCは結果のIPsecセキュリティアソシエーションをイニシエーターに配布します。この場合も、IPsecトラフィック自体が発信側と宛先の間を直接移動する可能性があります。
This example outlines a possible use of KX records with mobile hosts that dial into the network via PPP and are dynamically assigned an IP address and domain-name at dial-in time.
この例では、PPPを介してネットワークにダイヤルインし、ダイヤルイン時にIPアドレスとドメイン名が動的に割り当てられるモバイルホストでのKXレコードの可能な使用法を概説します。
Consider the situation where each mobile node is dynamically assigned both a domain name and an IP address at the time that node dials into the network. Let the policy require that each mobile node act as its own Key Exchanger. In this case, it is important that dial-in nodes use addresses from one or more well known IP subnets or address pools dedicated to dial-in access. If that is true, then no KX record or other action is needed to ensure that each node will act as its own Key Exchanger because lack of a KX record indicates that the node is its own Key Exchanger.
ノードがネットワークにダイヤルインするときに、各モバイルノードにドメイン名とIPアドレスの両方が動的に割り当てられる状況を考えます。ポリシーで、各モバイルノードが独自のキーエクスチェンジャーとして機能することを要求します。この場合、ダイヤルインノードは、1つ以上の既知のIPサブネットまたはダイヤルインアクセス専用のアドレスプールからのアドレスを使用することが重要です。これがtrueの場合、KXレコードがないことはノードが独自のキーエクスチェンジャーであることを示しているため、各ノードが独自のキーエクスチェンジャーとして機能することを保証するためのKXレコードやその他のアクションは必要ありません。
Consider the situation where the mobile node's domain name remains constant but its IP address changes. Let the policy require that each mobile node act as its own Key Exchanger. In this case, there might be operational problems when another node attempts to perform a secure reverse DNS lookup on the IP address to determine the corresponding domain name. The authenticated DNS binding (in the form of a PTR record) between the mobile node's currently assigned IP address and its permanent domain name will need to be securely updated each time the node is assigned a new IP address. There are no mechanisms for accomplishing this that are both IETF-standard and widely deployed as of the time this note was written. Use of Dynamic DNS Update without authentication is a significant security risk and hence is not recommended for this situation.
モバイルノードのドメイン名は一定のままですが、IPアドレスが変更される状況を考えてみます。ポリシーで、各モバイルノードが独自のキーエクスチェンジャーとして機能することを要求します。この場合、別のノードがIPアドレスに対して安全なDNS逆引き参照を実行して、対応するドメイン名を決定しようとすると、操作上の問題が発生する可能性があります。ノードに新しいIPアドレスが割り当てられるたびに、モバイルノードの現在割り当てられているIPアドレスとその永続的なドメイン名の間の（PTRレコードの形式の）認証済みDNSバインディングを安全に更新する必要があります。 IETF標準であり、このメモが作成された時点で広く展開されている、これを達成するためのメカニズムはありません。認証なしで動的DNS更新を使用することは重大なセキュリティリスクであるため、この状況では推奨されません。
A KX record has the DNS TYPE of "KX" and a numeric value of 36. A KX record is a member of the Internet ("IN") CLASS in the DNS. Each KX record is associated with a <domain-name> entry in the DNS. A KX record has the following textual syntax:
KXレコードのDNS TYPEは「KX」で、数値は36です。KXレコードは、DNSのインターネット（「IN」）クラスのメンバーです。各KXレコードは、DNSの<domain-name>エントリに関連付けられています。 KXレコードのテキスト構文は次のとおりです。
<domain-name> IN KX <preference> <domain-name>
For this description, let the <domain-name> item to the left of the "KX" string be called <domain-name 1> and the <domain-name> item to the right of the "KX" string be called <domain-name 2>. <preference> is a non-negative integer.
この説明では、「KX」文字列の左側にある<domain-name>項目を<domain-name 1>と呼び、「KX」文字列の右側にある<domain-name>項目を<domain -name 2>。 <preference>は負でない整数です。
Internet nodes about to initiate a key exchange with <domain-name 1> should instead contact <domain-name 2> to initiate the key exchange for a security service between the initiator and <domain-name 2>. If more than one KX record exists for <domain-name 1>, then the <preference> field is used to indicate preference among the systems delegated to. Lower values are preferred over higher values. The <domain-name 2> is authorised to provide key exchange services on behalf of <domain-name 1>. The <domain-name 2> MUST have a CNAME record, an A record, or an AAAA record associated with it.
<domain-name 1>とのキー交換を開始しようとしているインターネットノードは、代わりに<domain-name 2>に連絡して、イニシエーターと<domain-name 2>間のセキュリティサービスのキー交換を開始する必要があります。 <domain-name 1>に複数のKXレコードが存在する場合、<preference>フィールドを使用して、委任先のシステム間の優先順位を示します。高い値よりも低い値が優先されます。 <domain-name 2>は、<domain-name 1>に代わって鍵交換サービスを提供することを許可されています。 <domain-name 2>には、CNAMEレコード、Aレコード、またはAAAAレコードが関連付けられている必要があります。
The KX DNS record has the following RDATA format:
KX DNSレコードのRDATA形式は次のとおりです。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGER /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ただし：
PREFERENCE A 16 bit non-negative integer which specifies the preference given to this RR among other KX records at the same owner. Lower values are preferred.
PREFERENCE同じ所有者の他のKXレコードの中でこのRRに与えられる優先順位を指定する16ビットの非負整数。低い値が推奨されます。
EXCHANGER A <domain-name> which specifies a host willing to act as a mail exchange for the owner name.
EXCHANGER <domain-name>は、所有者名のメール交換として機能するホストを指定します。
KX records MUST cause type A additional section processing for the host specified by EXCHANGER. In the event that the host processing the DNS transaction supports IPv6, KX records MUST also cause type AAAA additional section processing.
KXレコードは、EXCHANGERで指定されたホストのタイプA追加セクション処理を引き起こす必要があります。 DNSトランザクションを処理するホストがIPv6をサポートする場合、KXレコードはタイプAAAA追加セクション処理も引き起こす必要があります。
The KX RDATA field MUST NOT be compressed.
KX RDATAフィールドは圧縮してはなりません（MUST NOT）。
KX records MUST always be signed using the method(s) defined by the DNS Security extensions specified in [RFC-2065]. All unsigned KX records MUST be ignored because of the security vulnerability caused by assuming that unsigned records are valid. All signed KX records whose signatures do not correctly validate MUST be ignored because of the potential security vulnerability in trusting an invalid KX record.
KXレコードは常に、[RFC-2065]で指定されているDNSセキュリティ拡張によって定義されたメソッドを使用して署名されている必要があります。未署名のレコードが有効であると想定することによって引き起こされるセキュリティの脆弱性のため、すべての未署名のKXレコードは無視する必要があります。署名が正しく検証されないすべての署名済みKXレコードは、無効なKXレコードを信頼する潜在的なセキュリティの脆弱性があるため、無視する必要があります。
KX records MUST be ignored by systems not implementing Secure DNS because such systems have no mechanism to authenticate the KX record.
セキュアDNSを実装していないシステムではKXレコードを無視する必要があります。そのようなシステムにはKXレコードを認証するメカニズムがないためです。
If a node does not have a permanent DNS entry and some form of Dynamic DNS Update is in use, then those dynamic DNS updates MUST be fully authenticated to prevent an adversary from injecting false DNS records (especially the KX, A, and PTR records) into the Domain Name System. If false records were inserted into the DNS without being signed by the Secure DNS mechanisms, then a denial-of-service attack results. If false records were inserted into the DNS and were (erroneously) signed by the signing authority, then an active attack results.
ノードに永続的なDNSエントリがなく、何らかの形の動的DNS更新が使用されている場合、それらの動的DNS更新は完全に認証され、敵が偽のDNSレコード（特にKX、A、およびPTRレコード）を挿入するのを防ぐ必要があります。ドメインネームシステムに。セキュアDNSメカニズムによって署名されずに偽のレコードがDNSに挿入された場合、サービス拒否攻撃が発生します。誤ったレコードがDNSに挿入され、署名機関によって（誤って）署名された場合、アクティブな攻撃が発生します。
Myriad serious security vulnerabilities can arise if the restrictions throuhout this document are not strictly adhered to. Implementers should carefully consider the openly published issues relating to DNS security [Bell95,Vixie95] as they build their implementations. Readers should also consider the security considerations discussed in the DNS Security Extensions document [RFC-2065].
このドキュメントの制限が厳守されない場合、無数の深刻なセキュリティの脆弱性が発生する可能性があります。実装者は、実装を構築する際に、DNSセキュリティ[Bell95、Vixie95]に関連して公開されている問題を慎重に検討する必要があります。読者は、DNS Security Extensionsドキュメント[RFC-2065]で説明されているセキュリティの考慮事項も考慮する必要があります。
[RFC-1825] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[RFC-1825] Atkinson、R。、「IP Authentication Header」、RFC 1826、1995年8月。
[RFC-1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[RFC-1827] Atkinson、R。、「IP Encapsulating Security Payload」、RFC 1827、1995年8月。
[Bell95] Bellovin, S., "Using the Domain Name System for System
Break-ins", Proceedings of 5th USENIX UNIX Security
Symposium, USENIX Association, Berkeley, CA, June 1995.
ftp://ftp.research.att.com/dist/smb/dnshack.ps
[RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC-2065] Eastlake、D。、およびC. Kaufman、「ドメインネームシステムセキュリティ拡張機能」、RFC 2065、1997年1月。
[RFC-1510] Kohl J., and C. Neuman, "The Kerberos Network Authentication Service", RFC 1510, September 1993.
[RFC-1510]コールJ.、およびC.ノイマン、「Kerberosネットワーク認証サービス」、RFC 1510、1993年9月。
[RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC-1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC-1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
the 5th USENIX UNIX Security Symposium, USENIX
Association, Berkeley, CA, June 1995.
ftp://ftp.vix.com/pri/vixie/bindsec.psf
ACKNOWLEDGEMENTS
謝辞
Development of this DNS record was primarily performed during 1993 through 1995. The author's work on this was sponsored jointly by the Computing Systems Technology Office (CSTO) of the Advanced Research Projects Agency (ARPA) and by the Information Security Program Office (PD71E), Space & Naval Warface Systems Command (SPAWAR). In that era, Dave Mihelcic and others provided detailed review and constructive feedback. More recently, Bob Moscowitz and Todd Welch provided detailed review and constructive feedback of a work in progress version of this document.
このDNSレコードの開発は、主に1993年から1995年の間に行われました。これに関する著者の作業は、Advanced Research Projects Agency（ARPA）のComputing Systems Technology Office（CSTO）とInformation Security Program Office（PD71E）が共同で主催しました。 Space＆Naval Warface Systems Command（SPAWAR）。その時代、Dave Mihelcicらは、詳細なレビューと建設的なフィードバックを提供しました。最近になって、Bob MoscowitzとTodd Welchが、このドキュメントの進行中のバージョンの詳細なレビューと建設的なフィードバックを提供しました。
AUTHOR'S ADDRESS
著者のアドレス
Randall Atkinson Code 5544 Naval Research Laboratory 4555 Overlook Avenue, SW Washington, DC 20375-5337
ランドールアトキンソンコード5544海軍研究所4555オーバールックアベニュー、SWワシントンDC 20375-5337
Phone: (DSN) 354-8590 EMail: atkinson@itd.nrl.navy.mil
電話：（DSN）354-8590メール：atkinson@itd.nrl.navy.mil
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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 implmentation may be prepared, copied, published andand 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。