RFC4322 日本語訳
4322 Opportunistic Encryption using the Internet Key Exchange (IKE).M. Richardson, D.H. Redelmeier. December 2005. (Format: TXT=95453 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Richardson
Request for Comments: 4322 SSW
Category: Informational D.H. Redelmeier
Mimosa
December 2005
コメントを求めるワーキンググループM.リチャードソンの要求をネットワークでつないでください: 4322年のSSWカテゴリ: 情報のD.H.Redelmeierミモザ2005年12月
Opportunistic Encryption using the Internet Key Exchange (IKE)
インターネット・キー・エクスチェンジを使用する便宜主義的な暗号化(イケ)
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.
リナックスFreeS/WANプロジェクトによって設計されていて、実装されるようにこのドキュメントは便宜主義的な暗号化(OE)について説明します。 OEはインターネット・キー・エクスチェンジ(IKE)とIPsecプロトコルを使用します。 目的はシステムの組に、特定の少しもかかわった根回しなしで安全なコミュニケーションのための暗号化を許容することです。 DNSは、かかわったそれぞれのシステムの公開鍵を分配するのに使用されます。 これは受け身の攻撃に抵抗力があります。 DNS Security(DNSSEC)の使用はまた、活発な攻撃者に対してこのシステムを固定します。
As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance.
その結果、管理オーバーヘッドはシステムの数の二乗から一次従属に下げられます、そして、パートナーがあらかじめ知られていないと、安全なコミュニケーションをデフォルトにするのは可能になります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. Encryption Regimes .........................................4
1.3. Peer Authentication in Opportunistic Encryption ............4
1.4. Use of RFC 2119 Terms ......................................5
2. Overview ........................................................6
2.1. Reference Diagram ..........................................6
2.2. Terminology ................................................6
2.3. Model of Operation .........................................8
1. 序論…3 1.1. 動機…3 1.2. 暗号化政権…4 1.3. 便宜主義的な暗号化における同輩認証…4 1.4. RFC2119用語の使用…5 2. 概要…6 2.1. 参照ダイヤグラム…6 2.2. 用語…6 2.3. 操作のモデル…8
Richardson & Redelmeier Informational [Page 1] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[1ページ]のRFC4322の便宜主義的な暗号化
3. Protocol Specification ..........................................9
3.1. Forwarding Plane State Machine .............................9
3.2. Keying Daemon -- Initiator ................................12
3.3. Keying Daemon -- Responder ................................20
3.4. Renewal and Teardown ......................................22
4. Impacts on IKE .................................................24
4.1. ISAKMP/IKE Protocol .......................................24
4.2. Gateway Discovery Process .................................24
4.3. Self Identification .......................................24
4.4. Public Key Retrieval Process ..............................25
4.5. Interactions with DNSSEC ..................................25
4.6. Required Proposal Types ...................................25
5. DNS Issues .....................................................26
5.1. Use of KEY Record .........................................26
5.2. Use of TXT Delegation Record ..............................27
5.3. Use of FQDN IDs ...........................................29
5.4. Key Roll-Over .............................................29
6. Network Address Translation Interaction ........................30
6.1. Co-Located NAT/NAPT .......................................30
6.2. Security Gateway behind a NAT/NAPT ........................30
6.3. End System behind a NAT/NAPT ..............................31
7. Host Implementations ...........................................31
8. Multi-Homing ...................................................31
9. Failure Modes ..................................................33
9.1. DNS Failures ..............................................33
9.2. DNS Configured, IKE Failures ..............................33
9.3. System Reboots ............................................34
10. Unresolved Issues .............................................34
10.1. Control of Reverse DNS ...................................34
11. Examples ......................................................34
11.1. Clear-Text Usage (Permit Policy) .........................34
11.2. Opportunistic Encryption .................................36
12. Security Considerations .......................................39
12.1. Configured versus Opportunistic Tunnels ..................39
12.2. Firewalls versus Opportunistic Tunnels ...................40
12.3. Denial of Service ........................................41
13. Acknowledgements ..............................................41
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
3. 仕様を議定書の中で述べてください…9 3.1. 飛行機を進めて、マシンを述べてください…9 3.2. デーモン--創始者を合わせます…12 3.3. デーモン--応答者を合わせます…20 3.4. 更新と分解…22 4. IKEの上の影響…24 4.1. ISAKMP/IKEは議定書を作ります…24 4.2. ゲートウェイ発見プロセス…24 4.3. 自己識別…24 4.4. 公開鍵検索過程…25 4.5. DNSSECとの相互作用…25 4.6. 提案タイプが必要でした…25 5. DNS問題…26 5.1. 主要な記録の使用…26 5.2. TXT委譲記録の使用…27 5.3. FQDN IDの使用…29 5.4. 主要な華麗なる陰謀…29 6. アドレス変換相互作用をネットワークでつないでください…30 6.1. NAT/NAPTの共同場所を見つけます…30 6.2. NAT/NAPTの後ろのセキュリティゲートウェイ…30 6.3. NAT/NAPTの後ろでシステムを終わらせてください…31 7. 実装を接待してください…31 8. マルチホーミング…31 9. 失敗モード…33 9.1. DNSの故障…33 9.2. 構成されたDNS IKEの故障…33 9.3. システムはリブートされます…34 10. 未定の問題…34 10.1. 逆のDNSのコントロール…34 11. 例…34 11.1. クリアテキスト用法(方針を可能にします)…34 11.2. 便宜主義的な暗号化…36 12. セキュリティ問題…39 12.1. 便宜主義的なTunnelsに対して構成されます…39 12.2. ファイアウォール対便宜主義的なTunnels…40 12.3. サービス妨害…41 13. 承認…41 14. 参照…41 14.1. 標準の参照…41 14.2. 有益な参照…42
Richardson & Redelmeier Informational [Page 2] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[2ページ]のRFC4322の便宜主義的な暗号化
1. Introduction
1. 序論
1.1. Motivation
1.1. 動機
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of systems involved. Each system administrator adds public key information to DNS records to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once this is done, any two such nodes can communicate securely.
便宜主義的な暗号化の目的はシステムの組に、特定の少しもかかわった根回しなしで暗号化を許容することです。 各システム管理者は、便宜主義的な暗号化をサポートするために公開鍵情報をDNS記録に追加して、次に、ノードのIPsecスタックでこの特徴を可能にします。 どんなそのような2つのノードも、一度、これをするとしっかりと伝えることができます。
This document describes opportunistic encryption as designed and implemented by the Linux FreeS/WAN project in revisions up and including 2.00. Note that 2.01 and beyond implements [RFC3445] in a backward compatible way. A future document [IPSECKEY] will describe a variation that complies with RFC 3445. For project information, see http://www.freeswan.org.
このドキュメントは、便宜主義的な暗号化が設計されていて、改正で上がっているリナックスFreeS/WANプロジェクトによって実装されて、2.00を含んでいると記述します。 後方のコンパチブル方法で2.01と道具[RFC3445]を超えてそれに注意してください。 将来のドキュメント[IPSECKEY]はRFC3445に従う変化について説明するでしょう。 プロジェクト情報に関しては、 http://www.freeswan.org を見てください。
The Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG) have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [RFC1984]. The Linux FreeS/WAN project attempts to provide a practical means to implement this policy.
インターネット・アーキテクチャ委員会(IAB)とインターネットEngineering Steering Group(IESG)はインターネットがセキュリティとプライバシーを提供するのに強力な暗号化を使用するべきである強い態度[RFC1984]を取りました。 リナックスFreeS/WANプロジェクトは、この政策を実施する実用的な手段を提供するのを試みます。
The project uses the IPsec, ISAKMP/IKE, DNS, and DNSSEC protocols because they are standardized, widely available, and can often be deployed very easily without changing hardware or software, or retraining users.
ハードウェアかソフトウェアを変えるか、またはユーザを再教育しないで、それらが標準化されるので、プロジェクトはIPsec、ISAKMP/IKE、DNS、およびDNSSECプロトコルを使用します、広く利用可能であり、しばしば非常に容易に配布することができます。
The extensions to support opportunistic encryption are simple. No changes to any on-the-wire formats are needed. The only changes are to the policy decision making system. This means that opportunistic encryption can be implemented with very minimal changes to an existing IPsec implementation.
便宜主義的な暗号化をサポートする拡大は簡単です。 ワイヤのどんな形式への変化も全く必要ではありません。 方針意志決定システムには唯一の変化があります。 これは、既存のIPsec実装への非常に最小量の変化で便宜主義的な暗号化を実装することができることを意味します。
Opportunistic encryption creates a "fax effect". The proliferation of the fax machine was possible because it did not require that everyone buy one overnight. Instead, as each person installed one, the value of having one increased because there were more people that could receive faxes. Once opportunistic encryption is installed, it automatically recognizes other boxes using opportunistic encryption, without any further configuration by the network administrator. So, as opportunistic encryption software is installed on more boxes, its value as a tool increases.
便宜主義的な暗号化は「ファックス効果」を作成します。 皆が夜通し1つを買うのが必要でなかったので、ファックス装置の増殖は可能でした。 各人が1つをインストールしたとき、ファックスを受け取ることができたより多くの人々がいたので、代わりに、1つを持つ値は増加しました。 便宜主義的な暗号化がいったんインストールされると、便宜主義的な暗号化を使用することで自動的に他の箱を認識します、ネットワーク管理者による少しもさらなる構成なしで。 それで、便宜主義的な暗号化ソフトウェアが、より多くの箱の上にインストールされるのに従って、ツールとしての値は増加します。
This document describes the infrastructure to permit deployment of Opportunistic Encryption.
このドキュメントは、Opportunistic Encryptionの展開を可能にするためにインフラストラクチャについて説明します。
Richardson & Redelmeier Informational [Page 3] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[3ページ]のRFC4322の便宜主義的な暗号化
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
用語S/WANは、RSAデータシステムズの商標であり、許可と共にこのプロジェクトによって使用されます。
1.2. Encryption Regimes
1.2. 暗号化政権
To aid in understanding the relationship between security processing and IPsec, we divide policies controlling network traffic into four categories. The traffic is categorized by destination address using longest prefix match. Therefore, each category is enumerated by a set of network prefixes. The categories are mutually exclusive; a particular prefix should only occur in one category.
セキュリティ処理とIPsecとの関係を理解する際に支援するために、私たちはネットワークトラフィックを制御する方針を4つのカテゴリに分割します。 トラフィックは、最も長い接頭語マッチを使用することで送付先アドレスによって分類されます。 したがって、各カテゴリは1セットのネットワーク接頭語によって列挙されます。 カテゴリは互いに排他的です。 特定の接頭語は1つのカテゴリで起こるだけであるべきです。
* Deny: network prefixes to which traffic is always forbidden.
* Permit: network prefixes to which traffic in the clear is
permitted.
* Opportunistic tunnel: network prefixes to which traffic is
encrypted if possible, when it otherwise might be sent in the
clear.
* Configured tunnel: network prefixes to which traffic must be
encrypted, and traffic in the clear is never permitted. A
traditionally defined Virtual Private Network (VPN) is a form of
configured tunnel.
* 否定します: トラフィックがいつも禁じられる接頭語をネットワークでつないでください。 * 以下を可能にしてください。 明確のトラフィックが受入れられる接頭語をネットワークでつないでください。 * 便宜主義的なトンネル: そうでなければ、明確でそれを送るかもしれないときできれば、トラフィックを暗号化する接頭語をネットワークでつないでください。 * 構成されたトンネル: トラフィックを暗号化しなければならない接頭語をネットワークでつないでください。そうすれば、明確のトラフィックは決して受入れられません。 伝統的に定義されたVirtual兵士のNetwork(VPN)は構成されたトンネルのフォームです。
Traditional firewall devices handle the first two categories. No authentication is required. The permit policy is currently the default on the Internet.
伝統的なファイアウォールデバイスは最初の2つのカテゴリを扱います。 認証は全く必要ではありません。 現在、許可証方針はインターネットのデフォルトです。
This document describes the third category: opportunistic tunnel, which is proposed as the new default for the Internet.
このドキュメントは3番目のカテゴリについて説明します: 便宜主義的なトンネル。(そのトンネルはインターネットへの新しいデフォルトとして提案されます)。
Category four's policy is a very strict "encrypt it or drop it" policy, which requires authentication of the endpoints. As the number of endpoints is typically bounded and is typically under a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology. The mechanism described here, however, does provides an additional way to distribute the authentication materials; it is a public key method that does not require deployment of an X.509 based infrastructure.
カテゴリfourの方針は「それを暗号化するか、またはそれを下げてください」という非常に厳しい方針です。(その方針は終点の認証を必要とします)。 終点の数は通常境界があって、通常ただ一つの権威の下にあって、難しい間、認証の材料の分配を準備するのは少しの新技術も必要としません。 しかしながら、ここで説明されたメカニズムがそうする、認証の材料を分配する追加方法を提供します。 それはX.509のベースのインフラストラクチャの展開を必要としない公開鍵メソッドです。
1.3. Peer Authentication in Opportunistic Encryption
1.3. 便宜主義的な暗号化における同輩認証
Opportunistic encryption creates tunnels between nodes that are essentially strangers. This is done without any prior bilateral arrangement. Therefore, there is the difficult question of how one knows to whom one is talking.
便宜主義的な暗号化は本質的には見知らぬ人であるノードの間のトンネルを作成します。 少しも先の双方のアレンジメントなしでこれをします。 したがって、1が話している人がどう知るかに関する難問題があります。
Richardson & Redelmeier Informational [Page 4] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[4ページ]のRFC4322の便宜主義的な暗号化
One possible answer is that since no useful authentication can be done, none should be tried. This mode of operation is named "anonymous encryption". An active man-in-the-middle attack can be used to thwart the privacy of this type of communication. Without peer authentication, there is no way to prevent this kind of attack.
1つの可能な答えはどんな役に立つ認証もできないのでなにも試みるべきでないということです。 この運転モードは「匿名の暗号化」と命名されます。 このタイプに関するコミュニケーションのプライバシーを阻むのに中央の活発な男性攻撃を使用できます。 同輩認証がなければ、この種類の攻撃を防ぐ方法が全くありません。
Although it is a useful mode, anonymous encryption is not the goal of this project. Simpler methods are available that can achieve anonymous encryption only, but authentication of the peer is a desirable goal. Authentication of the peer is achieved through key distribution in DNS, leveraging upon the authentication of the DNS in DNSSEC.
それは役に立つモードですが、匿名の暗号化はこのプロジェクトの目標ではありません。 より簡単なメソッドは利用可能です。匿名の暗号化しか達成できませんが、同輩の認証は望ましい目標です。 DNSSECでのDNSの認証のときに力を入れて、同輩の認証はDNSでの主要な分配で達成されます。
Peers are, therefore, authenticated with DNSSEC when available. Local policy determines how much trust to extend when DNSSEC is not available.
したがって、利用可能であるときに、同輩はDNSSECと共に認証されます。 DNSSECが利用可能でないときに、ローカルの方針は、どのくらいの信頼を広げるかを決定します。
An essential premise of building private connections with strangers is that datagrams received through opportunistic tunnels are no more special than datagrams that arrive in the clear. Unlike in a VPN, these datagrams should not be given any special exceptions when it comes to auditing, further authentication, or firewalling.
見知らぬ人との個人的な接続を組み込む不可欠の前提による便宜主義的なトンネルを通って受け取られたデータグラムが特別番組より明確に届くデータグラムであるということです。 VPNなどと異なって、監査で、さらなる認証、またはfirewallingのこととなる場合、少しの特例もこれらのデータグラムに与えるべきではありません。
When initiating outbound opportunistic encryption, local configuration determines what happens if tunnel setup fails. The packet may go out in the clear, or it may be dropped.
外国行きの便宜主義的な暗号化を開始するとき、地方の構成は、トンネルセットアップが失敗するなら何が起こるかを決定します。 パケットが明確で出かけるかもしれませんか、またはそれは下げられるかもしれません。
1.4. Use of RFC 2119 Terms
1.4. RFC2119用語の使用
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]
キーワードが解釈しなければならない、本書では現れるとき、中で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりません。[RFC2119]
Richardson & Redelmeier Informational [Page 5] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[5ページ]のRFC4322の便宜主義的な暗号化
2. Overview
2. 概要
2.1. Reference Diagram
2.1. 参照ダイヤグラム
The following network diagram is used in the rest of this document as the canonical diagram:
以下のネットワーク図は正準なダイヤグラムとしてこのドキュメントの残りに使用されます:
[Q] [R]
. . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
| ......
AS1 | ..PI..
| ......
[D]----+----[SG-D].......+....+.......[C] AS3
[Q][R] AS2[A]----+----[SG-A]…+....+.......[SG-B]-------[B]| ...... AS1| ..パイ。 | ...... [D]----+----[SG-D]…+....+.......[C] AS3
Figure 1: Reference Network Diagram
図1: 参照ネットワーク図
In this diagram, there are four end-nodes: A, B, C, and D. There are
three security gateways, SG-A, SG-B, SG-D. A, D, SG-A, and SG-D are
part of the same administrative authority, AS1. SG-A and SG-D are on
two different exit paths from organization 1. SG-B and B are part of
an independent organization, AS2. Nodes Q and R are nodes on the
Internet. PI is the Public Internet ("The Wild").
このダイヤグラムには、4つのエンドノードがあります: A、B、C、およびD.Thereは3セキュリティ門、SG-A、SG-B、SG-Dです。 AS1、A、D、SG-A、およびSG-Dは同じ職務権限の一部です。 SG-AとSG-Dが2つの組織1と異なった出口経路にあります。 SG-BとBは独立機関、AS2の一部です。 ノードQとRはインターネットのノードです。 PIはPublicインターネット(「荒野」)です。
2.2. Terminology
2.2. 用語
Note: The network numbers used in this document are for illustrative purposes only. This document could not use the reserved example network numbers of [RFC3330] because multiple address ranges were needed.
以下に注意してください。 本書では使用されるネットワーク・ナンバーは説明に役立った目的だけのためのものです。 複数のアドレスの範囲が必要であったので、このドキュメントは[RFC3330]の予約された例のネットワーク・ナンバーを使用できませんでした。
The following terminology is used in this document:
以下の用語は本書では使用されます:
Security gateway (or simply gateway): a system that performs IPsec
tunnel mode encapsulation/decapsulation. [SG-x] in the diagram.
セキュリティゲートウェイ(または、単にゲートウェイ): IPsecトンネルモードカプセル化/被膜剥離術を実行するシステム。 ダイヤグラムによる[SG-x。]
Alice: node [A] in the diagram. When an IP address is needed, this
is 192.1.0.65.
アリス: ダイヤグラムによるノード[A]。 IPアドレスが必要であるときに、これが必要です。192.1 .0 .65。
Bob: node [B] in the diagram. When an IP address is needed, this is
192.2.0.66.
ボブ: ダイヤグラムによるノード[B]。 IPアドレスが必要であるときに、これが必要です。192.2 .0 .66。
Carol: node [C] in the diagram. When an IP address is needed, this
is 192.1.1.67.
キャロル: ダイヤグラムによるノード[C]。 IPアドレスが必要であるときに、これが必要です。192.1 .1 .67。
Dave: node [D] in the diagram. When an IP address is needed, this is
192.3.0.68.
デーヴ: ダイヤグラムによるノード[D]。 IPアドレスが必要であるときに、これが必要です。192.3 .0 .68。
Richardson & Redelmeier Informational [Page 6] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[6ページ]のRFC4322の便宜主義的な暗号化
SG-A: Alice's security gateway. Internally it is 192.1.0.1,
externally it is 192.1.1.4.
SG-A: アリスのセキュリティゲートウェイ。 外部的に、それはそうです。本質的に、それがそうである、192.1 .0 .1、192.1 .1 .4。
SG-B: Bob's security gateway. Internally it is 192.2.0.1, externally
it is 192.1.1.5.
SG-B: ボブのセキュリティゲートウェイ。 外部的に、それはそうです。本質的に、それがそうである、192.2 .0 .1、192.1 .1 .5。
SG-D: Dave's security gateway. Also Alice's backup security gateway.
Internally it is 192.3.0.1, externally it is 192.1.1.6.
SG-D: デーヴのセキュリティゲートウェイ。 アリスのもバックアップセキュリティゲートウェイ。 外部的に、それはそうです。本質的に、それがそうである、192.3 .0 .1、192.1 .1 .6。
Configured tunnel: a tunnel that is directly and deliberately hand-
configured on participating gateways. Configured tunnels are
typically given a higher level of trust than opportunistic
tunnels.
構成されたトンネル: 直接、故意に参加ゲートウェイの上で手で構成されるトンネル。 便宜主義的なトンネルより高いレベルの信頼を構成されたトンネルに通常与えます。
Road warrior tunnel: a configured tunnel connecting one node with a
fixed IP address and one node with a variable IP address. A road
warrior (RW) connection must be initiated by the variable node,
since the fixed node cannot know the current address for the road
warrior.
道行く戦士トンネル: 可変IPアドレスで固定IPアドレスと1つのノードに1つのノードを接続する構成されたトンネル。 可変ノードで道行く戦士(RW)接続を開始しなければなりません、固定ノードが道行く戦士で現在のアドレスを知ることができないので。
Anonymous encryption: the process of encrypting a session without any
knowledge of who the other parties are. No authentication of
identities is done.
匿名の暗号化: 相手がだれであるかに関する少しも知識なしでセッションを暗号化するプロセス。 アイデンティティの認証は全く完了していません。
Opportunistic encryption: the process of encrypting a session with
authenticated knowledge of who the other party is without
prearrangement.
便宜主義的な暗号化: 相手が根回しがなければだれであるかに関する認証された知識とのセッションを暗号化するプロセス。
Lifetime: the period in seconds (bytes or datagrams) for which a
security association will remain alive before rekeying is needed.
生涯: セキュリティ協会が「再-合わせ」る前に命脈を保つ秒(バイトかデータグラム)の期間が必要です。
Lifespan: the effective time for which a security association remains
useful. A security association with a lifespan shorter than its
lifetime would be removed when no longer needed. A security
association with a lifespan longer than its lifetime would need to
be re-keyed one or more times.
寿命: セキュリティ協会が役に立ったままで残っている実効時間。 もう必要でないと、生涯より短い寿命とのセキュリティ協会を取り除くでしょう。 生涯より長い寿命とのセキュリティ協会は、再合わせられた1回以上である必要があるでしょう。
Phase 1 SA: an ISAKMP/IKE security association sometimes referred to
as a keying channel.
フェーズ1SA: ISAKMP/IKEセキュリティ協会は時々合わせているチャンネルを呼びました。
Phase 2 SA: an IPsec security association.
フェーズ2SA: IPsecセキュリティ協会。
Tunnel: another term for a set of phase 2 SA (one in each direction).
以下にトンネルを堀ってください。 フェーズ2SA(各方向への1)の1セットのための別の用語。
NAT: Network Address Translation (see [RFC2663]).
NAT: アドレス変換をネットワークでつないでください([RFC2663]を見てください)。
NAPT: Network Address and Port Translation (see [RFC2663]).
NAPT: アドレスとポート翻訳をネットワークでつないでください([RFC2663]を見てください)。
Richardson & Redelmeier Informational [Page 7] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[7ページ]のRFC4322の便宜主義的な暗号化
AS: an autonomous system.
: 自律システム。
FQDN: Fully-Qualified Domain Name
FQDN: 完全修飾ドメイン名
Default-free zone: a set of routers that maintain a complete set of
routes to all currently reachable destinations. Having such a
list, these routers never make use of a default route. A datagram
with a destination address not matching any route will be dropped
by such a router.
無デフォルトのゾーン: すべての現在届いている目的地に完全なセットのルートを維持する1セットのルータ。 そのようなリストを持っていて、これらのルータはデフォルトルートを決して利用しません。 送付先アドレスがどんなルートにも合っていないデータグラムはそのようなルータによって下げられるでしょう。
2.3. Model of Operation
2.3. 操作のモデル
The opportunistic encryption security gateway (OE gateway) is a regular gateway node, as described in [RFC0791] section 2.4 and [RFC1812], with the additional capabilities described here and in [RFC2401]. The algorithm described here provides a way to determine, for each datagram, whether or not to encrypt and tunnel the datagram. Two important things that must be determined are whether or not to encrypt and tunnel and, if so, the destination address or name of the tunnel endpoint that should be used.
便宜主義的な暗号化セキュリティゲートウェイ(OEゲートウェイ)は通常のゲートウェイノードです、[RFC0791]セクション2.4と[RFC1812]で説明されるように、ここと追加能力が[RFC2401]で説明されている状態で。 ここで説明されたアルゴリズムは各データグラムのためにデータグラムを暗号化して、トンネルを堀るかどうか決定する方法を提供します。 トンネルを堀ってください、そうだとすれば、目的地は、トンネルについて終点をそれと扱うか、または命名します。そして、2つの決定するに違いない重要なものがそう、暗号化する、使用されるべきです。
2.3.1. Tunnel Authorization
2.3.1. トンネル承認
The OE gateway determines whether or not to create a tunnel based on the destination address of each packet. Upon receiving a packet with a destination address not recently seen, the OE gateway performs a lookup in DNS for an authorization resource record (see Section 5.2). The record is located using the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps. If an authorization record is found, the OE gateway interprets this as a request for a tunnel to be formed.
OEゲートウェイは、それぞれのパケットの送付先アドレスに基づくトンネルを作成するかどうか決定します。 送付先アドレスが最近見られていなくパケットを受けると、OEゲートウェイは承認リソース記録のためにDNSでルックアップを実行します(セクション5.2を見てください)。 記録は、addr.arpaの(IPv4)かip6.arpa(IPv6)地図における検索を実行するのにIPアドレスを使用することで見つけられています。 承認記録が見つけられるなら、OEゲートウェイはトンネルが形成されるという要求としてこれを解釈します。
2.3.2. Tunnel Endpoint Discovery
2.3.2. トンネル終点発見
The authorization resource record also provides the address or name of the tunnel endpoint that should be used.
また、承認リソース記録は使用されるべきであるトンネル終点のアドレスか名前を提供します。
The record may also provide the public RSA key of the tunnel end point itself. This is provided for efficiency only. If the public RSA key is not present, the OE gateway performs a second lookup to find a KEY resource record for the endpoint address or name.
また、記録はトンネルエンドポイント自体の公共のRSAキーを提供するかもしれません。 これを効率だけに提供します。 公共のRSAキーが存在していないなら、OEゲートウェイは、終点アドレスか名前のためのKEYリソース記録を見つけるために2番目のルックアップを実行します。
Origin and integrity protection of the resource records is provided by DNSSEC (see [RFC4033]). Section 3.2.4.1 documents an optional restriction on the tunnel endpoint if DNSSEC signatures are not available for the relevant records.
リソース記録の発生源と保全保護はDNSSECによって提供されます([RFC4033]を見てください)。 セクション3.2 .4 .1 DNSSEC署名が関連記録に利用可能でないなら、トンネル終点に任意の制限を記録します。
Richardson & Redelmeier Informational [Page 8] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[8ページ]のRFC4322の便宜主義的な暗号化
2.3.3. Caching of Authorization Results
2.3.3. 承認結果のキャッシュ
The OE gateway maintains a cache, in the forwarding plane, of source/destination pairs for which opportunistic encryption has been attempted. This cache maintains a record of whether or not OE was successful so that subsequent datagrams can be forwarded properly without additional delay.
OEゲートウェイは便宜主義的な暗号化を試みてあるソース/目的地組の推進飛行機でキャッシュを維持します。 このキャッシュはOEが追加遅れなしでその後のデータグラムを適切に進めることができるようにうまくいったかどうかに関する記録を保守します。
Successful negotiation of OE instantiates a new security association. Failure to negotiate OE results in creation of a forwarding policy entry either to deny or permit transmission in the clear future datagrams. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking up the same information.
OEのうまくいっている交渉は新しいセキュリティ協会を例示します。 OEを交渉しない場合、明確な将来のデータグラムでトランスミッションを否定するか、または可能にするために推進方針エントリーの作成に結果として生じます。この否定的キャッシュが、繰り返して同じ情報を調べることによると長いプロセスを避けるのに必要です。
The cache is timed out periodically, as described in Section 3.4. This removes entries that are no longer being used and permits the discovery of changes in authorization policy.
キャッシュはセクション3.4で説明されるように外で定期的に調節されています。 これは、もう使用されていないエントリーを取り除いて、承認方針における変化の発見を可能にします。
3. Protocol Specification
3. プロトコル仕様
The OE gateway is modeled to have a forwarding plane and a control plane. A control channel, such as PF_KEY [RFC2367], connects the two planes.
OEゲートウェイは、推進飛行機と制御飛行機を持つためにモデル化されます。 PF_KEYなどの制御チャンネル[RFC2367]は2機の飛行機を接続します。
The forwarding plane performs per-datagram operations. The control plane contains a keying daemon, such as ISAKMP/IKE, and performs all authorization, peer authentication, and key derivation functions.
推進飛行機は1データグラムあたりの操作を実行します。 制御飛行機は、ISAKMP/IKEなどの合わせるデーモンを含んでいて、すべての承認、同輩認証、および主要な派生機能を実行します。
3.1. Forwarding Plane State Machine
3.1. 推進飛行機州のマシン
Let the OE gateway maintain a collection of objects -- a superset of the security policy database (SPD) specified in [RFC2401]. For each combination of source and destination address, an SPD object exists in one of five following states. Prior to forwarding each datagram, the responder uses the source and destination addresses to pick an entry from the SPD. The SPD then determines if and how the packet is forwarded.
OEゲートウェイにオブジェクトの収集を維持させてください--安全保障政策データベース(SPD)のスーパーセットは[RFC2401]で指定しました。 ソースと送付先アドレスの各組み合わせのために、SPDオブジェクトは5つの次の州の1つに存在しています。 各データグラムを進める前に、応答者は、SPDからエントリーを選ぶのにソースと送付先アドレスを使用します。 そしてSPDは確認します。そして、どうパケットを進めるか。
Richardson & Redelmeier Informational [Page 9] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[9ページ]のRFC4322の便宜主義的な暗号化
.--------------.
| nonexistent |
| policy |
`--------------'
|
| PF_ACQUIRE
|
|<---------.
V | new packet
.--------------. | (maybe resend PF_ACQUIRE)
| hold policy |--'
| |--.
`--------------' \ pass
| | \ msg .---------.
| | \ V | forward
| | .-------------. | packet
create | | | pass policy |--'
IPsec | | `-------------'
SA | |
| \
| \
V \ deny
.---------. \ msg
| encrypt | \
| policy | \ ,---------.
`---------' \ | | discard
\ V | packet
.-------------. |
| deny policy |--'
`-------------'
.--------------. | 実在しません| | 方針| `--------------' | | _が取得するpf| | <、-、-、-、-、-、-、-、--. V| 新しいパケット。--------------. | (多分、PF_ACQUIREを再送します) | 方針を保持してください。|--' | |--. `--------------'\パス'| | \msg。---------. | | \V| 転送| | .-------------. | パケットは作成します。| | | 方針を通過してください。|--'IPsec'| | `-------------'SA'| | | \ | \が否定する\V。---------. \msg| 暗号化します。| \ | 方針| \ ,---------. `---------' \ | | \Vを捨ててください。| パケット。-------------. | | 方針を否定してください。|--' `-------------'
3.1.1. Nonexistent Policy
3.1.1. 実在しない方針
If the gateway does not find an entry, then this policy applies. The gateway creates an entry with an initial state of "hold policy" and requests keying material from the keying daemon. The gateway does not forward the datagram; rather, it SHOULD attach the datagram to the SPD entry as the "first" datagram and retain it for eventual transmission in a new state.
ゲートウェイがそうしないなら、エントリーを見つけてください、そして、次に、この方針は適用されます。 ゲートウェイは合わせるデーモンから「保持方針」と要求の初期状態が材料を合わせているエントリーを作成します。 ゲートウェイはデータグラムを進めません。 むしろそれ、SHOULDは「1番目」のデータグラムとしてSPDエントリーにデータグラムを取り付けて、最後のトランスミッションのために新しい状態でそれを保有します。
3.1.2. Hold Policy
3.1.2. 方針を保持してください。
The gateway requests keying material. If the interface to the keying system is lossy (PF_KEY, for instance, can be), the implementation SHOULD include a mechanism to retransmit the keying request at a rate limited to less than 1 request per second. The gateway does not forward the datagram. The gateway SHOULD attach the datagram to the SPD entry as the "last" datagram, where it is retained for eventual
ゲートウェイは合わせることの材料を要求します。 合わせるシステムへのインタフェースが損失性(例えば、PF_KEYはそうであることができる)であるなら、実装SHOULDは、1秒あたり1つ未満の要求に制限されたレートで合わせる要求を再送するためにメカニズムを含んでいます。 ゲートウェイはデータグラムを進めません。 ゲートウェイSHOULDが「最後」のデータグラムとしてSPDエントリーにデータグラムを取り付ける、最後。(そこでは、それが保有されます)。
Richardson & Redelmeier Informational [Page 10] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[10ページ]のRFC4322の便宜主義的な暗号化
transmission. If there is a datagram already stored in this way, then that already-stored datagram is discarded.
トランスミッション。 既にこのように保存されたデータグラムがあれば、その既に保存されたデータグラムは捨てられます。
The rationale behind saving the "first" and "last" datagrams are as follows: The "first" datagram is probably a TCP SYN packet. Once there is keying established, the gateway will release this datagram, avoiding the need for the endpoint to retransmit the datagram. In the case where the connection was not a TCP connection, but was instead a streaming protocol or a DNS request, the "last" datagram that was retained is likely the most recent data. The difference between "first" and "last" may also help the endpoints determine which data was dropped while negotiation took place.
「1番目」で「最後」のデータグラムを取っておく後ろの原理は以下の通りです: 「1番目」のデータグラムはたぶんTCP SYNパケットです。 確立した合わせることがいったんあると、ゲートウェイはこのデータグラムをリリースするでしょう、終点がデータグラムを再送する必要性を避けて。 接続がTCP接続ではありませんでしたが、代わりにストリーミングのプロトコルかDNS要求であった場合では、保有された「最後」のデータグラムはありそうな最新のデータです。 また、違いは、「最初に」の間と、そして、「最後」ときの終点が、交渉が行われていた間、どのデータが下げられたかを決定するのを助けるかもしれません。
3.1.3. Pass-Through Policy
3.1.3. 方針を通り抜けてください。
The gateway forwards the datagram using the normal forwarding table. The gateway enters this state only by command from the keying daemon, and upon entering this state, also forwards the "first" and "last" datagrams.
ゲートウェイは、正常な推進テーブルを使用することでデータグラムを進めます。 ゲートウェイは、単に合わせるデーモンと、この状態に入るときのコマンドでこの状態に入れて、また、「1番目」で「最後」のデータグラムを送ります。
3.1.4. Deny Policy
3.1.4. 方針を否定してください。
The gateway discards the datagram. The gateway enters this state only by command from the keying daemon, and upon entering this state, discards the "first" and "last" datagrams. An implementation MAY provide the administrator with a control to determine if further datagrams cause ICMP messages to be generated (i.e., ICMP Destination Unreachable, Communication Administratively Prohibited. type=3, code=13).
ゲートウェイはデータグラムを捨てます。 ゲートウェイは単に合わせるデーモンと、この状態に入るときのコマンドでこの状態に入って、破棄は「1番目」で「最後」のデータグラムです。実装は、一層のデータグラムが生成するべきメッセージをICMPに引き起こすかどうか(すなわち、ICMP Destination Unreachable Communication Administratively Prohibited(タイプ=3)は=13をコード化します)決定するためにコントロールを管理者に提供するかもしれません。
3.1.5. Encrypt Policy
3.1.5. 方針を暗号化してください。
The gateway encrypts the datagram using the indicated security association database (SAD) entry. The gateway enters this state only by command from the keying daemon, and upon entering this state, releases and forwards the "first" and "last" datagrams using the new encrypt policy.
ゲートウェイは、示されたセキュリティ協会データベース(SAD)エントリーを使用することでデータグラムを暗号化します。 ゲートウェイは単に合わせるデーモンからのコマンドでこの状態に入ります、そして、この状態に入る、リリース、およびフォワード「1番目」と「最終」に、新しさを使用するデータグラムが方針を暗号化します。
If the associated SAD entry expires because of byte, packet or time limits, then the entry returns to the Hold policy, and an expire message is sent to the keying daemon.
メッセージを吐き出してください。そして、関連SADエントリーがバイト、パケットまたはタイムリミットのために期限が切れるならエントリーがHold方針に戻る、合わせるデーモンに送ります。
All states may be created directly by the keying daemon while acting as a gateway.
すべての州がゲートウェイとして機能している間、直接合わせるデーモンによって創設されるかもしれません。
Richardson & Redelmeier Informational [Page 11] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[11ページ]のRFC4322の便宜主義的な暗号化
3.2. Keying Daemon -- Initiator
3.2. デーモン--創始者を合わせます。
Let the keying daemon maintain a collection of objects. Let them be called "connections" or "conn"s. There are two categories of connection objects: classes and instances. A class represents an abstract policy (i.e., what could be). An instance represents an actual connection (i.e., what is running at the time).
合わせるデーモンにオブジェクトの収集を維持させてください。 それらを「接続」か「コン」sと呼ばせてください。 接続オブジェクトの2つのカテゴリがあります: クラスとインスタンス。 クラスは抽象的な方針を表します(すなわち、何があるかもしれませんか)。 インスタンスは実際の接続(すなわち、当時、稼働していること)の代理をします。
Let there be two further subtypes of connections: keying channels (Phase 1 SAs) and data channels (Phase 2 SAs). Each data channel object may have a corresponding SPD and SAD entry maintained by the datagram state machine.
そこで貸されて、接続のさらなる2血液型亜型になってください: チャンネル(フェーズ1SAs)とデータを合わせると、(フェーズ2SAs)はチャネルを開設されます。 それぞれのデータ・チャンネルオブジェクトで、データグラム州のマシンは対応するSPDとSADエントリーを維持するかもしれません。
For the purposes of opportunistic encryption, there MUST, at least, be connection classes known as "deny", "always-clear-text", "OE- permissive", and "OE-paranoid". The latter two connection classes define a set of destination prefixes for which opportunistic encryption will be attempted. The administrator MAY set policy options in a number of additional places. An implementation MAY create additional connection classes to further refine these policies.
便宜主義的な暗号化の目的のために、「OE寛大で」、「OEパラノイア」の「いつもクリアテキスト」と「否定する」とき、知られている接続のクラスが少なくともあるに違いありません。 2つの後者の接続のクラスが便宜主義的な暗号化が試みられる1セットの目的地接頭語を定義します。 管理者は多くの追加場所に政策選択をはめ込むかもしれません。 実装は、さらにこれらの方針を洗練するために追加接続のクラスを創設するかもしれません。
The simplest system may need only the "OE-permissive" connection, and would list its own (single) IP address as the source address of this policy and the wild-card address 0.0.0.0/0 as the destination IPv4 address. That is, the simplest policy is to try opportunistic encryption with all destinations.
最も簡単なシステムは、「OE寛大な」接続だけを必要とするかもしれなくて、送付先IPv4アドレスとしてこの方針のソースアドレスとワイルドカードアドレス0.0.0.0/0にそれ自身の(単一)のIPアドレスについて記載するでしょう。 すなわち、最も簡単な方針はすべての目的地で便宜主義的な暗号化を試みることです。
This simplest policy SHOULD be offered as a preconfigured default.
この最も簡単な方針SHOULD、あらかじめ設定されたデフォルトとして、提供してください。
The distinction between permissive and paranoid Opportunistic
Encryption ("OE-paranoid" below) use will become clear in the state
transition differences.
寛大でパラノイアのOpportunistic Encryption(以下の「OEパラノイア」の)使用の区別は状態遷移差で明確になるでしょう。
In brief, an OE-permissive policy means to permit traffic to flow in the clear when there is a failure to find and/or use the encryption keys. OE-permissive permits the network to function, even if in an insecure manner.
要するに、OE寛大な方針は、暗号化キーを見つける、そして/または、使用しないことがあるとき、トラフィックが明確を流れるのを許容することを意味します。 OE寛大である、不安定な方法でネットワークが機能することを許可します。
On failure, a paranoid OE ("OE-paranoid") will install a drop policy.
OE-paranoid permits traffic to flow only when appropriate security is
available.
失敗に、パラノイアのOE(「OEパラノイア」の)は低下方針をインストールするでしょう。 適切なセキュリティが利用可能であるときにだけ、OE-パラノイアは、トラフィックが流れるのを許容します。
In this description of the keying machine's state transitions, the states associated with the keying system itself are omitted because they are best documented in the keying system ([RFC2407], [RFC2408], and [RFC2409] for ISAKMP/IKE), and the details are keying system specific. Opportunistic encryption is not dependent upon any
合わせるマシンの状態遷移のこの記述では、合わせるシステム自体に関連している州は合わせるシステム([RFC2407]、[RFC2408]、およびISAKMP/IKEのための[RFC2409])でそれらを記録するので、最も良い省略されて、詳細は合わせるシステム特有です。 便宜主義的な暗号化はいずれもに依存していません。
Richardson & Redelmeier Informational [Page 12] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[12ページ]のRFC4322の便宜主義的な暗号化
specific keying protocol, but this document does provide requirements for those using ISAKMP/IKE to assure that implementations inter- operate.
しかし、特定の合わせるプロトコル、このドキュメントは実装が相互作動することを保証するのにISAKMP/IKEを使用するもののための要件を提供します。
The state transitions that may be involved in communicating with the forwarding plane are omitted. PF_KEY and similar protocols have their own set of states required for message sends and completion notifications.
推進飛行機で交信するのにかかわるかもしれない状態遷移は省略されます。 PF_KEYと同様のプロトコルには、それら自身のメッセージが発信するので必要である州と完成通知のセットがあります。
Finally, the retransmits and recursive lookups that are normal for DNS are not included in this description of the state machine.
最終的である、再送、そして、DNSがあるので標準が中に州のマシンのこの記述を含んでいなかったということである再帰的なルックアップ。
|
| PF_ACQUIRE
|
V
.---------------.
| nonexistent |
| connection |
`---------------'
| | |
send , | \
expired pass / | \ send
conn. msg / | \ deny
^ / | \ msg
| V | do \
.---------------. | DNS \ .---------------.
| clear-text | | lookup `->| deny |--->expired
| connection | | for | connection | connection
`---------------' | destination `---------------'
^ ^ | ^
| | no record | |
| | OE-permissive V | no record
| | .---------------. | OE-paranoid
| `------------| potential OE |---------'
| | connection | ^
| `---------------' |
| | |
| | got TXT record | DNSSEC failure
| | reply |
| V | wrong
| .---------------. | failure
| | authenticate |---------'
| | & parse TXT RR| ^
| repeated `---------------' |
| ICMP | |
| failures | initiate IKE to |
| (short timeout) | responder |
| | _が取得するpf| V。---------------. | 実在しません| | 接続| `---------------' | | | 発信してください。| \はパス/を吐き出しました。| \はコンmsg/を送ります。| \は^/を否定します。| \msg| V| \をしてください。---------------. | DNS\。---------------. | クリアテキスト| | ルックアップ'-'>| 否定します。|--->は期限が切れました。| 接続| | for| 接続| '接続‘---------------' | 'の目的地‘---------------' ^ ^ | ^ | | 記録がありません。| | | | OE寛大なV| 記録がありません。| | .---------------. | OE-パラノイア| `------------| 潜在的OE|---------' | | 接続| ^ | `---------------' | | | | | | TXT記録的になります。| DNSSECの故障| | 返信| | V| 間違う| .---------------. | 失敗| | 認証します。|---------' | | TXT RRを分析します。| ^ | 'たびたびの‘---------------' | | ICMP| | | 失敗| IKEを開始します。| | (短いタイムアウト) | 応答者|
Richardson & Redelmeier Informational [Page 13] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[13ページ]のRFC4322の便宜主義的な暗号化
| V |
| phase-2 .---------------. | failure
| failure | pending |---------'
| (normal | OE | ^
| timeout) | |invalid | phase-2 fail (normal
| | |<--.SPI | timeout)
| | | | | ICMP failures (short
| | +=======+ |---' | timeout)
| | | IKE | | ^ |
`----------------| states|---------------'
| +=======+ | |
`---------------' |
| IPsec SA | invalid SPI
| established |
V | rekey time
.--------------. |
| keyed |<---|------------------------------.
| connection |----' |
`--------------' |
| timer |
| |
V |
.--------------. connection still active |
clear-text----->| expired |-----------------------------------'
deny----->| connection |
`--------------'
| dead connection - deleted
V
| V| | -2の位相を合わせてください。---------------. | 失敗| 失敗| 未定|---------' | (normal | OE | ^ | timeout) | |病人| フェーズ-2は失敗します(標準| | | <--.SPI| タイムアウト)。| | | | | ICMPの'故障、(|ショートしてください| + ===が+と等しい、|、-、--、'| タイムアウト、)| | | イケ| | ^ | `----------------| 状態|---------------' | +=======+ | | `---------------' | | IPsec SA| 無効のSPI| 設立されます。| V| rekey時間。--------------. | | 合わせられます。|<---|------------------------------. | 接続|----' | `--------------' | | タイマ| | | V| .--------------. 接続の静かな能動態| クリアテキスト----->| 期限が切れます。|-----------------------------------'否定'----->| 接続| `--------------' | 停止コネクション--削除されたV
3.2.1. Nonexistent Connection
3.2.1. 実在しない接続
There is no connection instance for a given source/destination address pair. Upon receipt of a request for keying material for this source/destination pair, the initiator searches through the connection classes to determine the most appropriate policy. Upon determining an appropriate connection class, an instance object is created of that type. Both of the OE types result in a potential OE connection.
与えられたソース/目的地アドレス組接続インスタンスが全くありません。 このソース/目的地組のために材料を合わせるのを求める要求を受け取り次第、創始者は、最も適切な方針を決定するために接続のクラスを隅々まで捜します。 適切な接続のクラスを決定すると、インスタンスオブジェクトはそのタイプに作成されます。 OEの両方が潜在的OE接続に結果をタイプします。
Failure to find an appropriate connection class results in an administrator-defined default.
適切な接続のクラスを見つけない場合、管理者によって定義されたデフォルトをもたらします。
In each case, when the initiator finds an appropriate class for the new flow, an instance connection is made of the class that matched.
その都度、創始者が新しい流れに関して適切なクラスを見つけると、インスタンス接続は合っていたクラスで作られます。
Richardson & Redelmeier Informational [Page 14] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[14ページ]のRFC4322の便宜主義的な暗号化
3.2.2. Clear-Text Connection
3.2.2. クリアテキスト接続
The nonexistent connection makes a transition to this state when an always-clear-text class is instantiated, or when an OE-permissive connection fails. During the transition, the initiator creates a pass-through policy object in the forwarding plane for the appropriate flow.
実在しない接続はいつもクリアテキストのクラスが例示されるか、またはOE寛大な接続が失敗するとこの状態への変遷をします。 変遷の間、創始者は適切な流れのために推進飛行機で通じて通り政策目的を作成します。
Timing out is the only way to leave this state (see Section 3.2.7).
調節して、この状態を出る唯一の方法が外にあります(セクション3.2.7を見てください)。
3.2.3. Deny Connection
3.2.3. 接続を否定してください。
The empty connection makes a transition to this state when a deny class is instantiated, or when an OE-paranoid connection fails. During the transition, the initiator creates a deny policy object in the forwarding plane for the appropriate flow.
空の接続はaが、クラスが例示されることを否定するか、またはOE-パラノイア接続が失敗するとこの状態への変遷をします。 変遷の間、創始者はaを作成します。適切な流れのために推進飛行機で政策目的を否定してください。
Timing out is the only way to leave this state (see Section 3.2.7).
調節して、この状態を出る唯一の方法が外にあります(セクション3.2.7を見てください)。
3.2.4. Potential OE Connection
3.2.4. 潜在的OE接続
The empty connection makes a transition to this state when one of either OE class is instantiated. During the transition to this state, the initiator creates a hold policy object in the forwarding plane for the appropriate flow.
空の接続はこれへの変遷にどちらかのOEのクラスの1つがいつ例示されるかを述べさせます。 この状態への変遷の間、創始者は適切な流れのために推進飛行機で保持政策目的を作成します。
In addition, when making a transition into this state, DNS lookup is done in the reverse-map for a TXT delegation resource record (see Section 5.2). The lookup key is the destination address of the flow.
この状態に変遷を作りかえるとき、さらに、TXT委譲リソース記録のために逆地図でDNSルックアップをします(セクション5.2を見てください)。 ルックアップキーは流れの送付先アドレスです。
There are three ways to exit this state:
この状態を出る3つの方法があります:
1. DNS lookup finds a TXT delegation resource record.
1. DNSルックアップはTXT委譲リソース記録を見つけます。
2. DNS lookup does not find a TXT delegation resource record.
2. DNSルックアップはTXT委譲リソース記録を見つけません。
3. DNS lookup times out.
3. DNSルックアップ回のアウト。
Based upon the results of the DNS lookup, the potential OE connection makes a transition to the pending OE connection state. The conditions for a successful DNS look are:
DNSルックアップの結果に基づいて、潜在的OE接続は未定のOE接続状態への変遷をします。 うまくいっているDNS外観のための状態は以下の通りです。
1. DNS finds an appropriate resource record.
1. DNSは適切なリソース記録を見つけます。
2. It is properly formatted according to Section 5.2.
2. セクション5.2によると、それは適切にフォーマットされます。
3. If DNSSEC is enabled, then the signature has been vouched for.
3. DNSSECが有効にされるなら、署名は保証されました。
Richardson & Redelmeier Informational [Page 15] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[15ページ]のRFC4322の便宜主義的な暗号化
Note that if the initiator does not find the public key present in the TXT delegation record, then the public key must be looked up as a sub-state. Only successful completion of all the DNS lookups is considered a success.
創始者が、公開鍵がTXT委譲記録に存在しているのがわからないならサブ状態として公開鍵を見上げなければならないことに注意してください。 すべてのDNSルックアップの無事終了だけが成功であると考えられます。
If DNS lookup does not find a resource record or if DNS times out, then the initiator considers the receiver not OE capable. If this is an OE-paranoid instance, then the potential OE connection makes a transition to the deny connection state. If this is an OE-permissive instance, then the potential OE connection makes a transition to the clear-text connection state.
DNSルックアップがリソース記録を見つけないか、DNS回のアウトであるなら、創始者は、どんな受信機OEもできないと考えます。 これがOE-パラノイアインスタンス、次に、接続が変遷をする潜在的OEである、接続状態を否定してください。 これがOE寛大なインスタンスであるなら、潜在的OE接続はクリアテキスト接続状態への変遷をします。
If the initiator finds a resource record, but it is not properly formatted, or if DNSSEC is enabled and reports a failure to authenticate, then the potential OE connection makes a transition to the deny connection state. This action SHOULD be logged. If the administrator wishes to override this transition between states, then an always-clear class can be installed for this flow. An implementation MAY make this situation a new class.
創始者がリソース記録を見つけますが、DNSSECがフォーマットされるか、可能にされて、または認証する失敗を報告するならそれが適切にそうでなく、その時が接続が変遷をする潜在的OEである、接続状態を否定してください。 この動作SHOULD、登録されてください。 管理者が州の間のこの変遷をくつがえしたいなら、この流れのためにいつも明確なクラスをインストールできます。 実装はこの状況を新しいクラスにするかもしれません。
3.2.4.1. Restriction on Unauthenticated TXT Delegation Records
3.2.4.1. Unauthenticated TXT委譲記録における制限
An implementation SHOULD also provide an additional administrative control on delegation records and DNSSEC. This control would apply to delegation records (the TXT records in the reverse-map) that are not protected by DNSSEC. Records of this type are only permitted to delegate to their own address as a gateway. When this option is enabled, an active attack on DNS will be unable to redirect packets to other than the original destination.
またSHOULDが委譲記録とDNSSECで追加運営管理コントロールを提供する実装。 このコントロールはDNSSECによって保護されない委譲記録(逆地図でのTXT記録)に申請されるでしょう。 このタイプに関する記録がゲートウェイとしてそれら自身のアドレスに委任することが許可されるだけです。 元の目的地以外に、いつにこのオプションは可能にされて、DNSに対する活発な攻撃はパケットを向け直すことができないでしょうか?
3.2.5. Pending OE Connection
3.2.5. 未定のOE接続
The potential OE connection makes a transition to this state when the initiator determines that all the information required from the DNS lookup is present. Upon entering this state, the initiator attempts to initiate keying to the gateway provided.
潜在的OE接続は創始者が、DNSルックアップから必要であるすべての情報が存在していると決心しているとこの状態への変遷をします。 この状態に入って、ゲートウェイとの合わせることを開始する創始者試みは提供されました。
Exit from this state occurs with either a successfully created IPsec SA or a failure of some kind. Successful SA creation results in a transition to the key connection state.
この状態からの出口はある種の首尾よく作成されたIPsec SAか失敗のどちらかで現れます。 うまくいっているSA作成は主要な接続状態への変遷をもたらします。
Three failures have caused significant problems. They are clearly not the only possible failures from keying.
3つの失敗が重大な問題を引き起こしました。それらは明確に合わせるのからの唯一の可能な失敗ではありません。
Richardson & Redelmeier Informational [Page 16] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[16ページ]のRFC4322の便宜主義的な暗号化
Note that if there are multiple gateways available in the TXT delegation records, then a failure can only be declared after all of them have been tried. Further, creation of a phase 1 SA does not constitute success. A set of phase 2 SAs (a tunnel) is considered success.
TXT委譲記録で利用可能な複数のゲートウェイがある場合にだけそれらのすべてを試みてある後に失敗を宣言できることに注意してください。 さらに、フェーズ1SAの作成は成功を構成しません。 フェーズ2SAs(トンネル)の1セットは成功であると考えられます。
The first failure occurs when an ICMP port unreachable is consistently received without any other communication, or when there is silence from the remote end. This usually means that either the gateway is not alive, or the keying daemon is not functional. For an OE-permissive connection, the initiator makes a transition to the clear-text connection, but with a low lifespan. For an OE- pessimistic connection, the initiator makes a transition to the deny connection again with a low lifespan. The lifespan in both cases is kept low because the remote gateway may be in the process of rebooting or be otherwise temporarily unavailable.
ICMPポートであるときに、手が届かないのは、一貫してそうです。最初の失敗が起こる、いかなる他のコミュニケーションのはないリモートエンドからの沈黙があること時受け取ります。 通常、これは、ゲートウェイが生きていないか、または合わせるデーモンが機能的でないことを意味します。 OE寛大な接続のために、クリアテキスト接続への変遷をしますが、創始者は低い寿命でそうします。 OEの悲観的な接続、造のaが移行する創始者、低い寿命でもう一度接続を否定してください。 リモートゲートウェイがリブートの途中にあるか、またはそうでなければ、一時入手できないかもしれないので、寿命はどちらの場合も、低く保たれます。
The length of time to wait for the remote keying daemon to wake up is a matter of some debate. If there is a routing failure, 5 minutes is usually long enough for the network to re-converge. Many systems can reboot in that amount of time as well. However, 5 minutes is far too long for most users to wait to hear that they can not connect using OE. Implementations SHOULD make this a tunable parameter.
リモート合わせるデーモンが目覚めるのを待つ時間の長さは何らかの討論の問題です。 ルーティング失敗があれば、通常、5分はネットワークが再一点に集めることができるくらい長いです。 多くのシステムがまた、その時間、リブートされることができます。 しかしながら、5分はほとんどのユーザが、彼らがOEを使用することで接続できないと聞くのを待つことができないくらい長いです。 実装SHOULDはこれを調整可能なパラメタにします。
The second failure occurs after a phase 1 SA has been created, but there is either no response to the phase 2 proposal, or the initiator receives a negative notify (the notify must be authenticated). The remote gateway is not prepared to do OE at this time. As before, the initiator makes a transition to the clear-text or the deny connection based upon connection class, but this time with a normal lifespan.
2番目の失敗が起こる、フェーズの後に、1SAが作成されましたが、フェーズ2提案への応答が全くないか、または創始者がネガが通知するaを受ける、(通知、認証しなければならない、) リモートゲートウェイはこのときOEをするように準備されません。 または、創始者が従来と同様、クリアテキストへの変遷をする、正常な寿命で接続のクラスにもかかわらず、今回ベースの接続を否定してください。
The third failure occurs when there is signature failure while authenticating the remote gateway. This can occur when there has been a key roll-over, but DNS has not caught up. In this case again, the initiator makes a transition to the clear-text or the deny connection based upon the connection class. However, the lifespan depends upon the remaining time to live in the DNS. (Note that DNSSEC signed resource records have a different expiry time from non-signed records.)
署名失敗がリモートゲートウェイを認証している間あるとき、3番目の失敗は起こります。 主要なロールオーバーがあったとき、これは起こることができますが、DNSは追いついていません。 または、創始者がこの場合一方、クリアテキストへのa変遷をする、接続のクラスに基づいた接続を否定してください。 しかしながら、寿命はDNSに住む残っている時によります。 (リソース記録であると署名されるDNSSECが非署名している記録からのいろいろな満期時間を過すことに注意してください。)
3.2.6. Keyed Connection
3.2.6. 合わせられた接続
The pending OE connection makes a transition to this state when session keying material (the phase 2 SAs) is derived. The initiator creates an encrypt policy in the forwarding plane for this flow.
材料(フェーズ2SAs)を合わせるセッションが引き出されるとき、未定のOE接続はこの状態への変遷をします。 創始者が作成する、この流れのために推進飛行機で方針を暗号化してください。
Richardson & Redelmeier Informational [Page 17] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[17ページ]のRFC4322の便宜主義的な暗号化
There are three ways to exit this state. The first is by receipt of an authenticated delete message (via the keying channel) from the peer. This is normal teardown and results in a transition to the expired connection state.
この状態を出る3つの方法があります。 1番目が領収書である、認証されて、同輩からメッセージ(合わせることを通って、精神を集中する)を削除してください。 これは、正常な分解であり、満期の接続状態への変遷をもたらします。
The second exit is by expiry of the forwarding plane keying material. This starts a re-key operation with a transition back to pending OE connection. In general, the soft expiry occurs with sufficient time left to continue using the keys. A re-key can fail, which may result in the connection failing to clear-text or deny as appropriate. In the event of a failure, the forwarding plane policy does not change until the phase 2 SA (IPsec SA) reaches its hard expiry.
2番目の出口が材料を合わせる推進飛行機の満期であります。 これは未定のOE接続への変遷から再主要な操業を開始します。 一般に、柔らかい満期はキーを使用し続けているのを残っている十分な時間で起こります。 または、再キー(クリアテキストに失敗する接続をもたらすかもしれない)が失敗できる、適宜、否定します。 失敗の場合、フェーズ2SA(IPsec SA)が困難な満期に達するまで、推進飛行機方針は変化しません。
The third exit is in response to a negotiation from a remote gateway. If the forwarding plane signals the control plane that it has received an unknown SPI from the remote gateway, or an ICMP is received from the remote gateway indicating an unknown SPI, the initiator should consider that the remote gateway has rebooted or restarted. Since these indications are easily forged, the implementation must exercise care. The initiator should make a cautious (rate-limited) attempt to re-key the connection.
3番目の出口はリモートゲートウェイからの交渉に対応しています。 推進飛行機が、リモートゲートウェイから未知のSPIを受けたか、またはICMPが未知のSPI、創始者を示すのがそうするべきであるリモートゲートウェイから受け取られると制御飛行機に合図するなら、リモートゲートウェイがリブートするか、または再開したと考えてください。 これらの指摘が容易に鍛造されるので、実装は注意しなければなりません。 創始者は再キーへの用心深い(レートで限られた)試みを接続に作るべきです。
3.2.7. Expiring Connection
3.2.7. 接続を吐き出します。
The initiator will periodically place each of the deny, clear-text, and keyed connections into this sub-state. See Section 3.4 for more details of how often this occurs. The initiator queries the forwarding plane for last use time of the appropriate policy. If the last use time is relatively recent, then the connection returns to the previous deny, clear-text or keyed connection state. If not, then the connection enters the expired connection state.
創始者が定期的にそれぞれを置く、否定、クリアテキスト、およびこのサブ状態との合わせられた接続。 これがどれくらいの頻度で起こるかに関するその他の詳細に関してセクション3.4を見てください。 最終が適切な方針の時間を費やすので、創始者は推進飛行機について質問します。 最後の使用であるなら、時間は比較的最近です、前への接続リターンが否定するその時、明確なテキストの、または、合わせられた接続状態。 そうでなければ、そして、接続は満期の接続状態に入ります。
The DNS query and answer that lead to the expiring connection state are also examined. The DNS query may become stale. (A negative, i.e., no such record, answer is valid for the period of time given by the MINIMUM field in an attached SOA record. See [RFC1034] section 4.3.4.) If the DNS query is stale, then a new query is made. If the results change, then the connection makes a transition to a new state as described in potential OE connection state.
また、期限が切れている接続状態につながるDNS質問と答えは調べられます。 DNS質問は聞き古したであるなるかもしれません。 (否定的で、すなわち、あれほど記録的な答えは添付のSOA記録のMINIMUM分野によって与えられた期間に有効です。 [RFC1034]セクション4.3.4を見てください。) DNS質問が聞き古したである、新しい質問をします。 結果が変化するなら、接続は潜在的OE接続状態で説明されるように新しい状態への変遷をします。
Note that when considering how stale a connection is, both outgoing SPD and incoming SAD must be queried as some flows may be unidirectional for some time.
接続がどれくらい聞き古したであるか考えるとき、しばらくいくつかの流れが単方向であるかもしれないので、出発しているSPDと入って来るSADの両方について質問しなければならないことに注意してください。
Also note that the policy at the forwarding plane is not updated unless there is a conclusion that there should be a change.
また、変化があるはずであるという結論がない場合推進飛行機の方針をアップデートしないことに注意してください。
Richardson & Redelmeier Informational [Page 18] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[18ページ]のRFC4322の便宜主義的な暗号化
3.2.8. Expired Connection
3.2.8. 満期の接続
Entry to this state occurs when no datagrams have been forwarded recently via the appropriate SPD and SAD objects. The objects in the forwarding plane are removed (logging any final byte and packet counts, if appropriate) and the connection instance in the keying plane is deleted.
最近適切なSPDとSADオブジェクトを通してデータグラムを全く進めていないとき、この状態へのエントリーは現れます。 推進飛行機のオブジェクトを取り除きます、そして、(適切であるならどんな最終的なバイトとパケットカウントも登録して)合わせる飛行機の接続インスタンスを削除します。
The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in Section 3.4.
創始者はISAKMP/IKEを送ります。セクション3.4における説明されるとしての2SAsをフェーズに掃除するために、削除します。
Whether or not to delete the phase 1 SAs at this time is left as a local implementation issue. Implementations that do delete the phase 1 SAs MUST send authenticated delete messages to indicate that they are doing so. There is an advantage to keeping the phase 1 SAs until they expire: they may prove useful again in the near future.
このときフェーズ1SAsを削除するかどうかがローカルの導入問題として残されます。 認証されていた状態で1SAsが送らなければならないフェーズを削除する実装がそうしているのを示すメッセージを削除します。 彼らが期限が切れるまでフェーズが1SAsであることを保つ利点があります: 彼らは近い将来、再び有用であることが分かるかもしれません。
Richardson & Redelmeier Informational [Page 19] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[19ページ]のRFC4322の便宜主義的な暗号化
3.3. Keying Daemon -- Responder
3.3. デーモン--応答者を合わせます。
The responder has a set of objects identical to those of the initiator.
応答者には、創始者のものと同じオブジェクトのセットがあります。
The responder receives an invitation to create a keying channel from an initiator.
応答者は創始者から合わせているチャンネルを創造する招待状を受けます。
|
| IKE main mode
| phase 1
V
.-----------------.
| unauthenticated |
| OE peer |
`-----------------'
|
| lookup KEY RR in in-addr.arpa
| (if ID_IPV4_ADDR)
| lookup KEY RR in forward
| (if ID_FQDN)
V
.-----------------. RR not found
| received DNS |---------------> log failure
| reply |
`----+--------+---'
phase 2 | \ misformatted
proposal | `------------------> log failure
V
.----------------.
| authenticated | identical initiator
| OE peer |--------------------> initiator
`----------------' connection found state machine
|
| look for TXT record for initiator
|
V
.---------------.
| authorized |---------------------> log failure
| OE peer |
`---------------'
|
|
V
potential OE
connection in
initiator state
machine
| | IKEの主なモード| 1Vの位相を合わせてください。-----------------. | 非認証しました。| | OE同輩| `-----------------' | | addr.arpaのルックアップKEY RR| (_ID IPV4_ADDRであるなら) | フォワードのルックアップKEY RR| (ID_FQDNであるなら) V。-----------------. 見つけられなかったRR| 容認されたDNS|--------------->ログの故障| 返信| `----+--------+---'フェーズ2'| \は提案をmisformattedしました。| `------------------>ログの故障V。----------------. | 認証されます。| 同じ創始者| OE同輩|-------------------->'創始者‘----------------'接続は、状態がマシンであることがわかりました'| | 創始者のためにTXT記録を探してください。| V。---------------. | 認可されます。|--------------------->ログの故障| OE同輩| `---------------' | | 創始者州のマシンでのV潜在的OE接続
Richardson & Redelmeier Informational [Page 20] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[20ページ]のRFC4322の便宜主義的な暗号化
3.3.1. Unauthenticated OE Peer
3.3.1. Unauthenticated OE同輩
Upon entering this state, the responder starts a DNS lookup for a KEY record for the initiator. The responder looks in the reverse-map for a KEY record for the initiator if the initiator has offered an ID_IPV4_ADDR, and in the forward map if the initiator has offered an ID_FQDN type. (See [RFC2407] section 4.6.2.1.)
この状態に入ると、応答者は創始者へのKEY記録のためにDNSルックアップを始めます。 創始者がID_IPV4_ADDRを提供したなら、応答者は創始者のためにKEY記録に関して逆地図の中を見ます、そして、前進の地図では、創始者がID_を提供したなら、FQDNはタイプします。 (.1に[RFC2407]セクション4.6.2を見ます)
The responder exits this state upon successful receipt of a KEY from DNS, and use of the key to verify the signature of the initiator.
応答者は、創始者の署名について確かめるためにDNSからのKEYのうまくいっている領収書、およびキーの使用のこの状態を出ます。
Successful authentication of the peer results in a transition to the authenticated OE Peer state.
同輩のうまくいっている認証は認証されたOE Peer状態への変遷をもたらします。
Note that the unauthenticated OE peer state generally occurs in the middle of the key negotiation protocol. It is really a form of pseudo-state.
一般に、unauthenticated OE同輩状態が主要な交渉プロトコルの中央に起こることに注意してください。 それは本当に疑似状態のフォームです。
3.3.2. Authenticated OE Peer
3.3.2. 認証されたOE同輩
The peer will eventually propose one or more phase 2 SAs. The responder uses the source and destination address in the proposal to finish instantiating the connection state using the connection class table. The responder MUST search for an identical connection object at this point.
同輩は結局、1つ以上のフェーズ2SAsを提案するでしょう。 応答者は接続クラステーブルを使用することで接続状態を例示し終えるという提案にソースと送付先アドレスを使用します。 応答者はここに同じ接続オブジェクトを捜し求めなければなりません。
If an identical connection is found, then the responder deletes the old instance, and the new object makes a transition to the pending OE connection state. This means that new ISAKMP connections with a given peer will always use the latest instance, which is the correct one if the peer has rebooted in the interim.
同じ接続が見つけられるなら、応答者は古いインスタンスを削除します、そして、新しいオブジェクトは未定のOE接続状態への変遷をします。 これは、与えられた同輩との新しいISAKMP接続がいつも最新のインスタンスを使用することを意味します。(同輩がその間リブートしているなら、インスタンスは正しい方です)。
If an identical connection is not found, then the responder makes the transition according to the rules given for the initiator: it installs appropriate policy: clear, drop, or OE.
同じ接続が見つけられないなら、応答者は創始者のために与えられた規則に従って変遷をします: それは適切な方針をインストールします: クリアしてください、低下、またはOE。
If OE, and the phase 2 ID (source IP) is different than the phase 1 ID, then additional authorization is required. A TXT record associated with the proposed phase 2 source IP is requested. This is used to confirm authorization for the phase 1 identity to encrypt on behalf of the phase 2. Successful retrieval results in a transition to "Authorized OE Peer".
OE、およびフェーズ2ID(ソースIP)がそうなら、フェーズ1IDと異なって、次に、追加している承認が必要です。 提案されたフェーズ2ソースIPに関連しているTXT記録は要求されています。 これは、フェーズ1のアイデンティティがフェーズ2を代表して暗号化する承認を確認するのに使用されます。 うまくいっている検索は「認可されたOEはじっと見ること」への変遷をもたらします。
Note that if the initiator is in OE-paranoid mode and the responder is in either always-clear-text or deny, then no communication is possible according to policy. An implementation is permitted to create new types of policies such as "accept OE but do not initiate it". This is a local matter.
創始者がOE-パラノイアモードでいて、応答者がいつもクリアテキストにいるなら、それに注意するか、またはそして、方針によると、どんなコミュニケーションも可能でないことを否定してください。 実装が新しいタイプの「OEを受け入れなさい、ただし、それを開始しないでください」などの方針を作成することが許可されています。 これは地域にかかわる事柄です。
Richardson & Redelmeier Informational [Page 21] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[21ページ]のRFC4322の便宜主義的な暗号化
3.3.3. Authorized OE Peer
3.3.3. 認可されたOE同輩
This state is entered from the Authenticated OE Peer state, upon successful retrieval of the TXT record. The contents of the record are confirmed -- any failures lead to errors, as indicated in Section 3.2.4.
この状態はTXT記録のうまくいっている検索のAuthenticated OE Peer状態から入られます。 記録の内容は確認されます--どんな失敗もセクション3.2.4にみられるように誤りにつながります。
3.4. Renewal and Teardown
3.4. 更新と分解
3.4.1. Aging
3.4.1. 年をとること
A potentially unlimited number of tunnels may exist. In practice, only a few tunnels are used during a period of time. Unused tunnels MUST, therefore, be torn down. Detecting when tunnels are no longer in use is the subject of this section.
潜在的に無制限な数のトンネルが存在するかもしれません。 実際には、ほんのいくつかのトンネルが期間の間、使用されます。 したがって、未使用のトンネルを取りこわさなければなりません。 トンネルがいつもう使用中でないかを検出するのは、このセクションの対象です。
There are two methods for removing tunnels: explicit deletion or expiry.
トンネルを取り外すための2つのメソッドがあります: 明白な削除か満期。
Explicit deletion requires an IKE delete message. The deletes MUST be authenticated, so both ends of the tunnel must maintain the keying channel (phase 1 ISAKMP SA). An implementation that refuses to either maintain or recreate the keying channel SA will be unable to use this method.
明白な削除はIKEを必要とします。メッセージを削除してください。 削除、認証しなければならないので、トンネルの両端は合わせているチャンネルを維持しなければなりません(1ISAKMP SAの位相を合わせてください)。 合わせているチャンネルSAを維持するか、または再作成するのを拒否する実装は、このメソッドを使用できないでしょう。
The tunnel expiry method simply allows the IKE daemon to expire normally without attempting to re-key it.
トンネル満期メソッドで、再キーにそれを試みないで、IKEデーモンは単に通常期限が切れます。
Regardless of which method is used to remove tunnels, the implementation MUST use a method to determine if the tunnel is still in use. The specifics are a local matter, but the FreeS/WAN project uses the following criteria. These criteria are currently implemented in the key management daemon, but could also be implemented at the SPD layer using an idle timer.
どのメソッドがトンネルを取り外すのに使用されるかにかかわらず、実装はトンネルがまだ使用中であるかどうか決定するメソッドを使用しなければなりません。 詳細は地域にかかわる事柄ですが、FreeS/WANプロジェクトは以下の評価基準を使用します。 これらの評価基準を現在かぎ管理デーモンで実装されますが、また、SPD層で使用されていないタイマを使用することで実装することができるでしょう。
Set a short initial (soft) lifespan of 1 minute since many net flows last only a few seconds.
多くの純計循環がほんの数秒持続するので、1分の短い初期(柔らかい)の寿命を設定してください。
At the end of the lifespan, check to see if the tunnel was used by traffic in either direction during the last 30 seconds. If so, assign a longer tentative lifespan of 20 minutes, after which, look again. If the tunnel is not in use, then close the tunnel.
寿命の終わりでは、チェックして、トンネルが最後の30秒間、トラフィックによってどちらの方向にも使用されたかどうか確認してください。 そうだとすれば、後に20分の、より長い一時的な寿命を割り当ててください、どれ、もう一度見てくださいか。 トンネルが使用中でないなら、トンネルを閉じてください。
The expiring state in the key management system (see Section 3.2.7) implements these timeouts. The timer above may be in the forwarding plane, but then it must be resettable.
かぎ管理システム(セクション3.2.7を見る)の吐き出す州はこれらのタイムアウトを実装します。 上のタイマが推進飛行機にあるかもしれませんが、それは「再-舗装用敷石-可能」であるに違いありません。
Richardson & Redelmeier Informational [Page 22] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[22ページ]のRFC4322の便宜主義的な暗号化
The tentative lifespan is independent of re-keying; it is just the time when the tunnel's future is next considered. (The term lifespan is used here rather than lifetime for this reason.) Unlike re- keying, this tunnel use check is not costly and should happen reasonably frequently.
一時的な寿命は再の合わせるのから独立しています。 ただトンネルの未来が考えられた状態で次である時です。 (用語寿命はこの理由にここで生涯よりむしろ使用されます。) 再の合わせることと異なって、使用がチェックするこのトンネルは、高価でなく、頻繁に合理的に起こるはずです。
A multi-step back-off algorithm is not considered worth the effort here.
多段階下に後部アルゴリズムはここの取り組みの価値があると考えられません。
If the security gateway and the client host are the same, and not a Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel teardown decisions MAY pay attention to TCP connection status as reported by the local TCP layer. A still-open TCP connection is almost a guarantee that more traffic is expected. Closing of the only TCP connection through a tunnel is a strong hint that no more traffic is expected.
セキュリティゲートウェイとクライアントホストが同じであるか、そして、どんなスタックのBumpかワイヤのBump実装、トンネル分解決定は地方のTCP層のそばで報告されるようにTCP接続形態に注意を向けないかもしれません。 まだオープンなTCP接続はほとんどより多くのトラフィックが予想されるという保証です。 トンネルを通る唯一のTCP接続の閉鎖はそれ以上のトラフィックが全く予想されないという強いヒントです。
3.4.2. Teardown and Cleanup
3.4.2. 分解とクリーンアップ
Teardown should always be coordinated between the two ends of the tunnel by interpreting and sending delete notifications. There is a detailed sub-state in the expired connection state of the key manager that relates to retransmits of the delete notifications, but this is considered to be a keying system detail.
分解はトンネルの2つの端の間で解釈することによって、いつも調整されるべきです、そして、発信は通知を削除します。 そこ、それが関連する主要なマネージャの満期の接続状態の詳細なサブ状態が再送されるということである、通知を削除しなさい、ただし、これはa合わせているシステムの詳細であると考えられます。
On receiving a delete for the outbound SAs of a tunnel (or some subset of them), tear down the inbound ones also and notify the remote end with a delete. If the local system receives a delete for a tunnel that is no longer in existence, then two delete messages have crossed paths. Ignore the delete. The operation has already been completed. Do not generate any messages in this situation.
aを受けたら、外国行きのためにトンネル(または、彼らの何らかの部分集合)のSAsを削除してください、そして、本国行きのものも取りこわしてください、そして、aがある終わりが削除するリモートに通知してください。 ローカルシステムがaを受けるなら、aのためにもう現存しないトンネルを削除してください、そして、次に、2はメッセージを削除します。経路に交差しました。 無視、削除します。 操作は既に完了しました。 この状況におけるどんなメッセージも生成しないでください。
Tunnels are to be considered as bidirectional entities, even though the low-level protocols don't treat them this way.
低レベルであるプロトコルはこのようにそれらを扱いませんが、トンネルは双方向の実体であるとみなされることになっています。
When the deletion is initiated locally, rather than as a response to a received delete, send a delete for (all) the inbound SAs of a tunnel. If the local system does not receive a responding delete for the outbound SAs, try re-sending the original delete. Three tries spaced 10 seconds apart seems a reasonable level of effort. A failure of the other end to respond after 3 attempts indicates that the possibility of further communication is unlikely. Remove the outgoing SAs. (The remote system may be a mobile node that is no longer present or powered on.)
aを送ってください。削除がいつ応答より局所的に、むしろ開始されるかがaに受信された、削除、(すべて)には、トンネルの本国行きSAsを削除してください。 ローカルシステムが応じることを受けないなら、外国行きのためにSAsを削除してください、そして、オリジナルが削除する再送を試みてください。 10秒離れて区切られた3つのトライが妥当な水準の取り組みに見えます。 3つの試みの後に応じない場合、さらなるコミュニケーションの可能性がありそうもないのを示します。 出発しているSAsを取り外してください。 (リモートシステムはもう存在していなくて、電源を入れられているモバイルノードであるかもしれません。)
After re-keying, transmission should switch to using the new outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover outgoing SAs should be cleared out promptly (delete should be sent for the
再の合わせる、トランスミッションがすぐに新しい出発しているSAs(ISAKMPかIPsec)を使用するのに切り替わるべきであり、古い残り物の出発しているSAsが即座に取り除かれたべきであった後、(削除、呼びにやられるべきです。
Richardson & Redelmeier Informational [Page 23] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[23ページ]のRFC4322の便宜主義的な暗号化
outgoing SAs) rather than waiting for them to expire. This reduces clutter and minimizes confusion for the operator doing diagnostics.
出発しているSAs) 彼らが期限が切れるのを待つよりむしろ。 これは、病気の特徴をしているオペレータのために、散乱を減少させて、混乱を最小にします。
4. Impacts on IKE
4. IKEの上の影響
4.1. ISAKMP/IKE Protocol
4.1. ISAKMP/IKEプロトコル
The IKE wire protocol needs no modifications. The major changes are implementation issues relating to how the proposals are interpreted, and from whom they may come.
IKEワイヤプロトコルは変更を全く必要としません。 大きな変化は提案がどのように解釈されるか、そして、それらがだれから来るかもしれないかから関係する導入問題です。
As opportunistic encryption is designed to be useful between peers without prior operator configuration, an IKE daemon must be prepared to negotiate phase 1 SAs with any node. This may require a large amount of resources to maintain cookie state, as well as large amounts of entropy for nonces, cookies, and so on.
便宜主義的な暗号化が同輩の間で先のオペレータ構成なしで役に立つように設計されているとき、フェーズ1SAsをあらゆるノードと交渉するようにIKEデーモンを準備しなければなりません。 これはクッキー状態を維持するために多量のリソースを必要とするかもしれません、一回だけのための多量のエントロピー、クッキーなどと同様に。
The major changes to support opportunistic encryption are at the IKE daemon level. These changes relate to handling of key acquisition requests, lookup of public keys and TXT records, and interactions with firewalls and other security facilities that may be co-resident on the same gateway.
便宜主義的な暗号化をサポートする大きな変化がIKEデーモンレベルにあります。 これらの変化は同じゲートウェイの上のコレジデントであるかもしれない主要な獲得要求の取り扱い、公開鍵とTXT記録のルックアップ、およびファイアウォールと他のセキュリティ施設との相互作用に関連します。
4.2. Gateway Discovery Process
4.2. ゲートウェイ発見プロセス
In a typical configured tunnel, the address of SG-B is provided via configuration. Furthermore, the mapping of an SPD entry to a gateway is typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then the mapping to a gateway is determined by the reverse DNS records.
典型的な構成されたトンネルに、構成でSG-Bのアドレスを提供します。 その上、通常、ゲートウェイへのSPDエントリーに関するマッピングは1:1マッピングです。 0.0.0.0/0SPDエントリ手法が使用されていると、ゲートウェイへのマッピングは逆のDNS記録で決定します。
The need to do a DNS lookup and wait for a reply will typically introduce a new state and a new event source (DNS replies) to IKE. Although a synchronous DNS request can be implemented for proof of concept, experience is that it can cause very high latencies when a queue of queries must all timeout in series.
DNSルックアップをして、回答を待つ必要性は新しい状態と新しいイベントソース(DNS回答)をIKEに通常紹介するでしょう。 概念の証拠のために同期DNS要求を実装することができますが、経験は質問の待ち行列はシリーズにおけるすべてのタイムアウトを引き起こさなければならないとき、非常に高い潜在を引き起こす場合があるということです。
Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with some of the protocol steps.
また、非同期なDNSルックアップの使用はプロトコルステップのいくつかでDNSルックアップのオーバラップを可能にするでしょう。
4.3. Self Identification
4.3. 自己識別
SG-A will have to establish its identity. Use an IPv4 (IPv6) ID in phase 1.
SG-意志はアイデンティティを確立しなければなりません。 フェーズ1にIPv4(IPv6)IDを使用してください。
There are many situations where the administrator of SG-A may not be able to control the reverse DNS records for SG-A's public IP address. Typical situations include dialup connections and most residential-
多くの状況がSG-Aの管理者がSG-Aの公共のIPアドレスのための逆のDNS記録を制御できないかもしれないところにあります。 典型的な状況は住宅であることで電話での接続を最も含んでいます。
Richardson & Redelmeier Informational [Page 24] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[24ページ]のRFC4322の便宜主義的な暗号化
type broadband Internet access (ADSL, cable-modem) connections. In these situations, a fully qualified domain name that is under the control of SG-A's administrator may be used when acting as an initiator only. The FQDN ID should be used in phase 1. See Section 5.3 for more details and restrictions.
広帯域インターネットアクセス(ADSL、ケーブルモデム)接続をタイプしてください。 これらの状況で、創始者だけとして機能するとき、SG-Aの管理者のコントロールの下にある完全修飾ドメイン名は使用されるかもしれません。 FQDN IDはフェーズ1に使用されるべきです。 その他の詳細と制限に関してセクション5.3を見てください。
4.4. Public Key Retrieval Process
4.4. 公開鍵検索過程
Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID or an FQDN ID, an IKE daemon needs to examine local caches and configuration files to determine if this is part of a configured tunnel. If no configured tunnels are found, then the implementation should attempt to retrieve a KEY record from the reverse DNS in the case of an IPv4/IPv6 ID, or from the forward DNS in the case of FQDN ID.
IPv4(IPv6)IDかFQDN IDのどちらかとのフェーズの1SAの提案を受け取り次第、IKEデーモンは、これが構成されたトンネルの一部であるかどうか決定するためにローカルなキャッシュと構成ファイルを調べる必要があります。 構成されたトンネルが全く見つけられないなら、実装は、IPv4/IPv6IDの場合における逆のDNS、または、FQDN IDの場合における前進のDNSからのKEY記録を検索するのを試みるべきです。
It is reasonable that if other non-local sources of policy are used (COPS, LDAP), they be consulted concurrently, but that some clear ordering of policy be provided. Note that due to variances in latency, implementations must wait for positive or negative replies from all sources of policy before making any decisions.
他なら方針の非地元筋が使用されているのが(COPS、LDAP)、妥当である、彼ら、方針のいくつかの明確な注文を提供していなかったなら、同時に相談してください。 どんな決定もする前に潜在における変化のため、実装が方針のすべての源から肯定しているか否定している回答を待たなければならないことに注意してください。
4.5. Interactions with DNSSEC
4.5. DNSSECとの相互作用
The implementation described (FreeS/WAN 1.98) neither uses DNSSEC directly to explicitly verify the authenticity of zone information, nor uses the NSEC records to provide authentication of the absence of a TXT or KEY record. Rather, this implementation uses a trusted path to a DNSSEC-capable caching resolver.
説明された実装(FreeS/WAN1.98)は、明らかにゾーン情報の信憑性について確かめるのに直接DNSSECを使用しないで、またTXTかKEY記録の欠如の認証を提供するのにNSEC記録を使用しません。 むしろ、この実装はDNSSEC有能なキャッシュしているレゾルバに信じられた経路を使用します。
To distinguish between an authenticated and an unauthenticated DNS resource record, a stub resolver capable of returning DNSSEC information MUST be used.
そして、見分ける、認証、unauthenticated DNSリソース記録、情報をDNSSECに返すことができるスタッブレゾルバを使用しなければなりません。
4.6. Required Proposal Types
4.6. 必要な提案タイプ
4.6.1. Phase 1 Parameters
4.6.1. フェーズ1パラメタ
Main mode MUST be used.
主なモードを使用しなければなりません。
The initiator MUST offer at least one proposal using some combination of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be proposed first. (See [RFC3526])
創始者は以下の何らかの組み合わせを使用する少なくとも1つの提案を出さなければなりません。 3DESかHMAC-MD5かHMAC-SHA1、DHが2か5を分類します。 5SHOULDを分類してください。最初に、提案されます。 ([RFC3526]を見ます)
The initiator MAY offer additional proposals, but the cipher MUST not be weaker than 3DES. The initiator SHOULD limit the number of proposals such that the IKE datagrams do not need to be fragmented.
創始者が追加提案を出すかもしれませんが、暗号は3DESより弱いはずがありません。 創始者SHOULDが提案の数を制限するので、IKEデータグラムは断片化される必要はありません。
Richardson & Redelmeier Informational [Page 25] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[25ページ]のRFC4322の便宜主義的な暗号化
The responder MUST accept one of the proposals. If any configuration of the responder is required, then the responder is not acting in an opportunistic way.
応答者は提案の1つを受け入れなければなりません。 何か応答者の構成が必要であるなら、応答者は便宜主義的な方法で行動していません。
The initiator SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the external interface of the initiator for phase 1. (There is an exception, see Section 5.3.) The authentication method MUST be RSA public key signatures. The RSA key for the initiator SHOULD be placed into a DNS KEY record in the reverse space of the initiator (i.e., using in-addr.arpa or ip6.arpa).
創始者SHOULDはフェーズ1に、_創始者の外部のインタフェースのID IPV4_ADDR(_IPv6のためのID IPV6_ADDR)を使用します。 (セクション5.3は、例外があるのを見ます。) 認証方法はRSA公開鍵署名であるに違いありません。 RSAは創始者のためにSHOULDを合わせます。創始者(すなわち、addr.arpaで使用するか、ip6.arpa)の逆のスペースにDNS KEY記録に置かれてください。
4.6.2. Phase 2 Parameters
4.6.2. フェーズ2パラメタ
The initiator MUST propose a tunnel between the ultimate sender
("Alice" or "A") and ultimate recipient ("Bob" or "B") using 3DES-CBC
mode, MD5, or SHA1 authentication. Perfect Forward Secrecy MUST be
specified.
3DES-CBCモード、MD5、またはSHA1認証を使用して、創始者は究極の送付者(「アリス」か「A」)と究極の受取人(「ボブ」か「B」)の間のトンネルを提案しなければなりません。 完全なForward Secrecyを指定しなければなりません。
Tunnel mode MUST be used.
トンネルモードを使用しなければなりません。
Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
アイデンティティは_ID_IPV4がマスク存在/32があるADDR_SUBNETであったならそうしなければなりません。
Authorization for the initiator to act on Alice's behalf is determined by looking for a TXT record in the reverse-map at Alice's IP address.
創始者がアリスの代理に行動させる承認は、TXTを探すことによって、アリスのIPアドレスの逆地図で記録的に決定します。
Compression SHOULD NOT be mandatory. It MAY be offered as an option.
圧縮SHOULD NOT、義務的であってください。 オプションとしてそれを提供するかもしれません。
5. DNS Issues
5. DNS問題
5.1. Use of KEY Record
5.1. 主要な記録の使用
In order to establish their own identities, security gateways SHOULD publish their public keys in their reverse DNS via DNSSEC's KEY record. See section 3 of RFC 2535 [RFC2535].
それら自身のアイデンティティを確立するために、セキュリティゲートウェイSHOULDはそれらの逆のDNSでDNSSECのKEY記録でそれらの公開鍵を発行します。 RFC2535[RFC2535]のセクション3を見てください。
For example:
例えば:
KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
キー0x4200 4 1AQNJjkKlIk9…nYyUkKK8
0x4200: The flag bits, indicating that this key is prohibited for
confidentiality use (it authenticates the peer only, a separate
Diffie-Hellman exchange is used for confidentiality), and that
this key is associated with the non-zone entity whose name is the
RR owner name. No other flags are set.
0×4200: このキーが秘密性使用のために禁止されていて(同輩だけを認証して、別々のディフィー-ヘルマンの交換は秘密性に使用されます)、このキーが名前がRR所有者名である非ゾーン実体に関連しているのを示すフラグビット。 他の旗は全く設定されません。
4: This indicates that this key is for use by IPsec.
4: これは、このキーがIPsecによる使用のためのものであることを示します。
Richardson & Redelmeier Informational [Page 26] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[26ページ]のRFC4322の便宜主義的な暗号化
1: An RSA key is present.
1: RSAキーは存在しています。
AQNJjkKlIk9...nYyUkKK8: The public key of the host as described in
[RFC3110].
AQNJjkKlIk9…nYyUkKK8: 説明されるとしての[RFC3110]のホストの公開鍵。
Use of several KEY records allows for key roll-over. The SIG Payload in IKE phase 1 SHOULD be accepted if the public key, given by any KEY RR, validates it.
いくつかのKEY記録の使用は主要なロールオーバーを考慮します。IKEのSIG有効搭載量は、公開鍵であるなら受け入れられて、どんなKEY RRによっても与えられた1SHOULDの位相を合わせて、それを有効にします。
5.2. Use of TXT Delegation Record
5.2. TXT委譲記録の使用
If, for example, machine Alice wishes SG-A to act on her behalf, then she publishes a TXT record to provide authorization for SG-A to act on Alice's behalf. This is done similarly for Bob and SG-B.
例えば、マシンであるなら、アリスは、SG-Aに彼女の代理に影響して欲しく、次に、彼女は、SG-Aがアリスの代理に影響するように承認を提供するためにTXT記録を発表します。 ボブとSG-Bのために同様にこれをします。
These records are located in the reverse DNS (in-addr.arpa or ip6.arpa) for their respective IP addresses. The reverse DNS SHOULD be secured by DNSSEC. DNSSEC is required to defend against active attacks.
これらの記録は彼らのそれぞれのIPのためのDNS(コネ-addr.arpaかip6.arpa)が扱う逆で位置しています。 DNS SHOULDを逆にしてください。DNSSECによって固定されています。 DNSSECは活発な攻撃に対して防御しなければなりません。
If Alice's address is P.Q.R.S, then she can authorize another node to act on her behalf by publishing records at:
アリスのアドレスがP.Q.R.Sであるなら、彼女は、別のノードが以下で出版記録で彼女の代理に影響するのを認可できます。
S.R.Q.P.in-addr.arpa
addr.arpaのS.R.Q.P.
The contents of the resource record are expected to be a string that uses the following syntax, as suggested in RFC1464 [RFC1464]. (Note that the reply to query may include other TXT resource records used by other applications.)
リソース記録の内容は以下の構文を使用するストリングであると予想されます、RFC1464[RFC1464]に示されるように。 (質問する回答が他のアプリケーションで使用される他のTXTリソース記録を含むかもしれないことに注意してください。)
X-IPsec-Server(P)=A.B.C.D public-key
X-IPsecサーバ(P)はA.紀元前のD公開鍵と等しいです。
Figure 2: Format of reverse delegation record
図2: 逆の委譲記録の形式
P: Specifies a precedence for this record. This is similar to MX
record preferences. Lower numbers have stronger preference.
P: この記録のための先行を指定します。 これはMXの記録的な好みと同様です。 下側の数には、より強い好みがあります。
A.B.C.D: Specifies the IP address of the Security Gateway for this
client machine.
A.紀元前D: SecurityゲートウェイのIPアドレスをこのクライアントマシンに指定します。
public-key: Is the encoded RSA Public key of the Security Gateway.
The public-key is provided here to avoid a second DNS lookup. If
this field is absent, then a KEY resource record should be looked
up in the reverse-map of A.B.C.D. The key is transmitted in
base64 format.
公開鍵: Securityゲートウェイがコード化されたRSA Publicキーがありますか? 2番目のDNSルックアップを避けるために公開鍵をここに提供します。 この分野が欠けるなら、KEYリソース記録はA.紀元前の逆地図で調べられるべきです。D. キーはbase64形式で送られます。
The fields of the record MUST be separated by whitespace. This MAY be: space, tab, newline, or carriage return. A space is preferred.
空白で記録の野原を分離しなければなりません。 これは以下の通りです。 スペース、タブ、ニューライン、または復帰。 スペースは好まれます。
Richardson & Redelmeier Informational [Page 27] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[27ページ]のRFC4322の便宜主義的な暗号化
In the case where Alice is located at a public address behind a security gateway that has no fixed address (or no control over its reverse-map), then Alice may delegate to a public key by domain name.
そして、アリスが定番地(または、逆地図のコントロールがない)を全く持っていないセキュリティゲートウェイの後ろに場内放送に位置している場合では、アリスはドメイン名で公開鍵に委任するかもしれません。
X-IPsec-Server(P)=@FQDN public-key
X-IPsec-Server(P)は@FQDN公開鍵と等しいです。
Figure 3: Format of reverse delegation record (FQDN version)
図3: 逆の委譲記録の形式(FQDNバージョン)
P: Is as above.
FQDN: Specifies the FQDN that the Security Gateway will identify
itself with.
public-key: Is the encoded RSA Public key of the Security Gateway.
P: 同じくらい上に、あります。 FQDN: . 公開鍵でそれ自体で、Securityゲートウェイが特定するFQDNを指定します: Securityゲートウェイがコード化されたRSA Publicキーがありますか?
If there is more than one such TXT record with strongest (lowest numbered) precedence, one Security Gateway is picked arbitrarily from those specified in the strongest-preference records.
そのようなTXTの最も強いことで記録的な1つ以上がある、(下である、番号付、)、先行、1Securityのゲートウェイは最も強い好みの記録で指定されたものから任意に選ばれます。
5.2.1. Long TXT Records
5.2.1. 長いTXT記録
When packed into wire-format, TXT records that are longer than 255 characters are divided into smaller <character-strings>. (See [RFC1035] section 3.3 and 3.3.14.) These MUST be reassembled into a single string for processing. Whitespace characters in the base64 encoding are to be ignored.
ワイヤ形式に詰め込まれると、255のキャラクタより長いTXT記録はさらに小さい<文字列>に分割されます。 ([RFC1035]セクション3.3と3.3.14を見てください。) 処理のために一連にこれらを組み立て直さなければなりません。 base64コード化における空白キャラクタは無視されることになっています。
5.2.2. Choice of TXT Record
5.2.2. TXT記録の選択
It has been suggested to use the KEY, OPT, CERT, or KX records instead of a TXT record. None is satisfactory.
それは、TXT記録の代わりにKEY、OPT、CERT、またはKX記録を使用するために示されました。 なにも満足できません。
The KEY RR has a protocol field that could be used to indicate a new protocol, and an algorithm field that could be used to indicate different contents in the key data. However, the KEY record is clearly not intended for storing what are really authorizations, it is just for identities. Other uses have been discouraged.
KEY RRには、新しいプロトコルを示すのに使用できたプロトコル分野、および重要なデータの異なったコンテンツを示すのに使用できるアルゴリズム分野があります。 しかしながら、KEY記録がことを保存するために明確に意図していないのが、本当に承認であるということである、それはまさしくアイデンティティのためのものです。 他の用途はお勧めできないです。
OPT resource records, as defined in [RFC2671], are not intended to be used for storage of information. They are not to be loaded, cached or forwarded. They are, therefore, inappropriate for use here.
情報のストレージに[RFC2671]で定義されるOPTリソース記録が使用されることを意図しません。 それらをロードされてはいけないか、キャッシュされてはいけないか、または進めてはいけません。 したがって、ここでの使用に、それらは不適当です。
CERT records [RFC2538] can encode almost any set of information. A custom type code could be used permitting any suitable encoding to be stored, not just X.509. According to the RFC, the certificate RRs are to be signed internally, which may add undesirable and unnecessary bulk. Larger DNS records may require TCP instead of UDP transfers.
CERT記録[RFC2538]はほとんどどんなセットの情報もコード化できます。 どんな適当なコード化もX.509であるだけではないのに保存されることを許可しながら、カスタムタイプコードを使用できました。 RFCによると、証明書RRsは内部的に署名されることになっています(望ましくなくて不要な嵩を加えるかもしれません)。 より大きいDNS記録はUDP転送の代わりにTCPを必要とするかもしれません。
Richardson & Redelmeier Informational [Page 28] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[28ページ]のRFC4322の便宜主義的な暗号化
At the time of protocol design, the CERT RR was not widely deployed and could not be counted upon. Use of CERT records will be investigated, and may be proposed in a future revision of this document.
プロトコルデザイン時点で、CERT RRを広く配布しないで、当てにすることができませんでした。 CERT記録の使用は、調査されて、このドキュメントの今後の改正で提案されるかもしれません。
KX records are ideally suited for use instead of TXT records, but had not been deployed at the time of implementation.
KX記録は、理想的にTXT記録の代わりに使用に合いましたが、実装時点で、配布されていませんでした。
5.3. Use of FQDN IDs
5.3. FQDN IDの使用
Unfortunately, not every administrator has control over the contents of the reverse-map. Where the initiator (SG-A) has no suitable reverse-map, the authorization record present in the reverse-map of Alice may refer to a FQDN instead of an IP address.
残念ながら、すべての管理者が逆地図のコンテンツを管理するというわけではありません。 どこ、創始者、(SG-a)がそうしているノー適当な逆地図、アリスの逆地図の現在の承認記録はIPアドレスの代わりにFQDNについて言及するかもしれないか。
In this case, the client's TXT record gives the fully qualified domain name (FQDN) in place of its security gateway's IP address. The initiator should use the ID_FQDN ID-payload in phase 1. A forward lookup for a KEY record on the FQDN must yield the initiator's public key.
この場合、クライアントのTXT記録はセキュリティゲートウェイのIPアドレスに代わって完全修飾ドメイン名(FQDN)を与えます。 創始者はフェーズ1にID_FQDN ID-ペイロードを使用するべきです。 FQDNに関するKEY記録のための前進のルックアップは創始者の公開鍵をもたらさなければなりません。
This method can also be used when the external address of SG-A is dynamic.
また、SG-Aの外部アドレスがダイナミックであるときに、このメソッドを使用できます。
If SG-A is acting on behalf of Alice, then Alice must still delegate authority for SG-A to do so in her reverse-map. When Alice and SG-A are one and the same (i.e., Alice is acting as an end-node) then there is no need for this when initiating only.
SG-Aがアリスを代表して行動しているなら、アリスはまだSG-Aが彼女の逆地図でそうする権威を代表として派遣しなければなりません。 アリスとSG-Aが全く同じであり(すなわち、アリスはエンドノードとして務めています)いいえがこれにいつを必要とするかというそこのその時によることです。開始専用。
However, Alice must still delegate to herself if she wishes others to initiate OE to her. See Figure 3.
しかしながら、他のものに彼女にOEを開始して欲しいなら、アリスはまだ自分に委任しなければなりません。 図3を参照してください。
5.4. Key Roll-Over
5.4. 主要な華麗なる陰謀
Good cryptographic hygiene says that one should replace public/private key pairs periodically. Some administrators may wish to do this as often as daily. Typical DNS propagation delays are determined by the SOA Resource Record MINIMUM parameter, which controls how long DNS replies may be cached. For reasonable operation of DNS servers, administrators usually want this value to be at least several hours, sometimes as a long as a day. This presents a problem: a new key MUST not be used prior to its propagation through DNS.
良い暗号の衛生は、定期的に公衆/秘密鍵組に取って代わるべきであると言います。 日刊誌と同じくらい頻繁にこれをしたがっているかもしれない管理者もいます。 典型的なDNSの浸透遅れはSOA Resource Record MINIMUMパラメタで決定します。(それは、DNS回答がどれくらい長い間キャッシュされるかもしれないかを制御します)。 DNSサーバの合理的な操作のために、通常、管理者は、この値に少なくとも数時間であって欲しいです、時々1日としての長さとして。 これは問題を提示します: DNSを通した伝播の前に新しいキーを使用してはいけません。
This problem is dealt with by having the Security Gateway generate a new public/private key pair, at least MINIMUM seconds in advance of using it. It then adds this key to the DNS (both as a second KEY
Securityゲートウェイに新しい公衆/秘密鍵組を生成させることによって、この問題は対処されています、少なくともそれを使用するMINIMUM秒前に。 次に、それがDNSのこのキーを加える、(第2のKEYとしての両方
Richardson & Redelmeier Informational [Page 29] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[29ページ]のRFC4322の便宜主義的な暗号化
record and in additional TXT delegation records) at key generation time. Note: only one key is allowed in each TXT record.
記録とコネ追加しているTXT委譲記録) キー生成で、調節してください。 以下に注意してください。 1個のキーだけがそれぞれのTXT記録に許容されています。
When authenticating, all gateways MUST have available all public keys that are found in DNS for this entity. This permits the authenticating end to check both the key for "today" and the key for "tomorrow". Note that it is the end which is creating the signature (possesses the private key) that determines which key is to be used.
認証するとき、すべてのゲートウェイには、DNSでこの実体に関して見つけられるすべての利用可能な公開鍵がなければなりません。 これは、認証終わりが「今日」のためのキーと「明日」のためのキーの両方をチェックすることを許可します。 どのキーが使用されていることになっているかを決定するのが、署名(秘密鍵を持っている)を作成している終わりであることに注意してください。
6. Network Address Translation Interaction
6. ネットワーク・アドレス翻訳相互作用
There are no fundamentally new issues for implementing opportunistic encryption in the presence of network address translation. Rather, there are only the regular IPsec issues with NAT traversal.
ネットワークアドレス変換があるとき便宜主義的な暗号化を実装するためのどんな基本的に新しい問題もありません。 むしろ、NAT縦断には通常のIPsec問題しかありません。
There are several situations to consider for NAT.
NATのために考えるいくつかの状況があります。
6.1. Co-Located NAT/NAPT
6.1. 共同見つけられたNAT/NAPT
If a security gateway is also performing network address translation on behalf of an end-system, then the packet should be translated prior to being subjected to opportunistic encryption. This is in contrast to typically configured tunnels, which often exist to bridge islands of private network address space. The security gateway will use the translated source address for phase 2, and so the responding security gateway will look up that address to confirm SG-A's authorization.
また、セキュリティゲートウェイがエンドシステムを代表してネットワークアドレス変換を実行しているなら、パケットは便宜主義的な暗号化にかけられる前に、翻訳されるべきです。 これはと対照してあります。トンネルはしばしば個人的なネットワーク・アドレススペースのブリッジ島に存在します。 セキュリティゲートウェイがフェーズ2に翻訳されたソースアドレスを使用するので、応じているセキュリティゲートウェイはSG-Aの承認を確認するためにそのアドレスを調べるでしょう。
In the case of NAT (1:1), the address space into which the translation is done MUST be globally unique, and control over the reverse-map is assumed. Placing of TXT records is possible.
NAT(1:1)の場合では、翻訳が行われるアドレス空間はグローバルにユニークでなければなりません、そして、逆地図のコントロールは想定されます。 TXT記録の入賞は可能です。
In the case of NAPT (m:1), the address will be the security gateway itself. The ability to get KEY and TXT records in place will again depend upon whether or not there is administrative control over the reverse-map. This is identical to situations involving a single host acting on behalf of itself. For initiators (but not responders), an FQDN-style ID can be used to get around a lack of a reverse-map.
NAPT(m: 1)の場合では、アドレスはセキュリティゲートウェイにな自体でしょう。 適所でKEYとTXTに記録を得る能力は再び逆地図の上に運営管理コントロールがあるかどうかに依存するでしょう。 これはそれ自体を代表して行動している独身のホストにかかわる状況と同じです。 創始者(しかし、応答者でない)に関しては、逆地図の不足を逃れるのにFQDN-スタイルIDを使用できます。
6.2. Security Gateway behind a NAT/NAPT
6.2. NAT/NAPTの後ろのセキュリティゲートウェイ
If there is a NAT or NAPT between the security gateways, then normal IPsec NAT traversal problems occur. In addition to the transport problem, which may be solved by other mechanisms, there is the issue of what phase 1 and phase 2 IDs to use. While FQDN could be used during phase 1 for the security gateway, there is no appropriate ID for phase 2. Due to the NAT, the end systems live in different IP address spaces.
セキュリティゲートウェイの間には、NATかNAPTがあれば、正常なIPsec NAT縦断問題は起こります。 輸送問題に加えて、どんなフェーズ1とフェーズ2IDを使用したらよいかに関する問題があります。輸送問題は他のメカニズムによって解決されるかもしれません。 セキュリティゲートウェイに段階1の間FQDNを使用できましたが、フェーズ2のためのどんな適切なIDもありません。 NATのため、エンドシステムは異なったIPアドレス空間に生きています。
Richardson & Redelmeier Informational [Page 30] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[30ページ]のRFC4322の便宜主義的な暗号化
6.3. End System behind a NAT/NAPT
6.3. NAT/NAPTの後ろのエンドシステム
If the end system is behind a NAT (perhaps SG-B), then there is, in fact, no way for another end system to address a packet to this end system. Not only is opportunistic encryption impossible, but it is also impossible for any communication to be initiated to the end system. It may be possible for this end system to initiate such communication. This creates an asymmetry, but this is common for NAPT.
NAT(恐らくSG-B)の後ろにエンドシステムがあるなら、事実上、別のエンドシステムがこのエンドシステムにパケットを扱う方法が全くありません。 また、便宜主義的な暗号化が不可能であるだけではなく、どんなコミュニケーションもエンドシステムに開始されるのも、不可能です。 このエンドシステムがそのようなコミュニケーションを開始するのは、可能であるかもしれません。 非対称を引き起こしますが、NAPTに、これは一般的です。
7. Host Implementations
7. ホスト導入
When Alice and SG-A are components of the same system, they are considered to be a host implementation. The packet sequence scenario remains unchanged.
アリスとSG-Aが同じシステムの部品であるときに、それらはホスト導入であると考えられます。 パケット系列シナリオは変わりがありません。
Components marked Alice are the upper layers (TCP, UDP, the application), and SG-A is the IP layer.
アリスであるとマークされたコンポーネントは上側の層(TCP、UDP、アプリケーション)です、そして、SG-AはIP層です。
Note that tunnel mode is still required.
トンネルモードがまだ必要であることに注意してください。
As Alice and SG-A are acting on behalf of themselves, no TXT based delegation record is necessary for Alice to initiate. She can rely on FQDN in a forward map. This is particularly attractive to mobile nodes such as notebook computers at conferences. To respond, Alice/SG-A will still need an entry in Alice's reverse-map.
アリスとSG-Aが自分たちを代表して行動しているとき、アリスが開始するのにどんなTXTのベースの委譲記録も必要ではありません。 彼女は前進の地図でFQDNを当てにすることができます。 これは特に会議におけるノートパソコンなどのモバイルノードに魅力的です。 応じるために、SGアリス/意志はまだアリスの逆地図におけるエントリーがそうしなければなりません。
8. Multi-Homing
8. マルチホーミング
If there are multiple paths between Alice and Bob (as illustrated in the diagram with SG-D), then additional DNS records are required to establish authorization.
アリスとボブの間には、複数の経路があれば(SG-Dと共にダイヤグラムで例証されるように)、追加DNS記録が、承認を確立するのに必要です。
In Figure 1, Alice has two ways to exit her network: SG-A and SG-D. Previously, SG-D has been ignored. Postulate that there are routers between Alice and her set of security gateways (denoted by the + signs and the marking of an autonomous system number for Alice's network). Datagrams may, therefore, travel to either SG-A or SG-D en route to Bob.
図1では、アリスは彼女のネットワークを出る2つの方法を持っています: SG-AとSG-D。 以前、SG-Dは無視されました。 アリスと彼女のセキュリティゲートウェイ(アリスのネットワークの自律システム番号の+サインとマークで、指示される)のセットの間には、ルータがあるのを仮定してください。 したがって、データグラムはボブへの途中で、SG-AかSG-Dのどちらかに移動するかもしれません。
As long as all network connections are in good order, it does not matter how datagrams exit Alice's network. When they reach either security gateway, the security gateway will find the TXT delegation record in Bob's reverse-map, and establish an SA with SG-B.
すべてのネットワーク接続が整然としている限り、データグラムがどのようにアリスのネットワークを出るかは重要ではありません。 どちらのセキュリティゲートウェイにも達すると、セキュリティゲートウェイは、ボブの逆地図でTXT委譲記録に当たって、SG-Bと共にSAを設立するでしょう。
SG-B has no problem establishing that either of SG-A or SG-D may speak for Alice, because Alice has published two equally weighted TXT delegation records:
SG-Bには、SG-AかSG-Dのどちらかがアリスを代弁するかもしれないのを確証することにおける問題が全くありません、アリスが2つの等しく荷重しているTXT委譲記録を発表したので:
Richardson & Redelmeier Informational [Page 31] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[31ページ]のRFC4322の便宜主義的な暗号化
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
X-IPsecサーバ(10)=192.1.1.5AQMM…3s1Q=X-IPsecサーバ(10)=192.1.1.6AAJN…j8r9=
Figure 4: Multiple gateway delegation example for Alice
図4: アリスにとって複数のゲートウェイ委譲の例
Alice's routers can now do any kind of load sharing needed. Both SG-A and SG-D send datagrams addressed to Bob through their tunnel to SG-B.
アリスのルータは現在、必要である負荷分割法のどんな種類もできます。 SG-AとSG-Dの両方がそれらのトンネルを通ってボブに扱われたデータグラムをSG-Bに送ります。
Alice's use of non-equal weight delegation records to show preference of one gateway over another, has relevance only when SG-B is initiating to Alice.
アリスの非同量委譲の使用は、別のものの上に1門の好みを示しているために記録して、SG-Bがアリスに開始しているときだけ、関連性を持っています。
If the precedences are the same, then SG-B has a more difficult time. It must decide which of the two tunnels to use. SG-B has no information about which link is less loaded, nor which security gateway has more cryptographic resources available. SG-B, in fact, has no knowledge of whether both gateways are even reachable.
先行が同じであるなら、SG-Bは、より難しい時間を過します。 それは、2つのトンネルのどれを使用したらよいかを決めなければなりません。 SG-Bには、どのリンクがそれほど積み込まれないか、そして、どのセキュリティゲートウェイに利用可能なより暗号のリソースがあるかの情報が全くありません。 SG-Bには、事実上、両方のゲートウェイが届きさえするかどうかに関する知識が全くありません。
The Public Internet's default-free zone may well know a good route to Alice, but the datagrams that SG-B creates must be addressed to either SG-A or SG-D; they can not be addressed to Alice directly.
Publicインターネットの無デフォルトのゾーンはたぶんアリスにとって良いルートを知っているでしょうが、SG-AかSG-DのどちらかにSG-Bが作成するデータグラムを扱わなければなりません。 直接アリスにそれらを扱うことができません。
SG-B may make a number of choices:
SG-Bは多くの選択をするかもしれません:
1. It can ignore the problem and round robin among the tunnels.
This causes losses during times when one or the other security
gateway is unreachable. If this worries Alice, she can change
the weights in her TXT delegation records.
2. It can send to the gateway from which it most recently received
datagrams. This assumes that routing and reachability are
symmetrical.
3. It can listen to BGP information from the Internet to decide
which system is currently up. This is clearly much more
complicated, but if SG-B is already participating in the BGP
peering system to announce Bob, the results data may already be
available to it.
4. It can refuse to negotiate the second tunnel. (It is unclear
whether or not this is even an option.)
5. It can silently replace the outgoing portion of the first tunnel
with the second one while still retaining the incoming portions
of both. Thus, SG-B can accept datagrams from either SG-A or
SG-D, but send only to the gateway that most recently re-keyed
with it.
1. それはトンネルの中で問題と連続を無視できます。 これは1かもう片方のセキュリティゲートウェイが手が届かない回の間、損害を与えます。 これがアリスを心配させるなら、彼女は彼女のTXT委譲記録の重りを変えることができます。 2. それはごく最近データグラムを受けたゲートウェイに発信できます。これは、ルーティングと可到達性が対称であると仮定します。 3. それは、どのシステムが現在上がっているかを決めるためにインターネットからBGP情報を聞くことができます。 これは明確にはるかに複雑ですが、SG-Bが既にBGPじっと見るシステムに参加しているなら、ボブ、結果を発表するために、データは既にそれに利用可能であるかもしれません。 4. それは、2番目のトンネルを交渉するのを拒否できます。 (これがオプションでさえあるかどうか不明瞭です。) 5. それはまだ両方の入って来る部分を保有している間、静かに2番目のものがある最初のトンネルの外向的な部分を取り替えることができます。 したがって、SG-BはSG-AかSG-Dのどちらかからデータグラムを受け入れることができますが、ごく最近がそれで再合わせたゲートウェイだけに発信してください。
Richardson & Redelmeier Informational [Page 32] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[32ページ]のRFC4322の便宜主義的な暗号化
Local policy determines which choice SG-B makes. Note that even if SG-B has perfect knowledge about the reachability of SG-A and SG-D, Alice may not be reachable from either of these security gateways because of internal reachability issues.
ローカルの方針は、SG-Bがどの選択をするかを決定します。 SG-BにSG-AとSG-Dの可到達性に関する完全な知識があっても、アリスが内部の可到達性問題のためにこれらのセキュリティゲートウェイのどちらかから届かないかもしれないことに注意してください。
FreeS/WAN implements option 5. Implementing a different option is being considered. The multi-homing aspects of OE are not well developed and may be the subject of a future document.
FreeS/WANは、オプションが5であると実装します。 異なったオプションを実装するのは考えられています。 OEのマルチホーミング局面は、よく開発されないで、将来のドキュメントの対象であるかもしれません。
9. Failure Modes
9. 故障モード
9.1. DNS Failures
9.1. DNSの故障
If a DNS server fails to respond, local policy decides whether or not to permit communication in the clear as embodied in the connection classes in Section 3.2. It is easy to mount a denial of service attack on the DNS server responsible for a particular network's reverse-map. Such an attack may cause all communication with that network to go in the clear if the policy is permissive, or fail completely if the policy is paranoid. Please note that this is an active attack.
DNSサーバが応じないなら、ローカルの方針は、セクション3.2で接続のクラスに表現されるように明確でコミュニケーションを可能にするかどうか決めます。 特定のネットワークの逆地図に原因となるDNSサーバにサービス不能攻撃を仕掛けるのは簡単です。 完全に方針がパラノイアであるなら、そのような攻撃は、方針が寛大であるならそのネットワークとのすべてのコミュニケーションが明確に入ることを引き起こすか、または失敗するかもしれません。 これは攻撃します活発な。
There are still many networks that do not have properly configured reverse-maps. Further, if the policy is not to communicate, the above denial of service attack isolates the target network. Therefore, the decision of whether or not to permit communication in the clear MUST be a matter of local policy.
まだ、適切に構成された逆地図を持っていない多くのネットワークがあります。 さらに、方針が交信しないことであるなら、サービス攻撃の上の否定は目標ネットワークを隔離します。 したがって、明確でコミュニケーションを可能にするかどうかに関する決定はローカルの方針の問題であるに違いありません。
9.2. DNS Configured, IKE Failures
9.2. 構成されたDNS IKEの故障
DNS records claim that opportunistic encryption should occur, but the target gateway either does not respond on port 500, or refuses the proposal. This may be because of a crash or reboot, a faulty configuration, or a firewall filtering port 500.
DNS記録が、便宜主義的な暗号化が起こるべきであると主張しますが、目標ゲートウェイは、ポート500の上で応じないか、または提案を拒否します。 クラッシュ、リブート、不完全な構成、またはポート500をフィルターにかけるファイアウォールのためにこれはそうです。
The receipt of ICMP port, host or network unreachable messages indicates a potential problem, but MUST NOT cause communication to fail immediately. ICMP messages are easily forged by attackers. If such a forgery caused immediate failure, then an active attacker could easily prevent any encryption from ever occurring, possibly preventing all communication.
ICMPポート、ホストまたはネットワークの手の届かないメッセージの領収書は、潜在的な問題を示しますが、すぐに、コミュニケーションに失敗してはいけません。 ICMPメッセージは攻撃者によって容易に作り出されます。 そのような偽造が即座の失敗を引き起こすなら、活発な攻撃者は、どんな暗号化も起こるのを容易に防ぐことができるでしょうに、ことによるとすべてのコミュニケーションを防いで。
In these situations a log should be produced and local policy should dictate if communication is then permitted in the clear.
これらの状況で、ログは作り出されるべきです、そして、ローカルの方針は次に、コミュニケーションが明確で受入れられるかどうかと決めるべきです。
Richardson & Redelmeier Informational [Page 33] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[33ページ]のRFC4322の便宜主義的な暗号化
9.3. System Reboots
9.3. システムリブート
Tunnels sometimes go down because the remote end crashes, disconnects, or has a network link break. In general there is no notification of this. Even in the event of a crash and successful reboot, other SGs don't hear about it unless the rebooted SG has specific reason to talk to them immediately. Over-quick response to temporary network outages is undesirable. Note that a tunnel can be torn down and then re-established without any effect visible to the user except a pause in traffic. On the other hand, if one end reboots, the other end can't get datagrams to it at all (except via IKE) until the situation is noticed. So a bias toward quick response is appropriate, even at the cost of occasional false alarms.
リモートエンドが墜落するか、切断するか、またはネットワークリンクが壊れるので、トンネルは時々落ちます。 一般に、これの通知が全くありません。 速成の、そして、うまくいっているリブートの場合さえ、リブートされたSGにすぐに彼らと話す特定の理由がない場合、他のSGsはそれについて聞きません。 一時的なネットワーク供給停止への過剰素早い反応は望ましくありません。 トラフィックにおけるくぎりを除いて、少しも目に見える効果なしでトンネルをユーザに取りこわして、次に、復職させることができることに注意してください。 他方では、片端がリブートされるなら、状況が気付かれるまで、もう一方の端はデータグラムをそれに全く(IKEを除いて)手に入れることができません。 それで、素早い反応に向かった偏見は時々の間違い警報の費用でさえ適切です。
A mechanism for recovery after reboot is a topic of current research and is not specified in this document.
リブートの後の回復のためのメカニズムは、現在の研究の話題であり、本書では指定されません。
A deliberate shutdown should include an attempt, using delete messages, to notify all other SGs currently connected by phase 1 SAs that communication is about to fail. Again, a remote SG will assume this is a teardown. Attempts by the remote SGs to negotiate new tunnels as replacements should be ignored. When possible, SGs should attempt to preserve information about currently-connected SGs in non-volatile storage, so that after a crash, an Initial-Contact can be sent to previous partners to indicate loss of all previously established connections.
慎重な閉鎖は試みを含むべきであり、使用は、コミュニケーションが失敗しようとしているように現在フェーズ1SAsによって接続される他のすべてのSGsに通知するためにメッセージを削除します。 一方、リモートSGは、これが分解であると仮定するでしょう。 交換として新しいトンネルを交渉するリモートSGsによる試みは無視されるべきです。 可能であるときに、SGsは、非揮発性記憶装置で現在接続されたSGsの情報を保存するのを試みるはずです、クラッシュの後にすべての損失が以前に関係を樹立したのを示すためにInitial-接触を前のパートナーに送ることができるように。
10. Unresolved Issues
10. 未解決問題
10.1. Control of Reverse DNS
10.1. 逆のDNSのコントロール
The method of obtaining information by reverse DNS lookup causes problems for people who cannot control their reverse DNS bindings. This is an unresolved problem in this version, and is out of scope.
逆のDNSルックアップによる獲得情報のメソッドは彼らの逆のDNS結合を制御できない人々のために問題を起こします。 これは、このバージョンの未解決の問題であり、範囲の外にあります。
11. Examples
11. 例
11.1. Clear-Text Usage (Permit Policy)
11.1. クリアテキスト用法(許可証方針)
Two example scenarios follow. In the first example, GW-A (Gateway A) and GW-B (Gateway B) have always-clear-text policies, and in the second example they have an OE policy. The clear-text policy serves as a reference for what occurs in TCP/IP in the absence of Opportunistic Encryption.
2つの例のシナリオが従います。 最初の例では、GW-A(ゲートウェイA)とGW-B(ゲートウェイB)はいつもクリアテキスト方針を持っています、そして、2番目の例では、それらはOE方針を持っています。 クリアテキスト方針はOpportunistic Encryptionが不在のときTCP/IPで起こることのために参考になります。
Alice wants to communicate with Bob. Perhaps she wants to retrieve a web page from Bob's web server. In the absence of opportunistic encryptors, the following events occur:
アリスはボブとコミュニケートしたがっています。 恐らく、彼女はボブのウェブサーバーからウェブページを検索したがっています。便宜主義的な暗号化する人がないとき、以下のイベントは起こります:
Richardson & Redelmeier Informational [Page 34] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[34ページ]のRFC4322の便宜主義的な暗号化
Alice SG-A DNS SG-B Bob
Human or application
'clicks' with a name.
(1)
アリスSG-A DNS SG-BボブHumanかアプリケーションが名前で'クリックされます'。 (1)
------(2)-------------->
Application looks up
name in DNS to get
IP address.
------(2)-------------->アプリケーションは、IPアドレスを得るためにDNSの名前を調べます。
<-----(3)---------------
Resolver returns "A" RR
to application with IP
address.
<。-----(3)--------------- レゾルバはIPアドレスによるアプリケーションにRRを返します。
(4)
Application starts a TCP session
or UDP session and OS sends
first datagram
(4) アプリケーションはTCPセッションかUDPセッションを始めます、そして、OSは最初のデータグラムを送ります。
Alice SG-A DNS SG-B Bob
----(5)----->
Datagram is seen at first gateway
from Alice (SG-A).
アリス・SG-A DNS SG-Bボブ----(5)----->データグラムは最初のゲートウェイでアリスから見られます。(SG-a)。
----------(6)------>
Datagram traverses
network.
----------(6)------>データグラムはネットワークを横断します。
------(7)----->
Datagram arrives
at Bob, is provided
to TCP.
------(7)----->データグラムはボブに到着して、TCPに提供します。
<------(8)------
A reply is sent.
<。------(8)------ 回答を送ります。
<----------(9)------
Datagram traverses
network.
<----(10)-----
Alice receives
answer.
<。----------(9)------ データグラムはネットワークを横断します。 <、-、-、--(10)----- アリスは答えを受けます。
Alice SG-A DNS SG-B Bob
(11)----------->
A second exchange
occurs.
アリス・SG-A DNS SG-Bボブ(11)-----------2分の1が交換する>は現れます。
Richardson & Redelmeier Informational [Page 35] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[35ページ]のRFC4322の便宜主義的な暗号化
----------(12)----->
-------------->
<---------------
<-------------------
<-------------
----------(12)----->。--------------><。--------------- <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-、-、--
Figure 5: Timing of regular transaction
図5: 普通取引のタイミング
11.2. Opportunistic Encryption
11.2. 便宜主義的な暗号化
In the presence of properly configured opportunistic encryptors, the event list is extended. Only changes are annotated.
適切に構成された便宜主義的な暗号化する人があるとき、イベントリストは拡張されています。 変化だけが注釈されます。
The following symbols are used in the time-sequence diagram:
以下のシンボルは時間シーケンス線図で使用されます:
- A single dash represents clear-text datagrams. = An equals sign represents phase 2 (IPsec) cipher-text datagrams. ~ A single tilde represents clear-text phase 1 datagrams. # A hash sign represents phase 1 (IKE) cipher-text datagrams.
- ただ一つのダッシュはクリアテキストデータグラムを表します。= 等号はフェーズ2(IPsec)暗号文データグラムを表します。~Aただ一つのティルドはクリアテキストフェーズ1データグラムを表します。#Aハッシュサインはフェーズ1(IKE)暗号文データグラムを表します。
Richardson & Redelmeier Informational [Page 36] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[36ページ]のRFC4322の便宜主義的な暗号化
Alice SG-A DNS SG-B Bob
(1)
------(2)-------------->
<-----(3)---------------
(4)----(5)----->+
----(5B)->
<---(5C)--
~~~~~~~~~~~~~(5D)~~~>
<~~~~~~~~~~~~(5E)~~~~
~~~~~~~~~~~~~(5F)~~~>
<~~~~~~~~~~~~(5G)~~~~
#############(5H)###>
<----(5I)---
-----(5J)-->
<############(5K)####
#############(5L)###>
<----(5M)---
-----(5N)-->
<############(5O)####
#############(5P)###>
============(6)====>
------(7)----->
<------(8)------
<==========(9)======
<-----(10)----
(11)----------->
==========(12)=====>
-------------->
<---------------
<===================
<-------------
アリス・SG-A DNS SG-Bボブ(1)------(2)--------------><。-----(3)--------------- (4)----(5)----->+----(5B)-><。---(5C)-- ~~~~~~~~~~~~~(5D)~~~><。~~~~~~~~~~~~(5E)~~~~ ~~~~~~~~~~~~~(5F)~~~><。~~~~~~~~~~~~(5G)~~~~ #############(5H)###><。----(5I)--- -----(5J)--><############(5K)#### #############(5L)###><。----(5M)--- -----(5N)--><############(5O)#### #############(5P)###>======(6)====>。------(7)-----><。------(8)------ <=====(9)====== <、-、-、-、--(10)---- (11)----------->=====(12)=====>。--------------><。--------------- <========== <、-、-、-、-、-、-、-、-、-、-、-、--
Figure 6: Timing of opportunistic encryption transaction
図6: 便宜主義的な暗号化トランザクションのタイミング
Richardson & Redelmeier Informational [Page 37] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[37ページ]のRFC4322の便宜主義的な暗号化
For the purposes of this section, we will describe only the changes that occur between Figure 5 and Figure 6. This corresponds to time points 5, 6, 7, 9, and 10 on the list above.
このセクションの目的のために、私たちは図5と図6の間に起こる変化だけについて説明するつもりです。 これは上記のリストの時間ポイント5、6、7、9、および10に対応しています。
At point (5), SG-A intercepts the datagram because this source/destination pair lacks a policy (the nonexistent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon.
ポイント(5)では、このソース/目的地組が方針(実在しない政策ポジション)を欠いているので、SG-Aはデータグラムを妨害します。 SG-Aは保持方針を作成して、データグラムをバッファリングします。 SG-Aは合わせるデーモンからキーを要求します。
(5B) DNS query for TXT record.
(5C) DNS response for TXT record.
(5D) Initial IKE message to responder.
(5E) Message 2 of phase 1 exchange.
SG-B receives the message. A new connection instance is created
in the unauthenticated OE peer state.
(5F) Message 3 of phase 1 exchange.
SG-A sends a Diffie-Hellman exponent. This is an internal state
of the keying daemon.
(5G) Message 4 of phase 1 exchange.
SG-B responds with a Diffie-Hellman exponent. This is an
internal state of the keying protocol.
(5H) Message 5 of phase 1 exchange.
SG-A uses the phase 1 SA to send its identity under encryption.
The choice of identity is discussed in Section 4.6.1. This is
an internal state of the keying protocol.
(5I) Responder lookup of initiator key. SG-B asks DNS for the public
key of the initiator. DNS looks for a KEY record by IP address
in the reverse-map. That is, a KEY resource record is queried
for 4.1.1.192.in-addr.arpa (recall that SG-A's external address
is 192.1.1.4). SG-B uses the resulting public key to
authenticate the initiator. See Section 5.1 for further
details.
(5J) DNS replies with public key of initiator.
Upon successfully authenticating the peer, the connection
instance makes a transition to authenticated OE peer on SG-B.
The format of the TXT record returned is described in
Section 5.2.
Responder replies with ID and authentication.
SG-B sends its ID along with authentication material, completing
the phase 1 negotiation.
(5L) IKE phase 2 negotiation.
Having established mutually agreeable authentications (via KEY)
and authorizations (via TXT), SG-A proposes to create an IPsec
tunnel for datagrams transiting from Alice to Bob. This tunnel
is established only for the Alice/Bob combination, not for any
subnets that may be behind SG-A and SG-B.
TXT記録のための(5B)DNS質問。 (5C) TXT記録のためのDNS応答。 (5D) IKEメッセージに応答者に頭文字をつけてください。 (5E) フェーズ1交換に関するメッセージ2。 SG-Bはメッセージを受け取ります。 新しい接続インスタンスはunauthenticated OE同輩状態で作成されます。 (5F) フェーズ1交換に関するメッセージ3。 SG-Aはディフィー-ヘルマン解説者を送ります。 これは合わせるデーモンの内部の状態です。 (5G) フェーズ1交換に関するメッセージ4。 SG-Bはディフィー-ヘルマン解説者と共に応じます。 これは合わせるプロトコルの内部の事情です。 (5H) フェーズ1交換に関するメッセージ5。 SG-Aは、暗号化でアイデンティティを送るのにフェーズ1SAを使用します。 セクション4.6.1でアイデンティティの選択について議論します。 これは合わせるプロトコルの内部の事情です。 (5I) 創始者キーの応答者ルックアップ。 SG-Bは創始者の公開鍵をDNSに求めます。 DNSは逆地図のIPアドレスでKEY記録を探します。 すなわち、KEYリソース記録は(というSG-Aのそのものを思い出してください4.1.1.192.in-addr.arpa外部アドレスのために質問されているのが、192.1であるということです。.1 .4)。 SG-Bは、創始者を認証するのに結果として起こる公開鍵を使用します。 さらに詳しい明細についてはセクション5.1を見てください。 (5J) DNSは創始者の公開鍵で返答します。 首尾よく同輩を認証すると、接続インスタンスで、認証されたOEへの変遷はSG-Bをじっと見ます。 返されたTXT記録の形式はセクション5.2で説明されます。 応答者はIDと認証で返答します。 フェーズ1交渉を終了して、SG-Bは認証の材料に伴うIDを送ります。 (5L) IKEは2交渉の位相を合わせます。 互いに快い認証(KEYを通した)と承認(TXTを通した)を確立したので、SG-Aは、アリスからボブまで通過するデータグラムのためのIPsecトンネルを作成するよう提案します。 このトンネルはSG-AとSG-Bの後ろにあるどんなサブネットのためにも確立されるのではなく、アリス/ボブの組み合わせのためだけに確立されます。
Richardson & Redelmeier Informational [Page 38] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[38ページ]のRFC4322の便宜主義的な暗号化
(5M) Authorization for SG-A to speak for Alice.
While the identity of SG-A has been established, its authority
to speak for Alice has not yet been confirmed. SG-B does a
reverse lookup on Alice's address for a TXT record.
(5N) Responder determines initiator's authority.
A TXT record is returned. It confirms that SG-A is authorized
to speak for Alice.
Upon receiving this specific proposal, SG-B's connection
instance makes a transition into the potential OE connection
state. SG-B may already have an instance, and the check is made
as described above.
(5O) Responder agrees to proposal.
SG-B, satisfied that SG-A is authorized, proceeds with the
phase 2 exchange.
The responder MUST setup the inbound IPsec SAs before sending
its reply.
(5P) Final acknowledgement from initiator.
The initiator agrees with the responder's choice of proposal and
sets up the tunnel. The initiator sets up the inbound and
outbound IPsec SAs.
Upon receipt of this message, the responder may now setup the
outbound IPsec SAs.
(6) IPsec succeeds and sets up a tunnel for communication between
Alice and Bob.
SG-Aがアリスのために話す(5M)の承認。 SG-Aのアイデンティティは確立されましたが、アリスを代弁する権威はまだ確認されていません。 SG-BはTXT記録のためのアリスのアドレスで逆のルックアップをします。 (5N) 応答者は創始者の権威を決定します。 TXT記録を返します。 それは、SG-Aがアリスを代弁するのが認可されると確認します。 この明確な提案を受けると、SG-ビーズ接続インスタンスは潜在的OE接続状態に変遷を作りかえます。 SG-Bには、インスタンスが既にあるかもしれません、そして、上で説明されるようにチェックをします。 (5O) 応答者は提案に同意します。 SG-Aが認可されているのに満足するSG-Bはフェーズ2交換を続けます。 回答を送る前に、応答者は本国行きのIPsec SAsをセットアップしなければなりません。 (5P) 創始者からの最終的な承認。 創始者は、応答者の提案の選択に同意して、トンネルを設立します。 創始者は本国行きの、そして、外国行きのIPsec SAsをセットアップします。 このメッセージを受け取り次第、応答者は現在、外国行きのIPsec SAsをセットアップするかもしれません。 (6) IPsecはアリスとボブとのコミュニケーションのためにトンネルを引き継いで、設立します。
SG-A sends the datagram saved at step (5) through the newly
created tunnel to SG-B, where it gets decrypted and forwarded.
Bob receives it at (7) and replies at (8). SG-B already has a
tunnel up with G1 and uses it. At (9), SG-B has already
established an SPD entry mapping Bob->Alice via a tunnel, so this
tunnel is simply applied. The datagram is encrypted to SG-A,
decrypted by SG-A, and passed to Alice at (10).
SG-Aは新たに作成されたトンネルを通してステップ(5)に取っておかれたデータグラムをSG-Bに送ります。そこでは、解読されて、それは進められます。 ボブは(7)と回答のときに(8)でそれを受けます。 SG-Bは既にトンネルをG1に上がるようにして、それを使用します。 SG-Bが(9)で既にSPDエントリーマッピングを確立した、ボブ->、アリス、したがって、トンネルを通って、このトンネルは単に適用されます。 データグラムは、SG-Aに暗号化されて、SG-Aによって解読されて、(10)のアリスに渡されます。
12. Security Considerations
12. セキュリティ問題
12.1. Configured versus Opportunistic Tunnels
12.1. 便宜主義的なTunnelsに対して構成されます。
Configured tunnels are setup using bilateral mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that are in known places (distinguished name from LDAP, DNS). These keys are then used to configure a specific tunnel.
構成されたトンネルはバイラテラル機構を使用するセットアップです: 公開鍵(生のRSA、DSA、PKIX)、プレ共有秘密キーを交換するか、または知られている場所(LDAP、DNSからの分類名)にあるキーに参照をつけることによって。 そして、これらのキーは、特定のトンネルを構成するのに使用されます。
A pre-configured tunnel may be on all the time, or may be keyed only when needed. The endpoints of the tunnel are not necessarily static; many mobile applications (road warrior) are considered to be configured tunnels.
あらかじめ設定されたトンネルは、絶えずあるか、または必要である場合にだけ、合わせられるかもしれません。 トンネルの終点は必ず静的であるというわけではありません。 多くのモバイルアプリケーション(道行く戦士)が構成されたトンネルであると考えられます。
Richardson & Redelmeier Informational [Page 39] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[39ページ]のRFC4322の便宜主義的な暗号化
The primary characteristic is that configured tunnels are assigned specific security properties. They may be trusted in different ways relating to exceptions to firewall rules, exceptions to NAT processing, and to bandwidth or other quality of service restrictions.
プライマリ特性は特定のセキュリティ性質が構成されたトンネルに割り当てられるということです。 それらはファイアウォール規則への例外、NAT処理への例外と、そして、帯域幅か他のサービスの質制限に関係する異なった方法で信じられるかもしれません。
Opportunistic tunnels are not inherently trusted in any strong way. They are created without prior arrangement. As the two parties are strangers, there MUST be no confusion of datagrams that arrive from opportunistic peers and those that arrive from configured tunnels. A security gateway MUST take care that an opportunistic peer cannot impersonate a configured peer.
便宜主義的なトンネルは本来どんな強い方法でも信じられません。 それらは先のアレンジメントなしで作成されます。 2回のパーティーが見知らぬ人であるので、便宜主義的な同輩と構成されたトンネルから到着するものから届くデータグラムの混乱が全くあるはずがありません。 セキュリティゲートウェイは、便宜主義的な同輩が構成された同輩をまねることができないことに注意しなければなりません。
Ingress filtering MUST be used to make sure that only datagrams authorized by negotiation (and the concomitant authentication and authorization) are accepted from a tunnel. This is to prevent one peer from impersonating another.
交渉(そして、並立している認証と承認)で認可されたデータグラムだけがトンネルから受け入れられるのを確実にするのにイングレスフィルタリングを使用しなければなりません。 これは、1人の同輩が別のものをまねるのを防ぐためのものです。
An implementation suggestion is to treat opportunistic tunnel datagrams as if they arrive on a logical interface distinct from other configured tunnels. As the number of opportunistic tunnels that may be created automatically on a system is potentially very high, careful attention to scaling should be taken into account.
実装提案はまるで他の構成されたトンネルと異なった論理的なインタフェースで到着するかのように便宜主義的なトンネルデータグラムを扱うことです。 自動的にシステムに作成されるかもしれない便宜主義的なトンネルの数が潜在的に非常に大きいので、スケーリングに関する慎重な注意は考慮に入れられるべきです。
As with any IKE negotiation, opportunistic encryption cannot be secure without authentication. Opportunistic encryption relies on DNS for its authentication information and, therefore, cannot be fully secure without a secure DNS. Without secure DNS, opportunistic encryption can protect against passive eavesdropping but not against active man-in-the-middle attacks.
どんなIKE交渉ならも、便宜主義的な暗号化は認証なしで安全であるはずがありません。 便宜主義的な暗号化は、認証情報のためにDNSを当てにして、したがって、安全なDNSなしで完全に安全であるというわけではない場合があります。 安全なDNSがなければ、便宜主義的な暗号化は受け身の盗聴から守ることができますが、中央の活発な男性は攻撃します。
12.2. Firewalls versus Opportunistic Tunnels
12.2. ファイアウォール対便宜主義的なTunnels
Typical usage of per datagram access control lists is to implement various kinds of security gateways. These are typically called "firewalls".
典型的な用法、データグラムアクセスコントロールリスト単位で様々な種類のセキュリティゲートウェイを実装することになっています。 これらは通常「ファイアウォール」と呼ばれます。
Typical usage of a virtual private network (VPN) within a firewall is to bypass all or part of the access controls between two networks. Additional trust (as outlined in the previous section) is given to datagrams that arrive in the VPN.
ファイアウォールの中の仮想私設網(VPN)の典型的な用法は2つのネットワークの間のアクセス制御のすべてか一部を迂回させることです。 追加信頼(前項で概説されているように)をVPNに届くデータグラムに与えます。
Datagrams that arrive via opportunistically configured tunnels MUST not be trusted. Any security policy that would apply to a datagram arriving in the clear SHOULD also be applied to datagrams arriving opportunistically.
便宜主義的に構成されたトンネルを通って到着するデータグラムを信じてはいけません。 どんな安全保障政策、もそれは明確なSHOULDに届くデータグラムに適用されて、また、便宜主義的に届くデータグラムに適用されてください。
Richardson & Redelmeier Informational [Page 40] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[40ページ]のRFC4322の便宜主義的な暗号化
12.3. Denial of Service
12.3. サービス妨害
There are several different forms of denial of service that an implementor should be concerned with. Most of these problems are shared with security gateways that have large numbers of mobile peers (road warriors).
作成者が関するべきであるサービスの否定のいくつかの異なったフォームがあります。 これらの問題の大部分は多くのモバイル同輩(道行く戦士)がいるセキュリティゲートウェイと共有されます。
The design of ISAKMP/IKE, and its use of cookies, defend against many kinds of denial of service. Opportunism changes the assumption that if the phase 1 (ISAKMP) SA is authenticated, that it was worthwhile creating. Because the gateway will communicate with any machine, it is possible to form phase 1 SAs with any machine on the Internet.
ISAKMP/IKEのデザイン、およびクッキーのその使用は多くの種類のサービスの否定に対して防御されます。 日和見主義はそれが価値がある作成であったというフェーズ1(ISAKMP)SAであるなら認証される仮定を変えます。 ゲートウェイがどんなマシンでも交信するので、いくつかのマシンがインターネットにある状態でフェーズ1SAsを形成するのは可能です。
13. Acknowledgements
13. 承認
Substantive portions of this document are based upon previous work by Henry Spencer. [OEspec]
このドキュメントの実質的な部分はヘンリー・スペンサーによる前の仕事に基づいています。 [OEspec]
Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz, Jakob Schlyter, Bill Sommerfeld, John Gilmore, and John Denker for their comments and constructive criticism.
彼らのコメントと建設的批判をTero Kivinen、サンディー・ハリス、ウェスHardarker、ロバート・マスコウィッツ、ジェイコブSchlyter、ビル・ゾンマーフェルト、ジョン・ギルモア、およびジョン・デンカーをありがとうございます。
Sandra Hoffman and Bill Dickie did the detailed proof reading and editing.
詳細なプルーフ・リーディングとサンドラ・ホフマンとビル・ディッキーは編集しました。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2408] Maughan、D.、シュナイダー、M.、M.Schertler、および「インターネットSecurity Associationと主要なManagementプロトコル(ISAKMP)」、RFC2408、11月1998日
[RFC2409] Harkins, D. and D. Carrel, "The Internet key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.Carrel、「インターネットの主要なExchange(IKE)」、RFC2409 1998年11月。
Richardson & Redelmeier Informational [Page 41] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[41ページ]のRFC4322の便宜主義的な暗号化
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[RFC3110] イーストレークと、D.と、「ドメインネームシステム(DNS)におけるRSA/SHA-1SIGとRSAキー」(RFC3110)は2001がそうするかもしれません。
14.2. Informative References
14.2. 有益な参照
[IPSECKEY] Richardson, M., "A Method for Storing IPsec keying
Material in DNS", RFC 4025, March 2005.
[IPSECKEY] 2005年3月のリチャードソン、M.、「DNSでMaterialを合わせるStoring IPsecのためのMethod」RFC4025。
[OEspec] H. Spencer and Redelmeier, D., "Opportunistic Encryption",
paper, http://www.freeswan.org/
oeid/opportunism-spec.txt, May 2001.
[OEspec] H.スペンサーとRedelmeier、D.、「便宜主義的な暗号化」、紙、 http://www.freeswan.org/ 日和見主義oeid/spec.txt、2001年5月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1464]ローゼンボムR. (「任意のストリング属性を保存するのにドメインネームシステムを使用すること」でのRFC1464)は1993がそうするかもしれません。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG
Statement on Cryptographic Technology and the Internet",
RFC 1984, August 1996.
[RFC1984]IAB(IESG)は大工仕事をします、B.、F.はベイカーと、「暗号の技術に関するIABとIESG声明とインターネット」をB.です、RFC1984、1996年8月。
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management
API, Version 2", RFC 2367, July 1998.
[RFC2367] マクドナルドとD.とメスとC.とB.Phan、「pfの_の主要なKey Management API、バージョン2インチ、RFC2367、1998年7月。」
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2538] イーストレークとD.とO.グドムンソン、「ドメインネームシステム(DNS)で証明書を保存します」、RFC2538、1999年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2663] SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、1999年8月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.
[RFC3330]IANA、「特別な使用IPv4アドレス」、RFC3330、2002年9月。
Richardson & Redelmeier Informational [Page 42] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[42ページ]のRFC4322の便宜主義的な暗号化
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3445] RFC3445、「主要なリソース記録(RR)の範囲を制限し」て、マッシー、D.、およびS.は上昇して、12月は2002です。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3526] Kivinen、T.、およびM.Kojo、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、2003年5月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
Authors' Addresses
作者のアドレス
Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA
K1Z 5V7カリフォルニアのマイケルC.リチャードソンSandelmanソフトウェア作品470ドーソン・Avenueオタワ
EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/
メール: mcr@sandelman.ottawa.on.ca ユリ: http://www.sandelman.ottawa.on.ca/
D. Hugh Redelmeier Mimosa Systems Inc. 29 Donino Avenue Toronto, ON M4N 2W6 CA
M4N 2W6カリフォルニアのD.ヒューRedelmeierミモザシステム株式会社29Donino Avenueトロント
EMail: hugh@mimosa.com
メール: hugh@mimosa.com
Richardson & Redelmeier Informational [Page 43] RFC 4322 Opportunistic Encryption using IKE December 2005
2005年12月にIKEを使用するリチャードソンとRedelmeierの情報[43ページ]のRFC4322の便宜主義的な暗号化
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Richardson & Redelmeier Informational [Page 44]
リチャードソンとRedelmeier情報です。[44ページ]
一覧
スポンサーリンク
