Network Working Group M. Blaze
Request for Comments: 3586 AT&T Labs - Research
Category: Standards Track A. Keromytis
Columbia University
M. Richardson
Sandelman Software Works
L. Sanchez
Xapiens Corporation
August 2003
IP Security Policy (IPSP) Requirements
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements.
この文書では、IPセキュリティポリシー（IPSP）の構成と管理のフレームワークを開発するための問題空間とソリューションの要件について説明します。 IPSPアーキテクチャは、アクセス、承認、認証、機密性、データの整合性、および他のIPセキュリティの性質を支配するホストおよびネットワークのセキュリティポリシーを、管理発見し、交渉のためのスケーラブルな、分散型のフレームワークを提供します。この文書では、このようなアーキテクチャコンポーネントを強調し、その機能要件を提示します。
Table of Contents
目次
1. Introduction.................................................. 2
1.1. Terminology............................................. 2
1.2. Security Policy and IPsec............................... 2
2. The IP Security Policy Problem Space.......................... 3
3. Requirements for an IP Security Policy Configuration and
Management Framework.......................................... 5
3.1. General Requirements.................................... 5
3.2. Description and Justification........................... 5
3.2.1. Policy Model.................................... 5
3.2.2. Security Gateway Discovery...................... 6
3.2.3. Policy Specification Language................... 6
3.2.4. Distributed policy.............................. 6
3.2.5. Policy Discovery................................ 6
3.2.6. Security Association Resolution................. 6
3.2.7. Compliance Checking............................. 7
4. Security Considerations....................................... 7
5. IANA Considerations........................................... 7
6. Intellectual Property Statement............................... 7
7. References.................................................... 8
7.1. Normative References.................................... 8
7.2. Informative References.................................. 8
8. Disclaimer.................................................... 8
9. Acknowledgements.............................................. 8
10. Authors' Addresses............................................ 9
11. Full Copyright Statement...................................... 10
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにあります[RFC 2119]で説明されるように解釈されます。
Network-layer security now enjoys broad popularity as a tool for protecting Internet traffic and resources. Security at the network layer can be used as a tool for at least two kinds of security architecture:
ネットワーク層のセキュリティは現在、インターネットのトラフィックやリソースを保護するためのツールとして幅広い人気を楽しんでいます。ネットワーク層でのセキュリティは、セキュリティアーキテクチャの少なくとも2種類のツールとして使用することができます。
a) Security gateways. Security gateways (including "firewalls") at the edges of networks use IPsec [RFC-2401] to enforce access control, protect the confidentiality and authenticity of network traffic entering and leaving a network, and to provide gateway services for virtual private networks (VPNs).
a）のセキュリティ・ゲートウェイ。セキュリティネットワークの縁で（「ファイアウォール」を含む）のゲートウェイ、ネットワークトラフィック入りの機密性と信頼性を保護し、アクセス制御を強制するのIPsec [RFC-2401]を使用してネットワークを残して、仮想プライベートネットワーク用ゲートウェイサービスを提供するために、（VPNの）。
b) Secure end-to-end communication. Hosts use IPsec to implement host-level access control, to protect the confidentiality and authenticity of network traffic exchanged with the peer hosts with which they communicate, and to join virtual private networks.
b）は、セキュアなエンド・ツー・エンドの通信。ホストは、彼らが通信する相手のホストとの間で交換するネットワークトラフィックの機密性と信頼性を保護するために、ホスト・レベルのアクセス制御を実装するために、仮想プライベートネットワークに参加するためにIPsecを使用しています。
On one hand, IPsec provides an excellent basis for a very wide range of protection schemes; on the other hand, this wide range of applications for IPsec creates complex management tasks that become especially difficult as networks scale up and require different security policies, and are controlled by different entities, for different kinds of traffic in different parts of the network.
一方、IPsecは、保護スキームの非常に広い範囲のための優れた基礎を提供します。一方、IPsecのためのアプリケーションのこの広い範囲は、ネットワークがスケールアップし、異なるセキュリティポリシーを必要とし、ネットワークのさまざまな部分でのトラフィックの種類のために、異なるエンティティによって制御されているとして、特に困難になって、複雑な管理タスクを作成します。
As organizations deploy security gateways, the Internet divides into heterogeneous regions that enforce different access and security policies. Yet it is often still necessary for hosts to communicate across the network boundaries controlled by several different policies. The wide range of choices of cryptographic parameters (at multiple protocol layers) complicates matters and introduces the need for hosts and security gateways to identify and negotiate a set of security parameters that meets each party's requirements. Even more complexity arises as IPsec becomes the means through which firewalls enforce access control and VPN membership; two IPsec endpoints that want to establish a security association must identify, not only the mutually acceptable cryptographic parameters, but also exactly what kind of access the combined security policy provides.
組織がセキュリティゲートウェイを導入する際に、インターネットは異なったアクセスとセキュリティポリシーを実施異質の領域に分割します。ホストは、いくつかの異なるポリシーで制御ネットワークの境界を越えて通信するために、まだそれはまだしばしば必要です。 （複数のプロトコル層で）暗号化パラメータの選択肢の広い範囲が問題を複雑にして特定し、各当事者の要件を満たしているセキュリティパラメータのセットを交渉するホストとセキュリティゲートウェイの必要性を紹介します。 IPsecは、アクセス制御とVPNメンバーシップを強制ファイアウォールそれを通して手段となるように一層複雑さが生じます。 2つのIPSecだけではなく、相互に受け入れ可能な暗号パラメータを特定しなければならないセキュリティアソシエーションを確立したいエンドポイントが、また、組み合わせたセキュリティポリシーが提供するアクセスのまさに一種。
While the negotiation of cryptographic and other security parameters for IPsec security associations (SAs) is supported by key management protocols (e.g., ISAKMP [RFC-2408]), the IPsec key management layer does not provide a scheme for managing, negotiating, or enforcing the security policies under which SAs operate.
IPsecセキュリティアソシエーションの暗号化およびその他のセキュリティパラメータ（SAS）のネゴシエーションが鍵管理プロトコル（例えば、ISAKMP [RFC-2408]）によってサポートされていますが、IPsecの鍵管理層は、管理交渉、または実施するためのスキームを提供していません。 SAが動作するセキュリティポリシー。
IPSP provides the framework for managing IPsec security policy, negotiating security association (SA) parameters between IPsec endpoints, and distributing authorization and policy information among hosts that require the ability to communicate via IPsec.
IPSPは、IPsecセキュリティポリシーを管理するのIPsecエンドポイント間でセキュリティアソシエーション（SA）パラメータのネゴシエーション、およびIPSecを介して通信する能力を必要とするホスト間認可やポリシー情報を配信するためのフレームワークを提供します。
IPSP aims to provide a scalable, decentralized framework for managing, discovering and negotiating the host and network IPsec policies that govern access, authorization, cryptographic mechanisms, confidentiality, data integrity, and other IPsec properties.
IPSPは、アクセス、認証、暗号化メカニズム、機密性、データの整合性、およびその他のIPsecの特性を支配するホストおよびネットワークのIPsecポリシーを管理発見し、交渉のためのスケーラブルな、分散型のフレームワークを提供することを目指しています。
The central problem solved by IPSP is that of controlling security policy in a manner that is useful for the wide range of IPsec applications and modes of operation. In particular:
IPSPによって解決中心的な問題は、IPsecアプリケーションと動作モードの広い範囲のために有用な方法でセキュリティポリシーを制御することです。特に：
- IPSP hosts may serve as IPsec endpoints, security gateways, network management hubs, or a combination of these functions. IPSP will manage end-users computers (which may be fixed workstations controlled by a single organization or mobile laptops that require remote access to a corporate VPN), firewalls (which provide different services and allow different levels of access to different classes of traffic and users), VPN routers (which support links to other VPNs that might be controlled by a different organization's network policy), web and other servers (which might provide different services depending on where a client request came from), and so on.
- IPSPホストは、IPsecエンドポイント、セキュリティゲートウェイ、ネットワーク管理ハブ、またはこれらの機能の組み合わせとして機能することができます。 IPSPは、トラフィックとユーザーの異なるクラスへのアクセスの異なるレベルをエンドユーザーに異なるサービスを提供（単一の組織や企業のVPNへのリモートアクセスを必要とするモバイルノートブックPCで制御ワークステーションを固定してもよい）、コンピュータ、ファイアウォールを（管理し、できるようになりますなど）、VPNの異なる組織のネットワークポリシーによって制御されるかもしれない他のVPNへのリンクをサポートするルータ（）、ウェブクライアントの要求がどこから来たのに応じて、さまざまなサービスを提供するかもしれない他のサーバ（）、および。
- IPSP administration will be inherently heterogeneous and decentralized. A basic feature of IPsec is that two hosts can establish a Security Association even though they might not share a common security policy, or, indeed, trust one another at all. This property of IPsec becomes even more pronounced at the higher level abstraction managed by IPSP.
- IPSPの管理は、本質的に異質と分散化されます。 IPsecの基本的な機能は、2つのホストが、彼らは共通のセキュリティポリシーを共有する、または、実際に、全くお互いを信頼していない場合でも、セキュリティアソシエーションを確立することができるということです。 IPsecのこのプロパティは、IPSPが管理し、より高いレベルの抽象化で、より顕著になります。
- The SA parameters acceptable to any pair of hosts (operating under different policies) will often not be specified in advance. IPSP will often have to negotiate and discover the mutually-acceptable SA parameters on-the-fly when two hosts attempt to create a new SA.
- ホスト（異なるポリシーの下で動作する）のいずれかの対に許容されるSAパラメータは、多くの場合、事前に指定されないであろう。 IPSPは、多くの場合、交渉し、2つのホストが新しいSAを作成しようとすると、オンザフライで相互に許容可能なSAパラメータを発見する必要があります。
- Some hosts will be governed by policies that are not directly specified in the IPSP language. For example, a host's IPsec policy might be derived from a more comprehensive higher-layer security policy managed by some other system. Similarly, some vendors might develop specialized (and proprietary) tools for managing policy in their products. In such cases, it is necessary to derive an IPSP policy specification for only those aspects of a host's policy that involve interoperability with other hosts running IPSP.
- いくつかのホストが直接IPSP言語で指定されていないポリシーによって管理されます。たとえば、ホストのIPsecポリシーは、他のシステムで管理されるより包括的な上位レイヤのセキュリティポリシーから導出される可能性があります。同様に、いくつかのベンダーは、自社製品でポリシーを管理するための専門的な（そして独自の）ツールを開発することがあります。このような場合には、IPSPを実行している他のホストとの相互運用性を必要とするホストのポリシーの態様のみのためのIPSPポリシーの仕様を導出する必要があります。
- IPSP must scale to support complex policy administration schemes. In even modest-size networks, one administrator must often control policy remotely, and must have the ability to change the policy on many different hosts at the same time. In larger networks (or those belonging to large organizations), a host's policy might be governed by several different authorities (e.g., several different departments might have the authority to add users to a firewall or open access to new services). Different parts of a policy might be "owned" by different entities in a complex hierarchy. IPSP must provide a mechanism for delegating specific kinds of authority to specific entities.
- IPSPは、複雑なポリシー管理スキームをサポートするように拡張しなければなりません。でも控えめなサイズのネットワークでは、1つの管理者は、多くの場合、リモートでポリシーを制御しなければならないと同時に、多くの異なるホスト上のポリシーを変更する能力を持っている必要があります。大規模なネットワーク（または大規模な組織に属するもの）では、ホストの方針は、いくつかの異なる当局によって支配される可能性があります（例えば、いくつかの異なる部門は、ファイアウォールや新しいサービスへのオープンアクセスにユーザーを追加する権限を持っているかもしれません）。ポリシーの異なる部分は、複雑な階層内の別のエンティティによって「所有」される可能性があります。 IPSPは、特定のエンティティに権限の特定の種類を委任するためのメカニズムを提供しなければなりません。
- The semantics of IPSP must be well defined, particularly with respect to any security-critical aspects of the system.
- IPSPの意味はよく、特にシステムのいずれかのセキュリティ上重要な側面に関して、定義する必要があります。
- IPSP must be secure, sound, and comprehensible. It should be possible to understand what an IPSP policy does; the difficulty of understanding an IPSP policy should be somewhat proportional to the complexity of the problem it solves. It should also be possible to have confidence that an IPSP policy does what it claims, and that IPSP implementation is correct; architecturally, the security-critical parts of IPSP should be small and well-specified enough to allow verification of their correct operation. Ideally, IPSP should be compatible with formal methods, such as implementing security policies with provable properties.
- IPSPは、セキュアなサウンド、そして理解できる必要があります。 IPSP方針が何をするかを理解することが可能なはずです。 IPSP方針を理解することの難しさは、それが解決し、問題の複雑さに多少比例するはずです。また、IPSP方針は、それが主張するもの、およびIPSPの実装が正しいことないという確信を持つことが可能でなければなりません。アーキテクチャ、IPSPのセキュリティ上重要な部品は小さく、その正しい動作の検証を可能にするために十分なだけでなく、指定する必要があります。理想的には、IPSPは、そのような証明可能な特性を持つセキュリティポリシーを実装するように形式手法、と互換性があります。
3. Requirements for an IP Security Policy Configuration and Management Framework
IPセキュリティポリシーの設定と管理フレームワークのための3要件
An IPSP solution MUST include:
IPSP液が含まれている必要があります
- A policy model with well-defined semantics that captures the relationship between IPsec SAs and higher-level security policies,
- IPsecのSAを、より高いレベルのセキュリティ・ポリシーとの間の関係をキャプチャし、明確に定義されたセマンティクスを持つポリシーモデル、
- A gateway discovery mechanism that allows hosts to discover where to direct IPsec traffic intended for a specific endpoint,
- 特定のエンドポイントのために意図ここでIPsecトラフィックを指示するホストを発見することを可能にするゲートウェイの発見メカニズム、
- A well-specified language for describing host policies,
- ホストポリシーを記述するための、よく指定された言語、
- A means for distributing responsibility for different aspects of policy to different entities,
- 異なるエンティティにポリシーのさまざまな側面の責任を分配するための手段、
- A mechanism for discovering the policy of a host,
- ホストのポリシーを発見するためのメカニズム、
- A mechanism for resolving the specific IPsec parameters to be used between two hosts governed by different policies (and for determining whether any such parameters exist); and,
- （任意のそのようなパラメータが存在するかどうかを決定するための）異なるポリシーによって支配2つのホスト間で使用される特定のIPSecパラメータを解決するための機構とそして、
- A well-specified mechanism for checking for compliance with a host's policy when SAs are created.
- SAが作成されたときに、ホストのポリシーに準拠するためにチェックするためのよく指定された機構。
The mechanisms used in IPSP must not require any protocol modifications in any of the IPsec standards (ESP [RFC-2406], AH, [RFC-2402], IKE [RFC-2409]). The mechanisms must be independent of the SA-negotiation protocol, but may assume certain functionality from such a protocol (this is to ensure that future SA-negotiation protocols are not incompatible with IPSP).
IPSPに使用されるメカニズムは、IPsec規格のいずれかにおける任意のプロトコルの変更（ESP [RFC-2406]、AH、[RFC-2402]、IKE [RFC-2409]）を必要とはなりません。メカニズムは、SAネゴシエーションプロトコルとは独立でなければならないが、そのようなプロトコル（これは将来のSAネゴシエーションプロトコルはIPSPと互換性がないことを保証することである）から特定の機能をとることができます。
A Policy Model defines the semantics of IPsec policy. Policy specification, checking, and resolution should implement the semantics defined in the model. However, the model should be independent of the specific policy distribution mechanism and policy discovery scheme, to the extent possible.
Policy ModelがIPsecポリシーのセマンティクスを定義します。 Policy仕様は、チェック、および解像度は、モデルで定義されたセマンティクスを実装する必要があります。しかし、モデルは、可能な限り、特定のポリシー分配機構とポリシー・ディスカバリー・スキームとは無関係であるべきです。
The gateway discovery mechanism may be invoked by any host or gateway. Its goal is to determine what IPsec gateways exist between the initiator and the intended communication peer. The actual mechanism employed may be used to piggy-back information necessary by other components of the IPSP architecture (e.g., policy discovery, as is done in [SPP]). The discovery mechanism may have to be invoked at any time, independently of existing security associations or other communication, to detect topology changes.
ゲートウェイ発見メカニズムは、任意のホストまたはゲートウェイによって呼び出されてもよいです。その目標は、IPsecゲートウェイがイニシエータ及び意図通信ピアの間に存在するかを決定することです。 （[SPP]で行われているように、例えば、ポリシー・ディスカバリー）使用される実際のメカニズムは、IPSPアーキテクチャの他のコンポーネントによって必要ピギーバック情報を使用することができます。発見メカニズムは、トポロジの変化を検出するために、独立して、既存のセキュリティアソシエーションまたは他の通信の、任意の時点で呼び出さなければならないかもしれません。
In order to allow for policy discovery, compliance checking, and resolution across a range of hosts, a common language is necessary in which to express the policies of hosts that need to communicate with one another. Statements in this language are the output of policy discovery, and provide the input to the policy resolution and compliance checking systems. Note that a host's or network's security policy may be expressed in a vendor-specific way, but would be translated to the common language when it is to be managed by the IPSP services.
ホストの範囲にわたってポリシーディスカバリ、コンプライアンスチェック、及び解像度を可能にするために、共通の言語とは、互いに通信する必要があるホストのポリシーを表現するために必要です。この言語でのステートメントは政策発見の出力であり、政策の解像度やコンプライアンスチェックシステムへの入力を提供します。ホストのか、ネットワークのセキュリティポリシーは、ベンダー固有の方法で表現することができるが、それはIPSPサービスによって管理される場合、共通の言語に翻訳されることに注意してください。
As discussed above, it must be possible for all or part of a host's policy to be managed remotely, possibly by more than one entity. This is a basic requirement for large-scale networks and systems.
上述したように、それはおそらく複数のエンティティにより、リモートで管理するホストの方針の全部または一部を可能にする必要があります。これは、大規模なネットワークおよびシステムのための基本的な要件です。
A policy discovery mechanism must provide the essential information that two IPsec endpoints can use to determine what kinds of SAs are possible between one another. This is especially important for hosts that are not controlled by the same entity, and that might not initially share any common information about one another. Note that a host need not reveal its entire security policy, only enough information to support the SA resolution system for hosts that might want to communicate with it.
ポリシー検出メカニズムは、2つのIPSecエンドポイントが互いの間で可能であるかのSAの種類を判別するために使用できることが必要不可欠な情報を提供する必要があります。これは、同じエンティティによって制御されていないホストのために特に重要であり、それは最初はお互いについての共通の情報を共有していない可能性があります。ホストは、その全体のセキュリティポリシー、それと通信したい場合がありますホストのためのSA解決システムをサポートするだけの十分な情報を明らかにする必要はないことに注意してください。
Once two hosts have learned enough about each other's policies, it must be possible (and computationally feasible) to find an acceptable set of SA parameters that meets both host's requirements and will lead to the successful creation of a new SA.
2つのホストが互いの政策について十分に学んできたら、両方のホストの要件を満たし、新しいSAの作成に成功につながるSAパラメータの許容可能なセットを見つけることが可能（と、計算可能）でなければなりません。
When a host proposes the output of the SA resolution scheme, it must be checked for compliance with the local security policy of each host. The security and soundness of the SAs created by IPSP-managed communication should depend only on the correctness of the compliance checking stage. In particular, even if the SA resolution scheme (which is likely to be computationally and conceptually complex) produces an incorrect result, it should still not be possible to violate the specified policy of either host.
ホストがSA解決スキームの出力を提案しているときは、各ホストのローカルセキュリティポリシーに準拠してチェックする必要があります。 IPSPが管理する通信によって作成されたSAのセキュリティと健全性は、コンプライアンスチェックの段階の正確さに依存しなければなりません。具体的には、（計算上と概念的に複雑である可能性が高い）SA解決スキームが正しくない結果を生成しても、まだどちらかのホストの指定したポリシーに違反することはできないはずです。
This document discusses the high-level requirements for a policy framework and architecture for IPsec. A justification for the various components is given.
この文書では、IPsecのための政策枠組みとアーキテクチャのためのハイレベルの要件について説明します。様々な構成要素のための正当性が与えられます。
No action is required by IANA.
何のアクションは、IANAによって必要とされません。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。
Copies of claims of rights made available for publication 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 Secretariat.
権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC-2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC-2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC-2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC-2408]モーガン、D.、Shertler、M.、シュナイダー、M.とJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408、1998年11月。
[RFC-2409] Harkins, D and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC-2409]ハーキンズ、DおよびD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[SPP] Sanchez, L. and M. Condell, "The Security Policy Protocol", Work in Progress.
[SPP]サンチェス、L.およびM. Condell、 "セキュリティポリシー議定書" が進行中で働いています。
The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification.
ここでビューと仕様は著者のものであり、必ずしもその雇用者のそれではありません。著者とその雇い主は、特に正しいか正しくないの実装や、この仕様の利用から生じるいかなる問題の責任を負いかねます。
The authors thank the members of the IPsec Policy working group that contributed to this document.
著者は、この文書に貢献したIPsecポリシーワーキンググループのメンバーに感謝します。
Matt Blaze AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 USA
マット・ブレイズAT＆T研究所 - 研究180パークアベニューフローラムパーク、NJ 07932 USA
EMail: mab@crypto.com
メールアドレス：mab@crypto.com
Angelos D. Keromytis Computer Science Department Columbia University 1214 Amsterdam Avenue, M.C. 0401 New York, NY 10027, USA
アンゲロス・D. Keromytisコンピュータサイエンス学部コロンビア大学1214アムステルダムアベニュー、M.C。 0401ニューヨーク、NY 10027、USA
EMail: angelos@cs.columbia.edu
メールアドレス：angelos@cs.columbia.edu
Michael C. Richardson Sandelman Software Works Corp. 470 Dawson Avenue Ottawa, ON K1Z 5V7 Canada
マイケル・C.・リチャードソンSandelmanソフトウェアワークス社K1Z 5V7カナダON 470ドーソンアベニューオタワ、
Phone: +1 613 276-6809 EMail: mcr@sandelman.ottawa.on.ca
電話：+1 613 276-6809 Eメール：mcr@sandelman.ottawa.on.ca
Luis A. Sanchez Xapiens Corporation PO Box 9023694 San Juan, PR 00902 USA
ルイは、受け取りました。サンチェスSpians株式会社00902それで私書箱9023694サンファン、
Phone: +1 (787) 832-4717 EMail: lsanchez@xapiens.com
電話：+1（787）832-4717 Eメール：lsanchez@xapiens.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。