RFC3586 日本語訳
3586 IP Security Policy (IPSP) Requirements. M. Blaze, A. Keromytis,M. Richardson, L. Sanchez. August 2003. (Format: TXT=22068 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループM.炎の要求をネットワークでつないでください: 3586のAT&T研究室--カテゴリについて研究してください: 標準化過程A.Keromytisコロンビア大学M.リチャードソンSandelmanソフトウェアはL.サンチェスXapiens社の2003年8月に動作します。
IP Security Policy (IPSP) Requirements
IP安全保障政策(IPSP)要件
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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 Security Policy(IPSP)構成と管理フレームワークを発生するための問題スペースとソリューション要件について説明します。 IPSPアーキテクチャはスケーラブルで、分散しているフレームワークを管理するのに提供します、アクセス、承認、認証、秘密性、データ保全、および他のIP Security所有地を支配するホストとネットワーク安全保障政策を発見して、交渉して。 このドキュメントは、そのような建築構成を目立たせて、それらの機能条件書を提示します。
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
1. 序論… 2 1.1. 用語… 2 1.2. 安全保障政策とIPsec… 2 2. IP安全保障政策問題スペース… 3 3. IP安全保障政策構成と管理フレームワークのための要件… 5 3.1. 一般要件… 5 3.2. 記述と正当化… 5 3.2.1. 方針モデル… 5 3.2.2. セキュリティゲートウェイ発見… 6
Blaze, et al. Standards Track [Page 1] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[1ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
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
3.2.3. 方針仕様言語… 6 3.2.4. 方針を分配します… 6 3.2.5. 方針発見… 6 3.2.6. セキュリティ協会解決… 6 3.2.7. 承諾照合… 7 4. セキュリティ問題… 7 5. IANA問題… 7 6. 知的所有権声明… 7 7. 参照… 8 7.1. 標準の参照… 8 7.2. 有益な参照… 8 8. 注意書き… 8 9. 承認… 8 10. 作者のアドレス… 9 11. 完全な著作権宣言文… 10
1. Introduction
1. 序論
1.1. Terminology
1.1. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Security Policy and IPsec
1.2. 安全保障政策とIPsec
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) セキュリティゲートウェイ。 ネットワークの縁のセキュリティゲートウェイ(「ファイアウォール」を含んでいる)は、ネットワークトラフィックの入ることの秘密性と信憑性を保護して、ネットワークを出て、アクセスコントロールを実施して、仮想私設網(VPNs)にゲートウェイサービスを提供するのに、IPsec[RFC-2401]を使用します。
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のこの広範囲のアプリケーションはネットワークが異なった安全保障政策を拡大して、必要として、異なった実体によって制御されるとき特に難しくなる複雑な管理タスクを作成します、ネットワークの異なった部分の異種のトラフィックのために。
Blaze, et al. Standards Track [Page 2] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[2ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
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.
組織が、セキュリティがゲートウェイであると配布するとき、インターネットは異なったアクセスと安全保障政策を実施する異種の領域に分割されます。 しかし、ホストがいくつかの異なった方針で制御されたネットワーク限界の向こう側に交信するのがまだしばしば必要です。 暗号のパラメタの選択の広範囲は、件を複雑にして(複数のプロトコル層で)、各当事者の必要条件を満たす1セットのセキュリティパラメタを特定して、交渉するホストとセキュリティゲートウェイの必要性を導入します。 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.
かぎ管理プロトコル(例えば、ISAKMP[RFC-2408])でIPsecセキュリティ協会(SAs)のための暗号の、そして、他のセキュリティパラメタの交渉が後押しされている間、IPsecかぎ管理層は管理することの体系を提供しません、SAsが作動する安全保障政策を交渉するか、または実施して。
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を通って交信する能力を必要とするホストに承認と方針情報を分配して。
2. The IP Security Policy Problem Space
2. IP安全保障政策問題スペース
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に遠隔アクセスを必要とするモバイルラップトップであるかもしれない)を管理するでしょう、ファイアウォール(異なったサービスを提供して、異なったクラスのトラフィックとユーザへの異なったレベルのアクセスを許します); VPNルータ(異なった組織のネットワーク方針で制御されるかもしれない他のVPNsへのどのサポートリンク)、ウェブ、他のサーバ(クライアント要求が来たところによる異なったサービスを提供するかもしれない)など。
Blaze, et al. Standards Track [Page 3] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[3ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
- 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人のホストがSecurity Associationを設立できるということです。 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パラメタはあらかじめ、しばしば指定されるというわけではないでしょう。 2人のホストが、新しいSAを作成するのを試みるとき、IPSPはしばしば急いで互いに許容できる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
- IPSPは安全で、健全で、分かりやすいに違いありません。 IPSP方針が何をするかを理解しているのは可能であるべきです。 IPSP方針を理解しているという困難はそれが解決する問題の複雑さにいくらか比例しているべきです。 また、IPSP方針がそれが要求することをするのも、自信があるのにおいて可能であるべきであり、そのIPSP実装は正しいです。 建築上、IPSPのセキュリティ重要な部分は、彼らの正しい操作の検証を許すことができるくらい小さくよく指定されているべきです。 理想的に、IPSPは互換性があるべきです。
Blaze, et al. Standards Track [Page 4] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[4ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
formal methods, such as implementing security policies with
provable properties.
証明可能な特性で安全保障政策を実装することなどの正式なメソッド。
3. Requirements for an IP Security Policy Configuration and
Management Framework
3. IP安全保障政策構成と管理フレームワークのための要件
3.1. General Requirements
3.1. 一般要件
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 SAsと、よりハイレベルの安全保障政策との関係を得る明確な意味論をもっている政策モデル
- 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.
- ホストの方針への承諾がないかどうかSAsがいつ作成されるかをチェックするためのよく指定されたメカニズム。
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規格(超能力[RFC-2406]、AH、[RFC-2402]、IKE[RFC-2409])のどれかにおける少しのプロトコル変更も必要としてはいけません。 メカニズムは、SA-交渉プロトコルから独立していなければなりませんが、そのようなプロトコルからある機能性を仮定するかもしれません(これは将来のSA-交渉プロトコルが確実にIPSPと両立しなくならないようにするためのものです)。
3.2. Description and Justification
3.2. 記述と正当化
3.2.1. Policy Model
3.2.1. 政策モデル
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方針の意味論を定義します。 方針仕様、照合、および決議はモデルで定義された意味論を実装するべきです。 しかしながら、モデルは特定保険証券分配メカニズムと方針発見体系から可能な範囲に独立しているべきです。
Blaze, et al. Standards Track [Page 5] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[5ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
3.2.2. Security Gateway Discovery
3.2.2. セキュリティゲートウェイ発見
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ゲートウェイが創始者と意図しているコミュニケーション同輩の間に存在するかを決定することです。 使われた実際のメカニズムはIPSPアーキテクチャ(例えば、されたコネ[SPP]のような方針発見)の他の成分によってピギーバック必要情報に使用されるかもしれません。 発見メカニズムは、いつでも、既存のセキュリティ協会か他のコミュニケーションの如何にかかわらずトポロジー変化を検出するために呼び出されなければならないかもしれません。
3.2.3. Policy Specification Language
3.2.3. 方針仕様言語
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サービスで管理されることになっているとき、ホストかネットワークの安全保障政策がベンダー特有の方法で言い表されるかもしれませんが、共通語に翻訳されることに注意してください。
3.2.4. Distributed policy
3.2.4. 分配された方針
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.
上で議論するように、ホストの方針のすべてか一部が離れて管理されるのは、可能であるに違いありません、ことによると1つ以上の実体で。 これは大規模なネットワークとシステムのための基本的な要件です。
3.2.5. Policy Discovery
3.2.5. 方針発見
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終点がSAsのどんな種類がお互いの間で可能であるかを決定するのに使用できる不可欠の情報を提供しなければなりません。 同じ実体によって制御されないで、また初めはお互いに関して少しの一般的な情報も共有しないホストにとって、これは特に重要です。 ホストが全体の安全保障政策、それで交信したがっているかもしれないホストのSA解決システムをサポートできるくらいの情報だけを明らかにする必要はないことに注意してください。
3.2.6. Security Association Resolution
3.2.6. セキュリティ協会解決
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のうまくいっている作成に通じるでしょう。
Blaze, et al. Standards Track [Page 6] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[6ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
3.2.7. Compliance Checking
3.2.7. 承諾照合
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によって管理されたコミュニケーションによって作成されたSAsのセキュリティと健全さは承諾照合ステージの正当性だけによるべきです。 SA解決体系(計算上、そして、概念的に複雑である傾向がある)が不正確な結果を生んでも、どちらかのホストの特約保険証券に違反するのはまだ特に、可能であるべきではありません。
4. Security Considerations
4. セキュリティ問題
This document discusses the high-level requirements for a policy framework and architecture for IPsec. A justification for the various components is given.
このドキュメントはIPsecのために方針フレームワークとアーキテクチャのためのハイレベルの要件について議論します。 様々なコンポーネントのための正当化を与えます。
5. IANA Considerations
5. IANA問題
No action is required by IANA.
動作は全くIANAによって必要とされません。
6. Intellectual Property Statement
6. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。
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.
権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Blaze, et al. Standards Track [Page 7] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[7ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC-2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
7.2. Informative References
7.2. 有益な参照
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC-2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC-2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、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] Maughan、D.、Shertler、M.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[RFC-2409] Harkins, D and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC-2409] ハーキンとDとD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[SPP] Sanchez, L. and M. Condell, "The Security Policy
Protocol", Work in Progress.
[SPP] 「安全保障政策プロトコル」というサンチェス、L.、およびM.コンデルは進行中で働いています。
8. Disclaimer
8. 注意書き
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.
ここの視点と仕様は、作者のものであり、必ず彼らの雇い主のものであるというわけではありません。 作者と彼らの雇い主はこの仕様の正しいか不正確な実装か使用から起こることにおけるどんな問題によっても明確に責任を拒否します。
9. Acknowledgements
9. 承認
The authors thank the members of the IPsec Policy working group that contributed to this document.
作者はこのドキュメントに貢献したIPsec Policyワーキンググループのメンバーに感謝します。
Blaze, et al. Standards Track [Page 8] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[8ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
10. Authors' Addresses
10. 作者のアドレス
Matt Blaze AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 USA
マット炎のAT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー07932米国
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
Angelos D.Keromytisコンピュータサイエンス部のColumbia University1214アムステルダムアベニュー、ニューヨーク、ニューヨーク 10027、M.C.0401米国
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カナダで社470のドーソン・Avenueオタワを扱います。
Phone: +1 613 276-6809 EMail: mcr@sandelman.ottawa.on.ca
以下に電話をしてください。 +1 613 276-6809 メールしてください: mcr@sandelman.ottawa.on.ca
Luis A. Sanchez Xapiens Corporation PO Box 9023694 San Juan, PR 00902 USA
ルイスA.サンチェスXapiens社の私書箱9023694サンPR00902ホアン(米国)
Phone: +1 (787) 832-4717 EMail: lsanchez@xapiens.com
以下に電話をしてください。 +1 (787) 832-4717 メールしてください: lsanchez@xapiens.com
Blaze, et al. Standards Track [Page 9] RFC 3586 IP Security Policy (IPSP) Requirements August 2003
炎、他 標準化過程[9ページ]RFC3586IP安全保障政策(IPSP)要件2003年8月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Blaze, et al. Standards Track [Page 10]
炎、他 標準化過程[10ページ]
一覧
スポンサーリンク
