RFC3457 日本語訳
3457 Requirements for IPsec Remote Access Scenarios. S. Kelly, S.Ramamoorthi. January 2003. (Format: TXT=75167 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Kelly
Request for Comments: 3457 Airespace
Category: Informational S. Ramamoorthi
Juniper Networks
January 2003
コメントを求めるワーキンググループS.ケリー要求をネットワークでつないでください: 3457年のAirespaceカテゴリ: 情報のS.Ramamoorthi杜松は2003年1月をネットワークでつなぎます。
Requirements for IPsec Remote Access Scenarios
IPsecの遠隔アクセスのシナリオのための要件
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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
1. 用語. . . . . . . . . . . . . . . . 3 1.2の読者前提条件. . . . . . . . . . . . . . . . . . 3 1.3の一般用語. . . . . . . . . . . . . . . . . . 4 1.4が内容と組織. . . . . . . . . . . 4 2を記録するという序論. . . . . . . . . . . . . . . . . . . . . . . 2 1.1要件。 概要. . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1終点認証. . . . . . . . . . . . . . . . 6 2.1.1マシンレベル認証. . . . . . . . . . . 7 2.1.2はマシン認証. . . . . . . 8 2.1.4認証. . . . . . . . . . . . 7 2.1.3の結合したユーザ/遠隔アクセスの認証をユーザと同じくらい平らにします; . . . . . . . . . . 8 2.1.5 レガシー遠隔アクセスメカニズム9 2.2のリモートホスト構成. . . . . . . . . . . . . . . 10 2.3安全保障政策構成. . . . . . . . . . . . . 11 2.4の監査の.122.5仲介者縦断. . . . . . . . . . . . . . . . . 13との互換性
Kelly & Ramamoorthi Informational [Page 1] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[1ページ]のRFC3457IPsec
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
3. .2のシナリオ. . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1在宅勤務者(ダイアルアップ/DSL/Cablemodem). . . . . . . . . 14 3.1.1終点認証要件. . . . . . . 15 3.1デバイス構成必要条件. . . . . . . . 16 3.1; 3 .193.2のリモートエクストラネット.1認証要件への法人の方針構成必要条件. . . . . . . . 17 3.1.4の監査要求事項. . . . . . . . . . . . . . 18 3.1.5の仲介者縦断要件. . . . . . . 18 3.2; . . . . . . . . . . 19 3.2.2 ホームへの法人の.213.3エクストラネットラップトップが.223.3に.1の認証要件. . . . . . . . . . . 22 3.3.2のデバイス構成必要条件. . . . . . . . 23 3.3.3の方針構成必要条件. . . . . . . . 23 3.3を網で覆うデバイス構成必要条件. . . . . . . . 20 3.2.3の方針構成必要条件. . . . . . . . 21 3.2.4の監査要求事項. . . . . . . . . . . . . . 21 3.2.5の仲介者縦断要件.4 要件. . . . . . . . . . . . . . 24 3.3.5の仲介者縦断要件を監査して、ホームへの法人の.243.4エクストラネットデスクトップは.253.4に.2のデバイス構成必要条件. . . . . . . . 26 3.4.3の方針構成必要条件. . . . . . . . 26 3.4.4の監査要求事項. . . . . . . . . . . . . . 26 3を.1の認証要件. . . . . . . . . . . 25 3.4に網で覆います; 4.5 狙う.263.5パブリック・システムが.1の認証要件. . . . . . . . . . . 27 3.5.2のデバイス構成必要条件. . . . . . . . 28 3.5.3の方針構成必要条件. . . . . . . . 28 3.5.4の監査要求事項. . . . . . . . . . . . . . 29 3.5.5仲介者のために.273.5に縦断要件. . . . . . . 29 4をネットワークでつなぐという仲介者縦断要件。 シナリオ共通点. . . . . . . . . . . . . . . . . . 29 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . 30 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . 30 7。 承認. . . . . . . . . . . . . . . . . . . . . 30 8。 エディタのアドレス。 . . . . . . . . . . . . . . . . . . . . 30 9. 完全な著作権宣言文. . . . . . . . . . . . . . . . . 31
1. Introduction
1. 序論
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].
最近まで、遠隔アクセスはPublic Switched Telephone Network(PSTN)を通して目標ネットワークにアクセスするダイアルアップユーザーによって通常特徴付けられています、ダイアルアップ接続がターゲット・ドメインの中のNetwork Access Server(NAS)で終わっていて。 通常、これを容易にするプロトコルはPPPベースでした、そして、多くの利用可能なメカニズムの1つ以上を使用することでアクセスコントロール、承認、および会計機能を通常提供しました、RADIUS[RADIUS]を含んでいて。
Kelly & Ramamoorthi Informational [Page 2] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[2ページ]のRFC3457IPsec
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遠隔アクセスのシナリオの要件を調査して、列挙するこのドキュメントの目的です、それらの特殊解を示さないで。
1.1 Requirements Terminology
1.1 要件用語
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]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
1.2 Reader Prerequisites
1.2 読者前提条件
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.
RFCs2401-2412への読者親しみはここで議論した概念を理解していることへの最小の前提条件です。 また、公開鍵暗号基盤(PKIs)に関連する概念への親しみも必要です。 また、もっとも、RADIUS、PPP、PPTP、L2F、L2TP、および他の遠隔アクセスのサポートプロトコルへの親しみは、厳密に役立っていて、必要でなくなるでしょう。
Kelly & Ramamoorthi Informational [Page 3] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[3ページ]のRFC3457IPsec
1.3 General Terminology
1.3 一般用語
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 リモートAccess--今期は、リモート・ユーザーが必ずすなわち、ユーザのIPアドレスがどれであるかで修理されなかった固定ロケーションに住んでいるというわけではない場合について言及するのに使用されて、したがって、通常、コネクション確立の前に知られていません。
o Secure Remote Access - this term refers to remote access which is
secured using elements of the IPsec protocol suite.
o 安全なRemote Access--今期はIPsecプロトコル群の要素を使用することで保証される遠隔アクセスを示します。
o IPsec Remote Access Client (IRAC)- this term is used to refer to
the remote access user's system.
o IPsec Remote Access Client(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 Remote Access Server(IRAS)--今期は、目標ネットワークへのアクセスを提供しながら、デバイスについて言及します。 代替用語は「セキュリティゲートウェイ」です。
o Security GateWay (SGW) - this refers to the device providing
access to the target network. An alternative term is IRAS.
o セキュリティGateWay(SGW)--これは、目標ネットワークへのアクセスを提供しながら、デバイスを示します。 代替用語は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 マシンレベルAuthentication--今期はマシンのアイデンティティがマシンの固有識別文字の何らかの組み合わせの所有物と応用によって確かめられるケースについて説明します。 より完全な定義に関しては、セクション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 ユーザレベルAuthentication--今期はユーザ(マシンのものと対照的に)のアイデンティティがユーザの固有識別文字の何らかの組み合わせの所有物と応用によって確かめられるケースについて説明します。 より完全な定義に関しては、セクション2を見てください。
o NAPT - Network Address/Port Translation
o NAPT--ネットワーク・アドレス/ポート翻訳
1.4 Document Content and Organization
1.4 ドキュメント内容と組織
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
初めは単に様々な遠隔アクセスのシナリオのための要件について概説することを意図している間、このドキュメントはこれ以上をいくらか含むようになっています。 このドキュメントはIPsec Remote Access(IPSRA)ワーキンググループの中で議論から発展しました。 その結果、それはある点でこの思考過程の発展を記録します。 これは典型的なフォームのaから出発を表しますが
Kelly & Ramamoorthi Informational [Page 4] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[4ページ]のRFC3457IPsec
requirements document, the associated historical context should prove useful in interpreting the conclusions reached in the IPSRA working group.
要件ドキュメント、関連歴史的背景は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.
このドキュメントのバランスは以下の通り組織化されます: まず最初に、これらのカテゴリに関連している定義を含んでいて、基本的な要件カテゴリの概要があります。 これに続くのは、それぞれの遠隔アクセスのシナリオにささげられたセクションです。 中では、そこのそれぞれのこれらのセクションがそれぞれの以下の領域のそのシナリオに特定の要件を詳しく述べる小区分です: 終点認証、リモートホスト構成、方針構成、監査、および仲介者縦断。
2. Overview
2. 概要
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) | | +---+
+-------------+ +-----------+ |---| |
| +---+
目標ネットワーク| | +---+ +-------------+ +-----------+ |---| | |遠隔アクセス| インターネット| セキュリティ| | +---+ | クライアント|=============| ゲートウェイ|--| | (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
一般に、リモートアクセスがシナリオであると機密保護するために関連している要件のいくつかの基本的なカテゴリがあります、終点認証、リモートホスト構成、安全保障政策構成、監査、および仲介者縦断を含んでいて。 終点認証はコミュニケーションパートナー(例えば、IRACとIRAS)のアイデンティティの検証について言及します。 リモートホスト構成はIRACシステムに関するデバイス設定パラメータを示します。 そして安全保障政策構成がセキュリティゲートウェイとリモートホストの両方のIPsec方針構成について言及する。
Kelly & Ramamoorthi Informational [Page 5] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[5ページ]のRFC3457IPsec
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.
また、「アクセスコントロールと承認構成」と呼ばれるかもしれません。 監査は総合的なセキュリティを維持する目的と接続ネットワークの保全に必要である接続形態情報の世代と収集を参照します。 仲介者縦断は仲介者の向こう側に機密保護しているトラフィックを通過する能力について言及します。その或るものは何らかの方法でパケットを変更するかもしれません。 そのような仲介者はNAPTとファイアウォールデバイスを入れます。 これらの様々なカテゴリはさらに詳細に以下に扱われます。
2.1 Endpoint Authentication
2.1 終点認証
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か超能力を通してメカニズムを提供します。 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で前共有された秘密から様々な署名と暗号化体系までの範囲が秘密鍵を使って、それらの対応する公開鍵証明書であるとサポートしました。 これらのメカニズムは、エンドユーザだけか、デバイスだけか、エンドユーザとデバイスの両方を認証するのに使用されるかもしれません。 さらに詳細に以下でそれぞれこれらについて議論します。
Kelly & Ramamoorthi Informational [Page 6] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[6ページ]のRFC3457IPsec
2.1.1 Machine-Level Authentication
2.1.1 マシンレベル認証
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には、特定のデバイス(資格証明書があるもの)がアクセスが試みられているものであるのにもかかわらずの、システムのユーザのアイデンティティに関してどんな明白な保証もないという何らかのレベルを保証が分離してあるかもしれません。 IRASがユーザアイデンティティに関して追加保証を引き出すように、ある種の追加ユーザ資格証明書が必要でしょう。 以下でさらにこれについて議論します。
2.1.2 User-Level Authentication
2.1.2 ユーザレベル認証
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システムがそれ自身のさらなる資格証明書を全く提供しないなら、認証されるだけであったのは、ユーザです。 すなわち、ユーザがパケットを溯源しているネットワーク・アドレスに関して何らかの保証があるかもしれませんが、ユーザがアクセサリーを試みている特定のマシンに関して保証は全くありません。
Kelly & Ramamoorthi Informational [Page 7] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[7ページ]のRFC3457IPsec
2.1.3 Combined User/Machine Authentication
2.1.3 結合したユーザ/マシン認証
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が部分であるより大きいシステムの如何にかかわらず。
2.1.4 Remote Access Authentication
2.1.4 遠隔アクセスの認証
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
IRASのためのマシンレベル認証は十分ですが、これはIRACのためのそうではありません。 ここで、接続のもう一方の端の実体がそうするものであることを知るのはしばしば重要です。
Kelly & Ramamoorthi Informational [Page 8] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[8ページ]のRFC3457IPsec
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.
そのユーザのシステム、またはある他の権限のない実体で居住者がいない、しかし、別の方法で認可されたシステム、または悪意があるトロイの木馬アプリケーションに偶然出くわしただれかよりむしろローカル資源にアクセスするのが認可されます。 ユーザを認証すると、ユーザのマシンを認証するのと異なった要件は提示されます。 これは何らかの形式のユーザ入力を必要とします、そして、しばしば、定期的に認証を更新しなければなりません。
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.
明確に、様々な終点認証のテクニックで達成できる可変保証レベルがあります、そして、議論したテクニックのいずれも絶対保証を提供しません。 また、異なった遠隔アクセスのシナリオの中に認証要件の変化があります。 これは、「クッキーの抜き型」ソリューションが全くこの問題によってなくて、それぞれのための決められた一定の要求を引き出すために慎重に個々のシナリオを調べなければならないことを意味します。 これらはaでケースバイケースで調べられます。以下の詳細なシナリオ記述における基礎。
2.1.5 Compatibility With Legacy Remote Access Mechanisms
2.1.5 レガシー遠隔アクセスメカニズムとの互換性
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などの会計システムを提供するべきです。
Kelly & Ramamoorthi Informational [Page 9] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[9ページ]のRFC3457IPsec
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 ユーザー認証情報は、盗聴に対して保護されて、再演されなければなりません。(ユーザアイデンティティを含んでいます)
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-要素認証機構はサポートされるべきです。
2.2 Remote Host Configuration
2.2 リモートホスト構成
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 Broadcastアドレス(es)o Host名oのDomainがオプションo Staticがo MTU o Default TTL o Sourceルーティングオプションo IP Forwardingを発送するというオフセットo Servers(例えば、SMTP、POP、WWW、DNS/NIS、LPR、syslog、WINS、NTPなど)o Router(s)o Router Time o発見と命名するIPアドレス(es)o Subnetマスクoは、o PMTUオプションo ARPキャッシュタイムアウトo X-windowsオプションo NISオプションo NetBIOSオプションoがVendor特有のオプションoであると可能にするか、または無効にします。(別の選択肢)
Kelly & Ramamoorthi Informational [Page 10] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[10ページ]のRFC3457IPsec
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
目標ネット+------------------+ | | 遠隔アクセス| +--------+ | ( ~ ~ ~ ~ ~ ) |+-------+ クライアント| | | | (IRAC) ||仮想| | |セキュリティ| |~~~(仮想)です。 || ホスト| |--------|ゲートウェイ| | (存在) || |<========>| |----| ~ ~ ~ ~ ~ |+-------+ |--------| | | +------------------+ ^ +--------+ | +--------+ | |---| ローカル| IPsecトンネル| | ホスト| カプセル化される| +--------+ トラフィック内部
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に割り当てられます、そして、この割り当てられたアドレスを含むパケットがカプセルに入れられます、トンネルを通してIRASにIRACの発送可能アドレスを保管していて、送られた外側のヘッダーと共に。 これはIPsecトンネルを通して目標ネットワークで仮想の存在をIRACに提供します。 IRACには2つのアクティブなアドレスが現在あることに注意してください: ISP割り当てられたアドレス、およびVIP。
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サーバなどを必要とするかもしれません、ちょうど目標ネットワークに物理的に住んでいるダイナミックに構成されたホストがそうするように。 それはこの要件カテゴリが関するこの種類の構成です。
2.3 Security Policy Configuration
2.3 安全保障政策構成
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
安全保障政策構成は遠隔アクセスのクライアントとセキュリティゲートウェイの両方についてIPsecアクセス方針を示します。 目標ネットワークを保護する接続IRACシステムに関するアクセス方針を構成するのは望ましいかもしれません。 例えば、クライアントがインターネット(発送可能アドレスを通る)に近づく手段を持っているので、また、インターネットの他のシステムは何らかのレベルの相互的なアクセスをクライアントに持っています。 いくつかの場合、このインターネットを妨げるのは望ましいかもしれません。
Kelly & Ramamoorthi Informational [Page 11] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[11ページ]のRFC3457IPsec
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.
目標ネットワークにはアクセス(それにトンネルを通り抜けさせる)がクライアントである間、トンネルを堀られた接続があります。 これはクライアント安全保障政策構成の問題です。
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〜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.
リモートクライアントアクセスコントロールのための、よりスケーラブルなソリューションはダイナミックに認証された終点のアイデンティティに基づく特定のプールからのIPアドレスを割り当てるだろうことです、SGWのアドレスベースの方針で制御された特定のリソースへのアクセスで。 これは上で説明された静的なマッピングと非常に同様です、与えられたユーザー層(同じアクセス制御があるそれら)がいつも与えられたアドレスに写像する与えられたユーザよりむしろ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にというよりむしろIRASに特定です。 IRASとIRAC安全保障政策構成の両方がこの要件カテゴリによって取り囲まれます。
2.4 Auditing
2.4 監査
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が、この量が中にどこをケースに入れるかを正確に決定できるように接続終わりの時間属性のための要件がある種の接続鼓動メカニズムの必要性を含意することに注意してください。
Kelly & Ramamoorthi Informational [Page 12] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[12ページ]のRFC3457IPsec
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は明らかに接続を終えません。 また、この場合、鼓動メカニズムがIRACからIRASまでいつも指示されることに注意してください。
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.
いくつかの場合、鼓動の使用は否定的に接続に影響を及ぼすかもしれません。 例えば、鼓動間隔が非常に短く、接続がほんのわずかなハートビートパケットの損失の後にリセットされるなら、ネットワークの混雑が不要な接続リセットにつながるかもしれない可能性があります。 鼓動間隔とリセット敷居は念頭でこれで選ばれるべきです、そして、構成か交渉でこれらの量を調整するのは可能であるべきです。
2.5 Intermediary Traversal
2.5 仲介者縦断
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デバイスはアドレスとUDP/TCPが移植する出発しているパケットのソースIP、およびアドレスとUDP/TCPが移植する入って来るパケットの目的地IPを通常変更します、そして、いくつかの場合、それらはパケットのデータ部で追加分野を変更します。 そのような変更はAHプロトコルの使用を不可能にします。 超能力の場合では、UDP/TCPポート分野は、時々読みにくくて、いつも「非-修正でき」です、NAPTデバイスによる重要な翻訳を不可能にして。 同様に苦しむ他の頻繁なプロトコル分野組み合わせがあります。 この要件カテゴリはこれらの問題に関係があります。
3. Scenarios
3. シナリオ
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/cablemodem在宅勤務者
Kelly & Ramamoorthi Informational [Page 13] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[13ページ]のRFC3457IPsec
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 目標ネットワーク資源にアクセスするのに、借りられたシステム(例えば、空港の売店)を使用しているリモート・ユーザー
3.1 Telecommuters (Dialup/DSL/Cablemodem)
3.1 在宅勤務者(ダイアルアップ/DSL/Cablemodem)
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.
在宅勤務者シナリオは、より一般的な遠隔アクセスのシナリオの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アドレスをそれらにしばしば割り当てさせます、増加にはダイナミックな課題がありますが。 接続持続時間に関して、ダイアルアップ遠隔アクセス接続は通常短命です、常時接続がかなり長い期間に遠隔アクセスの接続を維持するかもしれませんが。
The general configuration in either case looks like this:
どちらかの場合における一般的な構成はこれに似ています:
corporate net
| +----+
+-----+ +-----+ /---/ Internet +---+ |--| |
|IRAC |---|modem|------|ISP|==========|SGW|--| +----+
+-----+ +-----+ /---/ +---+ |
|
法人のネット| +----+ +-----+ +-----+ /---/インターネット+---+ |--| | |IRAC|---|モデム|------|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接続が使用されている場合でこれは現在、最も一般的です。
Kelly & Ramamoorthi Informational [Page 14] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[14ページ]のRFC3457IPsec
3.1.1 Endpoint Authentication Requirements
3.1.1 終点認証要件
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つの一般的な脅威があります。 まず最初に、安全な接続が特定のユーザのために確立されますが、対象とする使用者以外のだれかが現在その接続を使用している可能性があります。 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
2番目の脅威の緩和(資格証明感染)は、難しく、多くの要因に依存します。 IRACシステムが非常に安全なオペレーティングシステムを動かしているなら、時間異形資格証明書は再び何らかの値を提供するかもしれません。 静的なパスワードはこのシナリオに明確に欠けています、それがオンラインの、または、オフラインの推測を条件として結局感染されるかもしれないので--私たちが緩和するのを試みている脅威はどれですか? しかしながら、IRACであるなら、オペレーティングシステムはそうではありません。
Kelly & Ramamoorthi Informational [Page 15] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[15ページ]のRFC3457IPsec
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.
硬くなります、複数の位置からの同時アクセスが禁じられて、資格証明世代メカニズムに容易に感染されない場合にだけ、時間異形資格証明書の使用は有効です。
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 ----
IRAS----
o machine authentication MUST be provided.
o マシン認証を提供しなければなりません。
IRAC ----
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 ユーザー認証SHOULDがどちらかのユーザのoサポートを提供するか、または認証を機械加工するので、サポートは権限のない接続使用からの保護を望んでいるならユーザー認証のoサポートを提供しなければならないかどうかということであるに違いありません。○ ユーザー認証が○ ユーザー認証を常時接続に提供するなら短命な電話での接続のために、周期的な更新が起こるかもしれないかどうかということであるなら、周期的な更新SHOULDは起こります。
3.1.2 Device Configuration Requirements
3.1.2 デバイス構成必要条件
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つの可能性があります: 目標ネットワークへのアクセスが在宅勤務者のシステムの固有のISP割り当てられたアドレスのために受入れられるか、または目標アドレス空間からの仮想アドレスは在宅勤務者のシステムに割り当てられます。 前者の場合、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
2番目のケースははるかに一般的です、目標の上で仮想の存在をIRACに提供することによって引き出された多数の利益のため
Kelly & Ramamoorthi Informational [Page 16] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[16ページ]のRFC3457IPsec
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.
ネットワークでつなぎます。 仮想の存在は例えば、どれが、目標ネットワークで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は数個からどこでも設定情報のずっと多くの要素に以上を必要とします、企業ネットワークの位相的な複雑さのレベルによって。 a、公正である、全リスト、セクション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 VIPサポートがアドレス課題の提供されたoサポートが認証されたアイデンティティに基づいたならSHOULDの上のセクション2.2でリストアップされたすべてのデバイス関連のパラメタのサポートが○ 認証されたアドレス課題がサポートされないなら、[ARCH]で説明されるようなアイデンティティベースのダイナミックな方針アップデートメカニズムをサポートしなければならないかどうかということであるかもしれないかどうかということであるなら、仮想のIP(VIP)アドレスのサポートにoを提供するかもしれません。
3.1.3 Policy Configuration Requirements
3.1.3 方針構成必要条件
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が最初にそれらがかけられるかもしれない目標ネットワークにトンネルを横断するすべてのインターネット行きのパケットにネットワーク方針を狙わせることによって、危険は緩和されるかもしれません。 時間目標についてIRACをネットワークでつなぐ反射するようにIRACの方針構成を変更する少し頭上でない限嗣相続を運ぶ2番目のアプローチは接続されています。 この場合、出るか、またはIRACに入る前に、トラフィックは目標サイトを通してやむを得ず輪にしません。 これはSA設立プロセスの一部としてある種の方針ダウンロード(または、変更)能力を必要とします。 「3番目のアプローチは、「トンネルすべて、」の仕様を可能にするIRACに構成変数を供給するか、またはSAが上がっていますが、目標ネットワークのために運命づけられなかったすべてのトラフィックを妨げる」ことです。
Kelly & Ramamoorthi Informational [Page 17] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[17ページ]のRFC3457IPsec
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 ----
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 アドレスの課題ベースの方針アップデートメカニズムがサポートされないなら、アドレス課題はSHOULDを認証されたアイデンティティに基礎づけました。サポートされます。
IRAC ----
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 SHOULDはIPsec遠隔アクセスが提供することにされるのであるリモートネットワークのために運命づけられなかったトラフィックのために「トンネルすべて、」、そして/または、「ブロックすべて、」に構成する能力を提供します。
o support for dynamic IRAS update of IRAC policy MAY be provided.
o IRAC方針のダイナミックなIRASアップデートのサポートを提供するかもしれません。
3.1.4 Auditing Requirements
3.1.4 監査要求事項
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が、接続が使用中であり残っているのを示すシグナル伝達機構が必要です。
3.1.5 Intermediary Traversal Requirements
3.1.5 仲介者縦断要件
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実装に透明にするために何らかのメカニズムを提供しなければなりません。
Kelly & Ramamoorthi Informational [Page 18] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[18ページ]のRFC3457IPsec
3.2 Corporate to Remote Extranet
3.2、リモートエクストラネットへの法人
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 |
| | +-----+
CORPはCORP Bです。| | +----+ | | +-----+ |ユーザ|---| |--| S1| +----+ | +------++ ++------+ | +-----+ |---|SGW/FW||===インターネット===||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つで達成されるかもしれません:
1) an end-to-end SA is formed from USER to S1 or S2
1) 終わりから終わりへのSAはS1かUSERから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とUSERの間のトラフィックを可能にするだけである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はUSERとS1/S2とUSERの間のトラフィックを可能にするだけであるSGW-Bの間で形成されます。
These various cases are individually discussed with respect to each requirements category below.
以下のそれぞれの要件カテゴリに関して個別にこれらの様々なケースについて議論します。
3.2.1 Authentication Requirements
3.2.1 認証要件
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
法人のエクストラネットシナリオのために、接続が優れている方法によって、認証要件はわずかに変わります。 特定のユーザだけがS1/S2にアクセスすることを許可されるなら、ユーザレベル認証が必要です。 結合方式(1)か(3)が使用されているなら、それが達成されるように在宅勤務者のためにこれは同じ方法で達成されるかもしれません。 結合方式(2)がそうなら
Kelly & Ramamoorthi Informational [Page 19] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[19ページ]のRFC3457IPsec
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.
使用されていて、2つのものの1つは起こらなければなりません: SGW-絶対に必要なものは何らかの局所機構をUSERを認証するのに提供します、そして、SGW-Bがこのメカニズムを信じなければなりませんか、またはSGW-BにはSGW-Aの如何にかかわらずUSERを認証するための何らかのメカニズムがなければなりません。
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.でだれにも受入れられて、Thisケースが非常に同様であるということであるシングルユーザーアクセス事件が上で議論したものであるかもしれなく、SGW-Aに必要であるメカニズムで本質的には同じ要件を持っています、アクセスが受入れられる組織的なユニットが十分なレベルの物理的なセキュリティを持っているなら、マシン認証は十分であるかもしれませんが。 一方、これはこの点でその会社B受託会社Aを必要とします。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
まとめるために↓これはIRASとIRACのための認証要件です:
IRAS ----
IRAS----
o machine authentication MUST be provided.
o マシン認証を提供しなければなりません。
IRAC ----
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 ユーザとマシン認証SHOULDの組み合わせのoサポートが○ ユーザー認証が使用されているなら、周期的な更新SHOULDが起こるかどうかということであるなら、ユーザかマシン認証のどちらかのサポートはそうであるに違いありません。
3.2.2 Device Configuration Requirements
3.2.2 デバイス構成必要条件
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が接続の持続時間のために仮想アドレスをUSERに割り当てたがっているのは、可能です。 これを達成できた唯一の方法がUSERがトンネル終点であるならあるでしょうに。(例えば、ケース(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を提供するかもしれません、SHOULDの上のセクション2.2でリストアップされたすべてのデバイス関連のパラメタのサポート、サポートされてください。
Kelly & Ramamoorthi Informational [Page 20] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[20ページ]のRFC3457IPsec
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 認証されたアドレス課題がサポートされないなら認証されたアイデンティティSHOULDに基づくアドレス課題のサポートがoであるとサポートされて、[ARCH]で説明されるようなアイデンティティベースのダイナミックな方針アップデートメカニズムをサポートしなければなりません。
3.2.3 Policy Configuration Requirements
3.2.3 方針構成必要条件
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トラフィックがUSERとS1/S2の間で終わるのを可能にするのを必要とするでしょう。 ケース(3)に、USERとSGW-Bの間には、IPsecトラフィックがあるだろうというのを除いて、同様の要件があるでしょう。 ケース(2)は、適切なトランジットトラフィックがUSERとS1/S2の間で保証されるのを必要とするでしょう。
None of these cases require dynamic policy configuration.
これらのケースのいずれもダイナミックな方針構成を必要としません。
3.2.4 Auditing Requirements
3.2.4 監査要求事項
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)のために、必要な監査のデータのタイプは複数のユーザからのトラフィックが単一のトンネルの中で集められたかどうかを当てにするでしょう。 そうだとすれば、個々の接続始め/停止時間の概念は失われるでしょう。 そのような測定が望まれているなら、これは、1ユーザあたりのトンネルがSGW-AとSGW-Bの間でセットアップされて、ある種のタイムアウト間隔がトラフィックが時間のいくつかの間隔の間流れないとき、トンネル分解をもたらすために費やされるのを必要とします。
3.2.5 Intermediary Traversal Requirements
3.2.5 仲介者縦断要件
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
IPsecスイートでプロトコルを通過するためにホストネットワークの縁に位置するファイアウォールを構成できないなら、何らかのメカニズムはデータがどの転向者であるかならどれを1つに流すかということであるに違いありません。
Kelly & Ramamoorthi Informational [Page 21] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[21ページ]のRFC3457IPsec
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に通過するためにファイアウォールを構成できるなら、コネクション確立の前にこれを達成しなければなりません。
3.3 Extranet Laptop to Home Corporate Net
3.3 ホームの法人のネットへのエクストラネットラップトップ
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 |---| |
+----+ | |
CORPはCORP Bです。| | +----+ | | +--------+ |飛び出してください。|---| |--| CORP-A| +----+ | +------++ ++------+ | | ラップトップ| |---|SGW/FW||===インターネット===||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.
これは在宅勤務者シナリオと非常に同様ですが、それはいくつかの重要な道において異なります。 まず最初に、SGW、そして/または、ファイアウォールがこの場合CORP-ビーズサイトの縁にしばしばあります。 2番目に、対象とする使用者以外のだれかにとって、長命の接続がなることができたかなり増強されたリスクがアクセスしやすかったなら、そこでは、そうするかもしれません。
3.3.1 Authentication Requirements
3.3.1 認証要件
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.
多くの場合、ラップトップがアクセサリーに願っているラップトップとSGW-AかCORP-Aサーバのどちらかの間には、CORP-Aの見解からの唯一の許容できる接続があります。 また、在宅勤務者に適用された問題の大部分はここに申し込まれます、そして、ユーザレベル認証が、それでも、接続を開始したユーザが活発なユーザであるという保証を提供するのに必要です。 いくつかの場合、加えられた注意として、ユーザレベルとマシンレベル認証の組み合わせは保証されるかもしれません。 さらに、どちらの場合ではも、この認証は頻繁に更新されるべきです。
Kelly & Ramamoorthi Informational [Page 22] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[22ページ]のRFC3457IPsec
To summarize, the following are the authentication requirements for the IRAS and IRAC:
まとめるために↓これはIRASとIRACのための認証要件です:
IRAS ----
IRAS----
o machine authentication MUST be provided.
o マシン認証を提供しなければなりません。
IRAC ----
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 ユーザの組み合わせとマシン認証SHOULDのoサポートがユーザー認証のo周期的な更新が起こらなければならないかどうかということであるならユーザー認証のoサポートがそうであるに違いないなら、マシン認証SHOULDのサポートはそうです。
3.3.2 Device Configuration Requirements
3.3.2 デバイス構成必要条件
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.
o VIPサポートが認証されたアドレス課題がサポートされないならアドレス課題のサポートしているoサポートが認証されたアイデンティティSHOULDに基づいたならSHOULDの上のセクション2.2でリストアップされたすべてのデバイス関連のパラメタのサポートがoであるとサポートされて、[ARCH]で説明されるようなアイデンティティベースのダイナミックな方針アップデートメカニズムをサポートしなければならないかどうかということであるなら、仮想アドレスのサポートにoを提供するかもしれません。
3.3.3 Policy Configuration Requirements
3.3.3 方針構成必要条件
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とラップトップの間のそれを除いたすべてのトラフィックを妨げることができました。
Kelly & Ramamoorthi Informational [Page 23] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[23ページ]のRFC3457IPsec
IRAC ----
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 MAYは、非トンネルを堀られたトラフィックのために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 SHOULDはIPsec遠隔アクセスが提供することにされるのであるリモートネットワークのために運命づけられなかったトラフィックのために「トンネルすべて、」、そして/または、「ブロックすべて、」に構成する能力を提供します。
3.3.4 Auditing Requirements
3.3.4 監査要求事項
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が、接続が使用中であり残っているのを示すシグナル伝達機構が必要です。
3.3.5 Intermediary Traversal Requirements
3.3.5 仲介者縦断要件
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に通過するためにファイアウォールを構成できるなら、コネクション確立の前にこれを達成しなければなりません。
Kelly & Ramamoorthi Informational [Page 24] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[24ページ]のRFC3457IPsec
3.4 Extranet Desktop to Home Corporate Net
3.4 ホームの法人のネットへのエクストラネットデスクトップ
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 |---| |
+----+ | |
CORPはCORP Bです。| | +----+ | | +--------+ |飛び出してください。|---| |--| CORP-B| +----+ | +------++ ++------+ | |デスクトップ| |---|SGW/FW||===インターネット===||SGW/FW|---| +--------+ | +------++ ++------+ | +----+ | SGW-A SGW-B| |FTP|---| | +----+ | |
3.4.1 Authentication Requirements
3.4.1 認証要件
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 ----
IRAS----
o machine authentication MUST be provided.
o マシン認証を提供しなければなりません。
IRAC ----
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周期的な更新が起こらなければならないかどうかということであるかもしれないかどうかということであるに違いないかどうかということであるかもしれません。
Kelly & Ramamoorthi Informational [Page 25] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[25ページ]のRFC3457IPsec
3.4.2 Device Configuration Requirements
3.4.2 デバイス構成必要条件
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-ビーズデスクトップ型のソフトウェア構成での管理欠如を考えて。
3.4.3 Policy Configuration Requirements
3.4.3 方針構成必要条件
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-ビーズの上のラップトップの上にあるだろうよりさらに少ない制御デスクトップがあるのを除いて。 これは、デスクトップ型で何らかの方法でトラフィックを制限するのが可能でないかもしれないことを意味します。
3.4.4 Auditing Requirements
3.4.4 監査要求事項
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が、接続が使用中であり残っているのを示すシグナル伝達機構が必要です。
3.4.5 Intermediary Traversal Requirements
3.4.5 仲介者縦断要件
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に通過するためにファイアウォールを構成できるなら、コネクション確立の前にこれを達成しなければなりません。
Kelly & Ramamoorthi Informational [Page 26] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[26ページ]のRFC3457IPsec
3.5 Public System to Target Network
3.5 ネットワークを狙うパブリック・システム
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と所有者の間に存在していますが、多くの場合で存在するかもしれないというメモはそうしないでしょう。
3.5.1 Authentication Requirements
3.5.1 認証要件
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回の変化があります。 1番目では、信頼関係は全く目標ネットワークと借りられたシステムの間に存在していません。 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.
別の可能なユーザー認証オプションはスマートカードでしょう。 しかしながら、多くのスマートカードが、それらを「アンロックする」ためにピンかパスフレーズを必要とします(ピンを記録しないようにキオスクで何らかのレベルの信頼を必要とします)。 したがって、このアプローチはこの点で静的なパスフレーズのものと同様の欠点に苦しみます。 プライマリ違いはスマートカード場合におけるアクセスに単独でピン/パスフレーズを使用できなかったということでしょう。
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
パブリック・システムの所有者との信頼関係が存在する場合では、信頼レベルは上で議論した危険水準を調節するでしょう。 例えば、システム所有者のための十分なレベルの信頼が存在しているなら、静的なパスフレーズの使用はこれから受入れられたならシステムがアクセスで目標を所有していたより多くの危険を提示しないかもしれません。 しかしながら、マシンを認証する能力からそのような信頼関係の主要便益を得るでしょう。
Kelly & Ramamoorthi Informational [Page 27] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[27ページ]のRFC3457IPsec
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 ----
IRAS----
o machine authentication MUST be provided.
o マシン認証を提供しなければなりません。
IRAC ----
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が中で信頼関係が間に存在するところにケースに入れる伝えられたコネがアクセスされたネットワークであったならアクセスされたネットワークとシステム所有者、極秘データSHOULD NOTの間に存在しないケースとシステム所有者、マシン認証SHOULDでは、サポートされてください; 信頼関係がアクセスされたネットワークとシステム所有者の間に存在する場合におけるo、静的なパスフレーズはIRACシステムのマシンレベル認証に関連して使用されるかもしれません。ユーザー認証のo頻繁な更新は起こらなければなりません。
3.5.2 Device Configuration Requirements
3.5.2 デバイス構成必要条件
None.
なし。
3.5.3 Policy Configuration Requirements
3.5.3 方針構成必要条件
None.
なし。
Kelly & Ramamoorthi Informational [Page 28] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[28ページ]のRFC3457IPsec
3.5.4 Auditing Requirements
3.5.4 監査要求事項
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が、接続が使用中であり残っているのを示すシグナル伝達機構が必要です。
3.5.5 Intermediary Traversal Requirements
3.5.5 仲介者縦断要件
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実装に透明にするために何らかのメカニズムを提供しなければなりません。
4. Scenario Commonalities
4. シナリオ共通点
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.
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 仲介者縦断メカニズムがシナリオのいずれでも必要であるかもしれません。
Kelly & Ramamoorthi Informational [Page 29] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[29ページ]のRFC3457IPsec
5. Security Considerations
5. セキュリティ問題
The topic of this document is secure remote access. Security considerations are discussed throughout the document.
このドキュメントの話題は安全な遠隔アクセスです。 ドキュメント中でセキュリティ問題について議論します。
6. References
6. 参照
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[アーチ形に曲げます] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のための主要なワーズ」、BCP14、RFC2119、1997年3月。
[RADIUS] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[半径]Rigney、C.、ルーベン、A.、シンプソン、W.、およびS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
7. Acknowledgements
7. 承認
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、マイクHornの多くの役に立つコメント、およびこの仕事のときに役に立つコメントをしたipsraワーキンググループの他のメンバーを承諾したがっています。
8. Editors' Addresses
8. エディタのアドレス
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134 USA
スコットケリーAirespace110Nortech Pkwyサンノゼカリフォルニア95134米国
Phone: +1 (408) 941-0500 EMail: scott@hyperthought.com
以下に電話をしてください。 +1 (408) 941-0500 メールしてください: scott@hyperthought.com
Sankar Ramamoorthi Juniper Networks 1194 North Mathilda Ave Sunnyvale CA 94089-1206 USA
Sankar Ramamoorthi杜松ネットワーク1194の北のマチルダAveサニーベルカリフォルニア94089-1206米国
Phone: +1 (408) 936-2630 EMail: sankarr@juniper.net
以下に電話をしてください。 +1 (408) 936-2630 メールしてください: sankarr@juniper.net
Kelly & Ramamoorthi Informational [Page 30] RFC 3457 IPsec Remote Access Scenarios January 2003
アクセスシナリオ2003年1月にリモートなケリーとRamamoorthiの情報[30ページ]のRFC3457IPsec
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。
Kelly & Ramamoorthi Informational [Page 31]
ケリーとRamamoorthi情報です。[31ページ]
一覧
スポンサーリンク
