Network Working Group S. Kelly Request for Comments: 3457 Airespace Category: Informational S. Ramamoorthi Juniper Networks January 2003 Requirements for IPsec Remote Access Scenarios Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractIPsec 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. 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 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. 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. 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. 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.
section 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 NAPT - Network Address/Port Translation
requirements document, the associated historical context should prove useful in interpreting the conclusions reached in the IPSRA working group. 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.
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. 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. 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.
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. 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.
o should encourage migration from existing low-entropy password-based systems to more secure authentication systems o if legacy user authentication support cannot be provided without some sort of migration, the impact of such migration should be minimized o user authentication information must be protected against eavesdropping and replay (including the user identity) o single sign-on capability should be provided in configurations employing load-balancing and/or redundancy o n-factor authentication mechanisms should be supported
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: 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. 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.
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. 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. 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 does not explicitly terminate the connection. Also note that the heartbeat mechanism in this case is always directed from the IRAC to the 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.
o extranet users using local corporate systems to access the remote company network of a business partner o extranet users using their own system within another company's network to access their home corporate network o extranet users using a business partner's system (located on that partner's network) to access their home corporate network o remote users using a borrowed system (e.g., an airport kiosk) to access target network resources
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. To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. 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
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. 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. To summarize, the following are the device configuration requirements for the 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.
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. To summarize, the following are the policy configuration requirements for the IRAS and IRAC: IRAS ---- o dynamic policy update mechanism based upon identity and assigned address MAY be supported. o if address assignment-based policy update mechanism is not supported, address assignment based upon authenticated identity SHOULD be supported. 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 support for dynamic IRAS update of IRAC policy MAY be provided.
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. 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. To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. 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 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.
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.
To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. 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 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.
IRAC ---- o support for IRAS update of IRAC policy MAY be provided. o if IRAS update of IRAC policy is not supported, IRAC MAY support IRAS directives to "block-all" for non-tunneled traffic. 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.
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. To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. 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
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RADIUS] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.