[要約] RFC 3457は、IPsecリモートアクセスシナリオに関する要件を定義しています。その目的は、セキュアなリモートアクセス接続を提供するためのガイドラインを提供することです。
Network Working Group S. Kelly
Request for Comments: 3457 Airespace
Category: Informational S. Ramamoorthi
Juniper Networks
January 2003
Requirements for IPsec Remote Access Scenarios
IPSECリモートアクセスシナリオの要件
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.
Copyright（c）The Internet Society（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].
最近まで、リモートアクセスは通常、パブリックスイッチ付き電話ネットワーク（PSTN）を介してターゲットネットワークにアクセスするダイヤルアップユーザーによって特徴付けられており、ターゲットドメイン内のネットワークアクセスサーバー（NAS）でダイヤルアップ接続が終了しました。これを促進するプロトコルは通常PPPベースであり、アクセス制御、承認、および会計機能は通常、半径[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ベースのトンネルメカニズムが、ダイヤルユーザーがローカルISPアカウントに最初にアクセスできるようにすることにより、リモートアクセスを提供するために使用され、次にインターネットを介して追加のPPP接続をターゲットネットワークにトンネルします。ブロードバンドユーザーの場合、そのような接続はインターネット上で直接トンネルされています。これらのメカニズムはセキュリティ機能の観点からは不足していますが、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].
キーワードは、[3]で説明されているように解釈される場合、このドキュメントに表示される場合、キーワードは、[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.
RFCS 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.
o Security Gateway（SGW） - これは、ターゲットネットワークへのアクセスを提供するデバイスを指します。代替用語はIRAです。
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は別のコーポレートネットワーク内にあるか、Dialup、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など）のIDの確認を指します。リモートホスト構成とは、IRACシステムのデバイス構成パラメーターを指します。セキュリティポリシーの構成とは、セキュリティゲートウェイとリモートホストの両方のIPSECポリシー構成を指し、「アクセス制御と承認の構成」とも呼ばれる場合があります。監査とは、接続されたネットワークの全体的なセキュリティと完全性を維持するために必要な接続ステータス情報の生成と収集を指します。中間トラバーサルとは、仲介業者全体で安全なトラフィックを渡す能力を指し、その一部は何らかの方法でパケットを変更する可能性があります。このような仲介者には、NAPTおよびFIREWALLデバイスが含まれます。これらのさまざまなカテゴリを以下で詳しく説明します。
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.
2種類の認証は異なりますが、無関係ではありません。実際、データソース認証は、特定の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.
場合によっては、保存された資格情報へのアクセスが与えられる前に、ユーザーが特定の基準を満たす必要がある場合があります。そのような場合、そのような資格情報の使用によって提供されるユーザー認証のレベルを導き出すことはやや困難です。クレデンシャルを収容するシステムに十分に強力なアクセス制御が存在する場合、承認されたシステムユーザーと資格情報の間に強力な拘束力があるかもしれません。ただし、資格情報が提示された時点で、IRA自体にはそのような保証はありません。つまり、IRAは、特定のデバイス（資格情報が存在するデバイス）がアクセスが試みられているものであるというある程度の保証を持っているかもしれませんが、システム。IRAがユーザーIDに関する追加の保証を導き出すためには、何らかの種類の追加のユーザー資格が必要です。これについては、以下でさらに説明します。
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.
場合によっては、ユーザーは認証トークン（Presharedキー、秘密キー、パスフレーズなど）を所有している場合があり、認証が必要な場合はいつでもこれまたはこれの派生物を提供する場合があります。このトークンまたはデリバティブが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、IRA、およびシステム保護とセキュリティ手順のコレクションで構成されるシステムの観点から、ユーザーはセキュリティ手順とシステム保護の強度に依存する範囲で認証されていると言えます。所定の位置にあります。ただし、IRAのみの観点からは、ユーザーのIDに関してはほとんど保証がありません。つまり、使用前にユーザー入力によって保存された資格情報を変更することを要求するスキームは、より大きなシステムのコンテキスト内でユーザーレベルの認証を提供するためにのみ言われる場合があり、その後、導出された保証のレベルは、最も弱いセキュリティ属性に直接比例しますシステム全体の。
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.
一般的な観点からリモートアクセスを検討する場合、システム全体に関する仮定は、間違っていることを証明する義務があります。これは、IRAとIRACが同じ制御の領域内にない可能性があるためです。エクストラネットシナリオは、この良い例です。したがって、このコンテキストで最も望ましい共同ユーザー/マシン認証メカニズムは、ユーザー、IRA、およびIRACが一部であるより大きなシステムとは無関係に、IRAと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の観点から見ると、接続の反対側にあるIRAが実際にそうであるように思われることを確認することが重要です。つまり、IRACにはIRAの機械レベルの認証が必要です。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.
IRAの機械レベルの認証で十分ですが、これは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システムにトロイの木馬馬の存在が存在する可能性が含まれる可能性があるため、1回限りのパスフレーズメカニズムが必要になることがよくあります。許容可能なレベルのリスクを提供するが、ユーザーをあまり困らせないパスフレーズメカニズムと更新間隔を選択することは困難な場合があります。このアプローチでさえ、多くの場合、限られた保証を提供することは明らかです。
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の展開前にインストールされた現在展開されているリモートアクセスメカニズムがいくつかあります。通常、これらはユーザー認証と会計のために半径に依存するダイヤルアップシステムですが、他のメカニズムもあります。理想的な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 Legacyユーザー認証と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 Legacyユーザー認証サポートが何らかの移行なしでは提供できない場合、そのような移行の影響は最小限に抑える必要があります
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 IPアドレス（es）oサブネットマスク（s）o放送アドレス（es）oホスト名oドメイン名oタイムオフセットOサーバー（例：SMTP、POP、www、dns/nis、lpr、syslog、wins、ntpなど。）oルーターoルーター発見オプションo静的ルートo Mtu oデフォルトTTL oソースルーティングオプションo IP転送o PMTUオプションo ARPキャッシュタイムアウトO X Windowsオプションo NISオプションoベンダー固有のオプションoベンダー固有のオプションオプションo（その他のオプション）
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に転送されます。これにより、IRACはIPSECトンネルを介してターゲットネットワーク上の仮想存在を提供します。IRACには、ISPが割り当てられたアドレスとVIPの2つのアクティブアドレスがあることに注意してください。
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.
セキュリティゲートウェイの場合、接続が確立されているユーザーに基づいてポリシーを動的に調整することも望ましい場合があります。たとえば、AliceとBobという名前の2人のリモートユーザーがいるとします。ボブの特定のセグメントへのアクセスを制限しながら、ターゲットネットワークへの無制限のアクセスをアリスに提供したいと考えています。これを達成する1つの方法は、各ユーザーが常に同じアドレスを持つように、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のアドレスベースのポリシーによって制御される特定のリソースへのアクセスにより、認証されたエンドポイントIDに基づいて特定のプールから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.
あるいは、特定のリソースへのアクセスを許可するために、リモートクライアント（および割り当てられた仮想アドレス）に基づいて、セキュリティゲートウェイのポリシーが動的に更新されるため、任意のアドレスをユーザーに割り当てることができます。これらの場合、関連するセキュリティポリシーの構成は、IRACではなくIRAに固有です。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 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.
IRAが接続を明示的に終了しない場合に、IRAがこの量を正確に決定できるように、接続エンドタイム属性の要件は、ある種の接続ハートビートメカニズムの必要性を意味することに注意してください。また、この場合のハートビートメカニズムは常にIRACからIRAに向けられていることに注意してください。
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 Dialup/DSL/CableModem Telecommutersは、システムを使用してリモートリソースにアクセスする
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.
Telecommuterシナリオは、より一般的なリモートアクセスシナリオの1つです。インターネットアクセスの利便性と幅広い可用性は、多くの状況でこれを魅力的なオプションにします。ユーザーは、家やホテルの部屋の快適さからインターネットにアクセスし、このインターネット接続を使用して、ターゲットネットワークのリソースにアクセスできます。場合によっては、ダイヤルアップアカウントを使用して最初のインターネットアクセスを提供しますが、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.
ダイヤルアップと常にオンのケースは非常に似ており、アドレス割り当てメカニズムと接続期間という2つの大きな違いがあります。ほとんどのダイヤルアップの場合、IRACのIPアドレスは接続セットアップの一部として動的に割り当てられており、IRACが接続するたびに異なる可能性がかなりあります。一方、DSL/CATVユーザーは、動的な割り当てが増加していますが、多くの場合、静的IPアドレスが割り当てられています。接続期間に関しては、Dialup Remote Access Connectionsは通常短命ですが、常にオンになっている接続では、リモートアクセス接続をかなり長い期間維持する場合があります。
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.
2番目の脅威である資格的妥協の緩和は困難であり、多くの要因に依存します。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ベースの資格情報を使用することが伴います（例：SmartCard）。このような資格が操作を継続するために定期的なユーザーインタラクションを必要とする場合（例：PINの再停止）、これは、接続されているが無人システムで発生する不正なユーザーのアクセスを制限するのに役立ちます。ただし、許容可能な更新間隔を選択することは困難な問題であり、ピンが時間変動でない場合、これにより追加の保証が限られています。
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短命のダイヤルアップ接続に対してユーザー認証が提供される場合、定期的な更新が発生する可能性があります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.
テレコミーターシナリオには、デバイス構成には2つの可能性があります。TelecommuterのシステムのネイティブISPが割り当てられたアドレスに対してターゲットネットワークへのアクセスが許可されているか、Telecommuterのシステムにターゲットアドレス空間内から仮想アドレスが割り当てられます。最初のケースでは、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.
2番目のケースは、IRACにターゲットネットワーク上の仮想存在感を提供することによって導出される多数の利点のために、はるかに一般的です。たとえば、仮想存在により、クライアントはサブネットブロードキャストを受信できるため、ターゲットネットワークで勝利を使用できます。さらに、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.
o 仮想IP（VIP）アドレスのサポートが提供される場合がありますo VIPサポートが提供されている場合、上記のセクション2.2にリストされているすべてのデバイス関連パラメーターのサポートは、認証されたアドレスに基づくアドレス割り当てのサポートを提供する必要があります。割り当てはサポートされておらず、[アーチ]に記載されているようなアイデンティティベースの動的ポリシー更新メカニズムをサポートする必要があります。
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確立プロセスの一部として、ある種のポリシーダウンロード（または変更）機能が必要です。3番目のアプローチは、「トンネルオール」の仕様を許可するIRACに構成変数を提供するか、「SAが上がっている間にターゲットネットワークに向けられていないすべてのトラフィックをブロックする」ことです。
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 IDと割り当てられたアドレスに基づく動的ポリシー更新メカニズムがサポートされる場合があります。
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が何らかの形で定期的に接続がアクティブのままであることを示す必要があります。これは、IRAが接続を介して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.
ISPによってIRACシステムに割り当てられたアドレスがグローバルにルーティング可能であり、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がより広く展開されるようになるにつれて、エクストラネットはますます一般的になっています。このシナリオでは、ある企業のユーザーが地元の企業システムを使用して、別の企業のネットワーク上のリソースにアクセスしています。通常、これらの企業はあるレベルで協力していますが、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」というラベルが付けられています。この図では、Corporation Bは、サーバーS1および/またはS2にアクセスできるCorporation 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) SGW-AとSGW-Bの間にトンネルモードSAが形成され、S1/S2とユーザー間のトラフィックのみが許可されます。
3) a tunnel-mode SA is formed between USER and SGW-B which only permits traffic between S1/S2 and USER.
3) トンネルモードSAは、ユーザーとSGW-Bの間に形成され、S1/S2とユーザー間のトラフィックのみを許可します。
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つのことのいずれかが発生する必要があります。SGW-Aはユーザーを認証するためのローカルメカニズムを提供する必要があり、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.
Corporation A内の人にアクセスが許可されている場合、マシン認証で十分です。ただし、これはほとんどありそうにありません。わずかに可能性の高い状況は、企業Aの特定の組織ユニット内の誰でもアクセスが許可されている可能性があります。SGW-Aは、アクセスを許可されている組織ユニットに十分なレベルの物理的セキュリティを持っている場合、マシン認証で十分かもしれません。繰り返しますが、これには、この点でCorporation B Trust Corporation 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.
Corporation 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 仮想アドレスのサポートが提供される場合がありますo VIPサポートが提供されている場合、上記のセクション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.
o 認証されたアイデンティティに基づいたアドレス割り当てのサポートは、認証されたアドレス割り当てがサポートされていない場合、[ARCH]に記載されているようなIDベースの動的ポリシー更新メカニズムをサポートする必要があります。
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トラフィックがユーザーと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が何らかの形で定期的に接続がアクティブのままであることを示す必要があります。これは、IRAが接続を介して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-Aラップトップに沿って持ち込み、ユーザーはこのラップトップを使用して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.
これはTelecommuterシナリオと非常によく似ていますが、いくつかの重要な方法で異なります。まず、この場合、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またはラップトップがアクセスを希望するサーバーの間です。Telecommuterに適用される考慮事項のほとんどもここに適用され、接続を開始したユーザーがまだアクティブなユーザーであるという保証を提供するために、ユーザーレベルの認証が必要です。追加の予防策として、場合によってはユーザーレベルとマシンレベルの認証の組み合わせが保証される場合があります。さらに、どちらの場合も、この認証は頻繁に更新される必要があります。
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.
このシナリオのデバイス構成要件は、Telecommuterの場合と同じです。つまり、ラップトップにコーポレートネットワーク上の仮想存在が割り当てられ、もしそうなら、完全なインフラストラクチャ構成が必要になります。
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.
o 仮想アドレスのサポートが提供される場合がありますo VIPサポートが提供されている場合、上記のセクション2.2にリストされているすべてのデバイス関連パラメーターのサポートは、認証されたアドレス割り当てがサポートされていない場合、認証されたアイデンティティに基づくアドレス割り当てのサポートをサポートする必要があります、[アーチ]に記載されているようなアイデンティティベースの動的ポリシー更新メカニズムをサポートする必要があります。
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.
o IRACポリシーのIRASの更新がサポートされていない場合、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が何らかの形で定期的に接続がアクティブのままであることを示す必要があります。これは、IRAが接続を介して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-AがCorp-Bのより高い信頼を必要とすることを除いて、上記のExtranetラップトップシナリオと非常によく似ています。このシナリオには次のような外観があります。
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のシステムの1つから来ているといういくつかの保証を導き出すことができます。ラップトップで。デスクトップの場合、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ユーザー認証のサポートは提供される必要があります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-AがCorp-Bのデスクトップシステムのソフトウェア構成を制御していないことを考えると、これはラップトップシナリオよりも可能性が低いようです。
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のデスクトップの制御がさらに少ないことを除いて、ポリシー構成要件はExtranetラップトップの要件と非常に似ています。これは、デスクトップシステムでトラフィックを制限することができない可能性があることを意味します。
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が何らかの形で定期的に接続がアクティブのままであることを示す必要があります。これは、IRAが接続を介して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-Bと信頼関係がある場合を除き、Extranet Desktopシナリオに非常によく似ていますが、このシナリオではCorp-Aは公的にアクセス可能なシステムを信頼できない場合があります。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.
1回限りのパスフレーズが使用された場合、これにより、パブリックシステムによるパスフレーズキャプチャのリスクが軽減されます。一方、そのようなキャプチャが実際の脅威であることが認められている場合（つまり、システム自体が悪意があります）、結果のセッションを介して送信および受信されたデータは、敬意とともに機密または信頼できるものではないことを認識する必要があります。この悪意のあるシステムに対して、そしてユーザーが立ち去ったときに実際に切断されたとシステムが信頼できなかったこと。これは、そのようなシステムからの非自明な情報へのアクセスは無礼であることを示唆しています。
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.
別の可能なユーザー認証オプションは、SmartCardです。ただし、多くのスマートカードは、ピンを「ロック解除」するためにピンまたはパスフレーズを必要とします。これには、ピンを記録しないためにキオスクに対するある程度の信頼が必要です。したがって、このアプローチは、この点で静的なパスフレーズの欠点と同様の欠点に悩まされています。主な違いは、PIN/PassPhraseをSmartCardケースでアクセスするために単独で使用できないことです。
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.
どちらの場合でも対処すべき追加の問題は、IRAのアイデンティティの検証に関係しています。IRACが何らかの形で誤った方向に向けられた場合、中間攻撃の男性が実施される可能性があり、その後、入手したパスワードを真のIRAへの悪意のあるアクセスに使用します。この場合、1回限りのパスワードメカニズムでさえ保護がほとんどないことに注意してください。そのような攻撃を回避するために、IRACは、接続を試みる前に、IRAの認定可能または秘密の知識を所有しなければなりません。信頼関係が存在しない場合、これは不可能であることに注意してください。
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が何らかの形で定期的に接続がアクティブのままであることを示す必要があります。これは、IRAが接続を介して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とIRAの間に中間デバイスがデータストリームで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 すべてのシナリオでIRAの機械認証が必要です
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.
o IRACのマシン認証は、一般にユーザー認証と組み合わせる場合にのみ役立ちます。ユーザーとマシンの認証を組み合わせて、一部のシナリオでは役立ちます。
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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.
編集者は、この作品について有益なコメントをしたサラ・ビタン、スティーブ・ケント、マーク・タウンズリー、バーナード・アボバ、マイク・ホーン、およびIPSRAワーキンググループの他のメンバーの多くの有益なコメントを認めたいと考えています。
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134 USA
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134 USA
Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com
Sankar Ramamoorthi Juniper Networks 1194 North Mathilda Ave Sunnyvale CA 94089-1206 USA
Sankar Ramamoorthi Juniper Networks 1194 North Mathilda Ave Sunnyvale CA 94089-1206 USA
Phone: +1 (408) 936-2630
EMail: sankarr@juniper.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。