INTERNET-DRAFT Vipul Gupta SUN Microsystems, Inc Nov 17, 1998 Secure, Remote Access over the Internet using IPSec Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstract.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes the use of IPSec [KeAt98a-c] for secure access to protected networks by authorized users connected to the Internet. An example target scenario is a corporate employee on the road accessing resources on his company's Intranet. It addresses firewall traversal, user authentication, data confidentiality and the use of private address spaces (the latter impacts routing and name lookups). A comparison to other mechanisms such as those based on Layer-2 tunneling or session layer security, is also included. This memo draws upon several ideas from [Dora97,Mosk98] and would not have been possible without the contributions of the IETF working groups on IP Security (IPSec) and Network Address Translation (NAT). 1. Introduction: Traditionally, corporate employees have accessed their protected networks remotely by dialing into their company's modem pools. More recently, mechanisms that use the Internet (rather than the Public Switched Telephone Network (PSTN)) for their transport are gaining Gupta Secure Remote Access [Page 1] INTERNET-DRAFT Expires May 17, 1999 November 1998 popularity since they offer significant savings in infrastructure costs and toll charges along with greater flexibility. Clearly, security is an important concern in this situation. Strong cryptographic mechanisms are required to ensure that only authorized users gain access to company resources and sensitive information is hidden from eavesdroppers. Internet based remote access mechanisms must deal with several issues such as firewall traversal, tunneling, private address spaces, and access control. This note describes how IPSec may be used to address these issues. The use of IPSec is motivated by the thought of enabling "full" network access for remote users. For situations where access to specific applications is sufficient, SSL (in the form of HTTPS) due to its wide availability may provide a better alternative (see Related Work). 1.1 Related Work: An HTTPS-based approach to remote access: This approach utilizes application-specific proxies at the protected network's periphery (within the Demilitarized zone (DMZ)). The proxy (aka application gateway) replaces direct communication between a remote client and an internal server with two separate connections: (i) a client-proxy connection, and (ii) a proxy-server connection. Confidentiality and authentication requirements are met by using SSL as the underlying transport for client-proxy communication. The remote client can be an applet downloaded from the proxy host and the two may communicate using a proprietary protocol without introducing interoperability problems. The proxy-server communication uses well established protocols (such as IMAP, SMTP, HTTP, telnet, NFS) so no changes are required on the server. A major advantage of this architecture is that the near-ubiquity of Java- and SSL-capable browsers eliminates the need to carry a personal device. In this sense, this approach supports "user mobility" and not just "device mobility". A salesperson can walk up to an Internet kiosk at an airport (or a public computer in a hotel lobby) and use its browser to gain secure access to specific applications on his or her corporate network. At least one vendor already offers a commercial product based on this approach. The product offers access to e-mail and files from any Java- and HTTPS- enabled web browser. The proxy server is authenticated through SSL's certificate exchange mechanism and one-time passwords are used to authenticate the user. Due to a peculiarity in the major browsers today, this approach is vulnerable to a password/session stealing attack when used by naive users in a kiosk-style setting [Aziz98] (this is not meant as a criticism of the general HTTPS-based Gupta Secure Remote Access [Page 2] INTERNET-DRAFT Expires May 17, 1999 November 1998 approach). Note that if IPSec capable devices were to become as pervasive as HTTPS- and Java-capable devices today, it would be possible to support user mobility with "full" network access using the mechanisms described in this draft. Layer-2 Tunneling: Tunneling refers to the practice of enclosing one packet within another. This may be necessary, for example, to carry datagrams belonging to one network protocol across a network based on a different protocol. PPTP, L2F and L2TP [VHRK98] tunnel Layer-2 (link layer) PPP packets across various transport media. By leveraging PPP's multi-protocol support, they allow even non-IP traffic (e.g. IPX or Appletalk) to be carried across the Internet between a remote client and its private network. The use of L2TP across the Internet results in a rather interesting situation: Layer-3 packets (e.g. IP, IPX) are encapsulated in Layer-2 packets (PPP) which are encapsulated in Layer-4 packets (UDP) which are themselves encapsulated in IP. GRE [HLFT94] rather than L2TP seems more appropriate for this situation. With GRE, a non-IP, layer-3 packet (e.g. IPX) can be directly encapsulated within IP. This approach has the following advantages over Layer-2 tunneling: o Better bandwidth utilization. Running protocol X over PPP over UDP (as with L2TP across the Internet) is less efficient than running protocol X directly over IP (here X may be IP, IPX and so on). o Greater reliability. With layer-two tunneling, each end point maintains a PPP state machine (including timers and retransmission logic) across a `simulated serial line''. Unlike a real serial line, end points of the simulated line are often separated by large distances and/or many hops with only best effort delivery. As such, the PPP connections are prone to timeouts and frequent resets. It is worth noting that tunneling protocols (including GRE) by themselves do not directly address data security. Instead, they rely on IPSec for services such as per-packet integrity, source authentication, and confidentiality when tunneling packets through the Internet. Since an increasing number of clients are adopting TCP/IP as their native networking protocol and others (such as IPX or Appletalk) can be carried across the Internet using GRE, it is interesting to explore how far IPSec alone (compared to L2TP + IPSec) will go towards solving the remote access problem. Gupta Secure Remote Access [Page 3] INTERNET-DRAFT Expires May 17, 1999 November 1998 2. Remote Access Model: This draft focuses on the simplest, and perhaps the most common, case: a mobile host connected to the general Internet attempting to access resources within a firewall-protected network. It does not address multiple firewall traversal, especially when those firewalls belong to different administrative domains (for example, company A's employee accessing its network from inside company B's network). Allowing an untrusted foreign host to connect to a protected network raises security concerns (such as the possibility of passive snooping) beyond the scope of this draft. Some organizations provide visitors with direct network connections to the Internet. In these situations, even though a visitor is physically inside a foreign organization; from a network topology perspective, he is on the Internet outside the protected networks of his home and foreign organizations. Mechanisms described here accommodate the use of private addresses within the protected network. These addresses are not advertised to the general Internet (even when they are globally unique). Packets sent to private addresses from the Internet reach only as far as the routing backbone where they elicit an "ICMP destination unreachable" message and are dropped. Quite often, routers within the protected network are similarly unaware of external addresses. We assume that hosts within the protected network trust each other (this assumption is typical of most Intranets) and IPSec is deployed "end-to-edge", that is, IPSec protection extends from the protected network's periphery all the way to the mobile host. It is certainly possible to deploy IPSec only between the corporate network and an ISP ("edge-to-edge"). While the former requires IPSec software on the portable device, it offers some significant advantages: - End-users are able to access protected network resources irrespective of the ISP used to "get on to the Internet". Many ISPs today are members of global roaming consortia [iPass, GRIC]. Their customers can connect to the Internet from most major cities world-wide for the price of a local phone call and without having to maintain multiple ISP accounts. In order to fully realize the benefits of this development, it is imperative that a remote access scheme be independent of the user's ISP. - Corporations do not need to establish trusted relationships with ISPs; they only need to trust their own employees. A corporation may be willing to trust an ISP based in the same country but may not be willing to trust an ISP based in another country even if the two ISPs are members of a Gupta Secure Remote Access [Page 4] INTERNET-DRAFT Expires May 17, 1999 November 1998 roaming consortium. One can also think of several situations where an employee may connect to the Internet through a "provider" that has no prior agreements with the user's corporation. Examples of such internet providers include universities or temporary terminal rooms provided at academic and industry conferences. As IPSec standards mature, we expect client operating systems to bundle this functionality, greatly alleviating the challenge of deploying IPSec at the user's end. 3. Operation Details: The basic operation is illustrated in the following diagram. Detailed security considerations are presented later. I N T E R N E T | P R O T E C T E D N E T | | (a) G_e IPSec G_i (b) Remote --------> ------gateway------- ------> Internal computer (R) <------- (G) <------ host (H) connected (d) | (c) via an ISP- | assigned | address, R_e (a),(d) = This traffic is protected by an IPSec tunnel. R_e and G_e appear as src/dst for this traffic. (b),(c) = This traffic is in the clear but external address R_e does not appear either as source or destination. Figure 1: Operational overview. In Figure 1, R is an IPSec-capable remote host connected to the Internet using an ISP-assigned address R_e. G is an IPSec gateway at the boundary of the protected network such that its "external" IP address G_e is reachable from the Internet. H denotes an internal host/server with which R wishes to communicate. The remote host negotiates a tunnel-mode IPSec security association with the IPSec gateway. This may be accomplished using IKE [HaCa98] or any other means as long as it does not preclude the remote host using a dynamically assigned address. Note that a minimally-compliant IKE implementation (that only implements Main mode with Pre-shared keys for authentication in Phase I) cannot be used on a remote host with a dynamically assigned address. The IKE responder (gateway) needs to look up the initaitor's (mobile node's) pre-shared key before it can Gupta Secure Remote Access [Page 5] INTERNET-DRAFT Expires May 17, 1999 November 1998 decrypt the latter's third main mode message (fifth overall in Phase I). Since the initiator's identity is contained in the encrypted message, only its IP address is available for lookup and must be predictable. Other Phase I combinations, such as Main mode with digital signatures or Aggressive mode with pre-shared keys, are better suited for the situation at hand. Private addresses within the protected network are accommodated by: (a) Using a bi-directional IPSec tunnel between R_e and G_e so internal addresses (e.g. H) are hidden from routers on the Internet, and (b) Mapping the remote host to an "internal presence" so that routers and hosts within the protected network perceive all communication as originating from and terminating at an internal address. [Note: This part is unnecessary if external addresses are allowed within the private network and outgoing packets to these addresses are routed to G (perhaps through default routing). Applications such as NFS use IP addresses for access control and internal NFS servers may have to be reconfigured to respond to external addresses.] There are two ways to map a remote host to an "internal presence". (i) Network Address and Port Translation (NAPT) After verifying an incoming packet's source, decrypting its payload and removing the tunnel header, the IPSec gateway overwrites the source R_e with G_i. Since multiple remote hosts may be simultaneously connected to the protected network via G, additional state (e.g. UDP/TCP port information or ICMP sequence numbers) is maintained and used for demultiplexing responses returned to G_i. It is also possible to use a range of internal addresses (rather than G_i alone) for NAPT. Details of the translation process are described in [SrEg98]. (ii) Dynamically assigning an internal address to the remote host With this approach, the remote host generates traffic for the protected network using an internal address (say, R_i) as source. This traffic is Gupta Secure Remote Access [Page 6] INTERNET-DRAFT Expires May 17, 1999 November 1998 tunneled to G using IPSec. After verifying the incoming packet's source, decrypting its payload and removing the tunnel header, the IPSec gateway obtains a packet with a source address that is valid within the protected network. This packet can be forwarded to H without any address/port translation. Unlike the NAPT-based approach, this one requires a pool of internal addresses to be set aside for remote hosts. The size of this pool must be as large as the number of simultaneously supported remote users (similar to what is done for conventional PPP- based access). Within the protected network, G must advertise reachability to these addresses. Packet formats corresponding to these two approaches are shown in Appendix A and Appendix B, respectively. The first approach requires fewer infrastructure changes but NAPT can break certain applications (see Appendix C). However, early experience indicates that enough applications can be supported to make this a useful alternative. The second approach is more general but requires additional mechanisms so remote hosts can acquire temporary internal addresses and other configuration information. The "ISAKMP Configuration Method" proposed within the IPSec working group addresses this need [PeAP98]. 4. Security Considerations: Two requirements must be met to ensure that only authorized individuals can access resources on the protected network: (a) The IPSec gateway must not allow unauthorized hosts to communicate with the protected network, and more importantly, (b) Unauthorized users must not be able to exploit authorized hosts to communicate with the protected network on their behalf. Item (a) is addressed by the strong cryptographic mechanisms built into IPSec. Even if an unauthorized host spoofs the IP address of an authorized host, it would not be able to get its packets past G since IPSec authentication will fail. Addressing item (b) requires that the remote host have some firewall- like characteristics. Under no circumstances should an attacker be able to "log into" the remote host over the network. Otherwise, he or she will have also gained access to the protected network -- the Gupta Secure Remote Access [Page 7] INTERNET-DRAFT Expires May 17, 1999 November 1998 IPSec module has no way of distinguishing between packets sent by a legitimate user and those sent by an attacker logged into the remote host. As another illustration of the potential security threat, consider a remote host, X, running an HTTP server with proxying capability. When X is connected to the protected network using IPSec, a malicious user on the Internet may be able to view internal web pages by configuring X as the proxy for his or her browser. To address this and similar threats, all non-essential networking services (e.g. telnet, ftp, rlogin, rsh, nfs, bind, http server functionality) must be disabled and IP forwarding must be turned off. This process is typically OS-specific. However, on most flavors of UNIX, a network service is disabled by commenting out the corresponding line in /etc/inetd.conf and reinitializing the inetd daemon (sending it a SIGHUP signal). Certain PC operating systems do not offer this functionality to begin with. If additional precautions are desired, IP packet filtering should be enabled on the remote host to disallow potentially troublesome packets (e.g. unsolicited packets like incoming TCP SYNs) and all traffic from the remote host should be directed to the protected network. That is, communication between the remote host and the general Internet (e.g. the CNN website or the Intuit stock server) may be directed through G. This indirection is likely to have an adverse impact on performance but should strengthen security. Some situations may require exceptions to this rule, e.g. if an ISP uses DHCP for address allocation and lease renewals, the remote host must be allowed to exchange DHCP traffic directly with its DHCP server. Setting up an IPSec tunnel between the protected network and a remote host must require its authorized user to type in a password. This provision is necessary to minimize the chance of a security breach if the remote host is stolen. 5. Other Issues: In most instances, host names within the protected network would not be known to external DNS resolvers. In such a situation, the remote host must direct all DNS queries to an appropriate resolver within the protected network. The resolver's IP address may be manually configured or learned as part of the key negotiation process [PeAP98]. DNS traffic (including internal host names) will be automatically protected like any other traffic to/from the protected network. This note does not address how a remote host discovers the IPSec gateway guarding its protected network. This information may be supplied by the remote user (our testbed uses manual configuration). If the protected network does not use private addresses, the Gupta Secure Remote Access [Page 8] INTERNET-DRAFT Expires May 17, 1999 November 1998 gateway's IP address may be published through DNS [Atki97]. 6. Acknowledgments The author would like to thank Naganand Doraswamy, Gabriel Montenegro, and Pyda Srisuresh for their feedback on an early version of this document. 7. Revision History Version Date Comments ------- ---- -------- 00 Jul 17, 1998 Created initial version. 01 Nov 17, 1998 Added a reference to [Aziz98] in Section 1.1. In Section 3, added a brief discussion on the suitability of various IKE (Phase I) exchanges for the remote access problem. Added Section 7 titled "Revision History". References [Atki97] R. Atkinson, "Key Exchange Delegation Record for the DNS", RFC 2230, Nov. 1997. [Aziz98] A. Aziz, Personal communication. A writeup describing a vulnerability in the use of passwords over HTTPS is available at http://playground.sun.com/~vgupta/password-over- https-vulnerability.txt. [Dora97] N. Doraswamy, "Implementation of Virtual Private Networks (VPNs) with IP Security", Internet draft , work in progress, Mar. 1997 or its successor. [GRIC] See http://www.gric.com/. [HaCa98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", Internet draft , work in progress, Mar. 1998 or its successor. [HLFT94] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, Oct. 1994. [iPass] See http://www.ipass.com/. [KeAk98a] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", Internet draft , work in progress, Mar. 1998 or its successor. [KeAk98b] S. Kent and R. Atkinson, "IP Authentication Header", Internet draft , work in progress, Mar. 1998 or its successor. [KeAk98c] S. Kent and R. Atkinson, "IP Encapsulating Security Payload (ESP)", Internet draft , work in progress, Mar. 1998 or its successor. [Mosk98] R. G. Moskowitz "Network Address Translation issues with IPsec", Internet draft , work in progress, Feb. 1998 or its successor. [PeAP98] R. Pereira, S. Anand and B. Patel, "The ISAKMP Configuration Method", Internet draft , work in progress, Apr. 1998 or its successor. [SrEg98] P. Srisuresh and K. Egevang, "The IP Network Address Translator (NAT)", Internet draft , work in progress, Feb. 1998 or its successor. [VHRK98] A. Valencia et al., "Layer Two Tunneling Protocol (L2TP)", Internet draft , work in progress, Mar. 1998 or its successor. [YlKS97] T. Ylonen, T. Kivinen, M, Saarinen, "SSH Protocol Architecture", Internet draft work in progress, Mar. 1997 or its successor. Author's Address Vipul Gupta Sun Microsystems, Inc. 901 San Antonio Rd. Palo Alto, CA 94303 Tel: (650) 786 3614 Fax: (650) 786 6445 EMail: vipul.gupta@eng.sun.com Gupta Secure Remote Access [Page 10] INTERNET-DRAFT Expires May 17, 1999 November 1998 APPENDIX A: NAPT hides the remote host's external address ========================================================= This appendix presents the packet formats for traffic labeled (a) through (d) (Figure 1) when a NAPT-based approach is used. The diagrams assume that a single address G_i (rather than an address range) is used to hide external addresses. ESP with authentication is used to secure traffic across the Internet. For (a) and (b), the packet head is shown to the right. For (c) and (d), the packet head is shown to the left to match the flow in Figure 1. Packet format in Step (a): <------ Original IP ------->|<--IPSec-->|<--Outer-->| datagram header(s) IP header -------------------+---------+-----------+-----------+ | src=R_e | ESP | src=R_e | | dst=H | (w/ auth) | dst=G_e | -------------------+---------+-----------+-----------+ At gateway G, the IPSec module authenticates the source (the packet is dropped if authentication fails) and recovers the original datagram. <------ Original IP ------>| datagram -------------------+---------+ | src=R_e | | dst=H | -------------------+---------+ Before this datagram is injected into the protected network, the NAPT module within G overwrites the source with G_i. It also adjusts all header checksums that may be affected and stores enough state so that responses returning to G can be reverse translated and sent to the appropriate external host. For TCP and UDP packets, even the source port may be overwritten as part of the NAPT operation. Gupta Secure Remote Access [Page 11] INTERNET-DRAFT Expires May 17, 1999 November 1998 Packet format in Step (b): <------ Original IP ------>| datagram (after NAPT) -------------------+---------+ | src=G_i | | dst=H | -------------------+---------+ Host H responds as if G had initiated this communication. The response packet appears as shown below: Packet format in Step (c) <------ Response IP ------> datagram +---------+----------------- | src=H | | dst=G_i | +---------+----------------- When this response gets to G, the NAPT module performs a reverse translation [SrEg98] and the translated packet is shown below: <------ Response IP ------> datagram +---------+----------------- | src=H | | dst=R_e | +---------+----------------- As the packet is about to be forwarded out of G's interface facing the Internet, IPSec policy causes the datagram to undergo security processing. Packet format in Step (d): <--Outer-->|<--IPSec-->|<--- Response datagram ---->| IP header header(s) (after reverse NAPT) +-----------+-----------+--------+-------------------- |src=G_e | ESP | src=H | |dst=R_e | (w/ auth) | dst=R_e| +-----------+-----------+--------+-------------------- Gupta Secure Remote Access [Page 12] INTERNET-DRAFT Expires May 17, 1999 November 1998 APPENDIX B: Remote host is assigned an internal address ======================================================= We assume that the remote host R (Figure 1) is assigned (perhaps temporarily) an internal address R_i. Packets for R_i are routed to G inside the protected network. ESP with authentication is used to secure traffic across the Internet. For (a) and (b), the packet head is shown to the right. For (c) and (d), the packet head is shown to the left to match the flow in Figure 1. The remote host generates traffic for the protected network using R_i as source and tunnels it to G. Packet format in Step (a): <------ Original IP ------->|<--IPSec-->|<--Outer-->| datagram header(s) IP header -------------------+---------+-----------+-----------+ | src=R_i | ESP | src=R_e | | dst=H | (w/ auth) | dst=G_e | -------------------+---------+-----------+-----------+ At gateway G, the IPSec module processes the encapsulating headers and recovers the original datagram. The packet is dropped if IPSec is unable to authenticate the source. Otherwise, the newly recovered packet is sent on its way to H without further translation. Packet format in Step (b): <------ Original IP ------->| datagram -------------------+---------+ | src=R_i | | dst=H | -------------------+---------+ Host H responds as shown below: Packet format in Step (c) <------ Response IP ------> datagram +---------+----------------- | src=H | | dst=R_i | +---------+----------------- Gupta Secure Remote Access [Page 13] INTERNET-DRAFT Expires May 17, 1999 November 1998 As the packet is about to be forwarded out of G's interface facing the Internet, IPSec policy causes the datagram to undergo security processing. Packet format in Step (d): <--Outer-->|<--IPSec-->|<--- Response datagram ---->| IP header header(s) +-----------+-----------+--------+-------------------- |src=G_e | ESP | src=H | |dst=R_e | (w/ auth) | dst=R_i| +-----------+-----------+--------+-------------------- APPENDIX C: Limitations of the NAPT-based approach ================================================== Certain application protocols carry network address information (IP address and/or TCP/UDP port) as part of the application payload. Examples include: FTP, IRC, H.323, CUSeeMe, Real Audio, Real Video, Vxtreme/Vosiac, VDOLive, VIVOActive, True Speech, RSTP, PPTP, StreamWorks, NTT AudioLink, NTT SoftwareVision, Yamaha MIDPlug, iChat Pager, Quake, and Diablo (for a more up to date list, see http://dijon.nais.com/~nevo/masq/). Performing NAPT for such applications can get complicated. Replacing the IP address or port information in the application payload may require adjustments to the IP packet length (and TCP sequence numbers). Certain NAPT implementations go to great lengths to accommodate these applications. Others, simply let them fail silently. On multi-homed hosts, certain UDP implementations respond with a source address different from the address at which the original request was sent. In Figure 1, if H were multi-homed and had such an implementation, it could respond to an NFS mount request (a UDP message) with source address H' even if the request were sent to H. In this situation, G may be unable to carry out the reverse NAPT translation (unless it ignores the source for UDP responses) and R may not be able to use H as an NFS server. NAPT at G works well when communication between an external host (R) and an internal host (H) is initiated by the external host. Packets sent by R automatically set up the appropriate NAPT mapping Gupta Secure Remote Access [Page 14] INTERNET-DRAFT Expires May 17, 1999 November 1998 at G used to route returning packets. Supporting communication initiated by an internal host to the external mobile host (e.g. regular X window traffic) is a little tricky. If the internal host tries to address the mobile node at its external address, its packets will be dropped by internal routers that are unaware of the external IP address. If the internal host directs its communication at the NAPT host (G), the absence of a NAPT mapping will make it impossible for G to figure out which remote host should receive the packet. NAPT implementations often support explicit mappings (aka redirection rules [Reed]) as a workaround for this situation. However, establishing these mappings requires knowledge of the mobile node's external IP address and must be updated whenever the mobile node's address changes. (Note: Tunneling X-window traffic over SSH [YlKS97] is a simpler alternative for enabling X applications across an intervening NAPT host.) Gupta Secure Remote Access [Page 15]