Network Working Group S. Kelly
Request for Comments: 3457 Airespace
Category: Informational S. Ramamoorthi
Juniper Networks
January 2003
Network Working Group S. Kelly
Request for Comments: 3457 Airespace
Category: Informational S. Ramamoorthi
Juniper Networks
January 2003
Requirements for IPsec Remote Access Scenarios
IPsec远程访问场景的要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios.
IPsec作为一种安全的远程访问机制提供了很多希望。但是，有许多不同的远程访问场景，每个场景都有一些共享和独特的需求。为了有效地评估特定机制集对任何特定远程访问场景的适用性，有必要彻底了解这些需求。本文档列举了许多常见远程访问场景的要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Requirements Terminology . . . . . . . . . . . . . . . . 3
1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . . 3
1.3 General Terminology . . . . . . . . . . . . . . . . . . 4
1.4 Document Content and Organization . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Endpoint Authentication . . . . . . . . . . . . . . . . 6
2.1.1 Machine-Level Authentication . . . . . . . . . . . 7
2.1.2 User-Level Authentication . . . . . . . . . . . . 7
2.1.3 Combined User/Machine Authentication . . . . . . . 8
2.1.4 Remote Access Authentication . . . . . . . . . . . 8
2.1.5 Compatibility With Legacy Remote Access Mechanisms 9
2.2 Remote Host Configuration . . . . . . . . . . . . . . . 10
2.3 Security Policy Configuration . . . . . . . . . . . . . 11
2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Requirements Terminology . . . . . . . . . . . . . . . . 3
1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . . 3
1.3 General Terminology . . . . . . . . . . . . . . . . . . 4
1.4 Document Content and Organization . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Endpoint Authentication . . . . . . . . . . . . . . . . 6
2.1.1 Machine-Level Authentication . . . . . . . . . . . 7
2.1.2 User-Level Authentication . . . . . . . . . . . . 7
2.1.3 Combined User/Machine Authentication . . . . . . . 8
2.1.4 Remote Access Authentication . . . . . . . . . . . 8
2.1.5 Compatibility With Legacy Remote Access Mechanisms 9
2.2 Remote Host Configuration . . . . . . . . . . . . . . . 10
2.3 Security Policy Configuration . . . . . . . . . . . . . 11
2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . 13
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Telecommuters (Dialup/DSL/Cablemodem) . . . . . . . . . 14
3.1.1 Endpoint Authentication Requirements . . . . . . . 15
3.1.2 Device Configuration Requirements . . . . . . . . 16
3.1.3 Policy Configuration Requirements . . . . . . . . 17
3.1.4 Auditing Requirements . . . . . . . . . . . . . . 18
3.1.5 Intermediary Traversal Requirements . . . . . . . 18
3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . 19
3.2.1 Authentication Requirements . . . . . . . . . . . 19
3.2.2 Device Configuration Requirements . . . . . . . . 20
3.2.3 Policy Configuration Requirements . . . . . . . . 21
3.2.4 Auditing Requirements . . . . . . . . . . . . . . 21
3.2.5 Intermediary Traversal Requirements . . . . . . . 21
3.3 Extranet Laptop to Home Corporate Net . . . . . . . . . 22
3.3.1 Authentication Requirements . . . . . . . . . . . 22
3.3.2 Device Configuration Requirements . . . . . . . . 23
3.3.3 Policy Configuration Requirements . . . . . . . . 23
3.3.4 Auditing Requirements . . . . . . . . . . . . . . 24
3.3.5 Intermediary Traversal Requirements . . . . . . . 24
3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . 25
3.4.1 Authentication Requirements . . . . . . . . . . . 25
3.4.2 Device Configuration Requirements . . . . . . . . 26
3.4.3 Policy Configuration Requirements . . . . . . . . 26
3.4.4 Auditing Requirements . . . . . . . . . . . . . . 26
3.4.5 Intermediary Traversal Requirements . . . . . . . 26
3.5 Public System to Target Network . . . . . . . . . . . . 27
3.5.1 Authentication Requirements . . . . . . . . . . . 27
3.5.2 Device Configuration Requirements . . . . . . . . 28
3.5.3 Policy Configuration Requirements . . . . . . . . 28
3.5.4 Auditing Requirements . . . . . . . . . . . . . . 29
3.5.5 Intermediary Traversal Requirements . . . . . . . 29
4. Scenario Commonalities . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . 30
6. References . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
8. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . 30
9. Full Copyright Statement . . . . . . . . . . . . . . . . . 31
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Telecommuters (Dialup/DSL/Cablemodem) . . . . . . . . . 14
3.1.1 Endpoint Authentication Requirements . . . . . . . 15
3.1.2 Device Configuration Requirements . . . . . . . . 16
3.1.3 Policy Configuration Requirements . . . . . . . . 17
3.1.4 Auditing Requirements . . . . . . . . . . . . . . 18
3.1.5 Intermediary Traversal Requirements . . . . . . . 18
3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . 19
3.2.1 Authentication Requirements . . . . . . . . . . . 19
3.2.2 Device Configuration Requirements . . . . . . . . 20
3.2.3 Policy Configuration Requirements . . . . . . . . 21
3.2.4 Auditing Requirements . . . . . . . . . . . . . . 21
3.2.5 Intermediary Traversal Requirements . . . . . . . 21
3.3 Extranet Laptop to Home Corporate Net . . . . . . . . . 22
3.3.1 Authentication Requirements . . . . . . . . . . . 22
3.3.2 Device Configuration Requirements . . . . . . . . 23
3.3.3 Policy Configuration Requirements . . . . . . . . 23
3.3.4 Auditing Requirements . . . . . . . . . . . . . . 24
3.3.5 Intermediary Traversal Requirements . . . . . . . 24
3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . 25
3.4.1 Authentication Requirements . . . . . . . . . . . 25
3.4.2 Device Configuration Requirements . . . . . . . . 26
3.4.3 Policy Configuration Requirements . . . . . . . . 26
3.4.4 Auditing Requirements . . . . . . . . . . . . . . 26
3.4.5 Intermediary Traversal Requirements . . . . . . . 26
3.5 Public System to Target Network . . . . . . . . . . . . 27
3.5.1 Authentication Requirements . . . . . . . . . . . 27
3.5.2 Device Configuration Requirements . . . . . . . . 28
3.5.3 Policy Configuration Requirements . . . . . . . . 28
3.5.4 Auditing Requirements . . . . . . . . . . . . . . 29
3.5.5 Intermediary Traversal Requirements . . . . . . . 29
4. Scenario Commonalities . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . 30
6. References . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
8. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . 30
9. Full Copyright Statement . . . . . . . . . . . . . . . . . 31
Until recently, remote access has typically been characterized by dial-up users accessing the target network via the Public Switched Telephone Network (PSTN), with the dial-up connection terminating at a Network Access Server (NAS) within the target domain. The protocols facilitating this have usually been PPP-based, and access control, authorization, and accounting functions have typically been provided using one or more of a number of available mechanisms, including RADIUS [RADIUS].
直到最近，远程访问的典型特征是拨号用户通过公共交换电话网（PSTN）访问目标网络，拨号连接终止于目标域内的网络访问服务器（NAS）。促进这一点的协议通常是基于PPP的，访问控制、授权和记帐功能通常使用一个或多个可用机制提供，包括RADIUS[RADIUS]。
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帐户，然后通过Internet将额外的PPP连接隧道到目标网络。对于宽带用户，这种连接直接通过互联网进行隧道传输。虽然这些机制在安全特性方面一直缺乏，但IPsec的日益可用性使得通过Internet提供对远程资源的更安全的远程访问成为可能。
Remote access via the Internet has numerous benefits, financial and otherwise. However, security is paramount, and this presents strong incentives for migration from the old dial-up model to a more secure IPsec-based remote access model. Meeting the security requirements of various classes of remote access users presents a number of challenges. It is the aim of this document to explore and enumerate the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them.
通过互联网远程访问有很多好处，包括财务和其他方面。但是，安全性至关重要，这为从旧的拨号模式迁移到更安全的基于IPsec的远程访问模式提供了强大的动力。满足各类远程访问用户的安全要求带来了许多挑战。本文档的目的是探索和列举各种IPsec远程访问场景的需求，而不建议针对这些场景的特定解决方案。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [3].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[3]中的说明进行解释。
Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to understanding the concepts discussed here. Familiarity with concepts relating to Public Key Infrastructures (PKIs) is also necessary. Familiarity with RADIUS, PPP, PPTP, L2F, L2TP, and other remote access support protocols will also be helpful, though not strictly necessary.
读者熟悉RFCs 2401-2412是理解此处讨论的概念的最低先决条件。熟悉与公钥基础设施（PKI）相关的概念也是必要的。熟悉RADIUS、PPP、PPTP、L2F、L2TP和其他远程访问支持协议也会有所帮助，尽管并非严格必要。
o Remote Access - this term is used to refer to the case in which the remote user does not necessarily reside at a fixed location, i.e., in which the user's IP address is not fixed, and therefore usually not known prior to connection establishment.
o 远程访问-此术语用于指远程用户不一定位于固定位置的情况，即用户的IP地址不固定，因此在建立连接之前通常不知道。
o Secure Remote Access - this term refers to remote access which is secured using elements of the IPsec protocol suite.
o 安全远程访问-此术语是指使用IPsec协议套件的元素进行安全的远程访问。
o IPsec Remote Access Client (IRAC)- this term is used to refer to the remote access user's system.
o IPsec远程访问客户端（IRAC）-此术语用于指远程访问用户的系统。
o IPsec Remote Access Server (IRAS) - this term refers to the device providing access to the target network. An alternative term is "Security Gateway".
o IPsec远程访问服务器（IRAS）-此术语指提供对目标网络的访问的设备。另一个术语是“安全网关”。
o Security GateWay (SGW) - this refers to the device providing access to the target network. An alternative term is IRAS.
o 安全网关（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 机器级身份验证-该术语描述了通过机器拥有和应用某种身份验证组合来验证机器身份的情况。有关更完整的定义，请参见第2节。
o User-Level Authentication - this term describes the case where the identity of a user (as opposed to that of a machine) is verified by virtue of the user's possession and application of some combination of authenticators. For a more complete definition, see section 2.
o 用户级身份验证-该术语描述了通过用户拥有和应用某种身份验证组合来验证用户身份（与机器身份相反）的情况。有关更完整的定义，请参见第2节。
o NAPT - Network Address/Port Translation
o NAPT-网络地址/端口转换
This document, while initially intended to simply outline requirements for various remote access scenarios, has come to include somewhat more than this. This document has evolved from discussion within the IPsec Remote Access (IPSRA) working group. As a result, it in some respects documents the evolution of this thought process. While this represents a departure from the typical form of a
本文档最初的目的是简单地概述各种远程访问场景的需求，但现在已经包含了更多内容。本文档由IPsec远程访问（IPSRA）工作组的讨论演变而来。因此，它在某些方面记录了这一思想过程的演变。虽然这代表着与典型的
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.
本文件的内容安排如下：首先，对基本需求类别进行了总体概述，包括与这些类别相关的定义。下面是专门介绍每个远程访问场景的一节。在每一节中，都有一些小节详细介绍了特定于该场景的以下各个领域的需求：端点身份验证、远程主机配置、策略配置、审核和中介遍历。
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) | | +---+
+-------------+ +-----------+ |---| |
| +---+
target network
|
| +---+
+-------------+ +-----------+ |---| |
|remote access| Internet | security | | +---+
| client |=============| gateway |--|
| (IRAC) | |(SGW/IRAS) | | +---+
+-------------+ +-----------+ |---| |
| +---+
In all cases, a remote client wishes to securely access resources either behind a SGW or on an IPsec-protected host, and/or wishes to provide other (specific) systems with secure access to the client's own resources. There are numerous details which may differ, depending on the particular scenario. For example, the IRAC may be within another corporate network, or connected to an ISP via dialup, DSL, or CATV media. There may be additional intermediaries between the remote client and the security gateway, but ultimately, all of these configurations may be viewed somewhat equivalently from a high level.
在所有情况下，远程客户端都希望安全地访问SGW后面或受IPsec保护的主机上的资源，和/或希望为其他（特定）系统提供对客户端自身资源的安全访问。根据具体情况，有许多细节可能会有所不同。例如，IRAC可以位于另一个公司网络内，或者通过拨号、DSL或CATV媒体连接到ISP。远程客户端和安全网关之间可能有其他中介，但最终，所有这些配置都可以从较高的层次上进行同等的查看。
In general, there are several basic categories of requirements relevant to secure remote access scenarios, including endpoint authentication, remote host configuration, security policy configuration, auditing, and intermediary traversal. Endpoint authentication refers to verification of the identities of the communication partners (e.g., the IRAC and the IRAS). Remote host configuration refers to the device configuration parameters of the IRAC system. Security policy configuration refers to IPsec policy configuration of both the security gateway and the remote host, and
通常，有几个与安全远程访问场景相关的基本需求类别，包括端点身份验证、远程主机配置、安全策略配置、审核和中介遍历。端点身份验证是指对通信伙伴（如IRAC和IRA）身份的验证。远程主机配置是指IRAC系统的设备配置参数。安全策略配置是指安全网关和远程主机的IPsec策略配置，以及
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和防火墙设备。下面将更详细地介绍这些不同的类别。
Before discussing endpoint authentication with respect to remote access, it is important to distinguish between data source authentication and end user authentication. Data source authentication in the IPsec context consists in providing assurance that a network packet originates from a specific endpoint, typically a user, host, or application. IPsec offers mechanisms for this via AH or ESP. End user authentication within the IPsec context consists in providing assurance that the endpoint is what or who it claims to be. IPsec currently offers mechanisms for this as part of IKE [IKE].
在讨论远程访问的端点身份验证之前，区分数据源身份验证和最终用户身份验证是很重要的。IPsec上下文中的数据源身份验证包括提供网络数据包来自特定端点（通常是用户、主机或应用程序）的保证。IPsec通过AH或ESP提供了实现这一点的机制。IPsec上下文中的最终用户身份验证包括确保端点是它所声称的或它所声称的人。IPsec目前作为IKE[IKE]的一部分为此提供了机制。
While the two types of authentication differ, they are not unrelated. In fact, data source authentication relies upon endpoint authentication, because it is possible to inject packets with a particular IP address into the Internet from many arbitrary locations. In many instances, we cannot be certain that a packet actually originates from a particular host, or even from the network upon which that host resides. To resolve this, one must first authenticate the particular endpoint somehow, and then bind the addressing information (e.g., IP address, protocol, port) of this endpoint into the trust relationship established by the authentication process.
虽然这两种类型的身份验证不同，但它们并非无关。事实上，数据源身份验证依赖于端点身份验证，因为可以从许多任意位置向Internet注入具有特定IP地址的数据包。在许多情况下，我们无法确定数据包是否确实来自某个特定的主机，或者甚至来自该主机所在的网络。要解决此问题，必须首先以某种方式对特定端点进行身份验证，然后将此端点的寻址信息（例如，IP地址、协议、端口）绑定到身份验证过程建立的信任关系中。
In the context of secure remote access, the authenticated entity may be a machine, a user (application), or both. The authentication methods currently supported by IPsec range from preshared secrets to various signature and encryption schemes employing private keys and their corresponding public key certificates. These mechanisms may be used to authenticate the end user alone, the device alone, or both the end user and the device. These are each discussed in more detail below.
在安全远程访问的上下文中，认证实体可以是机器、用户（应用程序）或两者。IPsec目前支持的身份验证方法从预共享秘密到使用私钥及其相应公钥证书的各种签名和加密方案。这些机制可用于单独认证最终用户、单独认证设备或同时认证最终用户和设备。下面将详细讨论每一个问题。
In the case where no user input is required in order for an authentication credential to be used, the entity authenticated will primarily be the device in which the credential is stored and the level of derived assurance regarding this authentication is directly related to how securely the machine's credential is maintained during both storage and use. That is, a shared secret or a private key corresponding to a public key certificate may be either stored within the device or contained in another device which is securely accessible by the device (e.g., a smartcard). If the knowledge required for the use of such authentication credentials is entirely contained within the subject device (i.e., no user input is required), then it is problematic to state that such credential usage authenticates anything other than the subject device.
在无需用户输入即可使用身份验证凭据的情况下，经过身份验证的实体主要是存储凭证的设备，有关此身份验证的衍生保证级别直接关系到在存储和使用期间维护机器凭证的安全性。也就是说，与公钥证书相对应的共享密钥或私钥可以存储在设备内，或者包含在设备可安全访问的另一设备中（例如，智能卡）。如果使用此类认证凭证所需的知识完全包含在主体设备内（即，不需要用户输入），则说明此类凭证使用认证除主体设备以外的任何内容是有问题的。
In some cases, a user may be required to satisfy certain criteria prior to being given access to stored credentials. In such cases, the level of user authentication provided by the use of such credentials is somewhat difficult to derive. If sufficiently strong access controls exist for the system housing the credential, then there may be a strong binding between the authorized system user and the credential. However, at the time the credential is presented, the IRAS itself has no such assurance. That is, the IRAS in isolation may have some level of assurance that a particular device (the one in which the credential resides) is the one from which access is being attempted, but there is no explicit assurance regarding the identity of the user of the system. In order for the IRAS to derive additional assurance regarding the user identity, an additional user credential of some sort would be required. This is discussed further below.
在某些情况下，在授予用户访问存储凭据的权限之前，可能需要用户满足某些标准。在这种情况下，通过使用此类凭证提供的用户身份验证级别有些难以推导。如果对容纳凭证的系统存在足够强的访问控制，则授权系统用户和凭证之间可能存在强绑定。然而，在出示凭证时，IRAS本身没有这样的保证。也就是说，隔离的ira可能具有某种程度的保证，即特定设备（凭证所在的设备）是尝试从中访问的设备，但是没有关于系统用户身份的明确保证。为了使IRA获得关于用户身份的额外保证，需要某种类型的额外用户凭证。这将在下文进一步讨论。
In some cases, the user may possess an authentication token (preshared key, private key, passphrase, etc.), and may provide this or some derivative of this whenever authentication is required. If this token or derivative is delivered directly to the other endpoint without modification by the IRAC system, and if the IRAC system provides no further credentials of its own, then it is the user alone which has been authenticated. That is, while there may be some assurance as to the network address from which the user is originating packets, there is no assurance as to the particular machine from which the user is attempting access.
在某些情况下，用户可以拥有认证令牌（预共享密钥、私钥、密码短语等），并且可以在需要认证时提供该令牌或其衍生产品。如果该令牌或衍生物直接交付给另一个端点，而IRAC系统未进行修改，并且IRAC系统未提供其自身的进一步凭证，则只有用户已通过身份验证。也就是说，虽然可以对用户从中发起数据包的网络地址有一些保证，但对用户试图从中访问的特定机器没有保证。
To authenticate both the user and the system, user input of some sort is required in addition to a credential which is securely stored upon the device. In some cases, such user input may be used in order to "complete" the credential stored on the device (e.g., a private key is password-encrypted), while in others the user's input is supplied independently of the stored credential. In the case where the passphrase is applied to the credential prior to use, the level of assurance derived from successful application of the credential varies according to your viewpoint.
为了对用户和系统进行身份验证，除了安全存储在设备上的凭证之外，还需要某种类型的用户输入。在某些情况下，可以使用这样的用户输入来“完成”存储在设备上的凭证（例如，私钥被密码加密），而在另一些情况下，用户输入是独立于存储的凭证提供的。如果在使用前将密码短语应用于凭证，则成功应用凭证所产生的保证级别会根据您的观点而有所不同。
From the perspective of a system consisting of user, IRAC, IRAS, and a collection of system protections and security procedures, it may be said that the user has been authenticated to an extent which depends upon the strength of the security procedures and system protections which are in place. However, from the perspective of the IRAS alone, there is little assurance with respect to user identity. That is, schemes requiring that stored credentials be modified by user input prior to use may only be said to provide user-level authentication within the context of the larger system, and then, the level of assurance derived is directly proportional to the weakest security attribute of the entire system.
从由用户、IRAC、IRAS和一系列系统保护和安全程序组成的系统的角度来看，可以说用户已经过认证，认证程度取决于现有安全程序和系统保护的强度。然而，仅从IRA的角度来看，用户身份几乎没有保证。也就是说，要求在使用之前通过用户输入修改存储的凭证的方案只能说是在更大系统的上下文中提供用户级认证，然后，导出的保证级别与整个系统的最弱安全属性成正比。
When considering remote access from a general perspective, assumptions regarding the overall system are liable to prove incorrect. This is because the IRAS and the IRAC may not be within the same domain of control; extranet scenarios are a good example of this. Hence, the most desirable joint user/machine authentication mechanisms in this context are those which provide a high level of assurance to both the IRAS and the IRAC, independently of the larger system of which the user, IRAS, and IRAC are a part.
当从一般角度考虑远程访问时，有关整个系统的假设可能被证明是错误的。这是因为IRA和IRAC可能不在同一控制范围内；外部网场景就是一个很好的例子。因此，在此上下文中最理想的联合用户/机器认证机制是那些为IRAS和IRAC提供高水平保证的机制，独立于用户、IRAS和IRAC所属的较大系统。
In the general case for remote access, authentication requirements are typically asymmetric. From the IRAC's perspective, it is important to ensure that the IRAS at the other end of the connection is indeed what it seems to be, and not some rogue system masquerading as the SGW. That is, the IRAC requires machine-level authentication for the IRAS. This is fairly straightforward, given the authentication mechanisms supported by IKE and IPsec. Further, this sort of authentication tends to persist through time, although the extent of this persistence depends upon the mechanism chosen.
在远程访问的一般情况下，身份验证要求通常是不对称的。从IRAC的角度来看，重要的是确保连接另一端的IRA确实是它看起来的样子，而不是伪装成SGW的流氓系统。也就是说，IRAC要求对IRA进行机器级身份验证。考虑到IKE和IPsec支持的身份验证机制，这是相当简单的。此外，这种身份验证往往会持续一段时间，尽管这种持续性的程度取决于所选择的机制。
While machine-level authentication for the IRAS is sufficient, this is not the case for the IRAC. Here, it is often important to know that the entity at the other end of the connection is one who is
虽然IRA的机器级身份验证已足够，但IRAC的情况并非如此。在这里，了解连接另一端的实体是
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系统上存在特洛伊木马应用程序的可能性，因此通常建议使用一次性密码短语机制。选择能够提供可接受的风险水平但不会让用户太烦恼的密码短语机制和更新间隔可能是一项挑战。显然，在许多情况下，即使是这种方法也只能提供有限的保证。
Clearly, there are variable assurance levels which are attainable with the various endpoint authentication techniques, and none of the techniques discussed offer absolute assurance. Also, there are variations in the authentication requirements among different remote access scenarios. This means there is no "cookie cutter" solution for this problem, and that individual scenarios must be carefully examined in order to derive specific requirements for each. These are examined on a case by case basis below in the detailed scenario descriptions.
显然，各种端点身份验证技术都可以达到不同的保证级别，并且讨论的技术都不能提供绝对的保证。此外，在不同的远程访问场景中，身份验证要求也有所不同。这意味着这个问题没有“曲奇饼”解决方案，必须仔细检查各个场景，以便为每个场景导出特定的需求。这些将在下面的详细场景描述中逐一进行检查。
There are a number of currently deployed remote access mechanisms which were installed prior to the deployment of IPsec. Typically, these are dialup systems which rely upon RADIUS for user authentication and accounting, but there are other mechanisms as well. An ideal IPsec remote access solution might utilize the components of the underlying framework without modification. Inasmuch as this is possible, this should be a goal. However, there may be cases where this simply cannot be accomplished, due to security and/or other considerations. In such cases, the IPsec remote access framework should be designed to accommodate migration from these mechanisms as painlessly as is possible.
在部署IPsec之前安装了许多当前部署的远程访问机制。通常，这些拨号系统依赖RADIUS进行用户身份验证和记帐，但也有其他机制。理想的IPsec远程访问解决方案可以不经修改地利用底层框架的组件。只要这是可能的，这应该是一个目标。然而，在某些情况下，由于安全和/或其他考虑，这可能根本无法实现。在这种情况下，IPsec远程访问框架的设计应尽可能轻松地适应这些机制的迁移。
In general, proposed IPsec remote access mechanisms should meet the following goals:
通常，提议的IPsec远程访问机制应满足以下目标：
o should provide direct support for legacy user authentication and accounting systems such as RADIUS
o 应直接支持传统用户身份验证和记帐系统，如RADIUS
o should encourage migration from existing low-entropy password-based systems to more secure authentication systems
o 应鼓励从现有的基于低熵密码的系统迁移到更安全的身份验证系统
o if legacy user authentication support cannot be provided without some sort of migration, the impact of such migration should be minimized
o 如果在没有某种迁移的情况下无法提供遗留用户身份验证支持，则应将此类迁移的影响降至最低
o user authentication information must be protected against eavesdropping and replay (including the user identity)
o 必须保护用户身份验证信息免受窃听和重播（包括用户身份）
o single sign-on capability should be provided in configurations employing load-balancing and/or redundancy
o 应在采用负载平衡和/或冗余的配置中提供单点登录功能
o n-factor authentication mechanisms should be supported
o 应支持n因素身份验证机制
Remote host configuration refers to the network-related device configuration of the client system. This configuration may be fixed or dynamic. It may be completely provided by the administrator of the network upon which the remote user currently resides (e.g., the ISP), or it may be partially provided by that administrator, with the balance provided by an entity on the remote corporate network which the client is accessing. In general, this configuration may include the following:
远程主机配置是指客户端系统的网络相关设备配置。此配置可以是固定的，也可以是动态的。它可以完全由远程用户当前所在网络的管理员（例如ISP）提供，也可以部分由该管理员提供，余额由客户端正在访问的远程公司网络上的实体提供。通常，此配置可能包括以下内容：
o IP address(es) o Subnet mask(s) o Broadcast address(es) o Host name o Domain name o Time offset o Servers (e.g., SMTP, POP, WWW, DNS/NIS, LPR, syslog, WINS, NTP, etc. ) o Router(s) o Router discovery options o Static routes o MTU o Default TTL o Source routing options o IP Forwarding enable/disable o PMTU options o ARP cache timeout o X Windows options o NIS options o NetBIOS options o Vendor-specific options o (other options)
o IP地址o子网掩码o广播地址o主机名o域名o时间偏移量o服务器（如SMTP、POP、WWW、DNS/NIS、LPR、syslog、WINS、NTP等）o路由器o路由器发现选项o静态路由o MTU o默认TTL o源路由选项o IP转发启用/禁用o PMTU选项o ARP缓存超时o X Windows选项o NIS选项o NetBIOS选项o供应商特定选项o（其他选项）
Cases where such configuration is fixed are uninteresting; it is the cases where specific IRAC configuration occurs as a result of remote access with which we are concerned. For example, in some cases the IRAC may be assigned a "virtual address", giving the appearance that it resides on the target network:
这种配置是固定的，这种情况是无趣的；我们所关心的是，由于远程访问而出现特定IRAC配置的情况。例如，在某些情况下，可以为IRAC分配一个“虚拟地址”，使其看起来驻留在目标网络上：
target net
+------------------+ |
| Remote Access | +--------+ | ( ~ ~ ~ ~ ~ )
|+-------+ Client | | | | ( IRAC )
||virtual| | |security| |~~~( virtual )
|| host | |--------|gateway | | ( presence )
|| |<================>| |----| ~ ~ ~ ~ ~
|+-------+ |--------| | |
+------------------+ ^ +--------+ | +--------+
| |---| local |
IPsec tunnel | | host |
with encapsulated | +--------+
traffic inside
target net
+------------------+ |
| Remote Access | +--------+ | ( ~ ~ ~ ~ ~ )
|+-------+ Client | | | | ( IRAC )
||virtual| | |security| |~~~( virtual )
|| host | |--------|gateway | | ( presence )
|| |<================>| |----| ~ ~ ~ ~ ~
|+-------+ |--------| | |
+------------------+ ^ +--------+ | +--------+
| |---| local |
IPsec tunnel | | host |
with encapsulated | +--------+
traffic inside
In this case, the IRAC system begins with an externally routable address. An additional target network address is assigned to the IRAC, and packets containing this assigned address are encapsulated, with the outer headers containing the IRAC's routable address, and forwarded to the IRAS through the tunnel. This provides the IRAC with a virtual presence on the target network via an IPsec tunnel. Note that the IRAC now has two active addresses: the ISP-assigned address, and the VIP.
在这种情况下，IRAC系统从外部可路由地址开始。另外一个目标网络地址被分配给IRAC，包含该分配地址的数据包被封装，外部报头包含IRAC的可路由地址，并通过隧道转发给IRAS。这将通过IPsec隧道为IRAC提供目标网络上的虚拟存在。请注意，IRAC现在有两个活动地址：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服务器等，就像物理上驻留在目标网络上的动态配置主机一样。这种配置与此需求类别有关。
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系统上配置访问策略，以保护目标网络。例如，由于客户端可以访问Internet（通过其可路由地址），Internet上的其他系统也可以在一定程度上相互访问客户端。在某些情况下，可能需要阻止此Internet
access (or force it to pass through the tunnel) while the client has a tunneled connection to the target network. This is a matter of client security policy configuration.
当客户端与目标网络有隧道连接时访问（或强制它通过隧道）。这是一个客户端安全策略配置问题。
For the security gateway, it may also be desirable to dynamically adjust policies based upon the user with which a connection has been established. For example, say there are two remote users, named Alice and Bob. We wish to provide Alice with unrestricted access to the target network, while we wish to restrict Bob's access to specific segments. One way to accomplish this would be to statically assign internal "virtual" addresses to each user in a one-to-one mapping, so that each user always has the same address. Then, a particular user's access could be controlled via policies based upon the particular address. However, this does not scale well.
对于安全网关，还可能希望基于与之建立连接的用户动态调整策略。例如，假设有两个远程用户，名为Alice和Bob。我们希望为Alice提供对目标网络的无限制访问，同时我们希望限制Bob对特定网段的访问。实现这一点的一种方法是在一对一映射中静态地将内部“虚拟”地址分配给每个用户，以便每个用户始终具有相同的地址。然后，可以通过基于特定地址的策略来控制特定用户的访问。然而，这并不能很好地扩展。
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地址池（被授予所需访问权限的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.
或者，可以将任意地址分配给用户，并根据远程客户端的身份（及其分配的虚拟地址）动态更新安全网关的策略，以允许访问特定资源。在这些情况下，相关安全策略配置特定于IRA，而不是IRAC。IRA和IRAC安全策略配置都包含在该需求类别中。
Auditing is used here to refer to the collection and reporting of connection status information by the IRAS, for the purpose of maintaining the security and integrity of the IRAS protected network. For remote access, the following auditing information is useful from a security perspective:
审计是指IRAS收集和报告连接状态信息，以维护受IRAS保护网络的安全性和完整性。对于远程访问，从安全角度来看，以下审核信息非常有用：
o connection start time o connection end time
o 连接开始时间o连接结束时间
Note that the requirement for a connection-end-time attribute implies the need for a connection heartbeat mechanism of some sort so that the IRAS can accurately determine this quantity in cases where the
请注意，对连接结束时间属性的要求意味着需要某种连接心跳机制，以便IRA能够在以下情况下准确确定该数量：
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.
在某些情况下，心跳的使用可能会对连接产生负面影响。例如，如果心跳间隔很短，并且在丢失很少的心跳数据包后重置连接，则网络拥塞可能会导致不必要的连接重置。选择心跳间隔和重置阈值时应牢记这一点，并且应能够通过配置或协商调整这些数量。
Intermediary traversal is used here to refer to passing a secured data stream through an intermediary such as a firewall or NAPT device. In the case of firewalls, numerous deployed products do not recognize the IPsec protocol suite, making it difficult (sometimes impossible) to configure them to pass it through. In such cases, a mechanism is required for making the data stream appear to be of a type which the firewall is capable of managing.
中间层遍历在这里指的是通过防火墙或NAPT设备等中间层传递安全数据流。在防火墙的情况下，许多已部署的产品无法识别IPsec协议套件，因此很难（有时不可能）配置它们以使其通过。在这种情况下，需要一种机制使数据流看起来是防火墙能够管理的类型。
In the case of NAPT devices, there are a number of issues with attempting to pass an encrypted or authenticated data stream. For example, NAPT devices typically modify the source IP address and UDP/TCP port of outgoing packets, and the destination IP address and UDP/TCP port of incoming packets, and in some cases, they modify additional fields in the data portion of the packet. Such modifications render the use of the AH protocol impossible. In the case of ESP, the UDP/TCP port fields are sometimes unreadable and always unmodifiable, making meaningful translation by the NAPT device impossible. There are numerous other protocol-field combinations which suffer similarly. This requirements category is concerned with these issues.
对于NAPT设备，尝试传递加密或认证的数据流时存在许多问题。例如，NAPT设备通常修改传出数据包的源IP地址和UDP/TCP端口，以及传入数据包的目标IP地址和UDP/TCP端口，在某些情况下，它们修改数据包数据部分中的其他字段。这种修改使得AH协议的使用变得不可能。在ESP的情况下，UDP/TCP端口字段有时不可读且始终不可修改，使得NAPT设备无法进行有意义的转换。还有许多其他协议字段组合也受到类似的影响。此需求类别与这些问题有关。
There are numerous remote access scenarios possible using IPsec. This section contains a brief summary enumeration of these, followed by a subsection devoted to each which explores the various requirements in terms of the categories defined above.
使用IPsec可以实现多种远程访问方案。本节简要列举了这些要求，随后有一小节专门讨论每种要求，探讨了上述类别的各种要求。
The following scenarios are discussed:
讨论了以下场景：
o dialup/dsl/cablemodem telecommuters using their systems to access remote resources
o 拨号/dsl/cablemodem远程工作者使用其系统访问远程资源
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 extranet用户在另一家公司的网络中使用自己的系统访问他们的家庭公司网络
o extranet users using a business partner's system (located on that partner's network) to access their home corporate network
o 外部网用户使用业务合作伙伴的系统（位于该合作伙伴的网络上）访问其家庭公司网络
o remote users using a borrowed system (e.g., an airport kiosk) to access target network resources
o 远程用户使用借用的系统（如机场信息亭）访问目标网络资源
The telecommuter scenario is one of the more common remote access scenarios. The convenience and wide availability of Internet access makes this an attractive option under many circumstances. Users may access the Internet from the comfort of their homes or hotel rooms, and using this Internet connection, access the resources of a target network. In some cases, dialup accounts are used to provide the initial Internet access, while in others some type of "always-on" connection such as a DSL or CATV modem is used.
远程办公场景是更常见的远程访问场景之一。互联网接入的便利性和广泛可用性使得这在许多情况下都是一个有吸引力的选择。用户可以从舒适的家中或酒店房间访问Internet，并使用此Internet连接访问目标网络的资源。在某些情况下，拨号帐户用于提供初始Internet访问，而在其他情况下，则使用某种类型的“始终打开”连接，如DSL或CATV调制解调器。
The dialup and always-on cases are very similar, with two significant differences: address assignment mechanism and connection duration. In most dialup cases, the IRAC's IP address is dynamically assigned as part of connection setup, and with fairly high likelihood, it is different each time the IRAC connects. DSL/CATV users, on the other hand, often have static IP addresses assigned to them, although dynamic assignment is on the increase. As for connection duration, dialup remote access connections are typically short-lived, while always-on connections may maintain remote access connections for significantly longer periods of time.
拨号和常开的情况非常相似，但有两个显著的区别：地址分配机制和连接持续时间。在大多数拨号情况下，IRAC的IP地址是作为连接设置的一部分动态分配的，并且很有可能每次IRAC连接时IP地址都不同。另一方面，DSL/CATV用户通常拥有分配给他们的静态IP地址，尽管动态分配正在增加。至于连接持续时间，拨号远程访问连接通常是短暂的，而始终打开的连接可能会使远程访问连接保持更长的时间。
The general configuration in either case looks like this:
两种情况下的一般配置如下所示：
corporate net
| +----+
+-----+ +-----+ /---/ Internet +---+ |--| |
|IRAC |---|modem|------|ISP|==========|SGW|--| +----+
+-----+ +-----+ /---/ +---+ |
|
corporate net
| +----+
+-----+ +-----+ /---/ Internet +---+ |--| |
|IRAC |---|modem|------|ISP|==========|SGW|--| +----+
+-----+ +-----+ /---/ +---+ |
|
An alternative to this configuration entails placing a security gateway between the user's system and the modem, in which case this added SGW becomes the IRAC. This is currently most common in cases where DSL/CATV connections are used.
这种配置的另一种选择是在用户系统和调制解调器之间放置一个安全网关，在这种情况下，添加的SGW将成为IRAC。目前，这在使用DSL/CATV连接的情况下最为常见。
The authentication requirements of this scenario depend in part upon the general security requirements of the network to which access is to be provided. Assuming that the corporate SGW is physically secure, machine authentication for the SGW is sufficient. If this assumption regarding physical security is incorrect, it is not clear that stronger authentication for the SGW could be guaranteed, and derivation of an effective mechanism for that case is beyond the scope of this document.
此场景的身份验证要求部分取决于要提供访问的网络的一般安全要求。假设公司SGW是物理安全的，那么SGW的机器身份验证就足够了。如果关于物理安全的假设不正确，则不清楚是否可以保证对SGW进行更强的身份验证，并且为该情况推导有效机制超出了本文档的范围。
For the IRAC, there are numerous threats to the integrity of the user authentication process. Due to the open nature of common consumer operating systems, some of these threats are quite difficult to protect against. For example, it is very difficult to assert, with any level of certainty, that a single user system which permits the downloading and running of arbitrary applications from the Internet has not been compromised, and that a covert application is not monitoring and interacting with the user's data at any point in time.
对于IRAC来说，用户身份验证过程的完整性面临许多威胁。由于通用消费类操作系统的开放性，其中一些威胁很难防范。例如，很难以任何程度的确定性断言，允许从互联网下载和运行任意应用程序的单用户系统没有遭到破坏，并且隐蔽应用程序在任何时间点都没有监控用户的数据并与之交互。
However, there are 2 general threats we might realistically hope to somehow mitigate with appropriate authentication mechanisms if we can assume that the system has not been compromised in this manner. First, there is the possibility that a secure connection is established for a particular user, but that someone other than the intended user is currently using that connection. Second, there is the possibility that the user's credential (password, hardware token, etc.) has been somehow compromised, and is being used by someone other than the authorized user to gain access.
但是，如果我们可以假设系统没有以这种方式受到危害，那么我们实际上可能希望通过适当的身份验证机制以某种方式缓解两种常见的威胁。首先，存在为特定用户建立安全连接的可能性，但预期用户以外的其他人当前正在使用该连接。其次，用户的凭证（密码、硬件令牌等）可能已被某种方式泄露，并被授权用户以外的其他人用于访问。
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
缓解第二个威胁，即凭证泄露，是困难的，取决于许多因素。如果IRAC系统运行的是高度安全的操作系统，那么时变凭证可能会再次提供一些价值。在这种情况下，静态密码显然是有缺陷的，因为它可能会受到在线或离线猜测的影响，并最终被泄露——这正是我们试图缓解的威胁。但是，如果IRAC操作系统不可用
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.
解决凭证泄露问题的第二种方法需要使用基于PKI的凭证，该凭证存储在某种安全容器中，并且在操作之前需要一些用户交互（例如，智能卡）。如果此类凭证需要定期用户交互才能继续操作（例如，pin重新输入），这可能有助于限制未经授权的用户访问已连接但无人值守的系统。然而，选择一个可接受的刷新间隔是一个困难的问题，如果pin不是时变的，这将提供有限的额外保证。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
总之，以下是IRA和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 应提供对用户身份验证的支持o必须提供对用户或机器身份验证的支持o如果需要防止未经授权的连接使用，则必须提供对用户身份验证的支持。o如果为短命拨号连接提供了用户身份验证，则可能会定期续订o如果为常开连接提供了用户身份验证，则应定期续订
There are 2 possibilities for device configuration in the telecommuter scenario: either access to the target network is permitted for the native ISP-assigned address of the telecommuter's system, or the telecommuter's system is assigned a virtual address from within the target address space. In the first case, there are no device configuration requirements which are not already satisfied by the ISP. However, this case is the exception, rather than the rule.
远程工作者场景中的设备配置有两种可能：远程工作者系统的本机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
第二种情况更为常见，因为在目标上为IRAC提供虚拟存在带来了诸多好处
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需要多个或多个配置信息元素，具体取决于公司网络的拓扑复杂程度。有关完整的列表，请参见第2.2节。
To summarize, the following are the device configuration requirements for the IRAC:
总而言之，以下是IRAC的设备配置要求：
o support for a virtual IP (VIP) address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be provided o support for address assignment based upon authenticated identity MAY be provided o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.
o 可提供对虚拟IP（VIP）地址的支持o如果提供VIP支持，则应提供对上文第2.2节中列出的所有设备相关参数的支持o如果不支持认证地址分配，则可提供基于认证身份的地址分配支持o如果不支持认证地址分配，必须支持[ARCH]中描述的基于身份的动态策略更新机制。
In terms of IRAC policy configuration, the most important issue pertains to whether the IRAC has direct Internet access enabled (for browsing, etc.) while a connection to the target network exists. This is important since the fact that the IRAC has access to sites on the Internet implies that those sites have some level of reciprocal access to the IRAC. It may be desirable to completely eliminate this type of access while a tunnel is active.
就IRAC策略配置而言，最重要的问题是，当与目标网络存在连接时，IRAC是否启用了直接Internet访问（用于浏览等）。这一点很重要，因为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连接期间目标网络的策略配置。在这种情况下，在退出或进入IRAC之前，不会强制流量循环通过目标站点。这需要某种策略下载（或修改）能力，作为SA建立过程的一部分。第三种方法是为IRAC提供一个配置变量，该变量允许指定“全部隧道”或“在SA启动时阻止所有未发送到目标网络的流量”。
In terms of IRAS configuration, it may be necessary to dynamically update the security policy database (SPD) when the remote user connects. This is because transit selectors must be based upon network address parameters, but these cannot be known a priori in the remote access case. As is noted above, this may be avoided by provision of a mechanism which permits address assignment based upon authenticated identity.
就IRAS配置而言，当远程用户连接时，可能需要动态更新安全策略数据库（SPD）。这是因为传输选择器必须基于网络地址参数，但在远程访问情况下，这些参数无法预先知道。如上所述，这可以通过提供允许基于认证身份的地址分配的机制来避免。
To summarize, the following are the policy configuration requirements for the IRAS and IRAC:
总而言之，以下是IRA和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 如果不支持基于地址分配的策略更新机制，则应支持基于身份验证的地址分配。
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应能够为非目的地为提供IPsec远程访问的远程网络的流量配置“隧道所有”和/或“阻塞所有”。
o support for dynamic IRAS update of IRAC policy MAY be provided.
o 可以提供对IRAC策略的动态IRAS更新的支持。
For telecommuter sessions, session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
对于远程办公会话，必须收集会话开始/结束时间。会话结束时间的可靠推导要求IRAC以某种方式定期指示连接保持活动状态。这意味着如果IRAS通过连接从IRAC接收数据，但是在一段时间内没有发送数据的情况下，IRAC需要一种信令机制来指示连接仍在使用中。
If the address assigned by the ISP to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
如果ISP分配给IRAC系统的地址是全局可路由的，并且IRAC和IRA之间没有中间设备对数据流执行NAPT操作，则不存在其他要求。如果在数据流上执行NAPT操作，则必须提供某种机制，以便使这些修改对IPsec实现透明。
Extranets are becoming increasingly common, especially as IPsec becomes more widely deployed. In this scenario, a user from one corporation uses a local corporate system to access resources on another corporation's network. Typically, these corporations are cooperating on some level, but not to the degree that unbridled access between the two networks would be acceptable. Hence, this scenario is characterized by limited access. The general topological appearance is similar to this:
外部网越来越普遍，特别是随着IPsec的部署越来越广泛。在此场景中，来自一家公司的用户使用本地公司系统访问另一家公司网络上的资源。通常，这些公司在某种程度上进行合作，但合作程度不足以使两个网络之间的无限制访问成为可接受的。因此，该场景的特点是访问受限。一般拓扑外观与此类似：
CORP A CORP B
| |
+----+ | | +-----+
|USER|---| |--| S1 |
+----+ | +------++ ++------+ | +-----+
|---|SGW/FW||===Internet===||SGW/FW|---|
| +------++ ++------+ | +-----+
| SGW-A SGW-B |--| S2 |
| | +-----+
CORP A CORP B
| |
+----+ | | +-----+
|USER|---| |--| S1 |
+----+ | +------++ ++------+ | +-----+
|---|SGW/FW||===Internet===||SGW/FW|---|
| +------++ ++------+ | +-----+
| SGW-A SGW-B |--| S2 |
| | +-----+
This is purposely simplified in order to illustrate some basic characteristics without getting bogged down in details. At the edge of each network is a combination security gateway and firewall device. These are labeled "SGW-A" and "SGW-B". In this diagram, corporation B wishes to provide a user from corporation A with access to servers S1 and/or S2. This may be accomplished in one of several different ways:
为了说明一些基本特征而不陷入细节，本文特意对其进行了简化。在每个网络的边缘是一个安全网关和防火墙设备的组合。这些标签分别为“SGW-A”和“SGW-B”。在该图中，公司B希望向公司a的用户提供对服务器S1和/或S2的访问。这可以通过以下几种不同方式之一实现：
1) an end-to-end SA is formed from USER to S1 or S2
1) 从用户到S1或S2形成端到端SA
2) a tunnel-mode SA is formed between SGW-A and SGW-B which only permits traffic between S1/S2 and USER.
2) SGW-a和SGW-B之间形成隧道模式SA，该模式仅允许S1/S2和用户之间的通信。
3) a tunnel-mode SA is formed between USER and SGW-B which only permits traffic between S1/S2 and USER.
3) 在用户和SGW-B之间形成隧道模式SA，该模式仅允许S1/S2和用户之间的通信。
These various cases are individually discussed with respect to each requirements category below.
这些不同的情况将针对下面的每个需求类别进行单独讨论。
For the corporate extranet scenario, the authentication requirements vary slightly depending upon the manner in which the connection is accomplished. If only a particular user is permitted to access S1/S2, then user-level authentication is required. If connection types (1) or (3) are used, this may be accomplished in the same manner as it would be for a telecommuter. If connection type (2) is
对于企业外部网场景，身份验证要求根据连接完成的方式略有不同。如果只允许特定用户访问S1/S2，则需要用户级身份验证。如果使用了连接类型（1）或（3），则可以与远程工作者相同的方式实现。如果连接类型（2）为
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.
使用时，必须出现以下两种情况之一：SGW-A必须提供一些本地机制来验证用户，SGW-B必须信任此机制，或者SGW-B必须具有一些独立于SGW-A的机制来验证用户。
If access is permitted for anyone within corporation A, then machine authentication will suffice. However, this is highly unlikely. A slightly more likely situation might be one in which access is permitted to anyone within a particular organizational unit in corporation A. This case is very similar the single user access case discussed above, and essentially has the same requirements in terms of the mechanism required for SGW-A, although machine authentication might suffice if the organizational unit which is permitted access has a sufficient level of physical security. Again, this requires that corporation B trust corporation A in this regard.
如果允许公司A中的任何人访问，那么机器身份验证就足够了。然而，这是极不可能的。更可能出现的情况是允许A公司特定组织单位内的任何人访问。这种情况与上文讨论的单用户访问情况非常相似，基本上在SGW-A所需的机制方面具有相同的要求，尽管如果允许访问的组织单位具有足够的物理安全级别，机器身份验证可能就足够了。同样，这要求B公司在这方面信任A公司。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
总之，以下是IRA和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 必须提供对用户或机器身份验证的支持o应提供对用户和机器身份验证组合的支持o如果使用用户身份验证，应定期更新
It is possible that corporation B would want to assign a virtual address to USER for the duration of the connection. The only way this could be accomplished would be if USER were a tunnel endpoint (e.g., in cases (1) and (3)). It is not clear what benefits, if any, this would offer.
公司B可能希望在连接期间为用户分配一个虚拟地址。实现这一点的唯一方法是，如果用户是隧道端点（例如，在案例（1）和（3）中）。目前尚不清楚这会带来什么好处（如果有的话）。
To summarize, the following are the device configuration requirements for the IRAC:
总而言之，以下是IRAC的设备配置要求：
o support for a virtual address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be supported
o 可提供对虚拟地址的支持o如果提供VIP支持，则应支持上文第2.2节中列出的所有设备相关参数
o support for address assignment based upon authenticated identity SHOULD be supported o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.
o 应支持基于身份验证的地址分配。o如果不支持身份验证的地址分配，则必须支持[ARCH]中描述的基于身份的动态策略更新机制。
Any of the cases discussed above would present some static policy configuration requirements. Case (1) would require that SGW-A and SGW-B permit IPsec traffic to pass between USER and S1/S2. Case (3) would have similar requirements, except that the IPsec traffic would be between USER and SGW-B. Case (2) would require that the appropriate transit traffic be secured between USER and S1/S2.
上面讨论的任何情况都会提出一些静态策略配置需求。情况（1）要求SGW-A和SGW-B允许IPsec通信在用户和S1/S2之间通过。情况（3）将有类似的要求，但IPsec通信将在用户和SGW-B之间。情况（2）将要求在用户和S1/S2之间保护适当的传输通信。
None of these cases require dynamic policy configuration.
这些情况都不需要动态策略配置。
For cases (1) and (3), session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
对于案例（1）和（3），必须收集会话开始/结束时间。会话结束时间的可靠推导要求IRAC以某种方式定期指示连接保持活动状态。这意味着如果IRAS通过连接从IRAC接收数据，但是在一段时间内没有发送数据的情况下，IRAC需要一种信令机制来指示连接仍在使用中。
For case (2), the type(s) of required auditing data would depend upon whether traffic from multiple users were aggregated within a single tunnel or not. If so, the notion of individual connection start/stop times would be lost. If such measures are desired, this requires that per-user tunnels be set up between SGW-A and SGW-B, and that some sort of timeout interval be used to cause tunnel teardown when traffic does not flow for some interval of time.
对于案例（2），所需审计数据的类型将取决于来自多个用户的流量是否在单个隧道内聚合。如果是这样的话，单个连接启动/停止时间的概念将丢失。如果需要这样的措施，这就要求在SGW-A和SGW-B之间建立每个用户的隧道，并且当流量在某个时间间隔内不流动时，使用某种超时间隔来导致隧道断开。
If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
如果主机网络分配给IRAC系统的地址是全局可路由的，并且IRAC和IRA之间没有中间设备对数据流执行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套件中的协议，则必须提供某种机制，将数据流转换为
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协议，则必须在建立连接之前完成。
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-a笔记本电脑，该笔记本电脑被静态或动态分配了CORP-B地址，用户希望使用该笔记本电脑安全地访问CORP-a网络上的资源。此场景具有以下外观：
CORP A CORP B
| |
+----+ | | +--------+
|POP |---| |--| CORP-A |
+----+ | +------++ ++------+ | | laptop |
|---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ |
+----+ | SGW-A SGW-B |
|FTP |---| |
+----+ | |
CORP A CORP B
| |
+----+ | | +--------+
|POP |---| |--| CORP-A |
+----+ | +------++ ++------+ | | laptop |
|---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ |
+----+ | SGW-A SGW-B |
|FTP |---| |
+----+ | |
This is very similar to the telecommuter scenario, but it differs in several important ways. First, in this case there is often a SGW and/or firewall at the edge of CORP-B's site. Second, there may be a significantly increased risk that a long-lived connection could become accessible to someone other than the intended user.
这与远程办公情景非常相似，但在几个重要方面有所不同。首先，在这种情况下，CORP-B的站点边缘通常有一个SGW和/或防火墙。第二，长期连接可能会被预期用户以外的人访问的风险显著增加。
In most cases, the only acceptable connections from CORP-A's perspective are between the laptop and either SGW-A or the CORP-A servers the laptop wishes to access. Most of the considerations applied to the telecommuter also apply here, and user-level authentication is required to provide assurance that the user who initiated the connection is still the active user. As an added precaution, a combination of user-level and machine-level authentication may be warranted in some cases. Further, in either case this authentication should be renewed frequently.
在大多数情况下，从CORP-A的角度来看，唯一可接受的连接是笔记本电脑与SGW-A或笔记本电脑希望访问的CORP-A服务器之间的连接。适用于远程工作者的大多数注意事项也适用于此，需要用户级身份验证来确保发起连接的用户仍然是活动用户。作为额外的预防措施，在某些情况下，可以保证用户级和机器级认证的组合。此外，在任何一种情况下，都应经常更新此身份验证。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
总之，以下是IRA和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 应提供对机器身份验证的支持o必须提供对用户身份验证的支持o应提供对用户和机器身份验证组合的支持o必须定期更新用户身份验证
The device configuration requirements in this scenario are the same as for the telecommuter, i.e., the laptop may be assigned a virtual presence on the corporate network, and if so, will require full infrastructure configuration.
此场景中的设备配置要求与远程办公者相同，即笔记本电脑可能被分配到公司网络上的虚拟存在，如果是，则需要完整的基础设施配置。
To summarize, the following are the device configuration requirements for the IRAC:
总而言之，以下是IRAC的设备配置要求：
o support for a virtual address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be supported o support for address assignment based upon authenticated identity SHOULD be supported o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.
o 可提供对虚拟地址的支持o如果提供VIP支持，则应支持上文第2.2节中列出的所有设备相关参数o支持基于身份验证的地址分配o如果不支持身份验证的地址分配，必须支持[ARCH]中描述的基于身份的动态策略更新机制。
The policy configuration requirements in this scenario differ from those of the telecommuter, in that the laptop cannot be assigned a policy which requires all traffic to be forwarded to CORP-A via the tunnel. This is due to the fact that the laptop has a CORP-B address, and as such, may have traffic destined to CORP-B. If this traffic were tunneled to CORP-A, there might be no return path to CORP-B except via the laptop. On the other hand, Internet-bound traffic could be subjected to this restriction if desired, and/or all traffic other than that between CORP-A and the laptop could be blocked for the duration of the connection.
此场景中的策略配置要求不同于远程办公者的策略配置要求，因为无法为笔记本电脑分配一个策略，该策略要求通过隧道将所有流量转发给CORP-a。这是因为笔记本电脑有一个CORP-B地址，因此，可能有指向CORP-B的流量。如果该流量通过隧道传输到CORP-a，则除了通过笔记本电脑外，可能没有指向CORP-B的返回路径。另一方面，如果需要，互联网上的流量可能受到此限制，和/或除CORP-A和笔记本电脑之间的流量之外的所有流量都可能在连接期间被阻止。
IRAC
----
IRAC
----
o support for IRAS update of IRAC policy MAY be provided.
o 可提供对IRAS更新IRAC政策的支持。
o if IRAS update of IRAC policy is not supported, IRAC MAY support IRAS directives to "block-all" for non-tunneled traffic.
o 如果不支持IRAS更新IRAC策略，IRAC可能会支持IRAS指令，以“阻止所有”非隧道流量。
o IRAC SHOULD provide ability to configure for "tunnel-all" and/or "block-all" for traffic not destined for the remote network to which IPsec remote access is being provided.
o IRAC应能够为非目的地为提供IPsec远程访问的远程网络的流量配置“隧道所有”和/或“阻塞所有”。
The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
此场景中的审核要求与远程办公场景中的审核要求相同。必须收集会话开始/结束时间。会话结束时间的可靠推导要求IRAC以某种方式定期指示连接保持活动状态。这意味着如果IRAS通过连接从IRAC接收数据，但是在一段时间内没有发送数据的情况下，IRAC需要一种信令机制来指示连接仍在使用中。
If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
如果主机网络分配给IRAC系统的地址是全局可路由的，并且IRAC和IRA之间没有中间设备对数据流执行NAPT操作，则在这方面没有额外要求。如果在数据流上执行NAPT操作，则必须提供某种机制，以便使这些修改对IPsec实现透明。
If a firewall situated at the edge of the host network cannot be configured to pass protocols in the IPsec suite, then some mechanism must be provided which converts the data stream to one which the firewall may be configured to pass. If the firewall can be configured to pass IPsec protocols, then this must be accomplished prior to connection establishment.
如果位于主机网络边缘的防火墙无法配置为通过IPsec套件中的协议，则必须提供某种机制，将数据流转换为防火墙可以配置为通过的数据流。如果可以将防火墙配置为通过IPsec协议，则必须在建立连接之前完成。
This is very similar to the extranet laptop scenario discussed above, except that a higher degree of trust for CORP-B is required by CORP-A. This scenario has the following appearance:
这与上面讨论的外联网笔记本电脑场景非常相似，只是CORP-a要求对CORP-B具有更高的信任度。此场景具有以下外观：
CORP A CORP B
| |
+----+ | | +--------+
|POP |---| |--| CORP-B |
+----+ | +------++ ++------+ | |desktop |
|---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ |
+----+ | SGW-A SGW-B |
|FTP |---| |
+----+ | |
CORP A CORP B
| |
+----+ | | +--------+
|POP |---| |--| CORP-B |
+----+ | +------++ ++------+ | |desktop |
|---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ |
+----+ | SGW-A SGW-B |
|FTP |---| |
+----+ | |
The authentication requirements for the desktop extranet scenario are very similar to those of the extranet laptop scenario discussed above. The primary difference lies in the authentication type which may be used, i.e., in the laptop case, CORP-A can derive some assurance that the connection is coming from one of CORP-A's systems if a securely stored machine credential is stored on and used by on the laptop. In the desktop case this is not possible, since CORP-A does not own the IRAC system.
桌面外联网场景的身份验证要求与上面讨论的外联网笔记本电脑场景的身份验证要求非常相似。主要区别在于可使用的身份验证类型，即，在笔记本电脑的情况下，如果笔记本电脑上存储并使用安全存储的机器凭证，则CORP-A可以从某种程度上保证连接来自CORP-A的一个系统。在台式机的情况下，这是不可能的，因为CORP-A不拥有IRAC系统。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
总之，以下是IRA和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必须定期更新用户身份验证
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.
此场景中的设备配置要求与膝上型电脑外联网场景中的设备配置要求相同，即桌面系统可能被分配到公司网络上的虚拟存在，如果是，则需要完整的基础设施配置。然而，考虑到A公司对B公司台式机系统的软件配置缺乏控制，这似乎不像笔记本电脑那样可能。
The policy configuration requirements are quite similar to those of the extranet laptop, except that in this scenario there is even less control over CORP-B's desktop than there would be over the laptop. This means it may not be possible to restrict traffic in any way at the desktop system.
策略配置要求与extranet笔记本电脑非常相似，只是在这种情况下，对CORP-B桌面的控制甚至比对笔记本电脑的控制更少。这意味着在桌面系统上可能无法以任何方式限制流量。
The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
此场景中的审核要求与远程办公场景中的审核要求相同。必须收集会话开始/结束时间。会话结束时间的可靠推导要求IRAC以某种方式定期指示连接保持活动状态。这意味着如果IRAS通过连接从IRAC接收数据，但是在一段时间内没有发送数据的情况下，IRAC需要一种信令机制来指示连接仍在使用中。
If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
如果主机网络分配给IRAC系统的地址是全局可路由的，并且IRAC和IRA之间没有中间设备对数据流执行NAPT操作，则在这方面没有额外要求。如果在数据流上执行NAPT操作，则必须提供某种机制，以便使这些修改对IPsec实现透明。
If a firewall situated at the edge of the host network cannot be configured to pass protocols in the IPsec suite, then some mechanism must be provided which converts the data stream to one which the firewall may be configured to pass. If the firewall can be configured to pass IPsec protocols, then this must be accomplished prior to connection establishment.
如果位于主机网络边缘的防火墙无法配置为通过IPsec套件中的协议，则必须提供某种机制，将数据流转换为防火墙可以配置为通过的数据流。如果可以将防火墙配置为通过IPsec协议，则必须在建立连接之前完成。
This scenario entails a traveling user connecting to the target network using a public system owned by someone else. A commonly cited example is an airport kiosk. This looks very similar to the extranet desktop scenario, except that in the extranet scenario, CORP-A might have a trust relationship with CORP-B, whereas in this scenario, CORP-A may not trust a publicly accessible system. Note that a trust relationship between CORP-A and the owner of the public system may exist, but in many cases will not.
此场景要求旅行用户使用其他人拥有的公共系统连接到目标网络。一个经常被引用的例子是机场信息亭。这看起来与extranet桌面场景非常相似，只是在extranet场景中，CORP-A可能与CORP-B存在信任关系，而在此场景中，CORP-A可能不信任可公开访问的系统。请注意，CORP-a和公共系统所有者之间可能存在信任关系，但在许多情况下不会。
There are two variations to this scenario. In the first, no trust relationship exists between the target network and the borrowed system. In the second, some trust relationship does exist. In the case where no trust relationship exists, machine authentication is out of the question, as it is meaningless in this context. Further, since such a system could easily capture a passphrase, use of a static passphrase from such a system would seem to be ill-advised.
此场景有两种变体。在第一种情况下，目标网络和借用系统之间不存在信任关系。在第二种情况下，确实存在一些信任关系。在不存在信任关系的情况下，机器身份验证是不可能的，因为在这种情况下它是没有意义的。此外，由于这样一个系统可以很容易地捕获密码短语，因此使用来自这样一个系统的静态密码短语似乎是不明智的。
If a one-time passphrase were used, this would mitigate the risk of passphrase capture by the public system. On the other hand, if it is acknowledged that such capture is a real threat (i.e., the system itself is malicious), then it must also be recognized that any data transmitted and received via the resulting session would not be confidential or reliable with respect to this malicious system, and that the system could not be trusted to have actually disconnected when the user walks away. This suggests that accessing non-trivial information from such a system would be imprudent.
如果使用一次性密码短语，这将降低公共系统捕获密码短语的风险。另一方面，如果确认此类捕获是真正的威胁（即，系统本身是恶意的），则还必须认识到，通过产生的会话传输和接收的任何数据对于该恶意系统来说都不是机密或可靠的，而且当用户离开时，不能相信系统实际上已经断开了连接。这表明从这样一个系统访问非琐碎的信息是不明智的。
Another possible user authentication option would be a smartcard. However, many smartcards require a pin or passphrase to "unlock" them, which requires some level of trust in the kiosk to not record the pin. Hence, this approach suffers from drawbacks similar to those of the static passphrase in this regard. The primary difference would be that the pin/passphrase could not be used alone for access in the smartcard case.
另一个可能的用户身份验证选项是智能卡。然而，许多智能卡需要pin或密码来“解锁”，这需要对信息亭有一定程度的信任才能不记录pin。因此，在这方面，这种方法存在与静态密码短语类似的缺点。主要区别在于，pin/密码短语不能单独用于智能卡机箱中的访问。
In cases where a trust relationship with the owner of the public system exists, the trust level would modulate the risk levels discussed above. For example, if a sufficient level of trust for the system owner exists, use of a static passphrase might present no more risk than if this were permitted from a system owned by the accessed target. However, the primary benefit of such a trust relationship would be derived from the ability to authenticate the machine from
在与公共系统所有者存在信任关系的情况下，信任级别将调整上述风险级别。例如，如果存在对系统所有者的足够信任级别，则使用静态密码短语的风险可能不会比从被访问目标所拥有的系统中允许使用静态密码短语的风险更大。然而，这种信任关系的主要好处将来自于从服务器对机器进行身份验证的能力
which the user is attempting access. For example, a security policy requiring that remote access only be permitted with combined user/machine authentication might be effected, with further control regarding which machines were allowed.
用户正在尝试访问的。例如，可能会实施一种安全策略，该策略要求仅允许通过组合用户/机器身份验证进行远程访问，并进一步控制允许哪些机器。
An additional issue to be dealt with in either case pertains to verification of the identity of the IRAS. If the IRAC were to be misdirected somehow, a man in the middle attack could be effected, with the obtained password being then used for malicious access to the true IRAS. Note that even a one-time password mechanism offers little protection in this case. In order to avert such an attack, the IRAC must possess some certifiable or secret knowledge of the IRAS prior to attempting to connect. Note that in the case where no trust relationship exists, this is not possible.
在这两种情况下都要处理的另一个问题涉及核查伊拉克共和国的身份。如果IRAC不知何故被误导，中间人攻击可以被执行，然后获得的密码被用于恶意访问真实的IRAS。请注意，在这种情况下，即使是一次性密码机制也不能提供什么保护。为了避免这样的攻击，IRAC必须在试图连接之前拥有一些可证明的或关于IRA的秘密信息。请注意，在不存在信任关系的情况下，这是不可能的。
To summarize, the following are the authentication requirements for the IRAS and IRAC:
总之，以下是IRA和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在接入网络和系统所有者之间存在信任关系的情况下，应支持机器身份验证。o在接入网络和系统所有者之间存在信任关系的情况下，可以将静态密码短语与IRAC系统的机器级认证结合使用。o必须频繁更新用户身份验证
None.
没有一个
None.
没有一个
The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use.
此场景中的审核要求与远程办公场景中的审核要求相同。必须收集会话开始/结束时间。会话结束时间的可靠推导要求IRAC以某种方式定期指示连接保持活动状态。这意味着如果IRAS通过连接从IRAC接收数据，但是在一段时间内没有发送数据的情况下，IRAC需要一种信令机制来指示连接仍在使用中。
If the address of the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation.
如果IRAC系统的地址是全局可路由的，并且IRAC和IRA之间没有中间设备对数据流执行NAPT操作，则在这方面没有额外要求。如果在数据流上执行NAPT操作，则必须提供某种机制，以便使这些修改对IPsec实现透明。
As we examine the various remote access scenarios, a general set of common requirements emerge. Following is a summary:
当我们检查各种远程访问场景时，出现了一组通用需求。以下为总结：
o Support for user authentication is required in almost all scenarios
o 几乎在所有场景中都需要支持用户身份验证
o Machine authentication for the IRAS is required in all scenarios
o 在所有情况下都需要对IRA进行机器身份验证
o A mechanism for providing device configuration for the IRAC is required in most scenarios. Such a mechanism must be extensible.
o 在大多数情况下，需要为IRAC提供设备配置的机制。这种机制必须是可扩展的。
o Machine authentication for IRAC is generally only useful when combined with user authentication. Combined user and machine authentication is useful in some scenarios.
o IRAC的机器身份验证通常只有在与用户身份验证结合使用时才有用。在某些情况下，用户和机器联合身份验证非常有用。
o Dynamic IRAC policy configuration is useful in several scenarios.
o 动态IRAC策略配置在几种情况下都很有用。
o Most scenarios require auditing for session start/stop times.
o 大多数场景都需要审核会话的开始/停止时间。
o An intermediary traversal mechanism may be required in any of the scenarios.
o 在任何场景中都可能需要中间遍历机制。
The topic of this document is secure remote access. Security considerations are discussed throughout the document.
本文档的主题是安全远程访问。整个文档中都讨论了安全注意事项。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RADIUS] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RADIUS]Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
The editors would like to acknowledge the many helpful comments of Sara Bitan, Steve Kent, Mark Townsley, Bernard Aboba, Mike Horn, and other members of the ipsra working group who have made helpful comments on this work.
编辑们要感谢Sara Bitan、Steve Kent、Mark Townsley、Bernard Aboba、Mike Horn和ipsra工作组的其他成员对这项工作做出的许多有益评论。
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134 USA
Scott Kelly Airespace 110 Nortech Pkwy加利福尼亚州圣何塞95134美国
Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com
Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com
Sankar Ramamoorthi Juniper Networks 1194 North Mathilda Ave Sunnyvale CA 94089-1206 USA
美国加利福尼亚州桑尼维尔北玛蒂尔达大道1194号桑卡拉玛莫尔蒂Juniper Networks 94089-1206
Phone: +1 (408) 936-2630
EMail: sankarr@juniper.net
Phone: +1 (408) 936-2630
EMail: sankarr@juniper.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。