Network Working Group S. Kelly
Request for Comments: 3457 Airespace
Category: Informational S. Ramamoorthi
Juniper Networks
January 2003
Requirements for IPsec Remote Access Scenarios
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios.
IPsecは、安全なリモートアクセスメカニズムとして多くの約束を提供しています。しかし、それぞれがいくつかの共有した異なるリモートアクセスシナリオの数、およびいくつかのユニークな要件があります。これらの要件の完全な理解は、効果的に、任意の特定のリモートアクセスシナリオのためのメカニズムの特定のセットの適合性を評価するために必要です。この文書では、一般的なリモートアクセスシナリオの数の要件を列挙します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Requirements Terminology . . . . . . . . . . . . . . . . 3
1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . . 3
1.3 General Terminology . . . . . . . . . . . . . . . . . . 4
1.4 Document Content and Organization . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Endpoint Authentication . . . . . . . . . . . . . . . . 6
2.1.1 Machine-Level Authentication . . . . . . . . . . . 7
2.1.2 User-Level Authentication . . . . . . . . . . . . 7
2.1.3 Combined User/Machine Authentication . . . . . . . 8
2.1.4 Remote Access Authentication . . . . . . . . . . . 8
2.1.5 Compatibility With Legacy Remote Access Mechanisms 9
2.2 Remote Host Configuration . . . . . . . . . . . . . . . 10
2.3 Security Policy Configuration . . . . . . . . . . . . . 11
2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . 13
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Telecommuters (Dialup/DSL/Cablemodem) . . . . . . . . . 14
3.1.1 Endpoint Authentication Requirements . . . . . . . 15
3.1.2 Device Configuration Requirements . . . . . . . . 16
3.1.3 Policy Configuration Requirements . . . . . . . . 17
3.1.4 Auditing Requirements . . . . . . . . . . . . . . 18
3.1.5 Intermediary Traversal Requirements . . . . . . . 18
3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . 19
3.2.1 Authentication Requirements . . . . . . . . . . . 19
3.2.2 Device Configuration Requirements . . . . . . . . 20
3.2.3 Policy Configuration Requirements . . . . . . . . 21
3.2.4 Auditing Requirements . . . . . . . . . . . . . . 21
3.2.5 Intermediary Traversal Requirements . . . . . . . 21
3.3 Extranet Laptop to Home Corporate Net . . . . . . . . . 22
3.3.1 Authentication Requirements . . . . . . . . . . . 22
3.3.2 Device Configuration Requirements . . . . . . . . 23
3.3.3 Policy Configuration Requirements . . . . . . . . 23
3.3.4 Auditing Requirements . . . . . . . . . . . . . . 24
3.3.5 Intermediary Traversal Requirements . . . . . . . 24
3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . 25
3.4.1 Authentication Requirements . . . . . . . . . . . 25
3.4.2 Device Configuration Requirements . . . . . . . . 26
3.4.3 Policy Configuration Requirements . . . . . . . . 26
3.4.4 Auditing Requirements . . . . . . . . . . . . . . 26
3.4.5 Intermediary Traversal Requirements . . . . . . . 26
3.5 Public System to Target Network . . . . . . . . . . . . 27
3.5.1 Authentication Requirements . . . . . . . . . . . 27
3.5.2 Device Configuration Requirements . . . . . . . . 28
3.5.3 Policy Configuration Requirements . . . . . . . . 28
3.5.4 Auditing Requirements . . . . . . . . . . . . . . 29
3.5.5 Intermediary Traversal Requirements . . . . . . . 29
4. Scenario Commonalities . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . 30
6. References . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
8. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . 30
9. Full Copyright Statement . . . . . . . . . . . . . . . . . 31
Until recently, remote access has typically been characterized by dial-up users accessing the target network via the Public Switched Telephone Network (PSTN), with the dial-up connection terminating at a Network Access Server (NAS) within the target domain. The protocols facilitating this have usually been PPP-based, and access control, authorization, and accounting functions have typically been provided using one or more of a number of available mechanisms, including RADIUS [RADIUS].
公開対象のドメイン内のネットワークアクセスサーバー（NAS）で終端するダイヤルアップ接続で、交換電話網（PSTN）を経由して最近まで、リモートアクセスは、典型的には、標的のネットワークにアクセスして、ダイヤルアップユーザによって特徴づけられています。これを容易にするプロトコルは、通常、ベースPPP、及びアクセス制御、許可されている、およびアカウンティング機能は、典型的には、RADIUS [RADIUS]を含む利用可能なメカニズムのうちの1つ以上を使用して提供されています。
Note that for such access, it has often been assumed that the communications infrastructure supporting the ISP connection (the PSTN) is relatively secure, and poses no significant threats to communications integrity or confidentiality. Based on this assumption, connection security has been limited to access control at the NAS based on username/passphrase pairs. In reality, PSTN dialup connections have never been impervious to a determined adversary.
このようなアクセスのために、多くの場合、ISP接続（PSTN）をサポートする通信インフラが比較的安全で、通信の整合性や機密性に有意な脅威を提起しないことが前提とされていることに注意してください。この仮定に基づいて、接続セキュリティは、ユーザ名/パスフレーズペアに基づいてNASにアクセス制御に限定されていました。実際には、PSTNのダイヤルアップ接続は、決定した敵を通さたことはありません。
The availability of widespread broadband access, in concert with the desire to reduce the cost of PSTN toll access, have driven the development of Internet-based remote access mechanisms. In some cases, PPP-based tunneling mechanisms have been used to provide remote access by allowing the dial user to first access a local ISP account, and then tunnel an additional PPP connection over the Internet into the target network. In the case of broadband users, such connections are tunneled directly over the Internet. While these mechanisms have been lacking in terms of security features, the increasing availability of IPsec renders it possible to provide more secure remote access to the remote resources via the Internet.
広範なブロードバンドアクセスの可用性は、PSTNの有料アクセスのコストを削減したいと協調して、インターネットベースのリモートアクセスメカニズムの発展を牽引してきました。いくつかのケースでは、PPPベースのトンネリング機構は、ダイヤルユーザが最初にターゲットネットワークにインターネットを介して追加のPPP接続をローカルISPアカウントにアクセスし、その後トンネルできるようにすることで、リモートアクセスを提供するために使用されてきました。ブロードバンド利用者の場合、このような接続は、インターネットを介して直接トンネリングされています。これらのメカニズムは、セキュリティ機能の面で不足してきたが、IPsecの増加の可用性は、インターネット経由でリモートリソースへのよりセキュアなリモートアクセスを提供することが可能にレンダリングします。
Remote access via the Internet has numerous benefits, financial and otherwise. However, security is paramount, and this presents strong incentives for migration from the old dial-up model to a more secure IPsec-based remote access model. Meeting the security requirements of various classes of remote access users presents a number of challenges. It is the aim of this document to explore and enumerate the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them.
インターネット経由のリモートアクセスは、金融やそれ以外の多くの利点を持っています。しかし、セキュリティが最も重要であり、これは、より安全なIPsecベースのリモートアクセスモデルに古いダイヤルアップモデルからの移行のための強力なインセンティブを提供します。リモートアクセスユーザーのさまざまなクラスのセキュリティ要件を満たすことは多くの課題を提示しています。彼らのために、特定のソリューションを示唆することなく、さまざまなIPSecリモートアクセスシナリオの要件を探求し、列挙するために、この文書の目的です。
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 [3].
キーワードは、REQUIREDは、、、、、MAYを推奨、オプション、彼らは、この文書に表示されたときに、で説明したように解釈されるすべきでないないものとものとしてはなりませんしなければならない[3]。
Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to understanding the concepts discussed here. Familiarity with concepts relating to Public Key Infrastructures (PKIs) is also necessary. Familiarity with RADIUS, PPP, PPTP, L2F, L2TP, and other remote access support protocols will also be helpful, though not strictly necessary.
RFCの2401-2412とリーダーの知識が、ここで説明する概念を理解するための最低限の前提条件です。公開キー基盤（PKIの）に関連する概念に精通しても必要です。 RADIUS、PPP、PPTP、L2F、L2TP、および他のリモートアクセスをサポートプロトコルに精通しても、厳密には必要ではないが参考になります。
o Remote Access - this term is used to refer to the case in which the remote user does not necessarily reside at a fixed location, i.e., in which the user's IP address is not fixed, and therefore usually not known prior to connection establishment.
Oリモートアクセス - この用語は、リモートユーザは、必ずしもユーザのIPアドレスが固定されていない、即ち、固定位置に存在しないので、通常は前の接続確立に知られないような場合を指すのに使用されます。
o Secure Remote Access - this term refers to remote access which is secured using elements of the IPsec protocol suite.
Oリモートアクセスを保護 - この用語は、IPsecプロトコルスイートの要素を使用して固定されているリモートアクセスを指します。
o IPsec Remote Access Client (IRAC)- this term is used to refer to the remote access user's system.
O IPsecリモートアクセスクライアント（IRAC） - この用語は、リモートアクセスユーザーのシステムを参照するために使用されます。
o IPsec Remote Access Server (IRAS) - this term refers to the device providing access to the target network. An alternative term is "Security Gateway".
O IPsecリモートアクセスサーバー（IRAS） - この用語は、ターゲットネットワークへのアクセスを提供するデバイスを指します。代替用語は、「セキュリティゲートウェイ」です。
o Security GateWay (SGW) - this refers to the device providing access to the target network. An alternative term is IRAS.
セキュリティゲートウェイ（SGW）O - これは、ターゲット・ネットワークへのアクセスを提供するデバイスを指します。代替用語はIRASです。
o Virtual IP address (VIP) - this term describes an address from a subnet local to the target network which is assigned to a remote client, giving the appearance that the remote client actually resides on the target network.
O仮想IPアドレス（VIP） - この用語は、リモートクライアントが実際にターゲットネットワーク上に存在するという外観を与える、リモートクライアントに割り当てられているターゲットネットワークへのローカルサブネットからのアドレスを記述します。
o Machine-Level Authentication - this term describes the case where the identity of a machine is verified by virtue of the machine's possession and application of some combination of authenticators. For a more complete definition, see section 2.
Oマシンレベル認証 - この用語は、マシンのアイデンティティはオーセンティケータのいくつかの組み合わせのマシンの所持やアプリケーションによって検証された場合について説明します。より完全な定義については、セクション2を参照してください。
o User-Level Authentication - this term describes the case where the identity of a user (as opposed to that of a machine) is verified by virtue of the user's possession and application of some combination of authenticators. For a more complete definition, see section 2.
Oユーザーレベルの認証 - この用語は、ユーザーのアイデンティティが（機械とは対照的に）ユーザの所有とオーセンティケータのいくつかの組み合わせのアプリケーションによって検証された場合について説明します。より完全な定義については、セクション2を参照してください。
o NAPT - Network Address/Port Translation
O NAPT - ネットワークアドレス/ポート変換
This document, while initially intended to simply outline requirements for various remote access scenarios, has come to include somewhat more than this. This document has evolved from discussion within the IPsec Remote Access (IPSRA) working group. As a result, it in some respects documents the evolution of this thought process. While this represents a departure from the typical form of a requirements document, the associated historical context should prove useful in interpreting the conclusions reached in the IPSRA working group.
最初は単に様々なリモートアクセスシナリオのための要件を概説することを意図しながら、この文書では、これよりややそれ以上を含むようになってきました。この文書では、IPSecリモートアクセス（IPSRA）ワーキンググループ内での議論から発展してきました。その結果、いくつかの点で、それはこの思考プロセスの進化を説明します。これは要件ドキュメントの典型的な形からの逸脱を表しているが、関連した歴史的な文脈ではIPSRAワーキンググループに到達した結論を解釈する際に有用であることが分かるはずです。
The balance of this document is organized as follows: First, there is a general overview of the basic requirements categories, including definitions relevant to these categories. Following this is a section devoted to each remote access scenario. Within each of these sections there are subsections detailing requirements specific to that scenario in each of the following areas: endpoint authentication, remote host configuration, policy configuration, auditing, and intermediary traversal.
まず、これらのカテゴリに関連する定義を含む基本的な要件カテゴリの一般的な概要は、そこにある、次のようにこのドキュメントのバランスが編成されています。これに続いては、各リモートアクセスシナリオに専念セクションです。エンドポイント認証、リモート・ホスト構成、ポリシー構成、監査、および中間トラバーサル：これらのセクションの各々内の以下の領域のそれぞれにそのシナリオに固有の要件を詳述するサブセクションがあります。
In a very general sense, all secure remote access scenarios have a similar high-level appearance:
非常に一般的な意味では、すべてのセキュアなリモートアクセスのシナリオは、類似したハイレベルな外観を持っています：
target network
|
| +---+
+-------------+ +-----------+ |---| |
|remote access| Internet | security | | +---+
| client |=============| gateway |--|
| (IRAC) | |(SGW/IRAS) | | +---+
+-------------+ +-----------+ |---| |
| +---+
In all cases, a remote client wishes to securely access resources either behind a SGW or on an IPsec-protected host, and/or wishes to provide other (specific) systems with secure access to the client's own resources. There are numerous details which may differ, depending on the particular scenario. For example, the IRAC may be within another corporate network, or connected to an ISP via dialup, DSL, or CATV media. There may be additional intermediaries between the remote client and the security gateway, but ultimately, all of these configurations may be viewed somewhat equivalently from a high level.
すべての場合において、リモートクライアントが確実にSGWの後ろやIPsecで保護されたホスト上のいずれかのリソースにアクセスしようとする、および/またはクライアント自身のリソースへのセキュアなアクセスを持つ他の（特定の）システムを提供することを希望します。特定のシナリオに応じて、異なる場合があり多くの詳細があります。例えば、IRACは、別の企業ネットワーク内であってもよいし、ダイヤルアップ、DSL、またはCATV媒体を介してISPに接続します。そこリモートクライアントとセキュリティゲートウェイとの間に追加の仲介であってもよいが、最終的に、これらの構成の全てがハイレベルから幾分等価見ることができます。
In general, there are several basic categories of requirements relevant to secure remote access scenarios, including endpoint authentication, remote host configuration, security policy configuration, auditing, and intermediary traversal. Endpoint authentication refers to verification of the identities of the communication partners (e.g., the IRAC and the IRAS). Remote host configuration refers to the device configuration parameters of the IRAC system. Security policy configuration refers to IPsec policy configuration of both the security gateway and the remote host, and might also be termed "access control and authorization configuration". Auditing refers to the generation and collection of connection status information which is required for the purpose of maintaining the overall security and integrity of the connected networks. Intermediary traversal refers to the ability to pass secured traffic across intermediaries, some of which may modify the packets in some manner. Such intermediaries include NAPT and firewall devices. These various categories are treated in more detail below.
一般的には、エンドポイント認証、リモートホストの設定、セキュリティポリシーの設定、監査、および仲介トラバーサルなどのリモートアクセスのシナリオを、確保するために、関連する要求事項のいくつかの基本的なカテゴリがあります。エンドポイント認証は、通信相手の識別情報（例えば、IRACとIRAS）の検証を指します。遠隔ホスト構成はIRACシステムのデバイス構成パラメータを指します。セキュリティポリシーの設定は、セキュリティゲートウェイとリモートホストの両方のIPsecポリシーの設定を参照し、また、「アクセス制御および権限の設定」と呼ばれることがあります。監査は、接続されたネットワーク全体のセキュリティと完全性を維持するために必要とされる接続状況情報の生成及び収集を指します。中間トラバーサルは、何らかの方法でパケットを変更することができるいくつかの媒体を横切って固定トラフィックを通過させる能力を指します。このような仲介者はNAPTとファイアウォールデバイスを含みます。これらの様々なカテゴリは、以下でより詳細に扱われます。
Before discussing endpoint authentication with respect to remote access, it is important to distinguish between data source authentication and end user authentication. Data source authentication in the IPsec context consists in providing assurance that a network packet originates from a specific endpoint, typically a user, host, or application. IPsec offers mechanisms for this via AH or ESP. End user authentication within the IPsec context consists in providing assurance that the endpoint is what or who it claims to be. IPsec currently offers mechanisms for this as part of IKE [IKE].
リモートアクセスに対するエンドポイント認証を議論する前に、データソース認証とエンドユーザー認証を区別することが重要です。 IPsecのコンテキストでデータソースの認証は、ネットワークパケットが特定のエンドポイント、典型的には、ユーザ、ホスト、またはアプリケーション由来の保証を提供することにあります。 IPsecはAHまたはESPを経由して、このためのメカニズムを提供しています。 IPsecのコンテキスト内でエンドユーザ認証は、エンドポイントは何か誰それがあることを主張しているという保証を提供することにあります。 IPsecは現在、IKE [IKE]の一環として、このためのメカニズムを提供しています。
While the two types of authentication differ, they are not unrelated. In fact, data source authentication relies upon endpoint authentication, because it is possible to inject packets with a particular IP address into the Internet from many arbitrary locations. In many instances, we cannot be certain that a packet actually originates from a particular host, or even from the network upon which that host resides. To resolve this, one must first authenticate the particular endpoint somehow, and then bind the addressing information (e.g., IP address, protocol, port) of this endpoint into the trust relationship established by the authentication process.
認証の二種類が異なるが、それらは無関係ではありません。多くの任意の場所からインターネットに特定のIPアドレスを持つパケットを注入することが可能であるため、実際には、データ・ソースの認証は、エンドポイントの認証に依存します。多くの場合、我々は、パケットが実際に特定のホストから、あるいはそのホストが常駐するネットワークに由来することを確信することはできません。これを解決するには、まず何とか特定のエンドポイントを認証して、認証プロセスによって確立された信頼関係に、このエンドポイントのアドレス情報（例えば、IPアドレス、プロトコル、ポート）をバインドする必要があります。
In the context of secure remote access, the authenticated entity may be a machine, a user (application), or both. The authentication methods currently supported by IPsec range from preshared secrets to various signature and encryption schemes employing private keys and their corresponding public key certificates. These mechanisms may be used to authenticate the end user alone, the device alone, or both the end user and the device. These are each discussed in more detail below.
安全なリモートアクセスの文脈では、認証されたエンティティは、マシン、ユーザ（アプリケーション）、またはその両方であってもよいです。現在、事前共有秘密から秘密鍵とそれに対応する公開鍵証明書を使用し、様々な署名と暗号化のスキームへのIPsec範囲でサポートされている認証方法。これらのメカニズムは、単独でエンドユーザを認証するために単独で、デバイス、またはエンドユーザとデバイスの両方を使用することができます。これらはそれぞれ、以下でより詳細に議論されます。
In the case where no user input is required in order for an authentication credential to be used, the entity authenticated will primarily be the device in which the credential is stored and the level of derived assurance regarding this authentication is directly related to how securely the machine's credential is maintained during both storage and use. That is, a shared secret or a private key corresponding to a public key certificate may be either stored within the device or contained in another device which is securely accessible by the device (e.g., a smartcard). If the knowledge required for the use of such authentication credentials is entirely contained within the subject device (i.e., no user input is required), then it is problematic to state that such credential usage authenticates anything other than the subject device.
ユーザ入力を使用する認証証明書ために必要とされない場合には、認証されたエンティティは、主に資格が格納されたデバイスとなり、この認証に関する派生保証のレベルは、どのように確実に機械のに直接関連しています信任状は、貯蔵および使用の両方の間に維持されます。つまり、共有秘密であるか、または公開鍵証明書に対応する秘密鍵は、デバイス内に格納された、またはデバイスによって確実にアクセス可能である他の装置（例えば、スマートカード）に含まれていてもよいいずれか。このような認証資格情報を使用するために必要な知識は完全対象デバイス（すなわち、ユーザ入力が必要とされない）内に含まれている場合、そのような資格使用が対象機器以外を認証することを述べることは問題です。
In some cases, a user may be required to satisfy certain criteria prior to being given access to stored credentials. In such cases, the level of user authentication provided by the use of such credentials is somewhat difficult to derive. If sufficiently strong access controls exist for the system housing the credential, then there may be a strong binding between the authorized system user and the credential. However, at the time the credential is presented, the IRAS itself has no such assurance. That is, the IRAS in isolation may have some level of assurance that a particular device (the one in which the credential resides) is the one from which access is being attempted, but there is no explicit assurance regarding the identity of the user of the system. In order for the IRAS to derive additional assurance regarding the user identity, an additional user credential of some sort would be required. This is discussed further below.
いくつかのケースでは、ユーザは、従来の保存された資格情報へのアクセスを与えられるために、特定の基準を満たすために必要とされ得ます。このような場合には、そのような資格情報を使用することによって提供されるユーザ認証のレベルを導き出すことがやや困難です。十分に強力なアクセス制御は、システムハウジング資格のために存在する場合は、許可されたシステム・ユーザと信任状との間に強い結合が存在してもよいです。ただし、証明書が提示された時点で、IRAS自体はそのような保証を持っていません。すなわち、単独でIRASは、特定のデバイス（資格が存在するもの）のアクセスが試行されているから1であることを保証するいくつかのレベルを有していてもよい、であるが、ユーザのアイデンティティに関して明示的な保証はありませんシステム。 IRASは、ユーザーのアイデンティティに関する追加の保証を導出するためには、ある種の追加のユーザーの資格情報が必要とされるであろう。これについては、以下でさらに説明します。
In some cases, the user may possess an authentication token (preshared key, private key, passphrase, etc.), and may provide this or some derivative of this whenever authentication is required. If this token or derivative is delivered directly to the other endpoint without modification by the IRAC system, and if the IRAC system provides no further credentials of its own, then it is the user alone which has been authenticated. That is, while there may be some assurance as to the network address from which the user is originating packets, there is no assurance as to the particular machine from which the user is attempting access.
いくつかのケースでは、ユーザは、認証トークン（事前共有鍵、秘密鍵、パスフレーズ等）を有していてもよいし、認証が要求されるたびに、このこのまたはいくつかの誘導体を提供することができます。このトークンまたは誘導体はIRACシステムによって修正することなく、他のエンドポイントに直接送達、およびIRACシステムは、独自の更なる資格情報を提供しない場合、それは認証されたユーザのみである場合。ユーザがパケットを発信されたネットワークアドレスへのようないくつかの保証があってもよいしながらつまり、ユーザがアクセスを試みているから特定のマシンのような保証はありません。
To authenticate both the user and the system, user input of some sort is required in addition to a credential which is securely stored upon the device. In some cases, such user input may be used in order to "complete" the credential stored on the device (e.g., a private key is password-encrypted), while in others the user's input is supplied independently of the stored credential. In the case where the passphrase is applied to the credential prior to use, the level of assurance derived from successful application of the credential varies according to your viewpoint.
ユーザとシステムの両方を認証するために、ある種のユーザ入力は、安全装置上に格納されている資格証明に加えて必要とされます。いくつかの場合において、そのようなユーザ入力が「完了」するために使用することができる他、ユーザの入力は、独立して格納された資格の供給されるデバイス上に格納された資格証明は、（例えば、プライベートキーは、パスワード暗号化です）。パスフレーズを使用する資格の前に適用された場合に、資格の成功したアプリケーションに由来する保証のレベルは、あなたの視点に応じて変化します。
From the perspective of a system consisting of user, IRAC, IRAS, and a collection of system protections and security procedures, it may be said that the user has been authenticated to an extent which depends upon the strength of the security procedures and system protections which are in place. However, from the perspective of the IRAS alone, there is little assurance with respect to user identity. That is, schemes requiring that stored credentials be modified by user input prior to use may only be said to provide user-level authentication within the context of the larger system, and then, the level of assurance derived is directly proportional to the weakest security attribute of the entire system.
ユーザからなるシステム、IRAC、IRAS、およびシステムの保護とセキュリティ手順の回収の観点から、ユーザがどのセキュリティ手順及びシステム保護の強度に依存する程度に認証されているといえます所定の位置にあります。しかし、単独のIRASの観点から、ユーザアイデンティティに関してはほとんど保証があります。すなわち、格納された証明書が使用前にユーザ入力によって修正されることを必要とする方式でのみ、より大きなシステムのコンテキスト内でユーザーレベルの認証を提供すると言われてもよい、であり、次いで、誘導された保証のレベルが最も弱いセキュリティ属性に正比例しますシステム全体の。
When considering remote access from a general perspective, assumptions regarding the overall system are liable to prove incorrect. This is because the IRAS and the IRAC may not be within the same domain of control; extranet scenarios are a good example of this. Hence, the most desirable joint user/machine authentication mechanisms in this context are those which provide a high level of assurance to both the IRAS and the IRAC, independently of the larger system of which the user, IRAS, and IRAC are a part.
一般的な観点からのリモートアクセスを考慮すると、システム全体に関する仮定が正しくないことを証明しやすいです。 IRASとIRACコントロールの同じドメイン内にない場合があるからです。エクストラネットのシナリオは、この良い例です。したがって、この文脈の中で最も望ましい関節ユーザ/マシン認証メカニズム独立ユーザー、IRAS、及びIRACが一部であるより大きなシステムの、IRASとIRAC両方に保証の高いレベルを提供するものです。
In the general case for remote access, authentication requirements are typically asymmetric. From the IRAC's perspective, it is important to ensure that the IRAS at the other end of the connection is indeed what it seems to be, and not some rogue system masquerading as the SGW. That is, the IRAC requires machine-level authentication for the IRAS. This is fairly straightforward, given the authentication mechanisms supported by IKE and IPsec. Further, this sort of authentication tends to persist through time, although the extent of this persistence depends upon the mechanism chosen.
リモートアクセスのための一般的なケースでは、認証要件は、一般的に非対称です。 IRACの観点から、接続のもう一方の端にIRASはあると思われる、となく、いくつかの不正なシステムがSGWを装ったものを実際にあることを確認することが重要です。つまり、IRACは、IRASのためにマシンレベルの認証が必要です。これは、IKEおよびIPsecでサポートされている認証メカニズムを考えると、非常に簡単です。この永続性の程度は、選択された機構に依存するが、さらに、認証のこの種は、時間を通して持続する傾向があります。
While machine-level authentication for the IRAS is sufficient, this is not the case for the IRAC. Here, it is often important to know that the entity at the other end of the connection is one who is authorized to access local resources rather than someone who happened upon an unoccupied but otherwise authorized system, or a malicious Trojan horse application on that user's system, or some other unauthorized entity. Authenticating the user presents different requirements than authenticating the user's machine; this requires some form of user input, and often the authentication must be periodically renewed.
IRASのためにマシンレベルの認証が十分であるが、これはIRACには当てはまりません。ここでは、接続のもう一方の端に実体がかなり空いているが、それ以外は許可されたシステムに起こった誰か、またはそのユーザーのシステム上の悪質なトロイの木馬アプリケーションよりも、ローカルリソースへのアクセスを認可されたものであることを知ることがしばしば重要です、またはその他の不正なエンティティ。ユーザーの認証は、ユーザーのマシンを認証するよりも、さまざまな要件を提示し、これは、ユーザー入力のいくつかのフォームを必要とし、多くの場合、認証が定期的に更新する必要があります。
In situations where a high level of physical security does not exist, it is common to require a user-input secret as part of the authentication process, and then to periodically renew the authentication. Furthermore, since such circumstances may include the possibility of the presence of a Trojan horse application on the IRAC system, one-time passphrase mechanisms are often advisable. Choosing passphrase mechanisms and renewal intervals which provide an acceptable level of risk, but which do not annoy the user too much, may be challenging. It should be obvious that even this approach offers limited assurance in many cases.
物理的なセキュリティの高いレベルが存在しない状況では、認証プロセスの一部として、ユーザ入力秘密を必要とすること、及びその後定期認証を更新することが一般的です。このような状況は、IRACシステムにトロイの木馬アプリケーションの存在の可能性を含むことができるので、ワンタイムパスフレーズメカニズムはしばしば賢明です。パスフレーズのメカニズムとあまりにも多くのユーザーを困らせていないリスクの許容レベルを提供しますが、更新間隔を選択、挑戦することがあります。それも、このアプローチは、多くの場合に限定された保証を提供していることは明らかです。
Clearly, there are variable assurance levels which are attainable with the various endpoint authentication techniques, and none of the techniques discussed offer absolute assurance. Also, there are variations in the authentication requirements among different remote access scenarios. This means there is no "cookie cutter" solution for this problem, and that individual scenarios must be carefully examined in order to derive specific requirements for each. These are examined on a case by case basis below in the detailed scenario descriptions.
明らかに、そこに様々なエンドポイントの認証技術で達成可能である可変保証レベルであり、議論の技術のいずれも絶対的な保証を提供しません。また、別のリモートアクセスシナリオの間で認証要件にばらつきがあります。これは、そこにこの問題の「クッキーカッター」ソリューションはなく、個々のシナリオは慎重にそれぞれに固有の要件を導出するために検討されなければならないことを意味しています。これらは、詳細なシナリオの説明で以下にケースバイケースで検討されています。
There are a number of currently deployed remote access mechanisms which were installed prior to the deployment of IPsec. Typically, these are dialup systems which rely upon RADIUS for user authentication and accounting, but there are other mechanisms as well. An ideal IPsec remote access solution might utilize the components of the underlying framework without modification. Inasmuch as this is possible, this should be a goal. However, there may be cases where this simply cannot be accomplished, due to security and/or other considerations. In such cases, the IPsec remote access framework should be designed to accommodate migration from these mechanisms as painlessly as is possible.
前のIPsecの展開にインストールされた現在展開リモートアクセスメカニズムがいくつかあります。典型的には、これらは、ユーザ認証およびアカウンティングのためのRADIUSに依存ダイアルアップシステムであるが、他のメカニズムも存在します。理想的なのIPsecリモートアクセスソリューションは、変更せずに基本的な枠組みの構成要素を利用することがあります。これが可能である限り、これは目標でなければなりません。しかし、これは単に、セキュリティおよび/またはその他の考慮による達成できない場合があります。このような場合には、IPSecリモートアクセス・フレームワークは、として無痛可能であるように、これらの機構からの移行に対応するように設計されるべきです。
In general, proposed IPsec remote access mechanisms should meet the following goals:
一般的には、提案のIPsecリモートアクセスメカニズムは、次の目標を満たしている必要があります。
o should provide direct support for legacy user authentication and accounting systems such as RADIUS
oはRADIUSなどのレガシーユーザー認証およびアカウンティングシステムを直接サポートを提供する必要があります
o should encourage migration from existing low-entropy password-based systems to more secure authentication systems
oは、既存の低エントロピーパスワードベースのシステムへのより安全な認証システムからの移行を奨励すべきです
o if legacy user authentication support cannot be provided without some sort of migration, the impact of such migration should be minimized
レガシーユーザ認証サポート移行のある種なしに提供することができない場合、O、かかるマイグレーションの影響は最小限にすべきです
o user authentication information must be protected against eavesdropping and replay (including the user identity)
Oユーザ認証情報（ユーザーIDを含む）を盗聴やリプレイから保護されなければなりません
o single sign-on capability should be provided in configurations employing load-balancing and/or redundancy
Oシングルサインオン機能は、ロードバランシング及び/又は冗長性を用いる構成で提供されなければなりません
o n-factor authentication mechanisms should be supported
O、N因子認証メカニズムをサポートしなければなりません
Remote host configuration refers to the network-related device configuration of the client system. This configuration may be fixed or dynamic. It may be completely provided by the administrator of the network upon which the remote user currently resides (e.g., the ISP), or it may be partially provided by that administrator, with the balance provided by an entity on the remote corporate network which the client is accessing. In general, this configuration may include the following:
リモートホストの設定は、クライアントシステムのネットワーク関連機器の構成を指します。この構成は、固定または動的ことができます。それは完全にリモート・ユーザが現在常駐するネットワーク（例えば、ISP）の管理者によって提供されてもよい、あるいはそれが部分的にリモート企業ネットワーククライアント上のエンティティによって提供さのバランスで、その管理者によって提供されてもよいですアクセスしています。一般的に、この構成は、以下を含むことができます。
o IP address(es) o Subnet mask(s) o Broadcast address(es) o Host name o Domain name o Time offset o Servers (e.g., SMTP, POP, WWW, DNS/NIS, LPR, syslog, WINS, NTP, etc. ) o Router(s) o Router discovery options o Static routes o MTU o Default TTL o Source routing options o IP Forwarding enable/disable o PMTU options o ARP cache timeout o X Windows options o NIS options o NetBIOS options o Vendor-specific options o (other options)
O時間Oドメイン名Oブロードキャストアドレス（複数可）Oホスト名O IPアドレス（複数可）Oサブネットマスク（複数可）Oサーバ（例えば、SMTP、POP、WWW、DNS / NIS、LPRは、Syslog、WINS、NTPを、オフセットなど）ルータ（複数可）OルータディスカバリオプションOスタティックルートO MTU OデフォルトTTL 0ソースルーティングオプションO IPフォワーディング〇〇ベンダーのNetBIOSオプションoをNISオプションoをX、WindowsのオプションoをARPキャッシュのタイムアウトO /無効OのPMTUのオプションを有効にします特定のオプション0（他のオプション）
Cases where such configuration is fixed are uninteresting; it is the cases where specific IRAC configuration occurs as a result of remote access with which we are concerned. For example, in some cases the IRAC may be assigned a "virtual address", giving the appearance that it resides on the target network:
このような構成が固定されている場合はつまらないです。それは特定IRAC構成は、我々が懸念しているとリモートアクセスの結果として生じる場合もあります。例えば、いくつかのケースではIRACは、それがターゲットネットワーク上に存在するという外観を与える、「仮想アドレス」を割り当ててもよいです。
target net
+------------------+ |
| Remote Access | +--------+ | ( ~ ~ ~ ~ ~ )
|+-------+ Client | | | | ( IRAC )
||virtual| | |security| |~~~( virtual )
|| host | |--------|gateway | | ( presence )
|| |<================>| |----| ~ ~ ~ ~ ~
|+-------+ |--------| | |
+------------------+ ^ +--------+ | +--------+
| |---| local |
IPsec tunnel | | host |
with encapsulated | +--------+
traffic inside
In this case, the IRAC system begins with an externally routable address. An additional target network address is assigned to the IRAC, and packets containing this assigned address are encapsulated, with the outer headers containing the IRAC's routable address, and forwarded to the IRAS through the tunnel. This provides the IRAC with a virtual presence on the target network via an IPsec tunnel. Note that the IRAC now has two active addresses: the ISP-assigned address, and the VIP.
この場合、IRACシステムは、外部ルーティング可能なアドレスで始まります。追加のターゲット・ネットワーク・アドレスがIRACに割り当てられ、この割り当てられたアドレスを含むパケットは、IRACのルーティング可能なアドレスを含むアウターヘッダと、カプセル化、トンネルを介してIRASに転送されます。これは、IPsecトンネルを介してターゲットネットワーク上の仮想存在とIRACを提供します。 ISPによって割り当てられたアドレス、およびVIP：IRACは今、二つの活性のアドレスを持っていることに注意してください。
Having obtained this virtual presence on the corporate network, the IRAC may now require other sorts of topology-related configuration, e.g., default routers, DNS server(s), etc., just as a dynamically configured host which physically resides upon the target network would. It is this sort of configuration with which this requirements category is concerned.
企業ネットワーク上でこの仮想存在感を得られたので、IRACは今ちょうど物理的にターゲットネットワーク上に常駐し、動的に設定されたホストとして、他のトポロジ関連の設定の種類、例えば、デフォルトルータ、DNSサーバ（複数可）、などが必要な場合がありますでしょう。これは、この要件のカテゴリが関係する設定のこの種です。
Security policy configuration refers to IPsec access policies for both the remote access client and the security gateway. It may be desirable to configure access policies on connecting IRAC systems which will protect the target network. For example, since a client has access to the Internet (via its routable address), other systems on the Internet also have some level of reciprocal access to the client. In some cases, it may be desirable to block this Internet access (or force it to pass through the tunnel) while the client has a tunneled connection to the target network. This is a matter of client security policy configuration.
セキュリティポリシー設定は、リモートアクセスクライアントとセキュリティゲートウェイの両方のためのIPsecアクセスポリシーを指します。ターゲット・ネットワークを保護しますIRACシステムを接続するには、アクセスポリシーを設定することが望ましい場合があります。クライアントが（そのルーティング可能なアドレスを経由して）、インターネットへのアクセスを持っているので、例えば、インターネット上の他のシステムでは、クライアントへの往復のアクセスのいくつかのレベルを持っています。クライアントがターゲットネットワークへのトンネル接続を有しているいくつかのケースでは、（またはトンネルを通過するように強制する）、このインターネットアクセスをブロックすることが望ましい場合があります。これは、クライアントのセキュリティポリシーの設定の問題です。
For the security gateway, it may also be desirable to dynamically adjust policies based upon the user with which a connection has been established. For example, say there are two remote users, named Alice and Bob. We wish to provide Alice with unrestricted access to the target network, while we wish to restrict Bob's access to specific segments. One way to accomplish this would be to statically assign internal "virtual" addresses to each user in a one-to-one mapping, so that each user always has the same address. Then, a particular user's access could be controlled via policies based upon the particular address. However, this does not scale well.
セキュリティゲートウェイのために、また、動的接続が確立されたユーザに基づいてポリシーを調整することが望ましい場合があります。例えば、アリスとボブという名前の2人のリモートユーザーは、そこにあると言います。我々は、特定のセグメントにボブのアクセスを制限したい一方で、ターゲットネットワークへの無制限のアクセスでアリスを提供したいです。これを実現するための一つの方法は、各ユーザが常に同じアドレスを持つように静的に、1対1のマッピングでは、各ユーザに内部の「仮想」アドレスを割り当てることであろう。次に、特定のユーザーのアクセスは、特定のアドレスに基づいてポリシーを介して制御することができます。しかし、これはうまくスケールしません。
A more scalable solution for remote client access control would be to dynamically assign IP addresses from a specific pool based upon the authenticated endpoint identity, with access to specific resources controlled by address-based policies in the SGW. This is very similar to the static mapping described above, except that a given group of users (those with identical access controls) would share a given pool of IP addresses (those which are granted the required access), rather than a given user always mapping to a given address. However, this also has scaling issues, though not as pronounced as for the static mapping.
リモート・クライアント・アクセス・コントロールのために、よりスケーラブルなソリューションは、動的SGW内のアドレスベースのポリシーによって制御される特定のリソースへのアクセスを、認証されたエンドポイントの識別情報に基づいて特定のプールからIPアドレスを割り当てることであろう。これにより、ユーザ（同じアクセス制御を有するもの）の与えられたグループは、IPアドレス（必要なアクセス権が付与されているもの）の与えられたプールではなく、特定のユーザー常にマッピングを共有することを除いて、上述した静的マッピングに非常に類似しています指定されたアドレスへ。静的マッピングのように発音されていないがしかし、これはまた、問題をスケーリングしています。
Alternatively, an arbitrary address could be assigned to a user, with the security gateway's policy being dynamically updated based upon the identity of the remote client (and its assigned virtual address) to permit access to particular resources. In these cases, the relevant security policy configuration is specific to the IRAS, rather than to the IRAC. Both IRAS and IRAC security policy configuration are encompassed by this requirements category.
また、任意のアドレスは、セキュリティゲートウェイのポリシーを動的に特定のリソースへのアクセスを許可するリモートクライアント（およびその割り当てられた仮想アドレス）の識別情報に基づいて更新されると、ユーザーに割り当てることができます。これらのケースでは、関連するセキュリティポリシーの設定はIRASのではなく、IRACに固有のものです。 IRASとIRACセキュリティポリシーの設定の両方がこの要件カテゴリに包含されます。
Auditing is used here to refer to the collection and reporting of connection status information by the IRAS, for the purpose of maintaining the security and integrity of the IRAS protected network. For remote access, the following auditing information is useful from a security perspective:
監査は、ネットワークの保護IRASのセキュリティと整合性を維持する目的のために、IRASによる接続状況情報の収集と報告を参照するためにここで使用されます。リモートアクセスのために、以下の監査情報は、セキュリティの観点から便利です。
o connection start time o connection end time
O接続は、時間O接続の終了時刻を開始します
Note that the requirement for a connection-end-time attribute implies the need for a connection heartbeat mechanism of some sort so that the IRAS can accurately determine this quantity in cases where the
IRASが正確な場合にこの量を決定することができるように、接続終了時間属性要件はある種の接続ハートビート機構の必要性を含意することに注意してください
IRAC does not explicitly terminate the connection. Also note that the heartbeat mechanism in this case is always directed from the IRAC to the IRAS.
IRACは、明示的に接続を終了しません。この場合にも、ハートビート機構が常にIRASにIRACから向けられていることに注意してください。
In some cases, use of a heartbeat may negatively influence a connection. For example, if the heartbeat interval is very short, and the connection is reset after loss of very few heartbeat packets, there is a possibility that network congestion could lead to unnecessary connection resets. The heartbeat interval and reset threshold should be chosen with this in mind, and it should be possible to adjust these quantities either through configuration or negotiation.
いくつかのケースでは、ハートビートを使用すると、負の接続に影響を与える可能性があります。ハートビート間隔が非常に短く、接続は非常に少数のハートビートパケットの損失の後にリセットされた場合、ネットワーク輻輳が不要な接続のリセットにつながる可能性があります。ハートビート間隔としきい値をリセットするには、これを念頭において選択しなければならない、そしていずれの構成や交渉を通じてこれらの量を調整することが可能でなければなりません。
Intermediary traversal is used here to refer to passing a secured data stream through an intermediary such as a firewall or NAPT device. In the case of firewalls, numerous deployed products do not recognize the IPsec protocol suite, making it difficult (sometimes impossible) to configure them to pass it through. In such cases, a mechanism is required for making the data stream appear to be of a type which the firewall is capable of managing.
中間トラバーサルは、ファイアウォールまたはNAPT装置として介して保護されたデータストリームを渡すを指すためにここで使用されます。ファイアウォールの場合には、数多くの展開の製品は、それが困難（時には不可能）、それを通過するように設定すること、IPsecプロトコルスイートを認識しません。このような場合には、機構は、データ・ストリームはファイアウォールが管理することができるタイプのものであるように見える作るために必要とされます。
In the case of NAPT devices, there are a number of issues with attempting to pass an encrypted or authenticated data stream. For example, NAPT devices typically modify the source IP address and UDP/TCP port of outgoing packets, and the destination IP address and UDP/TCP port of incoming packets, and in some cases, they modify additional fields in the data portion of the packet. Such modifications render the use of the AH protocol impossible. In the case of ESP, the UDP/TCP port fields are sometimes unreadable and always unmodifiable, making meaningful translation by the NAPT device impossible. There are numerous other protocol-field combinations which suffer similarly. This requirements category is concerned with these issues.
NAPT装置の場合には、暗号化又は認証されたデータ・ストリームを通過しようとすると多くの問題があります。例えば、NAPT装置は、通常、送信元IPアドレスと送信パケットのUDP / TCPポート、宛先IPアドレスと着信パケットのUDP / TCPポートを変更し、いくつかのケースでは、彼らは、パケットのデータ部分に追加のフィールドを変更します。そのような修飾は不可能AHプロトコルの使用をレンダリングします。 ESPの場合は、UDP / TCPポートフィールドは不可能NAPTデバイスによって意味のある翻訳を作り、時には読めないと常に変更不可能です。同様に苦しむ他の多数のプロトコル・フィールドの組み合わせがあります。この要件カテゴリは、これらの問題に関係しています。
There are numerous remote access scenarios possible using IPsec. This section contains a brief summary enumeration of these, followed by a subsection devoted to each which explores the various requirements in terms of the categories defined above.
IPsecを使用可能に数多くのリモートアクセスのシナリオがあります。このセクションでは、上記で定義されたカテゴリの面で様々な要件を探るそのそれぞれに専念サブセクションに続くこれらの簡単な要約を列挙し、含まれています。
The following scenarios are discussed:
次のシナリオを検討しています：
o dialup/dsl/cablemodem telecommuters using their systems to access remote resources
Oリモートリソースにアクセスするためにシステムを使用して/ DSL /ケーブルモデムの在宅勤務をダイヤルアップ
o extranet users using local corporate systems to access the remote company network of a business partner
ビジネスパートナーのリモート企業ネットワークにアクセスするために地元の企業システムを使用してOエクストラネットユーザー
o extranet users using their own system within another company's network to access their home corporate network
自宅企業ネットワークにアクセスするために、別の会社のネットワーク内で独自のシステムを使用してOエクストラネットユーザー
o extranet users using a business partner's system (located on that partner's network) to access their home corporate network
自宅企業ネットワークにアクセスするために（そのパートナーのネットワーク上にある）ビジネスパートナーのシステムを使用してOエクストラネットユーザー
o remote users using a borrowed system (e.g., an airport kiosk) to access target network resources
ターゲットネットワークリソースにアクセスするために借りシステム（例えば、空港のキオスク）を使用して、リモートユーザは、O
The telecommuter scenario is one of the more common remote access scenarios. The convenience and wide availability of Internet access makes this an attractive option under many circumstances. Users may access the Internet from the comfort of their homes or hotel rooms, and using this Internet connection, access the resources of a target network. In some cases, dialup accounts are used to provide the initial Internet access, while in others some type of "always-on" connection such as a DSL or CATV modem is used.
在宅勤務のシナリオは、より一般的なリモートアクセスシナリオの一つです。インターネットへのアクセスの利便性と広い可用性は、この多くの状況下では魅力的な選択肢になります。ユーザーは自分の家やホテルの部屋の快適さからインターネットにアクセスし、このインターネット接続を使用して、ターゲット・ネットワークのリソースにアクセスすることがあります。いくつかのケースでは、ダイヤルアップアカウントが他人にDSLやCATVモデムなどの「常時オン」の接続のいくつかのタイプが使用されている間、初期のインターネットアクセスを提供するために使用されています。
The dialup and always-on cases are very similar, with two significant differences: address assignment mechanism and connection duration. In most dialup cases, the IRAC's IP address is dynamically assigned as part of connection setup, and with fairly high likelihood, it is different each time the IRAC connects. DSL/CATV users, on the other hand, often have static IP addresses assigned to them, although dynamic assignment is on the increase. As for connection duration, dialup remote access connections are typically short-lived, while always-on connections may maintain remote access connections for significantly longer periods of time.
アドレス割り当てメカニズムと接続時間：ダイヤルアップおよび常時オンの場合には、二つの重要な相違点で、非常によく似ています。ほとんどのダイヤルアップの場合には、IRACのIPアドレスが動的に接続セットアップの一部として割り当てられており、かなり高い確率で、それはIRACが接続するたびに異なります。動的な割り当てが増加しているものの、DSL / CATVユーザーは、他の一方で、多くの場合、それらに割り当てられた静的IPアドレスを持っています。常時オン接続は、時間のかなり長い期間のためのリモートアクセス接続を維持することができる一方で、接続時間については、ダイヤルアップリモートアクセス接続は、一般的に短命です。
The general configuration in either case looks like this:
いずれの場合も、一般的な構成は次のようになります。
corporate net
| +----+
+-----+ +-----+ /---/ Internet +---+ |--| |
|IRAC |---|modem|------|ISP|==========|SGW|--| +----+
+-----+ +-----+ /---/ +---+ |
|
An alternative to this configuration entails placing a security gateway between the user's system and the modem, in which case this added SGW becomes the IRAC. This is currently most common in cases where DSL/CATV connections are used.
この構成の代わりに、これはSGWがIRACなる添加した場合に、ユーザのシステムとモデムとの間のセキュリティゲートウェイを配置することを伴います。これは、DSL / CATV接続が使用されている場合には、現在最も一般的です。
The authentication requirements of this scenario depend in part upon the general security requirements of the network to which access is to be provided. Assuming that the corporate SGW is physically secure, machine authentication for the SGW is sufficient. If this assumption regarding physical security is incorrect, it is not clear that stronger authentication for the SGW could be guaranteed, and derivation of an effective mechanism for that case is beyond the scope of this document.
このシナリオの認証要件を提供するアクセスするためにネットワークの一般的なセキュリティ要件に部分的に依存しています。企業のSGWは、物理的に安全であると仮定すると、SGWのためのマシン認証で十分です。物理的なセキュリティに関するこの仮定が間違っている場合、SGWのための強力な認証を保証することができることは明らかではないが、その場合のための効果的なメカニズムの導出は、このドキュメントの範囲を超えています。
For the IRAC, there are numerous threats to the integrity of the user authentication process. Due to the open nature of common consumer operating systems, some of these threats are quite difficult to protect against. For example, it is very difficult to assert, with any level of certainty, that a single user system which permits the downloading and running of arbitrary applications from the Internet has not been compromised, and that a covert application is not monitoring and interacting with the user's data at any point in time.
IRACのために、ユーザ認証処理の整合性に数多くの脅威があります。一般的な消費者のオペレーティング・システムのオープンな性質のため、これらの脅威のいくつかはから保護するのは非常に困難です。例えば、インターネットから任意のアプリケーションのダウンロードと実行を可能にするシングルユーザシステムが侵害されていないことを、確実性の任意のレベルでアサートすることは非常に困難であり、秘密アプリケーションは、監視とと相互作用していないことを任意の時点で、ユーザーのデータ。
However, there are 2 general threats we might realistically hope to somehow mitigate with appropriate authentication mechanisms if we can assume that the system has not been compromised in this manner. First, there is the possibility that a secure connection is established for a particular user, but that someone other than the intended user is currently using that connection. Second, there is the possibility that the user's credential (password, hardware token, etc.) has been somehow compromised, and is being used by someone other than the authorized user to gain access.
しかし、我々はシステムがこの方法で損なわれていないと仮定することができた場合、我々は現実的に何らかの形で適切な認証メカニズムを軽減したいと考えていかもしれない2つの一般的な脅威があります。まず、安全な接続が特定のユーザーのために確立されてしまう可能性があるが、意図されたユーザ以外の誰かが、現在、その接続を使用していること。第二に、ユーザーの資格情報（パスワード、ハードウェアトークンなど）が何らかの形で危険にさらされている、とのアクセスを得るために許可されたユーザ以外の誰かによって使用されている可能性があります。
Mitigation of the first threat, the possibility that someone other than the authorized user is currently using the connection, requires periodic renewal of user authentication. It should be clear that machine authentication will not suffice in this case, and that requiring periodic re-entry of an unchanging user password (which may be written on a post-it note which is stuck to the user's monitor) will have limited effectiveness. Convincing verification of the continued presence of the authorized user will, in many cases, require periodic application of a time-variant credential.
最初の脅威の軽減は、許可されたユーザ以外の誰かが、現在の接続を使用している可能性は、ユーザー認証の定期的な更新が必要となります。マシン認証は、この場合には十分で、かつ（ユーザのモニタに貼り付けられる付箋に書かれたこともある）不変のユーザーパスワードの定期的な再入力を要求することは限られた有効性を持つことはないだろうことは明らかです。許可されたユーザの継続的な存在の説得力の検証は、多くの場合、時変資格の定期的なアプリケーションが必要になります。
Mitigation of the second threat, credential compromise, is difficult, and depends upon a number of factors. If the IRAC system is running a highly secure operating system, then a time-variant credential may again offer some value. A static password is clearly deficient in this scenario, since it may be subject to either online or offline guessing, and eventually compromised - which is the threat we are attempting to mitigate. However, if the IRAC operating system is not hardened, the use of a time-variant credential is only effective if simultaneous access from more than one location is forbidden, and if the credential generation mechanism is not easily compromised.
第二の脅威、資格妥協の緩和は、困難であり、多くの要因に依存します。 IRACシステムは非常に安全なオペレーティングシステムを実行している場合、その時変資格は再びいくつかの値を提供することがあります。静的なパスワードは、それが推測オンラインまたはオフラインのどちらかを受ける可能性があるため、このシナリオでは明らかに不足している、そして最終的に妥協 - 私たちは軽減しようとしている脅威があります。 IRACオペレーティングシステムが硬化されていない場合は、複数の位置からの同時アクセスが禁止されている場合は、時変クレデンシャルの使用のみ有効であり、資格発生機構を容易に損なわれていない場合。
A second approach to the credential compromise problem entails using a PKI-based credential which is stored within a secure container of some sort, and which requires some user interaction prior to operation (e.g., a smartcard). If such a credential requires periodic user interaction to continue operating (e.g., pin re-entry), this may help to limit the access of an unauthorized user who happens upon a connected but unattended systems. However, choosing an acceptable refresh interval is a difficult problem, and if the pin is not time-variant, this provides limited additional assurance.
資格妥協問題に対する第2のアプローチは、ある種のセキュアコンテナ内に格納され、前の動作にいくつかのユーザ対話（例えば、スマートカード）が必要とされるPKIベースの信用証明書を使用することを伴います。このようなクレデンシャルは、オペレーティング（例えば、ピン再進入）を継続する周期的なユーザ対話を必要とする場合、これが接続されているが、無人システムの際に発生し、不正なユーザのアクセスを制限するのを助けることができます。しかし、許容可能なリフレッシュ間隔を選択することが困難な問題であり、かつピンが時変ではない場合、これは限られた追加の保証を提供します。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
要約すると、次はIRASとIRACのための認証要件は以下のとおりです。
IRAS
----
o machine authentication MUST be provided.
Oマシン認証を提供しなければなりません。
IRAC
----
o support for user authentication SHOULD be provided o support for either user or machine authentication MUST be provided o support for user authentication MUST be provided if protection from unauthorized connection use is desired. o if user authentication is provided for short-lived dialup connections, periodic renewal MAY occur o if user authentication is provided for always-on connections, periodic renewal SHOULD occur
ユーザまたはマシン認証のいずれかのサポートがユーザ認証のためのサポートoを提供しなければなりません〇〇ユーザ認証のためのサポートが提供されるべき不正な接続の使用からの保護が所望される場合に提供されなければなりません。ユーザー認証が短命ダイアルアップ接続のために提供されている場合、ユーザー認証は常時オン接続、定期的な更新が発生した場合のために提供されている場合、O、定期的な更新は、Oを発生するかもしれません
There are 2 possibilities for device configuration in the telecommuter scenario: either access to the target network is permitted for the native ISP-assigned address of the telecommuter's system, or the telecommuter's system is assigned a virtual address from within the target address space. In the first case, there are no device configuration requirements which are not already satisfied by the ISP. However, this case is the exception, rather than the rule.
ターゲットネットワークへのアクセスのいずれかが、在宅勤務者のシステムのネイティブISPによって割り当てられたアドレスに対して許可されている、または在宅勤務者のシステムは、ターゲット・アドレス空間内の仮想アドレスが割り当てられている：在宅勤務者シナリオにおけるデバイス構成のための2つの可能性があります。最初のケースでは、既にISPによって満たされていないいかなるデバイス構成要件は存在しません。ただし、この場合ではなく、ルールよりも、例外です。
The second case is far more common, due to the numerous benefits derived by providing the IRAC with a virtual presence on the target network. For example, the virtual presence allows the client to receive subnet broadcasts, which permits it to use WINS on the target network. In addition, if the IRAC tunnels all traffic to the target network, then the target policy can be applied to Internet traffic to/from the IRAC.
後者の場合は、ターゲット・ネットワーク上の仮想存在とIRACを提供することにより、得られる多くの利点のためにはるかに一般的です。例えば、仮想の存在は、それがターゲットネットワーク上のWINSを使用することを可能にする、クライアントがサブネット放送を受信することができます。 IRACがターゲットネットワークへのすべてのトラフィックをトンネリングした場合、また、その後、ターゲット・ポリシーは、へ/ IRACからのインターネットトラフィックに適用することができます。
In this case, the IRAC requires, at minimum, assignment of an IP address from the target network. Typically, the IRAC requires anywhere from several more to many more elements of configuration information, depending upon the corporate network's level of topological complexity. For a fairly complete list, see section 2.2.
この場合、IRACは、最低でも、ターゲットネットワークからIPアドレスの割り当てを必要とします。一般的に、IRACは、トポロジカル複雑さの社内ネットワークのレベルに応じて、任意の場所をよりいくつかから構成情報のより多くの要素を必要とします。かなり完全なリストについては、セクション2.2を参照してください。
To summarize, the following are the device configuration requirements for the IRAC:
要約すると、次はIRACのための装置の構成要件は、次のとおりです。
o support for a virtual IP (VIP) address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be provided o support for address assignment based upon authenticated identity MAY be provided o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.
VIPサポートが提供されている場合、認証場合に認証されたIDに基づいて、アドレス割り当てのためのサポートは、O設けられていてもよいO、セクション上記2.2に記載されているすべてのデバイス関連パラメータのサポートが提供されるべきであるoをO仮想IPのサポート（VIP）アドレスが提供されてもよいですアドレスの割り当ては、[ARCH]に記載されているようなアイデンティティベースの動的ポリシー更新機構をサポートしなければならない、サポートされていません。
In terms of IRAC policy configuration, the most important issue pertains to whether the IRAC has direct Internet access enabled (for browsing, etc.) while a connection to the target network exists. This is important since the fact that the IRAC has access to sites on the Internet implies that those sites have some level of reciprocal access to the IRAC. It may be desirable to completely eliminate this type of access while a tunnel is active.
IRACのポリシー設定の面では、最も重要な問題は、IRACがターゲットネットワークへの接続が存在する間（ブラウジングなど）が有効になってインターネットに直接アクセスしているかどうかに関係します。 IRACは、インターネット上のサイトへのアクセスを持っているという事実は、これらのサイトは、IRACに相互のアクセスのいくつかのレベルを持っていることを意味するので、これは重要です。トンネルがアクティブである間、完全にこのタイプのアクセスを排除することが望ましい場合があります。
Alternatively, the risks may be mitigated somewhat by forcing all Internet-bound packets leaving the IRAC to first traverse the tunnel to the target network, where they may be subjected to target network policy. A second approach which carries a bit less overhead entails modifying the IRAC's policy configuration to reflect that of the target network during the time the IRAC is connected. In this case, traffic is not forced to loop through the target site prior to exiting or entering the IRAC. This requires some sort of policy download (or modification) capability as part of the SA establishment process. A third approach is to provide a configuration variable for the IRAC which permits specification of "tunnel-all", or "block all traffic not destined for the target network while the SA is up".
代替的に、リスクは最初は、ネットワークポリシーを標的とするために施されていてもよいターゲットネットワークにトンネルを横断するIRACを残してすべてのインターネットに結合パケットを強制することにより、幾分緩和されてもよいです。ビットより少ないオーバーヘッドを搬送する第2のアプローチは、IRACが接続されている時間中に、ターゲットネットワークのそれを反映するようにIRACのポリシー設定を変更することを伴います。この場合、トラフィックは、前出たりIRACに入る標的部位をループに強制されていません。これは、SA確立プロセスの一部として、ポリシーのダウンロード（または変更）機能のいくつかの並べ替えを必要とします。第三のアプローチは、「トンネル全て」の指定を可能にする、または「SAが起動している間、ターゲットネットワークに向けられていないすべてのトラフィックをブロック」IRACのためのコンフィギュレーション変数を提供することです。
In terms of IRAS configuration, it may be necessary to dynamically update the security policy database (SPD) when the remote user connects. This is because transit selectors must be based upon network address parameters, but these cannot be known a priori in the remote access case. As is noted above, this may be avoided by provision of a mechanism which permits address assignment based upon authenticated identity.
IRASの構成の点では、リモートユーザが接続するときに動的にセキュリティポリシーデータベース（SPD）を更新する必要があるかもしれません。トランジットセレクタは、ネットワークアドレスパラメータに基づいてしなければならないからであるが、これらは、リモートアクセスの場合には事前に知られてすることはできません。上述されたように、これは、認証されたアイデンティティに基づいて、アドレスの割り当てを可能にする機構を設けることによって回避することができます。
To summarize, the following are the policy configuration requirements for the IRAS and IRAC:
要約すると、次はIRASとIRACのためのポリシー構成要件は次のとおりです。
IRAS
----
o dynamic policy update mechanism based upon identity and assigned address MAY be supported.
Oアイデンティティと割り当てられたアドレスに基づいて動的なポリシーの更新メカニズムをサポートすることができます。
o if address assignment-based policy update mechanism is not supported, address assignment based upon authenticated identity SHOULD be supported.
アドレス割り当てベースのポリシー更新メカニズムがサポートされていない場合は、O、認証された識別情報に基づいてアドレスの割り当てがサポートされる必要があります。
IRAC
----
o IRAC SHOULD provide ability to configure for "tunnel-all" and/or "block-all" for traffic not destined for the remote network to which IPsec remote access is being provided.
O IRACは、IPsecリモートアクセスが提供されたリモートネットワーク宛でないトラフィックのための「トンネル全て」及び/又は「ブロック全て」に対して設定する能力を提供すべきです。
o support for dynamic IRAS update of IRAC policy MAY be provided.
O IRAC方針のダイナミックIRASアップデートのサポートが提供されてもよいです。
For telecommuter sessions, session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
在宅勤務のセッションでは、セッション開始/終了時刻を収集する必要があります。セッション終了時の信頼性の導出は、IRACが何らかの形で定期的に接続がアクティブのままであることを意味していることが必要です。これは、IRASは、接続を介しIRACからデータを受信した場合に暗示されているが、何もデータがある期間送信されない場合には、シグナル伝達機構がIRAC接続が使用中のままであることを指示することにより、必要とされます。
If the address assigned by the ISP to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
IRACシステムにISPによって割り当てられたアドレスがグローバルにルーティング可能であり、そしてIRACとIRASの間に中間デバイスがデータ・ストリームにNAPT操作を実行しない場合、追加の要件は存在しません。 NAPT操作をデータストリーム上で実行される場合、いくつかの機構は、IPsec実装に透明これらの変更をレンダリングするために提供されなければなりません。
Extranets are becoming increasingly common, especially as IPsec becomes more widely deployed. In this scenario, a user from one corporation uses a local corporate system to access resources on another corporation's network. Typically, these corporations are cooperating on some level, but not to the degree that unbridled access between the two networks would be acceptable. Hence, this scenario is characterized by limited access. The general topological appearance is similar to this:
エクストラネットは、IPsecがより広く展開となり、特にとして、ますます一般的になってきています。このシナリオでは、1つの企業からのユーザーが、別の会社のネットワーク上のリソースにアクセスするために地元企業のシステムを使用しています。一般的に、これらの企業はいくつかのレベルではなく、2つのネットワーク間の奔放なアクセスを許容できるような程度に協力しています。したがって、このシナリオは、制限されたアクセスすることを特徴とします。一般的なトポロジカルな外観は、次のようになります。
CORP A CORP B
| |
+----+ | | +-----+
|USER|---| |--| S1 |
+----+ | +------++ ++------+ | +-----+
|---|SGW/FW||===Internet===||SGW/FW|---|
| +------++ ++------+ | +-----+
| SGW-A SGW-B |--| S2 |
| | +-----+
This is purposely simplified in order to illustrate some basic characteristics without getting bogged down in details. At the edge of each network is a combination security gateway and firewall device. These are labeled "SGW-A" and "SGW-B". In this diagram, corporation B wishes to provide a user from corporation A with access to servers S1 and/or S2. This may be accomplished in one of several different ways:
これは、意図的に詳細に行き詰まる取得せずに、いくつかの基本的な特性を説明するために簡略化されています。各ネットワークのエッジで組み合わせセキュリティゲートウェイおよびファイアウォールデバイスです。これらは、 "SGW-A" と "SGW-B" ラベル付けされています。この図では、法人Bは、サーバS1および/またはS2へのアクセスを企業Aからユーザに提供することを望みます。これは、いくつかの異なる方法のいずれかで達成することができます。
1) an end-to-end SA is formed from USER to S1 or S2
1）エンドツーエンドのSAは、ユーザからS1またはS2に形成されています。
2) a tunnel-mode SA is formed between SGW-A and SGW-B which only permits traffic between S1/S2 and USER.
2）トンネルモードSAは、SGW-AのみS1 / S2とユーザとの間のトラフィックを許可するSGW-Bとの間に形成されています。
3) a tunnel-mode SA is formed between USER and SGW-B which only permits traffic between S1/S2 and USER.
3）トンネルモードSAは、ユーザのみS1 / S2とユーザとの間のトラフィックを許可するSGW-Bとの間に形成されています。
These various cases are individually discussed with respect to each requirements category below.
これらの様々な例は、個別に以下の各要件のカテゴリに関して議論されています。
For the corporate extranet scenario, the authentication requirements vary slightly depending upon the manner in which the connection is accomplished. If only a particular user is permitted to access S1/S2, then user-level authentication is required. If connection types (1) or (3) are used, this may be accomplished in the same manner as it would be for a telecommuter. If connection type (2) is used, one of two things must occur: either SGW-A must provide some local mechanism for authenticating USER and SGW-B must trust this mechanism, or SGW-B must have some mechanism for authenticating USER independently of SGW-A.
企業エクストラネットのシナリオでは、認証要件は、接続が達成される方法に依存してわずかに変化します。のみ、特定のユーザが、S1 / S2へのアクセスが許可されている場合、ユーザ・レベルの認証が必要とされます。接続タイプ（1）または（3）が使用される場合は、在宅勤務者のためになるように、これは同様に行うことができます。接続タイプ（2）が使用される場合、2つのうちの1つが発生しなければならない：SGW-Aいずれかから独立してユーザを認証するためのいくつかのメカニズムを持っている必要があり、このメカニズム、またはSGW-Bを信頼しなければならないUSERとSGW-Bを認証するためにいくつかの局所的なメカニズムを提供しなければなりませんSGW-A。
If access is permitted for anyone within corporation A, then machine authentication will suffice. However, this is highly unlikely. A slightly more likely situation might be one in which access is permitted to anyone within a particular organizational unit in corporation A. This case is very similar the single user access case discussed above, and essentially has the same requirements in terms of the mechanism required for SGW-A, although machine authentication might suffice if the organizational unit which is permitted access has a sufficient level of physical security. Again, this requires that corporation B trust corporation A in this regard.
アクセスが企業A内の誰のために許可されている場合は、マシン認証で十分です。しかし、これは非常に低いです。わずかに可能性が高い状況は、この場合は、上述の単一のユーザアクセスの場合非常に類似しており、本質的に必要な機構の点で同じ要件を有するアクセスが企業Aに特定の組織単位内の誰にも許可されたものであるかもしれませんアクセスが許可されている組織単位は、物理的なセキュリティの十分なレベルを有する場合SGW-Aは、マシン認証で十分かもしれないが。繰り返しますが、これはこの点でその法人B信託法人Aが必要です。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
要約すると、次はIRASとIRACのための認証要件は以下のとおりです。
IRAS
----
o machine authentication MUST be provided.
Oマシン認証を提供しなければなりません。
IRAC
----
o support for either user or machine authentication MUST be provided o support for a combination of user and machine authentication SHOULD be provided o if user authentication is used, periodic renewal SHOULD occur
Oユーザまたはマシン認証のいずれかのためのサポートは、ユーザとマシン認証の組み合わせのサポートoを設けなければならないユーザ認証が使用される場合、定期的な更新が発生したoを提供されるべきです
It is possible that corporation B would want to assign a virtual address to USER for the duration of the connection. The only way this could be accomplished would be if USER were a tunnel endpoint (e.g., in cases (1) and (3)). It is not clear what benefits, if any, this would offer.
法人Bは、接続の持続のためにユーザに仮想アドレスを割り当てるということも可能です。これにより、ユーザはトンネルエンドポイントであった場合であろう達成することができる唯一の方法（例えば、ケース（1）と（3））。提供するであろうどのような利点があれば、明確ではありません。
To summarize, the following are the device configuration requirements for the IRAC:
要約すると、次はIRACのための装置の構成要件は、次のとおりです。
o support for a virtual address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be supported
仮想アドレスのOサポートは、VIPサポートが提供されている場合oを設けてもよい、上記セクション2.2に記載されているすべてのデバイス関連パラメータのサポートはサポートされてください
o support for address assignment based upon authenticated identity SHOULD be supported o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.
認証されたアドレスの割り当てがサポートされていない場合、[ARCH]に記載されているようなアイデンティティベースの動的ポリシー更新機構をサポートしなければならないoを認証アイデンティティに基づいて、アドレス割り当てのためのOサポートは、サポートされるべきです。
Any of the cases discussed above would present some static policy configuration requirements. Case (1) would require that SGW-A and SGW-B permit IPsec traffic to pass between USER and S1/S2. Case (3) would have similar requirements, except that the IPsec traffic would be between USER and SGW-B. Case (2) would require that the appropriate transit traffic be secured between USER and S1/S2.
上記の例はいずれも、いくつかの静的なポリシー構成要件を提示します。ケース（1）SGW-A及びSGW-B許可IPsecトラフィックがユーザとS1 / S2間を通過することを必要とするであろう。ケース（3）のIPsecトラフィックはUSERとSGW-Bの間になることを除いて、同様の要件を持っているでしょう。ケース（2）適切な通過トラフィックがユーザとS1 / S2の間に固定されることを必要とするであろう。
None of these cases require dynamic policy configuration.
これらの例はいずれも、動的なポリシー設定を必要としません。
For cases (1) and (3), session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
ケース（1）および（3）は、セッション開始/終了時刻を収集しなければなりません。セッション終了時の信頼性の導出は、IRACが何らかの形で定期的に接続がアクティブのままであることを意味していることが必要です。これは、IRASは、接続を介しIRACからデータを受信した場合に暗示されているが、何もデータがある期間送信されない場合には、シグナル伝達機構がIRAC接続が使用中のままであることを指示することにより、必要とされます。
For case (2), the type(s) of required auditing data would depend upon whether traffic from multiple users were aggregated within a single tunnel or not. If so, the notion of individual connection start/stop times would be lost. If such measures are desired, this requires that per-user tunnels be set up between SGW-A and SGW-B, and that some sort of timeout interval be used to cause tunnel teardown when traffic does not flow for some interval of time.
ケース（2）、必要な監査データのタイプ（複数可）は、複数のユーザからのトラフィックを単一のトンネル内か凝集したかどうかに依存するであろう。そう、個々の接続の概念が起動した場合/停止時間が失われてしまいます。このような対策が望まれる場合、これは、ユーザーごとのトンネルがSGW-A及びSGW-Bの間に設定されている必要があり、タイムアウト間隔のいくつかの並べ替えは、トラフィックが時間のいくつかの間隔で流れない場合、トンネルティアダウンを引き起こすために使用すること。
If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
IRACシステムにホストネットワークによって割り当てられたアドレスがグローバルにルーティング可能であり、そしてIRACとIRASの間に中間デバイスがデータ・ストリームにNAPT操作を行わない場合は、この点で追加の要件は存在しません。 NAPT操作をデータストリーム上で実行される場合、いくつかの機構は、IPsec実装に透明これらの変更をレンダリングするために提供されなければなりません。
If a firewall situated at the edge of the host network cannot be configured to pass protocols in the IPsec suite, then some mechanism must be provided which converts the data stream to one which the firewall may be configured to pass. If the firewall can be configured to pass IPsec protocols, then this must be accomplished prior to connection establishment.
ホストネットワークのエッジに位置するファイアウォールはIPsecのスイートでプロトコルを通過するように構成することができない場合、いくつかのメカニズムがファイアウォールを通過するように構成することができるいずれかのデータ・ストリームを変換が提供されなければなりません。ファイアウォールはIPsecプロトコルを通過するように構成することができる場合、これは、接続確立の前に達成されなければなりません。
The use of a laptop while visiting another corporation presents another increasingly common extranet scenario. In this case, a user works temporarily within another corporation, perhaps as part of a service agreement of some sort. The user brings along a CORP-A laptop which is assigned a CORP-B address either statically or dynamically, and the user wishes to securely access resources on CORP-A's network using this laptop. This scenario has the following appearance:
別の会社を訪問している間、ラップトップの使用は他のますます一般的なエクストラネットのシナリオを提示します。この場合、ユーザーは、おそらくある種のサービス契約の一部として、他の企業の中に一時的に動作します。ユーザは、静的または動的CORP-Bのアドレスが割り当てられているCORP、ラップトップに沿ってもたらし、ユーザが確実にこのラップトップを使用してCORP-Aのネットワーク上のリソースにアクセスすることを望みます。このシナリオでは、次のような外観を持っています：
CORP A CORP B
| |
+----+ | | +--------+
|POP |---| |--| CORP-A |
+----+ | +------++ ++------+ | | laptop |
|---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ |
+----+ | SGW-A SGW-B |
|FTP |---| |
+----+ | |
This is very similar to the telecommuter scenario, but it differs in several important ways. First, in this case there is often a SGW and/or firewall at the edge of CORP-B's site. Second, there may be a significantly increased risk that a long-lived connection could become accessible to someone other than the intended user.
これは、在宅勤務のシナリオと非常によく似ていますが、それはいくつかの重要な点で異なっています。まず、この場合にはCORP-BのサイトのエッジでSGWおよび/またはファイアウォールがあることが多いです。第二に、長寿命の接続が意図されたユーザ以外の誰かがアクセス可能になる可能性が大幅に増加したリスクがあるかもしれません。
In most cases, the only acceptable connections from CORP-A's perspective are between the laptop and either SGW-A or the CORP-A servers the laptop wishes to access. Most of the considerations applied to the telecommuter also apply here, and user-level authentication is required to provide assurance that the user who initiated the connection is still the active user. As an added precaution, a combination of user-level and machine-level authentication may be warranted in some cases. Further, in either case this authentication should be renewed frequently.
ほとんどの場合、CORP-Aの視点からのみ許容接続は、ラップトップとSGW-AのいずれかまたはラップトップがアクセスしたいCORP-Aのサーバー間です。また、在宅勤務者に適用される考慮事項のほとんどは、ここで適用され、ユーザーレベルの認証は、接続を開始したユーザーがまだアクティブユーザーであるという保証を提供するために必要とされます。追加予防措置として、ユーザレベルおよびマシンレベルの認証の組み合わせは、いくつかの場合には保証されてもよいです。さらに、いずれの場合もこの認証は頻繁に更新する必要があります。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
要約すると、次はIRASとIRACのための認証要件は以下のとおりです。
IRAS
----
o machine authentication MUST be provided.
Oマシン認証を提供しなければなりません。
IRAC
----
o support for machine authentication SHOULD be provided o support for user authentication MUST be provided o support for a combination of user and machine authentication SHOULD be provided o periodic renewal of user authentication MUST occur
Oマシン認証のためのサポートは、ユーザー認証のためのサポートoを提供すべきユーザ認証の周期的な更新が行われなければならないoをユーザとマシン認証の組み合わせのサポートが提供されるべきであるoを提供しなければなりません
The device configuration requirements in this scenario are the same as for the telecommuter, i.e., the laptop may be assigned a virtual presence on the corporate network, and if so, will require full infrastructure configuration.
このシナリオでは、デバイスの構成要件は、在宅勤務の場合と同じである、すなわち、ラップトップは、企業ネットワーク上の仮想プレゼンスを割り当ててもよく、その場合、完全なインフラストラクチャ構成を必要とするであろう。
To summarize, the following are the device configuration requirements for the IRAC:
要約すると、次はIRACのための装置の構成要件は、次のとおりです。
o support for a virtual address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be supported o support for address assignment based upon authenticated identity SHOULD be supported o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.
VIPサポートが提供されている場合、セクション上記2.2に記載されているすべてのデバイス関連パラメータのサポートが認証されたアイデンティティに基づいて、アドレス割り当てのためのサポートoをサポートするべきであるoをO仮想アドレスのためのサポートは、認証されたアドレスの割り当てがない場合はoをサポートするべきで提供されてもよいですサポートされている、[ARCH]に記載されているようなアイデンティティベースの動的ポリシー更新メカニズムをサポートしなければなりません。
The policy configuration requirements in this scenario differ from those of the telecommuter, in that the laptop cannot be assigned a policy which requires all traffic to be forwarded to CORP-A via the tunnel. This is due to the fact that the laptop has a CORP-B address, and as such, may have traffic destined to CORP-B. If this traffic were tunneled to CORP-A, there might be no return path to CORP-B except via the laptop. On the other hand, Internet-bound traffic could be subjected to this restriction if desired, and/or all traffic other than that between CORP-A and the laptop could be blocked for the duration of the connection.
このシナリオでは、ポリシー構成要件は、ラップトップは、トンネルを介してCORP-Aに転送されるすべてのトラフィックを必要とするポリシーを割り当てることができないことで、在宅勤務者のものとは異なります。これは、ラップトップはCORP-Bのアドレスを持っているという事実によるものであり、そのようなものとして、CORP-B宛てのトラフィックを有することができます。このトラフィックがCORP-Aにトンネリングされた場合は、ノートパソコン経由以外CORP-Bへのリターンパスがないかもしれません。所望であれば、一方、インターネットに結合したトラフィックは、この制限に供することができ、及び/又はCORP-Aとラップトップとの間のそれ以外のすべてのトラフィックは、接続の持続時間にわたって遮断することができます。
IRAC
----
o support for IRAS update of IRAC policy MAY be provided.
O IRAC方針のIRASアップデートのサポートが提供されてもよいです。
o if IRAS update of IRAC policy is not supported, IRAC MAY support IRAS directives to "block-all" for non-tunneled traffic.
IRAC方針のIRASの更新がサポートされていない場合は、O、IRACは「ブロックすべて」非トンネルトラフィックのためにIRASディレクティブをサポートするかもしれません。
o IRAC SHOULD provide ability to configure for "tunnel-all" and/or "block-all" for traffic not destined for the remote network to which IPsec remote access is being provided.
O IRACは、IPsecリモートアクセスが提供されたリモートネットワーク宛でないトラフィックのための「トンネル全て」及び/又は「ブロック全て」に対して設定する能力を提供すべきです。
The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
このシナリオでは、監査要件は、在宅勤務のシナリオの場合と同じです。セッション開始/終了時刻を収集する必要があります。セッション終了時の信頼性の導出は、IRACが何らかの形で定期的に接続がアクティブのままであることを意味していることが必要です。これは、IRASは、接続を介しIRACからデータを受信した場合に暗示されているが、何もデータがある期間送信されない場合には、シグナル伝達機構がIRAC接続が使用中のままであることを指示することにより、必要とされます。
If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
IRACシステムにホストネットワークによって割り当てられたアドレスがグローバルにルーティング可能であり、そしてIRACとIRASの間に中間デバイスがデータ・ストリームにNAPT操作を行わない場合は、この点で追加の要件は存在しません。 NAPT操作をデータストリーム上で実行される場合、いくつかの機構は、IPsec実装に透明これらの変更をレンダリングするために提供されなければなりません。
If a firewall situated at the edge of the host network cannot be configured to pass protocols in the IPsec suite, then some mechanism must be provided which converts the data stream to one which the firewall may be configured to pass. If the firewall can be configured to pass IPsec protocols, then this must be accomplished prior to connection establishment.
ホストネットワークのエッジに位置するファイアウォールはIPsecのスイートでプロトコルを通過するように構成することができない場合、いくつかのメカニズムがファイアウォールを通過するように構成することができるいずれかのデータ・ストリームを変換が提供されなければなりません。ファイアウォールはIPsecプロトコルを通過するように構成することができる場合、これは、接続確立の前に達成されなければなりません。
This is very similar to the extranet laptop scenario discussed above, except that a higher degree of trust for CORP-B is required by CORP-A. This scenario has the following appearance:
これは、CORP-Bの信頼度が高いがCORP-Aによって必要とされることを除いて、上述したエクストラネットラップトップシナリオに非常に類似しています。このシナリオでは、次のような外観を持っています：
CORP A CORP B
| |
+----+ | | +--------+
|POP |---| |--| CORP-B |
+----+ | +------++ ++------+ | |desktop |
|---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ |
+----+ | SGW-A SGW-B |
|FTP |---| |
+----+ | |
The authentication requirements for the desktop extranet scenario are very similar to those of the extranet laptop scenario discussed above. The primary difference lies in the authentication type which may be used, i.e., in the laptop case, CORP-A can derive some assurance that the connection is coming from one of CORP-A's systems if a securely stored machine credential is stored on and used by on the laptop. In the desktop case this is not possible, since CORP-A does not own the IRAC system.
デスクトップエクストラネットのシナリオのための認証要件は、上述のエクストラネットラップトップシナリオのものと非常に似ています。安全に格納されたマシン証明書が上に格納して使用する場合の主な違いは、ノートパソコンの場合には、CORP-Aは、接続がCORP-Aのシステムのいずれかから来ているいくつかの保証を得ることができる、すなわち、使用することができる認証の種類、ですラップトップ上によります。 CORP-AはIRACシステムを所有していないので、デスクトップの場合では、これは、不可能です。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
要約すると、次はIRASとIRACのための認証要件は以下のとおりです。
IRAS
----
o machine authentication MUST be provided.
Oマシン認証を提供しなければなりません。
IRAC
----
o support for machine authentication MAY be provided o support for user authentication MUST be provided o support for a combination of user and machine authentication MAY be provided o periodic renewal of user authentication MUST occur
ユーザ認証の周期的な更新が行われなければならないoをユーザとマシン認証の組み合わせのサポートが提供され得るoをユーザ認証のためのサポートが提供されなければならない〇〇マシン認証のためのサポートが提供されてもよいです
The device configuration requirements in this scenario are the same as for the laptop extranet scenario, i.e., the desktop system may be assigned a virtual presence on the corporate network, and if so, will require full infrastructure configuration. However, this seems less likely than in the laptop scenario, given CORP-A's lack of control over the software configuration of CORP-B's desktop system.
このシナリオでは、デバイスの構成要件、すなわち、デスクトップシステムは、企業ネットワーク上の仮想プレゼンスを割り当てることができるラップトップエクストラネットのシナリオの場合と同じであり、もしそうであれば、完全なインフラストラクチャ構成を必要とするであろう。しかし、これはCORP-Bのデスクトップシステムのソフトウェア構成を制御のCORP-Aの不足を考えると、ラップトップのシナリオよりも少ないようです。
The policy configuration requirements are quite similar to those of the extranet laptop, except that in this scenario there is even less control over CORP-B's desktop than there would be over the laptop. This means it may not be possible to restrict traffic in any way at the desktop system.
それは、このシナリオでは、ラップトップの上に存在することになるよりも、CORP-Bのデスクトップの上にさらに少ない制御がある以外ポリシーの構成要件は、エクストラネットラップトップのものと非常によく似ています。デスクトップシステムでどのような方法でトラフィックを制限することは可能ではないかもしれないことを意味します。
The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
このシナリオでは、監査要件は、在宅勤務のシナリオの場合と同じです。セッション開始/終了時刻を収集する必要があります。セッション終了時の信頼性の導出は、IRACが何らかの形で定期的に接続がアクティブのままであることを意味していることが必要です。これは、IRASは、接続を介しIRACからデータを受信した場合に暗示されているが、何もデータがある期間送信されない場合には、シグナル伝達機構がIRAC接続が使用中のままであることを指示することにより、必要とされます。
If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
IRACシステムにホストネットワークによって割り当てられたアドレスがグローバルにルーティング可能であり、そしてIRACとIRASの間に中間デバイスがデータ・ストリームにNAPT操作を行わない場合は、この点で追加の要件は存在しません。 NAPT操作をデータストリーム上で実行される場合、いくつかの機構は、IPsec実装に透明これらの変更をレンダリングするために提供されなければなりません。
If a firewall situated at the edge of the host network cannot be configured to pass protocols in the IPsec suite, then some mechanism must be provided which converts the data stream to one which the firewall may be configured to pass. If the firewall can be configured to pass IPsec protocols, then this must be accomplished prior to connection establishment.
ホストネットワークのエッジに位置するファイアウォールはIPsecのスイートでプロトコルを通過するように構成することができない場合、いくつかのメカニズムがファイアウォールを通過するように構成することができるいずれかのデータ・ストリームを変換が提供されなければなりません。ファイアウォールはIPsecプロトコルを通過するように構成することができる場合、これは、接続確立の前に達成されなければなりません。
This scenario entails a traveling user connecting to the target network using a public system owned by someone else. A commonly cited example is an airport kiosk. This looks very similar to the extranet desktop scenario, except that in the extranet scenario, CORP-A might have a trust relationship with CORP-B, whereas in this scenario, CORP-A may not trust a publicly accessible system. Note that a trust relationship between CORP-A and the owner of the public system may exist, but in many cases will not.
このシナリオでは、他の誰かが所有する公共システムを使用してターゲットネットワークに接続する移動ユーザーを伴います。一般的に引用された例では、空港のキオスクです。これは、このシナリオでは、CORP-Aは、公的にアクセス可能なシステムを信頼しない場合があるエクストラネットのシナリオでは、CORP-Aは、CORP-Bとの信頼関係を持っている可能性がある以外、エクストラネットデスクトップのシナリオと非常によく似ています。 CORP-Aおよび公共システムの所有者との間に信頼関係が存在する可能性がありますが、多くの場合ではないでしょう。
There are two variations to this scenario. In the first, no trust relationship exists between the target network and the borrowed system. In the second, some trust relationship does exist. In the case where no trust relationship exists, machine authentication is out of the question, as it is meaningless in this context. Further, since such a system could easily capture a passphrase, use of a static passphrase from such a system would seem to be ill-advised.
このシナリオには2つのバリエーションがあります。第一に、何の信頼関係は、ターゲット・ネットワークと借りシステムとの間に存在していません。第二に、いくつかの信頼関係が存在しません。それは、この文脈では無意味であるように信頼関係が存在しない場合は、マシン認証は、問題外です。このようなシステムは簡単にパスフレーズをキャプチャすることができので、このようなシステムからの静的なパスフレーズを使用することは、無分別であるように見えるでしょう。
If a one-time passphrase were used, this would mitigate the risk of passphrase capture by the public system. On the other hand, if it is acknowledged that such capture is a real threat (i.e., the system itself is malicious), then it must also be recognized that any data transmitted and received via the resulting session would not be confidential or reliable with respect to this malicious system, and that the system could not be trusted to have actually disconnected when the user walks away. This suggests that accessing non-trivial information from such a system would be imprudent.
ワンタイムパスフレーズを使用した場合、これは公共のシステムでパスフレーズキャプチャのリスクを軽減します。それは、このような捕捉が現実の脅威（すなわち、システム自体が悪意のあるである）であることを認めている一方、また、結果としてセッションを介して送信し、受信したデータはすべてに関して、機密情報や信頼性ではないことを認識しなければなりませんこの悪質なシステムに、システムは、ユーザが立ち去るときに実際に切断されているし、信頼することができなかったという。これは、このようなシステムからの非自明な情報にアクセスすることは軽率であろうことを示唆しています。
Another possible user authentication option would be a smartcard. However, many smartcards require a pin or passphrase to "unlock" them, which requires some level of trust in the kiosk to not record the pin. Hence, this approach suffers from drawbacks similar to those of the static passphrase in this regard. The primary difference would be that the pin/passphrase could not be used alone for access in the smartcard case.
別の可能なユーザ認証オプションは、スマートカードになります。しかし、多くのスマートカードは、ピンを記録しないように、キオスクでの信頼のいくつかのレベルが必要でピンまたはそれらを「アンロック」するためのパスフレーズを、必要としています。従って、このアプローチはこの点で静的パスフレーズと同様の欠点があります。主な違いは、ピン/パスフレーズは、スマートカード場合のアクセスのために単独で使用することができなかったということでしょう。
In cases where a trust relationship with the owner of the public system exists, the trust level would modulate the risk levels discussed above. For example, if a sufficient level of trust for the system owner exists, use of a static passphrase might present no more risk than if this were permitted from a system owned by the accessed target. However, the primary benefit of such a trust relationship would be derived from the ability to authenticate the machine from which the user is attempting access. For example, a security policy requiring that remote access only be permitted with combined user/machine authentication might be effected, with further control regarding which machines were allowed.
公共システムの所有者との信頼関係が存在する場合には、信頼レベルは、上述のリスクレベルを調節することになります。システム所有者のための信頼の十分なレベルが存在する場合、例えば、静的パスフレーズの使用は、これは、アクセス対象が所有するシステムから許可された場合よりもより多くのリスクを提示する可能性があります。しかし、そのような信頼関係の主な利点は、ユーザーがアクセスしようとしているからマシンを認証する機能から派生されるだろう。例えば、セキュリティポリシーがリモートアクセスのみ組み合わさユーザ/マシン認証と許可されていることが必要マシンはせに関するさらなる制御で、達成されるかもしれません。
An additional issue to be dealt with in either case pertains to verification of the identity of the IRAS. If the IRAC were to be misdirected somehow, a man in the middle attack could be effected, with the obtained password being then used for malicious access to the true IRAS. Note that even a one-time password mechanism offers little protection in this case. In order to avert such an attack, the IRAC must possess some certifiable or secret knowledge of the IRAS prior to attempting to connect. Note that in the case where no trust relationship exists, this is not possible.
いずれの場合で扱われる追加の問題は、IRASの身元の確認に関係します。 IRACは何とか誤って誘導されるようにした場合は、中間者攻撃は、真のIRASへの悪質なアクセスのために使用されている取得したパスワードで、行うことができます。でも、ワンタイムパスワードメカニズムが、この場合には少し保護を提供することに注意してください。このような攻撃を回避するためには、IRACは、接続しようとする前に、IRASのいくつかの認定や秘密の知識を持っている必要があります。何の信頼関係が存在しない場合には、これが不可能であることに注意してください。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
要約すると、次はIRASとIRACのための認証要件は以下のとおりです。
IRAS
----
o machine authentication MUST be provided.
Oマシン認証を提供しなければなりません。
IRAC
----
o in cases where no trust relationship exists between the accessed network and the system owner, sensitive data SHOULD NOT be transmitted in either direction. o in cases where a trust relationship exists between the accessed network and the system owner, machine authentication SHOULD be supported. o in cases where a trust relationship exists between the accessed network and the system owner, a static passphrase MAY be used in conjunction with machine-level authentication of the IRAC system. o frequent renewal of user authentication MUST occur
O全く信頼関係がアクセスネットワークおよびシステムの所有者との間に存在しない場合には、機密データがどちらの方向に送信されるべきではありません。 O信頼関係がアクセスネットワークおよびシステムの所有者との間に存在する場合には、マシン認証がサポートされるべきです。 O信頼関係がアクセスネットワークおよびシステムの所有者との間に存在する場合には、静的パスフレーズはIRACシステムの機械レベルの認証と併せて使用することができます。 Oユーザ認証の頻繁な更新が行われなければなりません
None.
無し。
None.
無し。
The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
このシナリオでは、監査要件は、在宅勤務のシナリオの場合と同じです。セッション開始/終了時刻を収集する必要があります。セッション終了時の信頼性の導出は、IRACが何らかの形で定期的に接続がアクティブのままであることを意味していることが必要です。これは、IRASは、接続を介しIRACからデータを受信した場合に暗示されているが、何もデータがある期間送信されない場合には、シグナル伝達機構がIRAC接続が使用中のままであることを指示することにより、必要とされます。
If the address of the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
IRACシステムのアドレスがグローバルにルーティング可能であり、そしてIRACとIRASの間に中間デバイスがデータ・ストリームにNAPT操作を行わない場合は、この点で追加の要件は存在しません。 NAPT操作をデータストリーム上で実行される場合、いくつかの機構は、IPsec実装に透明これらの変更をレンダリングするために提供されなければなりません。
As we examine the various remote access scenarios, a general set of common requirements emerge. Following is a summary:
私たちは、さまざまなリモートアクセスシナリオを調べると、共通の要件の一般的なセットが登場します。以下は要約です：
o Support for user authentication is required in almost all scenarios
Oユーザ認証のサポートは、ほぼすべてのシナリオで必要とされます
o Machine authentication for the IRAS is required in all scenarios
O IRASのマシン認証は、すべてのシナリオで必要とされます
o A mechanism for providing device configuration for the IRAC is required in most scenarios. Such a mechanism must be extensible.
O IRACのための装置構成を提供するための機構は、ほとんどのシナリオで必要とされます。そのような機構は、拡張可能でなければなりません。
o Machine authentication for IRAC is generally only useful when combined with user authentication. Combined user and machine authentication is useful in some scenarios.
ユーザー認証と組み合わせるとIRACのためのOのマシン認証は、一般的にのみ有効です。合わせてユーザとマシンの認証は、いくつかのシナリオで有用です。
o Dynamic IRAC policy configuration is useful in several scenarios.
OダイナミックIRACポリシー設定は、いくつかのシナリオで有用です。
o Most scenarios require auditing for session start/stop times.
Oほとんどのシナリオでは、セッション開始/停止時間の監査を必要としています。
o An intermediary traversal mechanism may be required in any of the scenarios.
O仲介トラバース機構は、シナリオのいずれかで必要とされ得ます。
The topic of this document is secure remote access. Security considerations are discussed throughout the document.
このドキュメントのトピックは、セキュアなリモートアクセスです。セキュリティの考慮事項は、文書全体で議論されています。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RADIUS] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RADIUS] Rigney、C.、ルーベンス、A.、シンプソン、W.とS. Willens、RFC 2865 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"、2000年6月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
The editors would like to acknowledge the many helpful comments of Sara Bitan, Steve Kent, Mark Townsley, Bernard Aboba, Mike Horn, and other members of the ipsra working group who have made helpful comments on this work.
編集者はサラBitan、スティーブ・ケント、マークTownsley、バーナードAboba、マイク・ホーン、そしてこの仕事に有益なコメントをしたIPSRAワーキンググループの他のメンバーの多くの有益なコメントを承認したいと思います。
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134 USA
スコット・ケリーAirespaceの110 NortechパークウェイサンノゼCA 95134 USA
Phone: +1 (408) 941-0500 EMail: scott@hyperthought.com
電話：+1（408）941-0500 Eメール：scott@hyperthought.com
Sankar Ramamoorthi Juniper Networks 1194 North Mathilda Ave Sunnyvale CA 94089-1206 USA
94089-1206彼女のハイブリッドRammurtiジュニパーネットワークスの1194北マチルダアベニューサニーベール
Phone: +1 (408) 936-2630 EMail: sankarr@juniper.net
電話：+1（408）936-2630 Eメール：sankarr@juniper.net
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。